MIOS32 without FreeRTOS

MIOS programming (C)
1

Hi TK,

Is there any way to use MIOS32 functions without FreeRTOS? For my upcoming MIDIbox Quad Genesis project, there’s some really precise timings on writing to the sound chips, and I need much better than 1ms resolution between tasks, plus several different ISRs which modify each others’ conditions and keep custom state information between them. (This is on the STM32F4 core of course.) 

Besides the main synth loop “background task” which I will take care of, the only other peripheral functions being done by the synth will be USB and UART MIDI, SPI for the SD card, and SPI for the front panel DIO matrix. The latter can have its timing interrupted at any point with no problem; but I’m a little concerned about the other two. Where among these is DMA used? Can I set up their DMA Complete interrupts to be lower priority than the sound-chip-write interrupts? How often do I have to service USB MIDI DMA Complete interrupts for the communication not to get messed up?

Basically, I know how to do each of these things individually in an embedded system, I want to know what parts I have to cut out of MIOS32 to get more complete control of them. Do you have any information for how to set these things up in a MIOS32 app? A lot of #MIOS32_DONT_USE_WHATEVERs?

Thanks,

Sauraen

2

See this architectural overview which shows, how MIOS32 apps are structured: http://www.ucapps.de/mios32/mios32_flowchart.png

The brown blocks are FreeRTOS related.
The good news: none of them is located in trunk/mios32, but under programming_models/traditional
Which means in other words: all you need to do is to create your own programming model w/o FreeRTOS, the “traditional” version can be taken as a reference.
Alternatively, if you don’t consider to share this model in different applications, you could locate main() and the a timer based task handling directly in your app.c file.

Best Regards, Thorsten.

3

Disclaimer: my experience is mostly on MIPS. I’m sure TK already knows all this, too :slight_smile:

FreeRTOS is an embedded OS. These aren’t OSes in the same sense as a desktop machine. If you think of it as a multitasking library, you’ll be closer to the truth - it doesn’t really handle interrupts, it has no real concept of DMA transfers. You don’t need to take FreeRTOS out to regain control, because it doesn’t really have it in the first place. You can put high performance control code in place, and leave FreeRTOS to deal with the low priority stuff.

4

Actually you are right. If we ignore the initial question about the usage of MIOS32 w/o FreeRTOS the answer is simple:

interrupt priorities are centrally defined in mios32_irq.h, and I also commented the reason for certain priority decisions there: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Finclude%2Fmios32%2Fmios32_irq.h

Since Saureans application relies on UART based MIDI, it has to be ensured that the UART handler has such a high priority, that incoming bytes can’t get lost.
If time critical ISRs never consume more than ca. 500 uS in worst case, even if they are requested back-to-back, they could just run with superhigh priority (priority value < MIOS32_IRQ_PRIO_HIGHEST, e.g. 3) to fulfill the requirements w/o any changes in MIOS32 or the programming model.

Best Regards, Thorsten.

5

Thank you for the input, sorry for not getting back to this sooner.

I was under the impression that using FreeRTOS meant:

  • Tasks run for a fixed 1ms each and are automatically switched, the only way to temporarily disable this being to disable global interrupts
  • Only one ISR exists in the system, it’s for the 1ms timer used by the OS, no other ISRs can be enabled or the OS will break

Is this not correct?

Why aren’t incoming UART bytes buffered in any way? Why aren’t they saved to RAM using DMA? Yes, there would be a small latency (<1ms) but this means bytes would never be lost (unless there was a buffer overrun).

In MIDIbox FM V2.0/V2.1 the 1ms task switching is plenty fast, as there’s no reason the OPL3s would have to be updated faster than this. But in MIDIbox Quad Genesis, there’s a mode in the OPN2 where sampled audio is played back on the sound chip, and the CPU has to write each sample one-by-one with no buffering. So there has to be an interrupt at 44.1kHz which cannot get delayed by more than 10us or so. Also, this interrupt will have to be able to play samples on four OPN2s at once–I think I can get the timing code right, but this has to be absolutely highest priority.

I read over the STM32F4 DMA application note, it’s pretty confusing, but it does look like DMA channels can be set up to handle receiving UART bytes.

Is there any other peripheral that needs extremely fast service? How about USB MIDI? I know very little about USB packets, but I’m assuming they go in some sort of buffer. The SPI interface to the SD card isn’t time-critical, right?

6
  • Only one ISR exists in the system, it’s for the 1ms timer used by the OS, no other ISRs can be enabled or the OS will break

Is this not correct?

No, this isn’t correct. In MIOS32, many other interrupts are running.
Also MIOS32_TIMER based app callbacks are called from interrupts with a much shorter interval if required.

Why aren’t incoming UART bytes buffered in any way? Why aren’t they saved to RAM using DMA? Yes, there would be a small latency (<1ms) but this means bytes would never be lost (unless there was a buffer overrun).

I’ve use cases in my own applications where I have to handle incoming bytes immediately.
E.g. MIDI clock in slave mode requires that processes are (immediately) clocked with each incoming 0xf8, and/or that delays are measured between the 0xf8 events to avoid unwanted jitter.

But in MIDIbox Quad Genesis, there’s a mode in the OPN2 where sampled audio is played back on the sound chip, and the CPU has to write each sample one-by-one with no buffering. So there has to be an interrupt at 44.1kHz which cannot get delayed by more than 10us or so. Also, this interrupt will have to be able to play samples on four OPN2s at once–I think I can get the timing code right, but this has to be absolutely highest priority.

have a look into the MBCV V2 application where I’m running high prio synth processing with a MIOS32_TIMER

 I read over the STM32F4 DMA application note, it’s pretty confusing, but it does look like DMA channels can be set up to handle receiving UART bytes.

I don’t think that you need this - it would especially conflict with my own applications, so it would be a dedicated modification at your side, which isn’t required if your ISR meets the requirements that I mentioned above.
So, I ask you again: does your ISR consume more than 500 uS?
(I don’t think so…!)

Is there any other peripheral that needs extremely fast service? How about USB MIDI? I know very little about USB packets, but I’m assuming they go in some sort of buffer. The SPI interface to the SD card isn’t time-critical, right?

IIC needs high priority as well, USB doesn’t (it’s a handshake protocol), SPI is only a question of required bandwidth (but SD Card transfers are handled via DMA already…), no risk for data loss.

Best Regards, Thorsten.

 

7

Thank you–I will do more research. :slight_smile:

As far as the timer ISRs for the sound chips, I didn’t answer the question because it’s complicated–the synth will be playing several (maybe more than 30!) VGM files from RAM at the same time, which can include up to 4 sampled streams. Depending on the load, the system may do different things. But I expect the typical behavior of the ISRs to be that they run for about 2-5us, then return, then get triggered again in another 5-10us. It should never be that they are running continuously for anything near 500us, but they will have to interrupt any MIDI-handling code many times.

I don’t expect to use IIC in this synth at all, I will probably disable the whole peripheral.