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

[Nantonos]

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