Hi all!
I'm thinking of creating a simple datalogger that prints out the characters onto a sdcard/USB device.
I would like to be able to poll data, save it in a buffer and simultaneously write it to a txt. file. If I just choose an ordinary stm32 cortex mcu and jump back and forth between the different processes eventually either the buffer (flash memory) will run out since I can't fully write as a continuous flow is coming, or I will miss data during the write to usb/sdcard section since the MCU is busy doing that.
So I tought a dual core mcu would solve this problem. One core samples data and fills the buffer, the other core writes to usb/sdcard from the buffer.
Question is, what are the best/cheapest options available?
What are you trying to log - volume of data? speed of data?
People have created plenty of "simple dataloggers" just on 8-bit processors - so an STM32 should have no trouble.
But, if you're after a dual-core micro, have you looked at the Raspberry Pi Pico?
www.raspberrypi.org/.../
I'm trying to log UART data being sent in and then printed onto sdcard/usb. I've seen those older dataloggers, in different DYI products and so on. Many are using the Atmega 328P 8bit because of the compatible Arduino IDE. However, those dataloggers and the ones you are talking about are mainly in applications with sporadic UARTmessages (no permanent stream). Because you are jumping back and forth between listening and printing, so you are bound to miss out messages while printing or the listening take precedence so the buffer fills up until its maxed and must be sent/or cleared no matter what.
Maybe a stm32 32/64MHz is enough of a boost from 328P to be able to handle logging at a "good" rate. But I'd imagine a dual core would solve any problem. That's why I'm wondering if there are some cheap dual core MCUs.
I'll take a look at the Pi Pico! It looks promising running a dual core Cortex-M0+ processor however I would've liked to buy a MCU only and not a development board because I intend to make my own PCB. But thanks!
You still haven't said how fast the UART data stream is.
Daarke1 said:Because you are jumping back and forth between listening(Uart interrupt) and printing (SPI)
Not if the software is properly structured.
Daarke1 said:I would've liked to buy a MCU only and not a development board
I think the RP2040 chip should be available to buy?
Speed is set by the user, a config(.txt) file from the sdcard/usb is read at startup (default i'm thinking (9600 8-N-1) if nothing else is set or file cant be found, since its most common). I'll imagine different senarios, sometimes maybe i just want to log a temperature stream ,so it doesn't matter if I miss out on a few samples. But if I want to log and debug a text stream coming in or sniff data it would be best to not miss out on every 3rd word or more during the writing process. So thats what the whole dual core idea is for.
I found out the chip isn't available yet to buy, but they will be on general sale in the near future. It's a bit of shame that it has not build in flash, needs external but If it becomes much cheaper than buying the entire Pi Pico that chip+memory would certainly be an ideal choice for me! Looks to be the best course of action, else I'll guess I try with a stm32 in the meantime and see how far I can press a single core MCU with either loops or task scheduling(RTOS).
At those kind of rates, there shouldn't be any problem at all.
Looking for a micro with a FIFO on its UART and/or DMA would help.
Certainly no need for an RTOS.
I've thought a lot about it, and I believe you are right. The most efficient way of doing this with a stm32 (1 core) would be to utilize DMA to reduce the number of clock cycles needed to write. I suspect this will be somewhat of a challenge, configure DMA to write to a sdcard (4gb fat32 for example) in parallel with UART gathering the characters in some buffer. In my experience the DMA overall is very complex. But that seems to be the best choice!
The easiest way is of course to poll UART (listen for an incoming message) and then send it right away to the sdcard in the same while loop. Or use interrupts and store in circular buffer and let the main loop send whenever it can. I'm just worried with interrupts that it will mess up the writing process if an incoming message happens at the same time. I'll give DMA a try before that, hopefully It can work!
Thanks for all the help, I appreciate it Andy!