Need RTOS for POV display + playing wav file?

[Camacho]

Hello,

I've never done any microcontroller programming, but I know my way around kicad and I did take C programming in college (back in the middle ages). For a project I wish to write some code that drives a persistence of vision display as well as plays some low-quality wave files from a flash IC. 

My question is will I need to run an RTOS to do this? Or can I do without, eg using interrupts to turn the LEDs on/off while a wav file is playing?

Also, can anyone suggest a rough minimum IC to do this? I was thinking I would order some sort of STM32 from LCSC.

Thanks!

[peter-h]

This is a vast topic but in general an RTOS makes life a lot easier. I use FreeRTOS.

OTOH if you can reasonably structure your project as a loop, plus a timer interrupt (say 1kHz) plus I/O interrupts (say for a UART, SPI, etc) then that will take less time to implement.

In your case, if I get your drift, you are reading 16 bit values out of an SPI FLASH chip, at a fixed rate say 48kHz, stuffing them into two DACs, and you want to generate one of those funny spectrum analyser patterns on an LCD. The 48kHz code is best run off a timer interrupt, and then a timer interrupt running at say 10-100Hz will pick up some recent values (you put some of the DAC samples somewhere), process them and update the LCD. That would be the simple way. The RTOS way would still use a 48kHz interrupt to do the first bit (you have to do that because audio playback must be done at exact sample timing) and you could use an RTOS task for the LCD stuff but it is hardly worth it.

If I was doing it I would use my RTOS stuff because I already have it.

Can't guess what CPU power you need. Is it .wav (which is lossless encoded and easy) or is it .mp3 (which needs decoding)?

Sorry I said LCD but you are using LEDs...

I don't think you need an RTOS.

[Camacho]

Peter, thanks for the reply.

To answer your question about the audio file type, I'm imagining 8KHz 8-bit WAV files or something like that.

Maybe I wasn't clear, but I just want to make a spinning persistence of vision display, not unlike the one in the attached image. It would be a clock that also speaks the time (not very original, I know). The display will be approximately 7x100 pixels in a circular pattern. I think that means if the motor is spinning 1000 RPM the leds would need to fire at around 100Khz.

So I assume this means there could be a 100KHz interrupt timer that runs the routine that draws 7 pixels per cycle? Or every few degrees of arm (propeller?) movement?

My concern is this routine would disrupt the audio playing, as there needs to be many pixel drawing routines executed while each audio file is played. But if there is a buffer, and the dac renders the audio independently, maybe this isn't an issue? Please forgive my naivete.

[DavidAlfa]

Cheap stm32G030, circular DMA will handle this like nothing with barely any cpu effort.
Any other stm32 with OTG USB will also work while making file/data handling much easier.

1K rpm is 16.6 revolutions per second. Let's say there're 20 leds.
100KHz/(16.6*20) will give about 300 pixel resolution, much higher than seen in that picture.

DMA can get this done much faster, easily in the MHz range.

[Camacho]

Cheap stm32G030, circular DMA will handle this like nothing with barely any cpu effort.
Any other stm32 with OTG USB will also work while making file/data handling much easier.

1K rpm is 16.6 revolutions per second. Let's say there're 20 leds.
100KHz/(16.6*20) will give about 300 pixel resolution, much higher than seen in that picture.

DMA can get this done much faster, easily in the MHz range.

David, thank you, your mention of DMA was what I was looking for.

Regarding the IC, I had assumed the STM32 was overpowered for this application. I was looking at the STM32F051 clones as they are cheap ob LCSC (although not as cheap as G030) and have a built in DAC. I also saw ATTINY1616 with DAC, which is cheaper, but no DMA. And I don't really want to get started with Arduino anyway.

Regarding the frequency, I forgot to divide by 60, so it would be more like 1.67KHz, not 100KHz. But that's neither here nor there.

[DavidAlfa]

The g030 can be found in AliExpress for 35 cents or so,

[Berni]

You better not take on a RTOS before you already know a fair bit of programming. They add complexity and might train you into some bad programing habits if you don't know how RTOSes actually work.

You can always use interrupts on MCUs to get simple multitasking functionality. This is especially effective on simpler smaller MCUs because they are not heavily pipelined and have a small number of CPU registers, this means they can jump into a interrupt handler and back out very quickly with cycle perfect precision.

Alternatively you can indeed use a DMA to move data into IO pins, but that tends to be quite complex to set up, also not all DMA controllers are made equal, some are much more smart and flexible than others.

[DavidAlfa]

DMA in stm32g0 series is very simple and easy!

[peter-h]

DMA is usable only if the FLASH memory is memory-mapped, not the more common SPI type.

What kind of display is used? LED matrix, or LCD?

OK so this is low quality audio.

In any case, the common 180MHz CPUs (like my 32F417) can do a 100kHz interrupt easily, reading FLASH (parallel or SPI) and loading a DAC.

I agree, an RTOS is unnecessary work.

[nctnico]

The worst thing to do is try to find the cheapest parts. Just get a big microcontroller with lots of IO, memory and processing speed. Also look at NXP's LPC range of ARM microcontrollers. I like these much better compared to what ST is offering. Good documentation and straightforward to use.

Playing sound is something which can be nicely done using DMA (streaming chunks of data out of an SPI flash). A built-in DAC makes life a lot easier but PWM will work just as good.

DMA is usable only if the FLASH memory is memory-mapped, not the more common SPI type.

But you can do DMA on the SPI interface. I think I have done that a long time ago.

[DavidAlfa]

It's usable anyways without ant mapping, join sdi with sdo and led buffer input, send read cmd, enable led buffer, tell the DMA to read n bytes, the SPI flash output will go straight to the leds.
I've done this to send video from SPI nand to a LCD, making a cheap video player.

[selcuk]

Operation systems for small embedded systems are not that complicated. There are many functions to learn but you can still use interrupts to turn on leds on timely basis. OS may reserve first timer interrupt then you can use the second one, etc. So there is no hard isolation between hardware and application.

Additionally, I can recommend ESP32 family of MCUs. Their IDF framework includes FreeRTOS, hardware drivers and software libraries. You may find similar projects on the internet. Check out this one for example:

https://github.com/parabuzzle/esp-idf-simple-audio-player/tree/main

[SiliconWizard]

The worst thing to do is try to find the cheapest parts. Just get a big microcontroller with lots of IO, memory and processing speed. Also look at NXP's LPC range of ARM microcontrollers. I like these much better compared to what ST is offering. Good documentation and straightforward to use.

Playing sound is something which can be nicely done using DMA (streaming chunks of data out of an SPI flash). A built-in DAC makes life a lot easier but PWM will work just as good.

DMA is usable only if the FLASH memory is memory-mapped, not the more common SPI type.

But you can do DMA on the SPI interface. I think I have done that a long time ago.

Yes, of course you can. That's just a bit more work as you need to handle the commands yourself, while QSPI controller or internal flash will do that transparently. But that's not rocket science.
The OP could also just use a QSPI flash otherwise.

Still the whole project looks a bit ambitious for someone who has never done any embedded development. The OP should probably start with something simpler. But having a motivating goal is still a good thing.
As to an appropriate MCU, there are many out there. Something cheap with ample resources for this would be the RP2040.

[Camacho]

Ok, thanks everyone for the replies. I agree with Siliconwizard - this is a bit ambitious, but I will be definitely writing some simpler programs first - probably as part of a series of tutorials or online course.

NCTNICO, thanks, using PWM sounds interesting and that would allow the use of the inexpensive STM32G030 suggested by David.

It sounds like I should just try this first with interrupts and skip the DMA if possible. And definitely no RTOS.

[peter-h]

You can do SPI via DMA but SPI FLASH devices need commands to set up the starting address etc. Also the chunks which can be sequentially read are of limited length - not usually IIRC the full device. A while since I did this...

In this case the OP is probably storing audio fragments and they can be stored in the CPU FLASH which can be read easily with DMA. It can even be reprogrammed if you make clever use of the block based erase/program options.

[DavidAlfa]

Both SPI not and nand memories can be read sequentially.

[agehall]

This reminds me of the PC demo scene back in the early 90s. We did a lot more back then with a lot less hardware than what you find in a pretty bog standard MCU these days. I don’t think there is anything that is very complicated in what you are looking to do here nor does it require an RTOS.

[Camacho]

Both SPI not and nand memories can be read sequentially.

Thanks David. I'm planning to use external 16Mbit NOR flash memory.

[Camacho]

This reminds me of the PC demo scene back in the early 90s. We did a lot more back then with a lot less hardware than what you find in a pretty bog standard MCU these days. I don’t think there is anything that is very complicated in what you are looking to do here nor does it require an RTOS.

Thanks, I will definitely skip the RTOS.

[SiliconWizard]

Both SPI not and nand memories can be read sequentially.

Thanks David. I'm planning to use external 16Mbit NOR flash memory.

If you pick a MCU with a QSPI controller, I suggest using a flash chip with a QSPI interface. These are ubiquitous now, so easy to source. The upside is that it'll allow to use the flash chip memory-mapped, and reads will be much faster. (The downside is that you'll have to set up the QSPI controller.)

[Camacho]

Both SPI not and nand memories can be read sequentially.

Thanks David. I'm planning to use external 16Mbit NOR flash memory.

If you pick a MCU with a QSPI controller, I suggest using a flash chip with a QSPI interface. These are ubiquitous now, so easy to source. The upside is that it'll allow to use the flash chip memory-mapped, and reads will be much faster. (The downside is that you'll have to set up the QSPI controller.)

Thanks, the flash chips I was looking at are "dual and quad serial" which I assume is QSPI