Comment by actionfromafar

Comment by actionfromafar 2 months ago

For things like VxWorks, it's mostly vibes and setting priority between processes. But there are other ways. You can "offline schedule" your tasks, i.e. you run a scheduler at compile time which decides all possible supported orderings and how long slots each task can run.

Then, there's the whole thing of hardware. Do you have one or more cores? If you have more than one core, can they introduce jitter or slowdown to each other accessing memory? And so on and so forth.

tonyarkles 2 months ago

> it's mostly vibes and setting priority between processes

I'm laughing so so hard right now. Thanks for, among other things, confirming for me that there isn't some magic tool that I'm missing :). At least I have the benefit of working on softer real-time systems where missing a deadline might result in lower quality data but there's no lives at risk.

Setting and clearing GPIOs on task entry/exit are a nice touch for verification too.

Reply View 4 replies

nine_k 2 months ago

Magic? Well, here's some: predictably fast interrupts, critical sections where you code cannot be preempted, but with a watchdog so if your code hits an infinite loop it's restarted, no unpredictable memory allocation delays, no unexpected page fault delays, things like that.
These are relatively easy to obtain on an MCU, where there's no virtual memory, physical memory is predictable (if slow), interrupt hardware is simple, hardware watchdogs are a norm, an normally there's no need for preemptive multitasking.
But when you try to make it work in a kernel that supports VMM, kernel / userland privilege separation, user sessions separation, process separation, preemptive multitasking, and has to work on hardware with a really complex bus and a complex interrupt controller, — well, here's where magic begins.

Reply View | 3 replies
- aulin 2 months ago
  
  VMM is one of the few things I really miss while working in embedded. I would happily trade off memory allocation errors from fragmented heap with some unpredictable malloc delay (which could be maybe mitigated with some timeout?).
  
  Reply View | 1 reply
  
  nine_k 2 months ago
  
  Reminds me of the time of banked memory in 8-bit systems :) It's certainly doable, to some extent, and is a hassle to manage %) I suppose it can be implemented with an MCU + QSPI RAM at a cost of one extra SPI clock to access the RAM through a small SRAM that would store the page translation table.
  I just think that something like A0 (to say nothing of ATMega) usually has too little RAM for it to be worth the trouble, and A7 (something like ESP32) already has an MMU.
  
  Reply View | 0 replies
- tonyarkles 2 months ago
  
  That first paragraph is where I fortunately get to live most of the time :D
  
  Reply View | 0 replies

rightbyte 2 months ago

> If you have more than one core, can they introduce jitter or slowdown to each other accessing memory?

DMA and fancy peripherals like UART, SPI etc, could be namedropped in this regard, too.

Reply View 1 reply

nine_k 2 months ago

Plot twist: the very memory may be connected via SPI.

Reply View | 0 replies