[sdiy] Freescale Kinetis K2 Arm Cortex M4: 120MHz, FPU & I2S DAC/ADC interface

Declare Update declareupdate at gmail.com
Thu Sep 11 15:33:24 CEST 2014


Thanks for these thorough posts!

I can vouch for the teensy 3.1 dev board as well. I've implemented a quite rad reverb with it, using only internal adcs and dac. input and output were 12bit, and it sounded really great. lack of fpu makes some things tedious, but other than that it's great.

maybe a lil OT, but the stm32 nucleo boards are quite appropriate for audio. I don't know about i2s, but the f4 board has dsp and fpu and the dev boards are crazy cheap.

Chris
Sent from my iPhone

> On Sep 11, 2014, at 8:08 AM, Nantonos <nantonos at epona.net> wrote:
> 
> Hello Robin,
> 
> Wednesday, September 10, 2014, 1:59:27 PM, you wrote:
>> Mouser have a new series of 32 bit ARM microcontrollers of potential
>> interest for music DSP work
> 
> It is an interesting line of chips. Since your posting focuses on the
> entire line in the abstract, I thought perhaps some notes on
> experience with a particular example might be interesting. Mainly to
> show that these theoretical possibilities have been implemented
> practically, although the particular dev board I mention may also be
> of interest to those who don't want to start from scratch.
> 
> The one I have used is the Freescale Kinetis MK20DX256VLH7
> http://au.mouser.com/ProductDetail/Freescale-Semiconductor/MK20DX256VLH7/?qs=%2fha2pyFaduhKv%2fQEjzcGII1cyujglmEd%252bjl5FNJ66o%252b08WOYXyZssQ%3d%3d
> which comes pre-installed on the Teensy 3.1 development board
> http://www.pjrc.com/teensy/teensy31.html
> 
>> These chips have a combination of characteristics which is probably not
>> unique, but which I had not seen before:
> 
>>  32 bit ARM Cortex M4 CPU to 120MHz.
> Yes. This is a big step up from typical AVR-based boards. Teensy 3.1
> uses a 72MHz part, which is easily and without issue clocked to 96Mhz.
> 
> 
>>  I2S interface for audio ADCs and DACs.
> On Teensy 3.1, this can be used with an add-on audio codec board
> http://www.pjrc.com/store/teensy3_audio.html
> which uses a Freescale  SGTL5000. This gives stereo 16/44.1 ADC and
> stereo 16/44.1 DAC, communicating over I2C. Codec configuration uses
> I2C.
> 
> Its worth noting that although the data sheets for both the MCU and
> the codec claim that sampling rates up to 96kHz are supported, testing
> showed that when generating the I2C MCLK from the PLL (in turn driven
> by the 16Mhz crystal) only the MCLK for 44.1kHz had useable stability
> and jitter. Attempting to create an MCLK suitable for 48kHz gave huge
> variation in duty cycle
> http://forum.pjrc.com/threads/24078-Audio-For-Teensy3-What-Features-Would-You-Want?p=34650&viewfull=1#post34650
> an external I2C clock generator may be required for other rates. Or of
> course some codecs provide their own clocks.
> 
>>  DSP unit to pipeline 32 bit integer operations.
> This turns out to be really useful, when working with 16bit quantities
> (not so much for 32bit or 24bit). For example, two 16-bit operands can
> be passed in a single memory access, with a DSP instruction to
> multiply them together with saturation to the max 16bit value.
> 
> The Cortex M4 also has a memory access mode where fetches from
> contiguous memory locations are much faster for the second and all
> subsequent access in that block, compared to random access.
> 
> 
>>  Floating Point Unit, for 32 bit FP.
> The chip used on Teensy 3.1 does not have hardware FP. Looking at the
> range of Kinetis chips, few have FP; many have DSP but not FP.
> 
>>  Potentially large amounts of RAM and FLASH program memory:
>>  256kB RAM and 1MB program memory.
> Yes (again, huge change from AVR). The MK20DX256VLH7 used on Teensy 3.1
> has 64k RAM and 256K flash. The flash has 192Mbytes/s bandwidth and a
> 256byte cache. There are also 16 DMA channels.
> 
> The audio board I mentioned earlier is supported by an audio library
> (still in beta, but stabilising) which provides higher-level audio
> objects like oscillators, SVG, ADSR (actualy dAhDSR, with delay and
> hold stages) plus I2S input and I2S output objects. These are
> connected together in classic modular synth style with patchcord-like
> connector objects.
> http://www.pjrc.com/teensy/td_libs_Audio.html
> 
> Internally these use Cortex M4 DSP instructions to operate on
> 128-sample blocks which are eventually sent via I2S to the DAC
> channels.
> http://www.pjrc.com/teensy/td_libs_AudioNewObjects.html
> 
> There is also a web-based gui for designing a particular patch, which
> then exports a fairly straightforward set of library calls.
> 
>>  USB.
> Teensy 3.1 provides a USB HID interface by default but can also be
> switched to Serial, Keyboard, Mouse, or USB MIDI.
> 
>>  Internal voltage regulator and I guess low enough power consumption
>>  to not need a heatsink.
> Yes, on the Teensy 3.1 there is a small SMD heatsink just using the
> copper pad with no external heatsink. This regulates from up to 5V5
> down to 3V3. Also handy is the 5V tolerance on the MK20DX256VLH7 pins.
> So mixing with 5V external circuitry is simpler than might otherwise
> be the case.
> 
>> I think this means there is enough RAM for reverb, and that reverb
>> algorithms could be done with floating point.
> Probably. The audio library does not provide a reverb and has no FP
> but it does provide an 8-tap delay object with up to 333ms of delay at
> 16/44.1 (at which point half the RAM is used for the delay).
> 
>> I think the firmware could be programmed largely or entirely in C and/or
>> C++.  I have no experience programming for ARM CPUs, but they supply an
>> SDK, which I guess uses the GNU C/C++ compiler and GDB debugger.
> The Teensy 3.1 uses the ARM GCC toolchain, integrated into the Arduino
> development environment. Although an external editor and traditional
> makefiles can be used if desired, of course.
> 
>> The chips with 256kB RAM are LQFP-100 or LQFP-144 devices.  These have
>> up to 1MB of program memory.
> Actually no, the one on Teensy 3.1 has 256k RAM and is a 64-pin LQFP.
> 
> 
>> I don't know what the typical instruction cycle time of the Cortex M4
>> is, but if the MIPS and FLOPS is anything like the 120MHz clock
>> frequency, they would be able to do a great deal of work per audio
>> sample cycle.
> 
> The audio library I mentioned uses 128-sample blocks, which are moved
> into a 256-sample I2C queue using DMA (thus, one 128-sample half is
> being processed by the codec while DMA is accessing the other half).
> This means that all the per-sample calculations are automatic and
> interrupt-driven with low jitter, leaving the audio calculations a
> leisurely 128 /44,100 = 2.9ms to get work done on a block of samples.
> 
> If 2.9ms latency is unacceptable, of course a per-sample approach has
> to be used and the programmer is then responsible for ensuring that
> calculations never cause jitter.
> 
> -- 
> Best regards,
> Nantonos                            mailto:nantonos at epona.net
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy



More information about the Synth-diy mailing list