5 ms·

C++ is still often the best or only way to write performant code on embedded platforms, while having a rich library ecosystem available. Hence, my first choice

C++ is still often the best or only way to write performant code on embedded platforms, while having a rich library ecosystem available. Hence, my first choice for a new embedded project is almost always C++. I would love to be able to use something like Rust, but the RTOS options and library support are not quite there yet. With more powerful embedded processors becoming available, Micropython is an option for some projects.

bfrog 4y ago
I think the RTOS side is being addressed pretty well for rust, which libraries do you feel are missing now?
- flykespice 4y ago
- deepspace 4y ago
  Last time I looked, RTIC was the most complete RTOS implementation, but it lacked some functionality related to timeout actions in the network stack that I needed (and was provided by FreeRTOS). Functionality appears to be increasing fairly rapidly though, so I might take another look soon.
  - bfrog 4y ago
    Tock is probably closer to a true RTOS in the sense that tasks have stacks. Maybe also hubris. RTIC, embassy, and probably a few others do ISR preemptive task scheduling and synchronization. This is super cool and probably enough for most people. Until you need time slicing probably. Threads have pros and cons like anything else, the biggest cons tend to be… Stack sizing is hard. Stack swapping kills caches. Stack overflows can be very infrequent and hard to debug. Thread priority doesnt always do what you think. Even with threads not every RTOS does time slicing. So right is there a complete network/usb/ble stack in rust today? Not that I’ve seen. So I can understand needing those and thinking maybe it’s not quite there. I do think though that some really interesting and cool ideas on scheduling, device Hal’s, and state machinery has been pretty well explored at this point. It’s still young but evolving and maturing quickly.
- elcritch 4y ago
  Nah, the RTOS side in Rust is still in its infancy. Hubris is pretty cool but really only supports two families of chips (and requires an MPU iirc). Rust's ecosystem still struggles with no_std, so the majority of crates won't work. Worse (for me) is that using Rust with arrays (not heap allocated vec's) is still a pain.
  - steveklabnik 4y ago
    (Hubris does require an MPU, you're recalling correctly :) )
throwaway2037 4y ago
Real question: You specifically wrote <<C++ is still often the best or only way to write performant code on embedded platforms>>. To be clear, I am not an embedded systems programmer (nor an HN troll!): Does C also qualify? I heard that sometimes embedded engineers are forced to choose C where the C++ compiler is poor or does not exist. Can you please also share your platform(s) and compiler(s)? I am curious to learn more from an industry insider!
- deepspace 4y ago
  Maybe 10-15 years ago, C was the best option for some microprocessors. These days, good C++ support is pretty universal. There is always a compiler available from the manufacturer, and often a gcc target. The AVR family of processors, for example, are supported by the manufacturer's IAR compiler, the ImageCraft ICCAVR compiler, AVR-GCC and several others. IAR produces the fastest / most compact code in many scenarios, but costs $thousands. The ICCAVR compiler and IDE is much cheaper and preferred by many developers. Personally, I tend to avoid pushing the limits of a processor, so the GCC toolchain is most often good enough.
johnboiles 4y ago
Came here to write pretty much exactly what you said. I'm using ESP32-S3 chips in a project. Rust support is really nascent and I can't afford to burn too much time on fixing tooling & recreating libraries. Though it does sound kinda fun. But I imagine there's a chicken/egg challenge where it's hard to see Rust on embedded platforms get more mature unless it gets more adoption and it's hard to imagine a significant uptick in adoption unless it gets more mature. Modern C++ is getting a little better all the time. And perhaps someday Carbon could be a smoother path to modernity because of its focus on migrating existing c++ codebases.
- TillE 4y ago
  > Modern C++ is getting a little better all the time. Honestly, this is the reason I haven't moved anything to Rust, despite seriously considering it in the past. I would ditch C++03 in a heartbeat, but C++14 and beyond are very usable. C++ could certainly be better - I'm hopeful about Carbon - but it's good enough and improving fast enough that if you're already a C++ expert, I think you're pretty happy.
  - Quekid5 4y ago
    Constexpr all the things is kind of a super-power of C++. Zig has an even more powerful comptime feature, but that's an aside. (Bonus points: Declare a static constexpr value in a compilation unit... and use it somewhere at runtime to get the moral equivalent of consteval for the values you care about.)
    - elcritch 4y ago
      Compile time typing is awesome (in Nim its `{.compileTime.}`). Combine it with compile time "duck typing" and you can write some powerful but still simple code. I hope the style becomes more common!
elcritch 4y ago
You should checkout Nim! I use it extensively on embedded. Nim is fantastic to program in if you're an experienced C/C++ developer. Its safer and smarter but not not pedantic about it. Nim compiles to C or C++ so its easy to use on any embedded platform and compiler suite. Thats still huge for embedded. Rust forces a type-trait centric programming style which makes interfacing hardware/embedded harder as you have to make type heavy HALs everywhere -- hence the lack of rtos & library support despite its relative popularity). Its pretty trivial to re-use any C/C++ libraries which gives a big boost to the native ecosystem. I wrapped most of the esp32 idf in a few weeks: https://github.com/elcritch/nesper https://github.com/elcritch/nesper The new GC (ARC) is basically a built in `shared_ptr<T>` or `Rc<T>`. You can also do stack-based programming too and the compiler enforces a safe memory accesses. The performance is great and can match or beat C/C++ if you do a few hours of tuning. Though its easy kill performance if you're lazy (e.g. parse json into a bunch of heaps objects), but that can have its place.
- deepspace 4y ago
  Hmm, I’ve been meaning to check out Nim. Now I definitely will.
  - elcritch 4y ago
    It's smallish, but there's an embedded channel on Nim's discord thats active as well as the forums. Checkout https://github.com/embeddednim/ https://github.com/embeddednim/ too, I've been working to get more projects there. Someone recently added a wrapper for the rpi pico's I've wanted to try :)

bfrog 4y ago

I think the RTOS side is being addressed pretty well for rust, which libraries do you feel are missing now?

flykespice 4y ago
deepspace 4y ago
Last time I looked, RTIC was the most complete RTOS implementation, but it lacked some functionality related to timeout actions in the network stack that I needed (and was provided by FreeRTOS). Functionality appears to be increasing fairly rapidly though, so I might take another look soon.
- bfrog 4y ago
  Tock is probably closer to a true RTOS in the sense that tasks have stacks. Maybe also hubris. RTIC, embassy, and probably a few others do ISR preemptive task scheduling and synchronization. This is super cool and probably enough for most people. Until you need time slicing probably. Threads have pros and cons like anything else, the biggest cons tend to be… Stack sizing is hard. Stack swapping kills caches. Stack overflows can be very infrequent and hard to debug. Thread priority doesnt always do what you think. Even with threads not every RTOS does time slicing. So right is there a complete network/usb/ble stack in rust today? Not that I’ve seen. So I can understand needing those and thinking maybe it’s not quite there. I do think though that some really interesting and cool ideas on scheduling, device Hal’s, and state machinery has been pretty well explored at this point. It’s still young but evolving and maturing quickly.
elcritch 4y ago
Nah, the RTOS side in Rust is still in its infancy. Hubris is pretty cool but really only supports two families of chips (and requires an MPU iirc). Rust's ecosystem still struggles with no_std, so the majority of crates won't work. Worse (for me) is that using Rust with arrays (not heap allocated vec's) is still a pain.
- steveklabnik 4y ago
  (Hubris does require an MPU, you're recalling correctly :) )

throwaway2037 4y ago

Real question: You specifically wrote <<C++ is still often the best or only way to write performant code on embedded platforms>>. To be clear, I am not an embedded systems programmer (nor an HN troll!): Does C also qualify? I heard that sometimes embedded engineers are forced to choose C where the C++ compiler is poor or does not exist. Can you please also share your platform(s) and compiler(s)? I am curious to learn more from an industry insider!

deepspace 4y ago
Maybe 10-15 years ago, C was the best option for some microprocessors. These days, good C++ support is pretty universal. There is always a compiler available from the manufacturer, and often a gcc target. The AVR family of processors, for example, are supported by the manufacturer's IAR compiler, the ImageCraft ICCAVR compiler, AVR-GCC and several others. IAR produces the fastest / most compact code in many scenarios, but costs $thousands. The ICCAVR compiler and IDE is much cheaper and preferred by many developers. Personally, I tend to avoid pushing the limits of a processor, so the GCC toolchain is most often good enough.

johnboiles 4y ago

Came here to write pretty much exactly what you said. I'm using ESP32-S3 chips in a project. Rust support is really nascent and I can't afford to burn too much time on fixing tooling & recreating libraries. Though it does sound kinda fun. But I imagine there's a chicken/egg challenge where it's hard to see Rust on embedded platforms get more mature unless it gets more adoption and it's hard to imagine a significant uptick in adoption unless it gets more mature. Modern C++ is getting a little better all the time. And perhaps someday Carbon could be a smoother path to modernity because of its focus on migrating existing c++ codebases.

TillE 4y ago
> Modern C++ is getting a little better all the time. Honestly, this is the reason I haven't moved anything to Rust, despite seriously considering it in the past. I would ditch C++03 in a heartbeat, but C++14 and beyond are very usable. C++ could certainly be better - I'm hopeful about Carbon - but it's good enough and improving fast enough that if you're already a C++ expert, I think you're pretty happy.
- Quekid5 4y ago
  Constexpr all the things is kind of a super-power of C++. Zig has an even more powerful comptime feature, but that's an aside. (Bonus points: Declare a static constexpr value in a compilation unit... and use it somewhere at runtime to get the moral equivalent of consteval for the values you care about.)
  - elcritch 4y ago
    Compile time typing is awesome (in Nim its `{.compileTime.}`). Combine it with compile time "duck typing" and you can write some powerful but still simple code. I hope the style becomes more common!

elcritch 4y ago

You should checkout Nim! I use it extensively on embedded. Nim is fantastic to program in if you're an experienced C/C++ developer. Its safer and smarter but not not pedantic about it. Nim compiles to C or C++ so its easy to use on any embedded platform and compiler suite. Thats still huge for embedded. Rust forces a type-trait centric programming style which makes interfacing hardware/embedded harder as you have to make type heavy HALs everywhere -- hence the lack of rtos & library support despite its relative popularity). Its pretty trivial to re-use any C/C++ libraries which gives a big boost to the native ecosystem. I wrapped most of the esp32 idf in a few weeks: https://github.com/elcritch/nesper https://github.com/elcritch/nesper The new GC (ARC) is basically a built in `shared_ptr<T>` or `Rc<T>`. You can also do stack-based programming too and the compiler enforces a safe memory accesses. The performance is great and can match or beat C/C++ if you do a few hours of tuning. Though its easy kill performance if you're lazy (e.g. parse json into a bunch of heaps objects), but that can have its place.

deepspace 4y ago
Hmm, I’ve been meaning to check out Nim. Now I definitely will.
- elcritch 4y ago
  It's smallish, but there's an embedded channel on Nim's discord thats active as well as the forums. Checkout https://github.com/embeddednim/ https://github.com/embeddednim/ too, I've been working to get more projects there. Someone recently added a wrapper for the rpi pico's I've wanted to try :)