Interface converter with FPGA board

Status
Not open for further replies.

Fritz

Member
If you want to use the MikroE-506 with the Wolfson WM8731 codec, the interface has a little problem. The WM8731 can use DSP or I2S for data output but unfortunately there is an interface problem depending on the microcontroller used.

Most of the time, the microcontrollers do not have an I2S or can only operate them in slave mode.
After doing some research on the net, I came across the TinyFPGA boards.
That would be the ideal solution for all interface problems. Program an interface with an FPGA board, e.g. from DSP to SPI or from DSP to USB. This allows you to convert the serial DSP data from the codec to SPI data and all common microcontrollers can communicate with the WM8731 codec via an FPGA interface converter.

Has anyone in the forum ever had the interface problems with an FPGA module such as B. tried to solve the TinyFPGA?

Here is an example of how the FPGA can be used: http://www.dossmatik.de/vhdl/spimaster.pdf
 
Yes, sure, the hardware can do that, and much more.

You need to write some code. (Not for 48KHz - the audiolib can already do that with a bit trickery).
Without the audiolib it's even easier .. edit a few lines in the existing I2S code and it's done.

But you have to do the same - no..MORE work, since no audio-code for SPI exists so far - with the FPGA - the only difference is the interface.
(btw, you could program a Teensy 3.2 (or maybe even a LC(<- without usb audio) ) to act as a I2S/SPI/USBAudio interface, too)

If it's for your Mikro_E - is it really good for 24BIT? How sure are you that the additional 8 bits aren't just noise?
With 16Bit, you would have to do nothing - just connect, and it should work out of the box.


https://forum.pjrc.com/threads/5227...E-506-(WM8731)?p=179186&viewfull=1#post179186
 
Last edited:
The Teensy Audio Library already supports WM8731, in both I2S master mode and I2S slave mode. There is no need for a FPGA. You can just connect the I2S signals directly to Teensy 3.2, 3.5, 3.6 or 4.0.

Usually running Teensy as the I2S master (generating the clocks) is best. This is the default way. It's the way used with the Teensy Audio Shield, so master mode (Teensy outputs MCLK, BCLK, LRCLK) is by far the most mature, most well tested & proven way. If you have the MikroE-506 board, this requires removing the crystal and soldering 1 extra wire for MCLK.

Teensy can also work in I2S slave mode (where the WM8731 creates BCLK and LRCLK), but that mode is not used very often. The code is not as mature, and it has many limitations regarding simultaneous use with other audio I/O. But slave does work on Teensy 3.x. Problems have been reported on Teensy 4.0 with slave mode, and are on my list of issues to investigate. If using Teensy 4.0, avoid this mode and plan on having Teensy 4.0 generate MCLK, BCLK, LRCLK.

WM8731 is not a good codec chip. It's performance falls far short of even 16 bits. It also has known issues with I2C communication, which we (mostly) handle automatically in the audio library by repeatedly retrying when WM8731 fails to respond properly. If you already have WM8731 chips or MikroE-506 boards boards, I can understand your desire to use them. But if you haven't purchased the hardware yet, I would urge you to reconsider choosing WM8731. Its problems have come up *many* times on this forum.
 
If you're not familiar with the Teensy Audio Library, and especially if your experience with audio on microcontrollers revolves around terrible hacks like using SPI, you're probably imagining audio is going to be difficult even to just play a file or generate simple waveforms. But in fact the Teensy Audio Library makes even quite complex audio projects very easy.

If you haven't used it yet, please do yourself a favor and check out this 31 page tutorial which covers most of the basics.

https://www.pjrc.com/store/audio_tutorial_kit.html

There's also a full 45 minute walkthrough video, where you can watch me & Alysia demo every step. If you get stuck or just want to watch how it's done without having the hardware handy, the video might be easier than reading the 31 pages.

If you don't have 45 minutes, skip forward to section 2 where we cover how to use the Design Tool to draw your audio processing system. If you're imagining hacking SPI, hopefully you can see how Teensy's audio is light years beyond that sort to tough project. You can just drag combinations of all sorts of audio processing stuff and connect their signals however you like. If you use the normal master mode I/O, you can even send audio to both I2S and USB and pins simultaneously. It's so very easy. No FPGAs and tough programming required!
 
Ths is 8 Bit music (from AMIGA) .. .[/URL]

For what it is worth, Amiga Paula chip had 4 separate 8 bit multiplying DACs each with independently controlled sampling rate and with 6 bit digital volume control for each DAC all driven by dedicated DMA. This effectively gave it dynamic range equivalent to 14 bit DAC. So this clever design by Glenn Keller (https://www.youtube.com/watch?v=fuXH2csMR8Y) was actually better than just 8 bit.
 
Last edited:
On a good day, WM8731 probably has about 14 noise-free bits too. ;)

I think you're being a little harsh on this CODEC. All codecs from reliable manufacturers can meet their datasheet specs, but rarely do in a system because it's the design of the system around it that is the problem. I use the WM8731 codec specifically because with a really good mixed-signal design around it, it gives fantastic quality and features for a pretty decent price.

The most common compliment I get for the TGA Pro is how dead silent it is.

I2C problems with the WM8731 are caused by setting the drive strength too high. Setting the drive strength and slew properly for an I2C bus on a Teensy resolves the issue.

Regarding the limited support for the WM8731 Codec in the Teensy library, I have an extended control class based on your original work here:
https://github.com/Blackaddr/BALibrary/blob/master/src/peripherals/BAAudioControlWM8731.cpp

It supports both slave and master mode quite well.
 
I also think that Wolfson codecs are generally very good. I got bunch of WM8591 (110dB DAC/102db ADC) and that is true that it requires proper mixed signal design of your board but results are very good.
 
I think you're being a little harsh on this CODEC.

Yeah, I'm personally a bit frustrated with WM8731, because it has regularly been a cause of tech support issues. I do not recall any other codec or dac having the I2C problems WM8731 has. But that's only during setup and (usually) infrequent config changes.

Still, if you watch its I2S output on an oscilloscope, it's easy to see how pointless more than 16 bits is with WM8731. The same is true for STGL5000 and many others. Even with their inputs shorted, the low 9 bits flicker randomly.
 
Y
Still, if you watch its I2S output on an oscilloscope, it's easy to see how pointless more than 16 bits is with WM8731. The same is true for STGL5000 and many others. Even with their inputs shorted, the low 9 bits flicker randomly.

That number actually sounds spot on to me. The SNR spec for the WM8731 is 90 dB on the ADC. Using the 6 dB-per-bit rule, this is 90/6 = 15 bits of usable noise-free bits in an ideal scenario. In 24-bit mode, you would expect exactly 9 bits of noise and 15 bits of usable signal as you observed.
The SGTL5000 is 85 db SNR. That is 14.1 bits of usable signal.

It's unlikely you will achieve the ideal scenario though in practice. Once you start factoring in the noise and interference coming from the rest of the system on the power/ground pins, you'll end up close to 12 ENOB (effective number of bits) if you're not being very careful about mixed-signal design.
https://en.wikipedia.org/wiki/Effective_number_of_bits

It's important to note that 24-bit audio is actually NOT intended for the ADC/DAC operation in a consumer grade audio system. It's for digital processing headroom. Using 16-bit precision, rounding errors during audio processing can start adding up if you don't keep 24-bits around, but for "transport" interfaces at the start and end of the line 16-bit is more than adequate from a noise/quantification perspective.

The purpose of a 24-bit mode on the WM8731 and similar codecs (given they are guaranteed to be nothing but noise on the lower bits) is actually to prevent you from having to do extra copies and save memory in your processor. If you need more than 16-bits internally you need to copy & convert the incoming 16-bit up to 24-bit just to get your processing headroom.

It's so much easier to just put the codec in 24-bit mode and have the data arrive exactly in the format you need. You don't care that the extra 8-bits are all noise.

I sympathize with your support issues. I've spent quite a bit of time myself on both the T3.X and T4.X debugging I2C/I2S issues. It is true that the codec is not robust to very fast edges coming from a processor with I/O designed for high speed busses when compared to some other codecs. When I realized the problems went away when I configured the I/O slew/strength properly for the low-speed protocol I was actually using, honestly that's my fault for driving it out of spec.

As processors get faster and faster capable I/O, legacy applications using low-speed busses are more likely to suddenly start having issues where rise/fall times exceed what the peripheral chips are capable of handling. I've had to debug this exact problem several times in my career. I was very disappointed it took me so long to solve the issues I was having when I've seen this several times before at work, I should have seen it sooner.

Sorry for the long-winded post, but hopefully some readers find some helpful info in it.
 
Last edited:
Still, if you watch its I2S output on an oscilloscope, it's easy to see how pointless more than 16 bits is with WM8731. The same is true for STGL5000 and many others. Even with their inputs shorted, the low 9 bits flicker randomly.
"This 9-bit flicker randomly" is only valid for broadband analysis. For all narrowband signals, this argument does not hold. There is a good reason why noise is specified as spectral density, i.e. re sqrt(Hz).
I'm not saying that the WM8731 or the SGTL5000 are useful codecs, they are cheep, that's all.
 
WM8731 Codec

Hello forum.

A question to the forum about the Wolfson WM8731 codec.

The Wolfson is connected to the I2C interface.
The ADC runs in DSP mode and brings the data to the MOSI output.
Now the question:
Can the ADC output (MOSI) be connected directly to the DAC input (MISO) in master mode so that the ADC data is sent directly to the DAC?

Thank you.
 
Hi all,

I like to start a new project for my Radioberry, the radioberry has a FPGA Cyclone CL025 and I am wondering if the Teensy4 can load the FPGA.

Perhaps someone can give some information..

Best regards,

Johan
 
Hi Paul, Kurt and Mike,

I there any change that the Teensy4 can load my FPGA Cyclone CL025 ?

Best,
Johan
 
It's been a long time since I've actually used a FPGA, and even then I've really only used Xilinx, not Altera (acquired by Intel). So please understand this is a rather generic answer, not based on actual experience with Cyclone CL025.

There are 2 ways to understand these "Can Teensy do XYZ" questions, and from only the words you've written I can not tell which way you meant.

Sometimes the question is whether a software library or example has been published, such that you could use that code with perhaps a little customization & fiddling, but get the idea is to get it working without writing much code "from scratch". In that sense, at least as far as I know, I have not seen any projects using Teensy 4 to load this type of FPGA.

Other times the question is more theoretical, whether the hardware is expected to be able to do the task, giving enough time and effort to write all the code to do so. In that sense, I do believe it should be possible to program Teensy 4 to load a FPGA. Normally the bitstreams for modern FPGA are large, so you'd probably store it on a SD card or flash chip. Most FPGAs have a well defined protocol to load the data, so you'd write code which reads the bitstream data from the media and uses Teensy's pins to implement that protocol.

Of course this is just a generic answer from experience with older Xilinx FPGAs. I haven't actually used Cyclone CL025.
 
Status
Not open for further replies.
Back
Top