4 ms·

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 do

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.
  - dayjaby 2y ago
    Do you by chance have an example repo with mcu management working? I always struggled with that in Zephyr :)
johnwalkr 2y ago
Glad you mentioned PLCs. I keep seeing more and more young engineers reinventing wheels with raspberry pi and arduinos, especially for things like test jigs. It’s almost like PLCs are a secret in some industries.
- mardifoufs 2y ago
  It's not that they are a secret. It's that they are sometimes cost prohibitive and lock you into a proprietary, rigid ecosystem regardless of which PLC you chose. PLCs are awesome for what they are intended for, and they work very well with each other/equipment made with PLCs in mind. but they are an immense pain to "integrate" into an existing non-industrial system. They are basically in their own world, with tooling that's specific to the PLC world, with very little open source support. I agree that for some one off things like controlling a CNC, they might be more useful than a Frankenstein esp attached to some servo controllee though.
  - DannyBee 2y ago
    I agree on both counts. You can easily get locked in. For anyone else who is just sort of lurking (you already know what i'll say). Codesys is basically the standard here, and the way to "avoid" lock in - it has the most hardware support, and lots of vendors use it under the covers. This gives you some standard. It supports IEC 61131-3, happy to export it as text or whatever, and i've actually moved code between implementations. You can use Codesys Control RTE on anything that runs windows or linux to get soft-realtime support. Twincat is similar (it was based on codesys at one point but no longer). Integration is, as you say, a pain outside of industrial land. But i will admit i am amazed that i have an entire CNC machine built out of ethercat servo drives, I/O, VFD, vacuum pump, pneumatic valve actuators, limit switches, etc. They all are from different manufacturers. But damned if it doesn't work perfectly, and i only have an ethernet cable running between 99% of things where it used to require a metric ton of cables and you were just flinging bits and analog current around between things. 6 If i bothered to update the spindle to ethercat, the only real physical I/O would be brake power relays (unavoidable) and emergency stop. I do have one modbus thing (dust control flow monitor) i use as well. It also is pretty good at hiding complexity - I can link a variable to an I/O input or analog value or VFD status word, know that it will deterministically update. I can set up a structure of bits for each pneumatic valve and map it to the manufacturer's single I/O word and again, get deterministic two-way updating and not worry about it. Now, can i get status out of this thing? Well, no, to your point, either something else needs to speak modbus, ethercat, profinet, ethernet/ip, pure digital i/o to it. These days i could publish status to MQTT, but something like "expose an HTTP port that outputs a bunch of JSON" is totally uncommon, and will net you strange looks. It's like you are asking about cold fusion. Don't even get started on controlling it from the other side through something like that. But yeah, otherwise paying 500 bucks for a license to ladder program a PLC is not a pleasant thing.

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.
- dayjaby 2y ago
  Do you by chance have an example repo with mcu management working? I always struggled with that in Zephyr :)

johnwalkr 2y ago

Glad you mentioned PLCs. I keep seeing more and more young engineers reinventing wheels with raspberry pi and arduinos, especially for things like test jigs. It’s almost like PLCs are a secret in some industries.

mardifoufs 2y ago
It's not that they are a secret. It's that they are sometimes cost prohibitive and lock you into a proprietary, rigid ecosystem regardless of which PLC you chose. PLCs are awesome for what they are intended for, and they work very well with each other/equipment made with PLCs in mind. but they are an immense pain to "integrate" into an existing non-industrial system. They are basically in their own world, with tooling that's specific to the PLC world, with very little open source support. I agree that for some one off things like controlling a CNC, they might be more useful than a Frankenstein esp attached to some servo controllee though.
- DannyBee 2y ago
  I agree on both counts. You can easily get locked in. For anyone else who is just sort of lurking (you already know what i'll say). Codesys is basically the standard here, and the way to "avoid" lock in - it has the most hardware support, and lots of vendors use it under the covers. This gives you some standard. It supports IEC 61131-3, happy to export it as text or whatever, and i've actually moved code between implementations. You can use Codesys Control RTE on anything that runs windows or linux to get soft-realtime support. Twincat is similar (it was based on codesys at one point but no longer). Integration is, as you say, a pain outside of industrial land. But i will admit i am amazed that i have an entire CNC machine built out of ethercat servo drives, I/O, VFD, vacuum pump, pneumatic valve actuators, limit switches, etc. They all are from different manufacturers. But damned if it doesn't work perfectly, and i only have an ethernet cable running between 99% of things where it used to require a metric ton of cables and you were just flinging bits and analog current around between things. 6 If i bothered to update the spindle to ethercat, the only real physical I/O would be brake power relays (unavoidable) and emergency stop. I do have one modbus thing (dust control flow monitor) i use as well. It also is pretty good at hiding complexity - I can link a variable to an I/O input or analog value or VFD status word, know that it will deterministically update. I can set up a structure of bits for each pneumatic valve and map it to the manufacturer's single I/O word and again, get deterministic two-way updating and not worry about it. Now, can i get status out of this thing? Well, no, to your point, either something else needs to speak modbus, ethercat, profinet, ethernet/ip, pure digital i/o to it. These days i could publish status to MQTT, but something like "expose an HTTP port that outputs a bunch of JSON" is totally uncommon, and will net you strange looks. It's like you are asking about cold fusion. Don't even get started on controlling it from the other side through something like that. But yeah, otherwise paying 500 bucks for a license to ladder program a PLC is not a pleasant thing.