Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 17 of 17

Thread: Interface converter with FPGA board

  1. #1
    Junior Member
    Join Date
    Dec 2019
    Posts
    9

    Interface converter with FPGA board

    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

  2. #2
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    As all Teensy 3.x + 4.0 have full I2S I wonder why you post this here(?)

  3. #3
    Junior Member
    Join Date
    Dec 2019
    Posts
    9
    Quote Originally Posted by Frank B View Post
    As all Teensy 3.x + 4.0 have full I2S I wonder why you post this here(?)
    Can the above Teensy I2S with 24 bit and 48 kHz sample rate?

  4. #4
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    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/52276...l=1#post179186
    Last edited by Frank B; 02-27-2020 at 05:24 PM.

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,498
    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.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,498
    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!

  7. #7
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    Ths is 8 Bit music (from AMIGA) .. . yes, samples with 8 bits, 4 channels only - rough put together without filter, low samplerate and PCM(!) output.
    It will win no quality contest, but it can give you an idea how good 16 bits are

    https://www.youtube.com/watch?v=cS6E-GPM8ew

    https://www.youtube.com/watch?v=oBfHnyxdPJ0
    Last edited by Frank B; 02-27-2020 at 09:36 PM.

  8. #8
    Junior Member
    Join Date
    Feb 2020
    Posts
    4
    Quote Originally Posted by Frank B View Post
    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 by tomas; 02-27-2020 at 10:37 PM.

  9. #9
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    Quote Originally Posted by tomas View Post
    For what it is worth, Amiga Paula chip had 4 separate 8 bit multiplying DACs with 6 bit volume control for each DAC. 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.
    Ok, I read it was 8Bit pwm (no dacs). Must be wrong, then..

  10. #10
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,498
    On a good day, WM8731 probably has about 14 noise-free bits too.

  11. #11
    Junior Member
    Join Date
    Dec 2019
    Posts
    9

    Thank you for the comments and suggestions!

  12. #12
    Senior Member Blackaddr's Avatar
    Join Date
    Mar 2017
    Location
    Canada
    Posts
    256
    Quote Originally Posted by PaulStoffregen View Post
    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/BALibra...trolWM8731.cpp

    It supports both slave and master mode quite well.

  13. #13
    Junior Member
    Join Date
    Feb 2020
    Posts
    4
    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.

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,498
    Quote Originally Posted by Blackaddr View Post
    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.

  15. #15
    Senior Member Blackaddr's Avatar
    Join Date
    Mar 2017
    Location
    Canada
    Posts
    256
    Quote Originally Posted by PaulStoffregen View Post
    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 by Blackaddr; 02-29-2020 at 01:39 PM.

  16. #16
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,570
    Quote Originally Posted by PaulStoffregen View Post
    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.

  17. #17
    Junior Member
    Join Date
    Dec 2019
    Posts
    9

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •