Safe way to store data without dangerous dynamic memory allocation

Projects General Guidance
1

Hi there

I'm using an ADS1015 to collect some data for a project which i need a high frequency (~500Hz). I have been doing some testing and also with some help on another post realised that more than anything it was the Serial.prints which were slowing down my data rate.

I'm used to using MATLAB where for this you could just create an array, and continually modify it's size in a loop to save the data. However this is on a desktop which is unlikely to run out of RAM. When i looked into doing this on an arduino, there was conflicting advice about how to achieve this. Some people suggest dynamic allocation/ say it's fine, others try to avoid it due to issues like heap fragmentation or running out of RAM.

My question is, what is a safe way to store data such as in a buffer when you don't know how much space your going to use. The data is from analog accelerometers but i don't know how long they will be running. My hope was to be able to get the data from the accelerometer to the ADC, transfer to the arduino using I2C or SPI (if i can find an ADC which uses SPI!) then save the data to a buffer, which after the test is done, a button can be pressed which saves the data (in number format) to an SD card. the format would be similar to;

Time   X_Axis1    Y_Axis1   Z_Axis1   X_Axis2    Y_Axis2   Z_Axis2   X_Axis3    Y_Axis3   Z_Axis3

Am i thinking about this completely wrong or have the right idea and just miising the implementation.

Thanks

Ross

2

So your looking for a safe way to store an unlimited amount of data ?

3

Ross46:
My question is, what is a safe way to store data such as in a buffer when you don't know how much space your going to use.

No matter what system you use you can't store more data than the SRAM of the Arduino can accommodate.

So the simple reliable way is to allocate a large fixed-size array at compile time and put the data into that, taking care not to write beyond the limits of the array.

...R

4

not an unlimited amount of data, just an unknown amount. is there a way of creating an array that is just smaller than the amount of SRAM available? then when it gets to the end i can code in a warning message for the rider?

thanks

Ross

5

Ross46:
Hi there

Hello.

I'm using an ADS1015...

12 bit values converted to text is four characters.

i need a high frequency (~500Hz)

500 packets per second.

Time   X_Axis1    Y_Axis1   Z_Axis1   X_Axis2    Y_Axis2   Z_Axis2   X_Axis3    Y_Axis3   Z_Axis3

9 values plus the time.

That comes out to about 300,000 bits per second sent as text with appropriate delimiters.

My question is, what is a safe way to store data such as in a buffer...

Don't. Try 500000 baud. If that does not solve the problem get a Teensy.

6

Ross46:
is there a way of creating an array that is just smaller than the amount of SRAM available?

Yes.

That is what I was suggesting in Reply #2

...R

7

Hi there (<== just politeness :slight_smile: )

@ Coding Badly;

i do own a Due and was playing with the native USB port and got over 1800 Hz for albeit only 3 serial.prints but it was over twice as fast as an uno so i might just use that.

@ Robin2

Sorry, that didn't click straight away for me, i'll have a look into that

My only other question is, which would be the best way to go about this going forward? fixed size array's at compile time? or the teensy? or both!

Ross

8

For your communication purpose, a Due and a Teensy are the same: they both have native USB which allows higher speeds.

9

well i made some progress. While trawling the forums, found a line of code to increase the speed of the I2C bus.

Wire.setClock(100000);


[code]

would be the 100kHz bus speed which gave me 188Hz data rate


[code]


Wire.setClock(400000);


[code]


and this makes the bus speed 400kHz and i got 468Hz.


so the main bottleneck was the i2c bus. lets see what else i can do...

Thanks for everyones help

Ross