Sampling 2pcs IMU 6axis @ 200Hz with PIC32,STM32,or ESP32?

[mnfisher]

I would guess it's when a sector buffer (512 bytes) is full and actually gets written?

Should be possible to write in a different task - pass data in a queue to it?

Martin

[stefan.erni]

yes a string is 21*7byte +“\r\n” = 149byte
After 3times it's a problem
Yes I think the data is not so big...
I can also make a second string and alternate which one is written on the disk and which one gets new data

[mnfisher]

You can buffer up to a point - how many samples do you read before taking a breather... The esp32 has quite a lot of memory - so you can buffer a lot of samples - but if the sample rate > sd write rate - at some point you can either pause or discard samples.... Buffer as 32 bit numbers not strings?

Martin

[stefan.erni]

Hi Martin
I have modified a program and it works to send a string via uart in a separate task.
sending and pausing does not interfere with the main part
I guess I can do the same with the SD card just use then append string.
But I have a problem with the watchdog if I use less than 10mSec

2025-01-22_11-24-19.PNG (11.17 KiB) Viewed 1319 times

How Can I use this a c-code?

2025-01-22_11-18-57.PNG (3.17 KiB) Viewed 1319 times

or turn off or set different value in Menueconfig?

2025-01-22_11-18-02.PNG (266.09 KiB) Viewed 1319 times

This program works on ESP32-wroom_32

[mnfisher]

Yes - main is busy-waiting on a sample.... This might be better moved to a separate task and sending the 'sample' as a notification - see viewtopic.php?t=2548&hilit=esp32+task
I just sent a 32bit value in the demo here - but this can be extended.

I have to work a while - but I'll try and draw up a demo of this later...

Martin

[mnfisher]

Actually it is easy to do using a queue - the trick is to wait for the queue to get a message use portMAX_DELAY.

This is a simple example with two 'sensors' writing dummy data to a UART (via a task called display) Sensor 1 writes 'AAAA...' / 'BBBB...' at slightly random intervals - but if the queue is full for more than 10 ticks - it gives up and then waits 10s before writing again.

Sensor2 writes 'Pony' and 'Express' at 1s intervals - and like it's namesake - it always gets through (- it waits until there is space in the queue using portMAX_DELAY)

Note that the queue holds 10 x 10 character strings - and the data is copied when posted to the queue - so the task can start building the next data string immediately after posting.

Display also has a delay in it - this should be removed in the real world - it is not needed (waiting for data in the queue uses no CPU and acts as a context switch for multi-tasking - I added it to get the queue to fill up more quickly) If data is sent very fast (as fast as Display can cope with - I'm not sure if a delay is needed. I didn't encounter any WDT errors) It displays the string and the number of items in the queue.

A small 'gotcha' - UART::Print isn't re-entrant so only one task can print at a time - note that I print the 'title' before creating the tasks. Would need to use a semaphore or lock if multiple tasks were attempting to print.


<<< Oops - correct file to follow >>>


Martin

[stefan.erni]

Hi Martin

That sounds good. I would like to test it
but I think you posted the old program.

I managed to switch off the watchdog. I did a test, sampling the data in the main and sending it in a second task. That worked . But if I use the fileappendstring instead of send with uart, the program crahed and I have to press reset.

I have something else which makes it easier.
I use two sensors, but they are both of the same type. So I can (must) read both in the same task and save them in the same string. At the moment I am still saving in a csv file but later I will save in a wave file. I also have the option of sending an integer array to the APP and saving it there.
but I also have something that makes it more difficult. I will sample with 1Khz so all 1mSec. I suspect that will work.

2025-01-23_10-37-58.PNG (93.99 KiB) Viewed 1232 times

[mnfisher]

Sorry - that I did. It had been a long day.. I'll post my version this evening..

1kHz - for how many samples? If it's for, say 1s, then one option is to just do it and buffer them - then have a rest while they get sent to storage / UART.
Plan B - use an interrupt to read the samples - so a 1kHz timer interrupt (the code to push items to the queue is different). This needs to be quick (of course) - so would need to check if the queue is full rather than waiting?
Might need to speed up the shifting of data out too - can you send as raw data rather than strings?

Martin

[mnfisher]

The real file!

So - I modified it slightly. I changed the queue size to 100 x str[10] (Although for large data structures it would be better to pass a pointer - although this introduces other memory management issues)

I added a Sensor1kHz - which writes (dummy) data to the queue at 1kHz - when tmr is set to true. This also checks if the queue is full before attempting to write (an alternative is to attempt to write - and 'drop' the data on failure)

Main now toggles tmr - 5s off and 1s on.

I reduced (and also tested with it removed) the delay in Display...

I didn't hit any WDT issues - and all three 'sensors' happily write to the queue - enable / disable them as required.

With a 10ms delay in Display - Sensor1kHz can add ~9 new samples to the queue (note that the data copied is always 10 bytes - it is not copied as a string) between lines being printed.
With no delay - Display seems to keep up - reducing the baud rate would be another way to test the issues of data 'blocking'

Martin

[stefan.erni]

Hi Martin

Buffer as 32 bit numbers not strings?

Yes exactly i will save as a wave file. i can use 16bit integer and these wave files are easy to open with audacity or matlab. it will take a while until i have that.

But I still don't understand what you mean by display in the queue_test.fcfx