Speed demands of the FRDM K64F

[thijs_vandenste]

Greetings,

For a couple months I’ve been working with the K64F microcontroller for my master dissertation. (I am an electro-mechanical engineer with specialization in automation) The goal of the thesis is to create a system able to sample underwater sounds at 300 KHz (period is 3,3333 µs), check the frequencies (with RFFT) and if some criteria are met, it should write the raw data away (in a .wav file) to a SD-card. Energy consumption is an important factor as well.  Currently I am using the MCUXpresso ide for the software in the microcontroller.

The working of the code should look the following: We have several input buffers (=array of signed short integers because the output of ADC is 16 bit) with the size of the RFFT (1024, 2048 or 4096) and two bigger output buffers. When one input buffer is filled, another one should start filling. Meanwhile, the data of the first input buffer is being processed (RFFT, check if certain criteria are met and if the criteria are met, the data has to be copied to the output buffer). If the output buffer, with let’s say 10 times the size of an input buffer, is completely filled, it should also write away the data to the SD card. The timing of the samples is currently realized with the PIT, the ADC in the interrupt routine triggered by the PDB, for the RFFT I use the CMSIS library and to write away my data I use the example of the SDK (2.5).

Yet, even now, I have doubts the microcontroller can handle the speed. I have done some speed tests where I put a certain pin high at the beginning of a function and low at the end, so I can observe what the system is doing on the oscilloscope. When I time every function apart (let’s say the interrupt routine with ADC conversion, RFFT calculation and writing away are the 3 main functions), it should be able to handle everything with some extra time left. But as soon as I start putting the code together, it goes wrong.  Some things take way more time as intended. For example, clearing the PIT flag and waiting till the AD conversion is done takes about 1 µs, but reading the actual conversion value, converting it to a float32_t and writing it to one of the input buffers suddenly takes up about 1,3 µs. Resulting in an interrupt routine taking way longer than intended (2,3 µs instead of 1 µs), with only one result: the microcontroller can’t handle the speed. Because one sample should be taken every 3,33 µs. This is just one example where it goes wrong.

I could ask a lot of questions about certain problems I have/had to deal with, but mainly I have one big important question: Can my microcontroller handle the speed? If not, are there other microcontroller systems (preferably also programmable with MCUXpresse ide) with better processor speed with a good energy efficiency? And if it if should be able to handle the speed, do I need to switch to another approach to get the maximum efficiency?

Kind regards,

Thijs

[mjbcswitzerland]

Hi Thijs

the answer to your question is that it depends on the design. A bad (or incorrect) design will not be able to achieve what you need with the K64. A good design can do it quite easily, although it will not be that low power since the CPU will still be loaded at maybe 50% (and can only sleep about 50% of the time - and not in extremely low power modes) if the operation needs to run without any breaks.

The uTasker project contains a turn key solution for what you have described with a 400kHz ADC sampling with 4096 point floating point FFT with Blackmann-Harris windowing which consumes around 70% of the CPU power at 120MHz operation. (300kHz sample rate will reduce loading to around 50%).

The complete operation is simulated (including ADC, DMA, interrupts) on its simulated K64 in visual studio and the code has been proven in industrial products doing similar functions. It builds immediately on MCUXpresso (or KDS, or IAR, Keil, etc.) so can be used in most preferred IDEs. It also has .WAV storage of samples on SD card or memory stick (which is also simulated for better understanding, testing and debugging), or remote storage to FTP server, MQTT broker etc. or USB device based transfers.

The open source version of the project doesn't include all of this but if you request the professional version it is supplied free of charge (with basic support at this forum) for higher education use.

Regards

Mark

Complete K64 solutions, training and support: http://www.utasker.com/kinetis.html
Kinetis K64:
- http://www.utasker.com/kinetis/FRDM-K64F.html
- http://www.utasker.com/kinetis/TWR-K64F120M.html
- http://www.utasker.com/kinetis/TEENSY_3.5.html
- http://www.utasker.com/kinetis/Hexiwear-K64F.html

[jingpan]

Hi Thijs,

Do you mean the sample rate is 300k?

The CMSIS DSP Library contains optimised functions for Complex and Real FFT working on 32-bit floating point
data (F32). Cortex-M4 need 55538 cycles to do a 1024 point FFT.  Thus K64 running at 120M use about 0.5ms to do it, ideally. Sampling 1024 point at 300k need  3.4ms. So, I think K64 is ok.

Regards,

Jing