3 ms·

The difference is that with RTOSes you typically link the application together with the OS, whereas with Linux you can dynamically load applications at run-time

The difference is that with RTOSes you typically link the application together with the OS, whereas with Linux you can dynamically load applications at run-time.

pjmlp 4y ago
Like everything in computing, it depends.
solarkraft 4y ago
This is a big deal to me. What's stopping normal microcontroller platforms like Zephyr from providing dynamic loading of programs? It'd be great for iteration to have a solid OS that cares about networking and updates and a an application layer you can move fast and break things with without risking soft-bricking your device. I'm currently finding this with interpreted platforms like Espruino and Micropython, but don't understand at all why they have to be the only ones making this possible.
- pantalaimon 4y ago
  Where would you even load to program to and where from? Typical microcontroller platforms only have a few kB of ROM and RAM, you can't load your application to RAM to run it, it's directly run from Flash. But the internal flash of a MCU can only be erased in pages that can range up to 4k or 8k depending on the platform. So that already limits how many free pages you might have that you could dedicate to an application. What usually is done is to partition the flash into two areas, so you have two firmware slots. This allows you do do OTA updates: While you run from slot A you can write the new firmware to slot B, once you verified the firmware in slot B you set a flag that tell the bootloader to boot from slot B next time. (Oh and you need different firmware images for slot A and slot B as ROM addresses will be different and there is no address translations. Some bootloaders will avoid this always copying slot B to slot A if it's newer than slot A, but IMHO that's unnecessarily complex/inefficient. You might as well always generate both slot images and let the firmware decide which one to request). Another question is, why would you even want to dynamically load applications? Those systems are not interactive, if you have some sensor monitoring the water level of your pot plant or the vibrations on some industrial equipment, it will only ever run that single application. It might get updates if it's doing some networking, but that will just be an update of the whole firmware.
  - kevin_thibedeau 4y ago
    The base PDP-11 had 56KB. Many microcontrollers exceed that.
- deleted 4y ago
  [deleted]
- VLM 4y ago
  Not entirely sure what you're saying, as Micropython on Zephyr exists. https://docs.micropython.org/en/latest/zephyr/quickref.html https://docs.micropython.org/en/latest/zephyr/quickref.html Very weird seeing the Zephyr booting message I've seen so many times followed by the micropython repl startup message I've seen so many times. Hard to think of a good app for that topology. In the sense that I could stick circuitpython or micropython on a ESP32, or zephyr on a ESP32, so an app running both would get me ... ? Conceptually, the *python people "could in theory" give up on porting to infinite number of new boards and focus really hard on working under Zephyr, and let Zephyr worry about porting to infinite number of new boards. The idea of upgrading my MicroPython under Zephyr under MCUboot under Eclipse hawkBit over the wifi is pretty intriguing sounding challenge. I have not dug into this technology stack other than recreationally. I'm a little unclear how interop works beyond the existing example of passing simple hardware pins thru. For example if MicroPython had a library that interop directly with the Zephyr RTOS features, that would be quite handy. Another thing I notice is the interop in the docs is simple pin pass thru, hard to even imagine how Zephyr's wide variety of networking stacks would pass thru for Python to use. It looks like there is nothing developed at this point where the uC could run a RTOS thread to "do stuff" while a MicroPython thread handled a wifi UI or UI in general or handled the non-RTOS tasks, although that would be cool.

The difference is that with RTOSes you typically link the application together with the OS, whereas with Linux you can dynamically load applications at run-time.

pjmlp 4y ago

Like everything in computing, it depends.

solarkraft 4y ago

This is a big deal to me. What's stopping normal microcontroller platforms like Zephyr from providing dynamic loading of programs? It'd be great for iteration to have a solid OS that cares about networking and updates and a an application layer you can move fast and break things with without risking soft-bricking your device. I'm currently finding this with interpreted platforms like Espruino and Micropython, but don't understand at all why they have to be the only ones making this possible.

pantalaimon 4y ago
Where would you even load to program to and where from? Typical microcontroller platforms only have a few kB of ROM and RAM, you can't load your application to RAM to run it, it's directly run from Flash. But the internal flash of a MCU can only be erased in pages that can range up to 4k or 8k depending on the platform. So that already limits how many free pages you might have that you could dedicate to an application. What usually is done is to partition the flash into two areas, so you have two firmware slots. This allows you do do OTA updates: While you run from slot A you can write the new firmware to slot B, once you verified the firmware in slot B you set a flag that tell the bootloader to boot from slot B next time. (Oh and you need different firmware images for slot A and slot B as ROM addresses will be different and there is no address translations. Some bootloaders will avoid this always copying slot B to slot A if it's newer than slot A, but IMHO that's unnecessarily complex/inefficient. You might as well always generate both slot images and let the firmware decide which one to request). Another question is, why would you even want to dynamically load applications? Those systems are not interactive, if you have some sensor monitoring the water level of your pot plant or the vibrations on some industrial equipment, it will only ever run that single application. It might get updates if it's doing some networking, but that will just be an update of the whole firmware.
- kevin_thibedeau 4y ago
  The base PDP-11 had 56KB. Many microcontrollers exceed that.
deleted 4y ago
[deleted]
VLM 4y ago
Not entirely sure what you're saying, as Micropython on Zephyr exists. https://docs.micropython.org/en/latest/zephyr/quickref.html https://docs.micropython.org/en/latest/zephyr/quickref.html Very weird seeing the Zephyr booting message I've seen so many times followed by the micropython repl startup message I've seen so many times. Hard to think of a good app for that topology. In the sense that I could stick circuitpython or micropython on a ESP32, or zephyr on a ESP32, so an app running both would get me ... ? Conceptually, the *python people "could in theory" give up on porting to infinite number of new boards and focus really hard on working under Zephyr, and let Zephyr worry about porting to infinite number of new boards. The idea of upgrading my MicroPython under Zephyr under MCUboot under Eclipse hawkBit over the wifi is pretty intriguing sounding challenge. I have not dug into this technology stack other than recreationally. I'm a little unclear how interop works beyond the existing example of passing simple hardware pins thru. For example if MicroPython had a library that interop directly with the Zephyr RTOS features, that would be quite handy. Another thing I notice is the interop in the docs is simple pin pass thru, hard to even imagine how Zephyr's wide variety of networking stacks would pass thru for Python to use. It looks like there is nothing developed at this point where the uC could run a RTOS thread to "do stuff" while a MicroPython thread handled a wifi UI or UI in general or handled the non-RTOS tasks, although that would be cool.