4 ms·

This author seems like they are expecting an RTOS to be the same as Arduino environment, or at least, susceptible to just hacking around and hoping it works. M

This author seems like they are expecting an RTOS to be the same as Arduino environment, or at least, susceptible to just hacking around and hoping it works. Most are not. Given a lot of Arduino these days have mbed or freertos under the covers, with some way to expose it, that may have been a better route for the author's style. Zephyr is easy to use (Clion also has good support for it), but like, you can't just choose not to install the toolchain and expect it to all work. It also definitely supports the Pi Pico - i've used it on it before, no issues. A simpler rundown of these RTOSen would be: 1. FreeRTOS - supported by roughly everything, but drivers and such are mostly per-SOC/device, which is a pain in the ass. The APIs are not very user friendly, but you get used to it. To give a sense of level - if you wanted to use bluetooth with FreeRTOS, you get to find your own stack. 2. Zephyr - supports real hardware abstractions and supports most SOC. You may have to do a little board work. If you wanted to use bluetooth with Zephyr, it has a bluetooth stack you can use, you may have to add a little support for your HCI. 3. NuttX - not great support, but very cool if you can get it working - not really highly supported by industry yet. I never got far enough into NuttX to try bluetooth in NuttX. There is also mbed, but we'll skip it. In practice, people in the RTOS world will usually go with what the SOC vendor supports. So if you are using Nordic stuff, you are probably on Zephyr. If you are using NXP stuff, probably FreeRTOS, etc. That is how they get good support.

anymouse123456 2y ago
"Zephyr is easy to use" That has not been my experience. From where I sit, Zephyr has very pretty marketing material. Behind all that snazz, Zephyr is outrageously bloated, extremely slow to compile and wildly difficult to get up and running.
- DannyBee 2y ago
  I dunno, maybe i got lucky. It takes me maybe 10 minutes to get clion + zephyr started and working for a new project. If there is board work, at that point i'm playing with making the board work. I started with platformio's zephyr support and then moved to clion as platformio kind of died. I have never, and would never, try to use west as the main build system of my project directly. As for bloat/compilation speed, i guess it all depends on what you are trying to use it for. As per the other thread - if you are trying to use it as "an RTOS that is a less hacky version of arduino stuff", i think it works great. If you are trying to use it for "i have meaningful hardware constraints and need to keep track of every byte", i doubt it would work well compared to FreeRTOS. I think the limit is probably "i am using nordic boards to develop bluetooth stuff". I do agree they try to sell it for a lot of things.
  - einsteinx2 2y ago
    What do you mean by “platformio kind of died”? I used to use it a lot but haven’t done any microcontroller projects in a while.
    - DannyBee 2y ago
      Most manufacturers seem to have abandoned trying to support them, their community has slowly disappeared, and you can see it. They seem to only care about Espressif these days. Zephyr support has not been updated in ages (2021) Patches submitted to platformio arduino to add Giga R1 support have gone unreviewed for years (I get poked every so often because i did some work on it, so i see the github comments). The only things that seem to be in okay shape these days are ESP and STM32. Given the other options at this point, it is nowhere near as useful as it used to be.
      - Kubuxu 2y ago
        That is partially on PlatformIO. AFAIK, they started pushing hard the scheme "be a partner (meaning pay us) or we won't even accept external contributions to support your platform". ESP had a pretty public dispute with them (payment wasn't explicitly mentioned but can be inferred).
        DannyBee 2y ago
        Yeah, they thought they controlled the eyeballs, and it turns out they did not.
      - einsteinx2 2y ago
        Ah that’s unfortunate, I liked the idea of Platformio.
    - bborud 2y ago
      I can't speak to what he meant, but if I were to guess, Zephyr isn't necessarily that easy to wrangle into shape for PlatformIO so despite a lot of initial enthusiasm and optimism, progress has been a bit disappointing. As for why, it is probably because MCU makers are a bit nearsighted when it comes to the software side so you get little or no help from there. The strategic decision makers don't understand software. (That's not my assessment, by the way, but that of people I know who either work for one of the major MCU makers or has worked there). So they do their own thing, they don't do it particularly well, they don't see that they don't do it particularly well or why it is even their problem. I also think that they are a bit afraid of common tooling - possibly because they think it is giving up control or robbing them of the opportunity to differentiate themselves (which is tragically funny since most can, at best, hope to be no worse than the competition). You'd think that if lots of players can agree on using Zephyr it shouldn't be hard to make them agree on supporting sensible common tooling (akin to PlatformIO), but then again, these companies don't really get software. (I was tempted to say "modern tooling", but then I remembered that I hate it when people use the word "modern" so Dobby had to iron his hands and delete it).
- deleted 2y ago
  [deleted]
bborud 2y ago
Quick question: do you develop for prototyping boards or do you write firmware for OEM devices? I have never encountered a single project where we had to do firmware for an OEM device where developers didn't struggle with Zephyr. Not once. Nor have I actually met any of those mythical developers that do actual firmware work on shipping products who think Zephyr hardware abstractions actually help. I'm not denying they exist. I just haven't encountered any in the past 5 or so years.
- TickleSteve 2y ago
  Agree... As an embedded developer for over 25 years, I would never use the provided hardware abstractions from one particular vendor. Typically, you use your own abstraction layer over multiple vendors BSPs/OS/libraries. One of the driving principles behind embedded software is minimalism because you pay real money for every byte and cycle. That leads you to creating minimal abstractions for your particular use case that still gives you the flexibility that is also often required (multiple sources for processors for example).
  - londons_explore 2y ago
    In the VC/startup world here in HN, I suspect lots of embedded engineering won't be highly cost constrained, and picking a microcontroller with 1MByte of flash when the task could have been done with 1 Kbyte of flash will be seen as no big deal. In turn, that means a focus on premade software to reduce Dev time rather than optimizing every byte.
  - selfmodruntime 2y ago
    Eh. We mostly went with IDF since we run all our products on ESP boards. I really like their abstraction layers.
- DannyBee 2y ago
  Prototyping boards - I can totally believe trying to do firmware on a shipping product with real constraints in zephyr would be a pain in the ass because you don't have enough control. I often use C++ with zephyr, which also pretty much immediately disqualifies me from that club :) Though i've done it plenty of times with C only and nordic boards. Amusingly, I got into it years ago because I was porting my dust collector controller to an RTOS, and it was very easy to port to zephyr (I had to hack up the C++ threading support, but the hardware was very easy to make work). But i've since used it for everything from the "the keypad and receiver that is on the gate to my house" to embedded devices that transmit flow data, etc. I have had to fix bugs in the hardware abstractions for LoRa (interrupt based packet reception did not work on all chips), and do things like add hardware acceleration for LVGL, but overall the abstractions work pretty well for me. Having had to build themselves in FreeRTOS, it's just not worth my time. I view it as more of a "less hacky arduino" than "serious thing i would base my life on". At most, i would use it for nordic boards to develop bluetooth stuff (because they have such good support for this). Anything that requires real serious guarantees i'll use PLC hardware, not zephyr. But i'm in the machine world, so this is like "make sure spindle has stopped moving before allowing tool release" type stuff that needs to be deterministic, but is also fairly simple. It does not require more than PLCOpen or ladder.
shadowpho 2y ago
Why skip mbed? That’s the “best” part!

anymouse123456 2y ago

"Zephyr is easy to use" That has not been my experience. From where I sit, Zephyr has very pretty marketing material. Behind all that snazz, Zephyr is outrageously bloated, extremely slow to compile and wildly difficult to get up and running.

DannyBee 2y ago
I dunno, maybe i got lucky. It takes me maybe 10 minutes to get clion + zephyr started and working for a new project. If there is board work, at that point i'm playing with making the board work. I started with platformio's zephyr support and then moved to clion as platformio kind of died. I have never, and would never, try to use west as the main build system of my project directly. As for bloat/compilation speed, i guess it all depends on what you are trying to use it for. As per the other thread - if you are trying to use it as "an RTOS that is a less hacky version of arduino stuff", i think it works great. If you are trying to use it for "i have meaningful hardware constraints and need to keep track of every byte", i doubt it would work well compared to FreeRTOS. I think the limit is probably "i am using nordic boards to develop bluetooth stuff". I do agree they try to sell it for a lot of things.
- einsteinx2 2y ago
  What do you mean by “platformio kind of died”? I used to use it a lot but haven’t done any microcontroller projects in a while.
  - DannyBee 2y ago
    Most manufacturers seem to have abandoned trying to support them, their community has slowly disappeared, and you can see it. They seem to only care about Espressif these days. Zephyr support has not been updated in ages (2021) Patches submitted to platformio arduino to add Giga R1 support have gone unreviewed for years (I get poked every so often because i did some work on it, so i see the github comments). The only things that seem to be in okay shape these days are ESP and STM32. Given the other options at this point, it is nowhere near as useful as it used to be.
    - Kubuxu 2y ago
      That is partially on PlatformIO. AFAIK, they started pushing hard the scheme "be a partner (meaning pay us) or we won't even accept external contributions to support your platform". ESP had a pretty public dispute with them (payment wasn't explicitly mentioned but can be inferred).
      - DannyBee 2y ago
        Yeah, they thought they controlled the eyeballs, and it turns out they did not.
    - einsteinx2 2y ago
      Ah that’s unfortunate, I liked the idea of Platformio.
  - bborud 2y ago
    I can't speak to what he meant, but if I were to guess, Zephyr isn't necessarily that easy to wrangle into shape for PlatformIO so despite a lot of initial enthusiasm and optimism, progress has been a bit disappointing. As for why, it is probably because MCU makers are a bit nearsighted when it comes to the software side so you get little or no help from there. The strategic decision makers don't understand software. (That's not my assessment, by the way, but that of people I know who either work for one of the major MCU makers or has worked there). So they do their own thing, they don't do it particularly well, they don't see that they don't do it particularly well or why it is even their problem. I also think that they are a bit afraid of common tooling - possibly because they think it is giving up control or robbing them of the opportunity to differentiate themselves (which is tragically funny since most can, at best, hope to be no worse than the competition). You'd think that if lots of players can agree on using Zephyr it shouldn't be hard to make them agree on supporting sensible common tooling (akin to PlatformIO), but then again, these companies don't really get software. (I was tempted to say "modern tooling", but then I remembered that I hate it when people use the word "modern" so Dobby had to iron his hands and delete it).
deleted 2y ago
[deleted]

bborud 2y ago

Quick question: do you develop for prototyping boards or do you write firmware for OEM devices? I have never encountered a single project where we had to do firmware for an OEM device where developers didn't struggle with Zephyr. Not once. Nor have I actually met any of those mythical developers that do actual firmware work on shipping products who think Zephyr hardware abstractions actually help. I'm not denying they exist. I just haven't encountered any in the past 5 or so years.

TickleSteve 2y ago
Agree... As an embedded developer for over 25 years, I would never use the provided hardware abstractions from one particular vendor. Typically, you use your own abstraction layer over multiple vendors BSPs/OS/libraries. One of the driving principles behind embedded software is minimalism because you pay real money for every byte and cycle. That leads you to creating minimal abstractions for your particular use case that still gives you the flexibility that is also often required (multiple sources for processors for example).
- londons_explore 2y ago
  In the VC/startup world here in HN, I suspect lots of embedded engineering won't be highly cost constrained, and picking a microcontroller with 1MByte of flash when the task could have been done with 1 Kbyte of flash will be seen as no big deal. In turn, that means a focus on premade software to reduce Dev time rather than optimizing every byte.
- selfmodruntime 2y ago
  Eh. We mostly went with IDF since we run all our products on ESP boards. I really like their abstraction layers.
DannyBee 2y ago
Prototyping boards - I can totally believe trying to do firmware on a shipping product with real constraints in zephyr would be a pain in the ass because you don't have enough control. I often use C++ with zephyr, which also pretty much immediately disqualifies me from that club :) Though i've done it plenty of times with C only and nordic boards. Amusingly, I got into it years ago because I was porting my dust collector controller to an RTOS, and it was very easy to port to zephyr (I had to hack up the C++ threading support, but the hardware was very easy to make work). But i've since used it for everything from the "the keypad and receiver that is on the gate to my house" to embedded devices that transmit flow data, etc. I have had to fix bugs in the hardware abstractions for LoRa (interrupt based packet reception did not work on all chips), and do things like add hardware acceleration for LVGL, but overall the abstractions work pretty well for me. Having had to build themselves in FreeRTOS, it's just not worth my time. I view it as more of a "less hacky arduino" than "serious thing i would base my life on". At most, i would use it for nordic boards to develop bluetooth stuff (because they have such good support for this). Anything that requires real serious guarantees i'll use PLC hardware, not zephyr. But i'm in the machine world, so this is like "make sure spindle has stopped moving before allowing tool release" type stuff that needs to be deterministic, but is also fairly simple. It does not require more than PLCOpen or ladder.

shadowpho 2y ago

Why skip mbed? That’s the “best” part!