Mindset difference between workstation and embedded programmers

Question

What do you think are the difference in mindset between a programmer doing work for a desktop environment (windows, linux, whatever...) and someone doing work on an embedded system?

A simple example I can think of is that in an embedded environment, I always check that a malloc is not NULL. Most code I have seen that target desktops is certainly not diligent in checking malloc return value.

Any other examples of mindset differences?

Answer 1

I desktop environment there's the idea that "hey I can always release an update or patch to fix this later." In embedded design, you get more "this has to work cause we don't want to recall the device or release an even longer patching program."

Answer 2

size matters

Answer 3

2 things - as Suroot already mentioned, once you release a desktop app, it doesn't have to be "forever", especially nowadays.

But in embedded, once you "ship it", it's on its way to Mars so you're not going to be able to pull it back.

Also one of the major differences are that embedded programmers are generally a LOT more conscious about efficient code and memory management - desktops run horrible code really fast, embedded doesn't.

Answer 4

Desktop programmers view resources as practically unlimited. Memory, computing power, drive space. Those never run out. Embedded programmers focus intently on all of those.

Oh, and embedded programmers also often have to worry about memory alignment issues. Desktop coders don't. The Arm chips care. x86 chips don't.

Answer 5

Funny that you mention malloc() specifically in your example.

In every hard-real-time, deeply embedded system that I've worked on, memory allocation is managed specially (usually not the heap, but fixed memory pools or something similar)... and also, whenever possible, all memory allocation is done up-front during initialization. This is surprisingly easier than most people would believe.

malloc() is vulnerable to fragmentation, is non-deterministic, and doesn't discrminate between memory types. With memory pools, you can have pools that are located/pulling from super fast SRAM, fast DRAM, battery-backed RAM (I've seen it), etc...

There are a hundred other issues (in answer to your original question), but memory allocation is a big one.

Also:

• Respect for / knowledge of the hardware platform
• Not automatically asssuming the hardware is perfect or even functional
• Awareness of certain language apects & features (e.g., exceptions in C++) that can cause things to go sideways quickly
• Awareness of CPU loading and memory utilization
• Awareness of interrupts, pre-emption, and the implications on shared data (where absolutely necessary -- the less shared data, the better)
• Most embedded systems are data/event driven, as opposed to polled; there are exceptions of course
• Most embedded developers are pretty comfortable with the concept of state machines and stateful behavior/modeling