Hi,
we are using a tri-axial accelerometer which generated 26KByte of information in a single axis for 1 sec. so for 3 axis, it is 26K*3=78kB. we have reached a bottleneck of internal memory in the controller. I would like to know the possible ways to use external memory with faster processing capabilities. we have thought about external spi-type-based ram but that speed is not sufficient. we need to do the data acquisition, filtering, and fast Fourier transform on board itself. we are using RSL10 controller from on semi. any inputs/guidance is much appreciated.
-
Thanks,
Ashok

 

Lower your expectations on what you can do with chip designed as a radio controller system. Usually a lot of the accelerometer data is redundant and can be compressed (lossy is usually faster) for storage before processing in hunks.
It's the classic time,space, processing power trade-off.

https://besjournals.onlinelibrary.wiley.com/doi/full/10.1111/1365-2656.13164

Does the tri-axial accelerometer have buffering and preprocessing functions that can reduce the controller SRAM buffer requirements?

 

The STM32F407 MCU I use has 192kB of memory. You can also add external serial SRAM or even a microSD memory card for more storage.

 

I think the best way to deal with lack of memory is simply to step up to a processor that has what you need, not fool around with makeshift methods that let you keep using the same hardware! For instance, the Pi Pico has 264K of RAM.

 

I agree, messing around with stopgap measures will waste enormous amounts of time and compel you to lag further behind. Bite the bullet now for decidedly less pain later.

 

Do you need to sample at such a high rate? Do you need 16-bit data, or will 8-bit suffice? Can you process the data as you read it, so that you don't have to store it?

 

The hardware of the OP can be made to work IMO fairly easily by being smarter about data acquisition design instead of brute force. It's a complete radio module with limitations, not a general controller that can be easily replaced with a another GP controller.

 

I'm probably being naive here, not being a professional in these kinds of things (I'm here for the coffee) - but could you implement a multi-threaded scheme, such as what is discussed here?

http://pauguillamon.com/portfolio/c-threads-in-arm-cortex-m3/

That way, the processor could be taking in the data as fast as it can, as currently designed, dumping to SRAM; then another thread could be reading and processing the data from the "other end" and putting that transformed data into some other memory - either the on-board flash (if there is any leftover to use?) or some kind of off-board memory.

If possible, "thread 1" could do pre-processing (as already suggested - removing redundancy, filtering, etc - to reduce the amount of data stored - ie, a form of compression), and that might lessen the burden on "thread 2" as it "moved" and "processed" the data further (if needed) to migrate it from the on-board SRAM to on-board Flash or off-board SRAM/Flash.

Essentially, using the on-board SRAM as a buffer, with one thread filling it, while the other "drained" it. It would certainly complicate the software end of things, and not knowing your schedule, budget, etc - that may not be workable from a business standpoint...

Another possibility - depending on design requirements, of course - might be to take an approach some (all?) digital oscilloscopes use - that is, a fast "ring-buffer" design - with the SRAM being that buffer. One thread just dumps the data as fast as possible into the "buffer" (around and around, overwriting each revolution) - and the other thread samples that buffer as fast as it can - but no faster than what an external SRAM (or whatever is needed to be used) can store it. In a way - that's a form of compression (lossy) - but if you don't need every single triple data point from the accelerometer, that might work?

Of course - the above probably would work the same as just lowering the sampling-rate directly from the accelerometer, which could be done from a single thread, and makes all of the above moot...

See - just the coffee...

 

This isn't what you asked about, and maybe you have already fully considered it, but it might also be worth talking about the type of results you need and what kind of processing is necessary to achieve it as that will also affect the memory requirements. I'm assuming you don't need to store all of the incoming data long-term, but just buffer it long enough to do the necessary processing on it. In that case, a 2048 point FFT, for example, is going to require more memory than a 256 point FFT would. Maybe you don't need to store even close to a whole second's worth of data because you can process small chunks as you go.

What is the highest frequency you need to be able to detect in the FFT output? Can you make the accelerometer sample more slowly? If you don't need high bandwidth but your accelerometer hardware doesn't low-pass the signal before digitizing it, and aliasing is a concern (Nyquist, half the sample rate, etc.), consider keeping the sample rate high and running the samples through a decimating low pass filter before buffering them for the FFT.

Once you have samples at the lowest sample rate that supports the bandwidth you need, consider the frequency resolution you need out of the FFT. That will dictate the FFT size. If you need to detect only certain frequencies, look into the Goertzel algorithm.

Do you need to process every sample, or is it OK to process a buffer of samples, then wait a bit and do it again? If the latter, you won't need memory to buffer the samples received during processing, and your processing won't have to run real-time to keep up with every sample, just fast enough to provide updates to the results at the rate you require.

Perhaps some combination of these ideas will reduce the memory requirements enough to avoid needing to add more memory. If you can give us more information about the application, we might be able to help more.