4 ms·

Another big challenge is that most of the embedded software I have seen is written by people who aren't exactly top notch programmers. I spent a about 15 years

by bborud 10y ago

Another big challenge is that most of the embedded software I have seen is written by people who aren't exactly top notch programmers. I spent a about 15 years mostly writing server code for UNIX machines in C (before ditching it in favor of Java, and 13 years later: Go). Since embedded programming is a bit of a specialty field where things like predictable performance and robustness is important, I expected the embedded world to be pretty professional. Because any time people start using words like "guarantees" or "real-time", you tend to assume that they do some pretty amazing stuff. I can't really say that's what I found. A lot of code is brutally ugly, many lack understanding of even the most basic defensive programming techniques and there's a lot of superstition around abstractions by people who don't really seem to understand what comes out of a compiler (Having the compiler "compile away" abstraction layers was something we often obsessed over on projects I worked on in the 90s and early 00s). Code is often badly organized, badly formatted, badly documented and amateurishly maintained (eg bullshit commit logs -- if the source is even kept in a version control system). As a result, you constantly fight the urge to rewrite stuff because the code is just so damn hairy. Of course, any talk of rewriting code makes people nervous ("we invested a lot in order for this to work and now it does! Don't touch it". Yeah, I'm not surprised it took a lot of work) And all of this was code by serious companies whose brands you have heard of. I'm hoping the IoT craze is going to accomplish at least one thing: educate embedded developers. Sure, a lot of us "regular" software people are going to run around like a bunch of flatfooted morons because it is unfamiliar territory, but the embedded world is in _dire_ need of some software culture and discipline.

tluyben2 10y ago
Lucky you even had commit logs / versioning :) A lot of embedded orgs are not actually using versioning even. Just zips with the date...
- adrianN 10y ago
  Stored in SAP.
odinthenerd 10y ago
I couldn't agree more! Although coming from the microcontroller world there is practically nothing in the STL which gives me the guarantees I need to use it in ISRs and most devs have no chance at reviewing the STL piece to see if its going to deadlock in ISR or something. Another problem is that although the abstraction compiles away in release mode the debug build usually still has to fit on the chip and/or meet realtime deadlines. Tooling is still super bad at optimizing part of a build and not other parts even though we have an optimize pragma (I brought this up in the SG14 working group but concluded that its more of a tooling than a language issue). In short I think at least the drivers should be written in C++ with proper abstraction but for the most part those abstractions have not been written yet and we can't just borrow from other domains because we have to be deterministic in timing and RAM use and also usually use other threading models (RTC event based) and memory management models (pools, state local storage) at least in drivers. - Odin Holmes
planteen 10y ago
I think a lot of that is changing due to the rise of Linux in embedded systems. Many more traditional software engineering concepts are becoming mainstream in embedded. And for embedded in high value (hundreds of millions of dollars) or human life, I think there has always been lots of proper discipline and engineering process.
- bborud 10y ago
  I was mostly talking about stuff that runs on much smaller CPUs that have from a few hundred bytes to a few tens of kilobytes of memory. Those kinds of devices are important for applications where you have extremely tight power constraints (like powering stuff off a coin-cell battery for two years etc).
HeyLaughingBoy 10y ago
At my last job, the EE manager wanted to improve the quality of firmware, so one of the things he did was to ask for a software guy to show them how we did code reviews. As an EE working in software, I volunteered. One of the comments I made was that the many magic numbers in the code should be replaced by definitions that explained what they meant. I got back code for re-review that contained the line: #define ZERO 0 To this day I'm not sure if the author didn't understand or was just irritated at having me review his code. Probably both, come to think of it.
bradstewart 10y ago
Your hope is becoming a reality, at least in my experience working at a semiconductor company (public, mid-sized). The IoT craze has forced a lot of software on hardware companies: everything from ZigBee, Thread, and Bluetooth stacks to RTOS's to manage all of those stacks, to IDEs that are actually usable. The companies embracing software as a vital part of their products are doing well, and will continue to do well at the expense of the companies who treat software as an after thought.
pjmlp 10y ago
> lot of superstition around abstractions by people who don't really seem to understand what comes out of a compiler (Having the compiler "compile away" abstraction layers was something we often obsessed over on projects I worked on in the 90s and early 00s). I have seen this a lot, specially like caring about bounds checking or virtual method dispatch without measuring if it really matters. Even some modern microcontrollers are quite powerful versus those mainframes running Lisp, yet were we are still preaching Assembly and C as if it was the 80's, early 90's.

by bborud 10y ago

tluyben2 10y ago

Lucky you even had commit logs / versioning :) A lot of embedded orgs are not actually using versioning even. Just zips with the date...

adrianN 10y ago
Stored in SAP.

odinthenerd 10y ago

I couldn't agree more! Although coming from the microcontroller world there is practically nothing in the STL which gives me the guarantees I need to use it in ISRs and most devs have no chance at reviewing the STL piece to see if its going to deadlock in ISR or something. Another problem is that although the abstraction compiles away in release mode the debug build usually still has to fit on the chip and/or meet realtime deadlines. Tooling is still super bad at optimizing part of a build and not other parts even though we have an optimize pragma (I brought this up in the SG14 working group but concluded that its more of a tooling than a language issue). In short I think at least the drivers should be written in C++ with proper abstraction but for the most part those abstractions have not been written yet and we can't just borrow from other domains because we have to be deterministic in timing and RAM use and also usually use other threading models (RTC event based) and memory management models (pools, state local storage) at least in drivers. - Odin Holmes

planteen 10y ago

I think a lot of that is changing due to the rise of Linux in embedded systems. Many more traditional software engineering concepts are becoming mainstream in embedded. And for embedded in high value (hundreds of millions of dollars) or human life, I think there has always been lots of proper discipline and engineering process.

bborud 10y ago
I was mostly talking about stuff that runs on much smaller CPUs that have from a few hundred bytes to a few tens of kilobytes of memory. Those kinds of devices are important for applications where you have extremely tight power constraints (like powering stuff off a coin-cell battery for two years etc).

HeyLaughingBoy 10y ago

At my last job, the EE manager wanted to improve the quality of firmware, so one of the things he did was to ask for a software guy to show them how we did code reviews. As an EE working in software, I volunteered. One of the comments I made was that the many magic numbers in the code should be replaced by definitions that explained what they meant. I got back code for re-review that contained the line: #define ZERO 0 To this day I'm not sure if the author didn't understand or was just irritated at having me review his code. Probably both, come to think of it.

bradstewart 10y ago

Your hope is becoming a reality, at least in my experience working at a semiconductor company (public, mid-sized). The IoT craze has forced a lot of software on hardware companies: everything from ZigBee, Thread, and Bluetooth stacks to RTOS's to manage all of those stacks, to IDEs that are actually usable. The companies embracing software as a vital part of their products are doing well, and will continue to do well at the expense of the companies who treat software as an after thought.

pjmlp 10y ago

> lot of superstition around abstractions by people who don't really seem to understand what comes out of a compiler (Having the compiler "compile away" abstraction layers was something we often obsessed over on projects I worked on in the 90s and early 00s). I have seen this a lot, specially like caring about bounds checking or virtual method dispatch without measuring if it really matters. Even some modern microcontrollers are quite powerful versus those mainframes running Lisp, yet were we are still preaching Assembly and C as if it was the 80's, early 90's.