4 ms·

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 fi

• 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.
  • bborud 2y ago
    Have you tried ESP32 and ESP-IDF (FreeRTOS?). I'd be interested in your take on that after using Zephyr :-)
    • DannyBee 2y ago
      I have tried ESP32 a bunch, ESP-IDF itself less. I mainly used ESP32 through platformio (which used the arduino compatibility layer of ESP-IDF), and then through the rust support. I did use ESP-IDF directly for one project, but only for a small time. For that application, it was just way too high power and too finicky (it was easy to crash it by doing normal things - admittedly, it could be that there are just a lot of crappy ESP32 boards out there) I did find ESP-IDF a lot nicer than either platformio, or the rust support, for sure. It was nice having regular old cmake and stuff that just worked for you, without worrying about it. For a simple app, i would use it over zephyr, no issue. But zephyr's abstractions have bought me stuff. For example, I have learned how to make zephyr's MCU management subsystem do OTA over bluetooth across any device that supports mcuboot (IE everything). So like, i don't worry about needing to use each manufacturer's OTA support. It also works with nuttx if i ever go that way. It's hard to give stuff like that up for my use cases. I can walk near my gate transmitter/receiver, or near a machine, or near anything else i've built, and using the same tools, make sure the device is working and update the device with an image, without needing to worry about or keep 75 types of OTA tools and keys around :) (I could make it work over wifi or lora or ... easily too, but i don't really need to). These devices do not all use the same SOC - the gate transmitter is a very low power sleep device (small battery will last about 21 years at current rate). The gate receiver is not. The embedded sensors on machines are yet a different SOC (nordic), with other types needing a little more power being higher power STM's. There is even an NXP device around somewhere from when i was experimenting with LVGL. It is possible to make this kind of thing work with freertos (they have a 3 year old not-updated labs project to support mcumgr, for example). But i don't want to have to combine my own pieces, etc. This, of course, is basically the point of FreeRTOS, so it's not a surprise i don't go that way :) ESP-IDF obviously provides it's own OTA layer, though it leaves transmitting data and management to you. I did build an OTA over bluetooth impl that worked pretty well (updates at about 50-200k/s) before i moved entirely to the zephyr one.
• 5ADBEEF 2y ago
  anybody doing new BLE products has a 50/50 shot of using Zephyr in current year. I think the real benefit of Zephyr is that the wheel has already been invented, no need to do it yourself