Seems to miss the part where it's ok to create terrible software in embedded, with custom forks of everything, binary blobs galore. But it's all fine as it shaves a few cents from the BOM.
>Seems to miss the part where it's ok to create terrible software in embedded
As opposed to the absolute perfection that is modern web, enterprise and mobile SW?
>But it's all fine as it shaves a few cents from the BOM.
Every engineering job, including SW development, works to reduce material costs and automate away other jobs. Why do you feel embedded development is somehow worse here?
Embedded development is substantially worse when it comes to out of tree unmaintainable kernel patches, compiler forks, binary blobs around terrible hardware etc etc.
Completely incomparable to web, enterprise and mobile (android and co is a part of the embedded trashfire of course). They all have their problems but are minor league compared to embedded development hell.
Embedded development takes BoM reduction to the extreme and piles all the technical debt onto software.
Binary blobs you say? How about how our entire lives are ruined by having to use garbage apps like Teams every day or any other multitude of garbage websites on a daily baiss ?
Did you actually work in the embedded industry, or are you just venting on some bad experiences you had with some boards/phones?
You know, embedded is more than r-pi clones and android devices, right? It's auomotive, aerospace, industrial automation, healthcare, etc.
I cannot overestimate how mistaken you are but you seem to be already set in your ways, and have a bone to pick so I'll leave the conversation here to save my sanity as you can't be reasoned with nor is anyone's time worth it to convince you otherwise.
Unfortunately the industry I am in (multimedia) is slowly getting invaded by all the awful embedded development practices, binary blobs, custom forks, hacks galore. It's ruining an area where there was clean code, no blobs.
I remember people hacking on the binary of the MS mpeg4 encoder to create "DivX" binary blobs are everywhere (though much less so in every industry than they were 30 years ago)
> android and co is a part of the embedded trashfire of course
I don't consider e.g. Android phones to be embedded. A smartphone is much more like a small laptop. That being said, there is a sliding scale; e.g. car infotainment systems have properties of both embedded and non-embedded software.
embedded hardware has much simpler cost calculations than web, it's pretty easy to come up with an out the door unit cost for hardware, while a web service might not even have any coherent idea of a unit sold, let alone what it costs before there are users
and a simple number is a very easy bludgeon to wield in discussions about engineering choices
We are slowly getting better at this. Most embedded Linux companies for example have shifted or are in the process of shifting to an upstream-first policy. A lot of the toolchains are open, busybox is used everywhere. A lot of the really good HALs are open source. We're getting there!
I've been using Zephyr lately and have been really enjoying it. It still has the vendor HAL libraries available (e.g. Microchip/Atmel ASF), but the devicetree-based HAL has been fabulous to work with. I've tried a number of different embedded frameworks/RTOSes over the years, but it's the first that I actually feel happy using. There's a few sharp edges for sure, but it's at least an order of magnitude better than anything I've used in the past. One thing that's been particularly good is that the abstractions feel right, and it's allowed our team to collaborate on firmware without constantly tripping each other, because the module boundaries and abstractions are good.
This is good to hear. I'm just getting up and running with tutorials for a Nordic IoT SIP using Zephyr, with plans to develop a new model of an agricultural data monitoring/control product we've been offering for a few years. So far it seems really good. I personally have very little experience with embedded software (many years with web software) but am finding it easy to pick up.
Great to know, Zephyr is on my to-use list and I need move it up the list more. Heard good things about it. It might become the Linux OS for low resource MCUs as the trend goes, it's also a LF(Linux foundation) project and vendor neutral, very promising.
I've been using Zephyr on an Atmel/Microchip SAMD21 for $WORK and it's been awesome.
I have an RP2040 sitting on my desk for a personal project and the plan was to use Zephyr for that as well, but it seems the WiFi is based around a binary blob and a weird interface to it that the Arduino BSP has wrappers for... It's been crunch time at work and I haven't gone back yet to see if the RP2040 port is coming along further, but on the Saturday I was looking at it, it seemed like connectivity was potentially going to be an issue for now.
ESP32 support is currently great for some chips and a WIP for other chips. I got unlucky and the one board I planned to use for a different project was pretty much completely unsupported, but I found a different one in my parts bin that only took about 4 hours to get going with the sensors I had planned on using (I2C or SPI, I don't recall), Bluetooth Central for some different sensors, and WiFi to connect it to the local network. It was really smooth!
There is quite a bit of interesting work in the embedded Rust space on this. The embedded-hal project has made some progress on standardizing traits for peripherals and there are some decent HAL crates that have largely adopted those standards. The stm32-hal crates are fantastic.
rust is too hard to use for me, if I need pick up a modern language for low level it will be zig instead of rust.
while rust might be fine for MCU low level embedded, it does not work for mid-range embedded linux when you have 64MB storage for example, as rust is by default static linked, a few of rust executable will fill up the storage, unlike c or c++ or zig where they can share some libraries _easily_ to save space.
