Embedded System

Systems development for machines where the processor is built into the equipment. Typically requires a broad knowledge base; electronics hardware, software, electromechanical, and other disciplines. Pretty cool stuff, but boring as all sin to somebody not involved.

Embedded software is frequently designed to run without user intervention, often for years on end. Embedded software may also be designed to act like a replacement for electronic hardware, and just be a working component of a non-computer machine. Examples include the software inside toasters, cars, video players, DVD players, set-top boxes, burglar alarms, missile detection and defence systems, telecommunication systems and many more besides.

Some embedded software is characterized by running on small, ultra-cheap hardware with little memory and a slow processor. It often needs to be written in tight assembly or low-level C, and operating system support is frequently minimal.

It's very like games programming on a PIC, but without the player ..

Other embedded software has a lot of hardware and operating system support, but still has "hard" time constraints and extreme reliability requirements.

This term is sometimes used to refer to HandHeld computers, PersonalDigitalAssistants, mobile phones, and video-game systems. While such systems do share a lot of the characteristics of other embedded systems (slower CPUs, less memory, restricted input and output, running continuously, use of cross-compilers), they are also a lot like general-purpose PCs. Do "traditional" embedded-systems people consider PalmOs and PocketPc programming to be embedded-systems programming?

No, they do not. They consider developing for phones and PDAs somewhat luxurious. In fact, they find it hilarious when phone and PDA developers start talking about "small memory". A contemporary high end mobile phone (mid 2003) might have a megabyte or two available for user applications. Well, the laptop I'm typing at now has half a gig (and is only half-full, at that), so in once sense that is small memory. On the other hand, the hard core embedded folks feel pleased to have twenty kilobytes available.

That said, don't underestimate how much different developing apps for SymbianOs, for instance, is from building desktop PC apps. And it's a different universe from building server-side components. The Symbian compilers will reject any program that, while otherwise conforming, has any single stack frame size in excess of 2K. Severe limits on stack depth on most devices prohibits using recursive solutions. A phone/PDA app might be running for years, during which time it must not do anything that locks up the device.

This is especially important with phones: any organization that let an app out that stopped a phone user being able to call 999/211/911/whatever could see themselves on the end of a staggering law suit. It mustn't do anything that runs down the battery. Etc. etc.

In some ways the phone developer loses out to both the true embedded and the desktop developer. The hard core embedded developer usually has access to the hardware in a way that phone developers don't (and that PC developers take for granted). There's currently no way to debug an application running on a production Symbian phone, for example. If you can get hold of the development hardware, and if you're using 7.0 or later, and you're in a position to burn your own ROMs, then you can do it. But if you're using production phone hardware, no chance. So you have to rely on an emulator running on a PC, and sometimes that just isn't good enough. Unit tests help a lot with this. -- KeithBraithwaite.

Education and Research

There are a lot of universities all over the world that have courses on Embedded Systems. If you are a student or developer you can submit your project description to [http://www.emlabs.info/].

That's phunny. I have only been in embedded systems for the past 30 years or so, but I've yet to hear of a university course on embedded technology that was worth the time it took to attend the lectures. Hmm.

Additional note as of May 05: an engineer buddy of mine told me about his client who sent an embedded controller job to India for software development. The Indian crew were told to optimize the code for size. Instead of turning on the compiler size optimizer these smart but inexperienced folks went through the code and added conditional compilation to take out all the features that wouldn't be used for particular models of the target product.

Oy.

Nice try, though.

Many EmbeddedSystems are also RealTime systems. In fact, this is most often the case. The real time requirements vary (a TV remote control versus a heart defibrillator, for instance), but pretty much all embedded systems stuff needs to act in real time. How long are you willing to wait for your toaster to lower the bread into the heating chamber?

More importantly, how long are you going to wait for a runaway motor drive on that Class IIB patient-controlled analgesic pump to be shut down by the monitoring intelligence? On the last medical product I worked on the (projected) highest concentration of the most potent pain medication to be dispensed could kill the patient within some brief period, like less than a second. (Don't recall all the exact numbers.) The safety monitor was a separate processor that had direct control over the FETs driving the motor, and thusly could shut the pump down before the patient got whacked. This is real time For Real, if you get my drift.

Is there a connection between "EmbeddedSystem" and "EmbeddedLanguage" ?

Not really.

"EmbeddedSystem" refers to a hardware system that happens to have a computer hidden away inside.

"EmbeddedLanguage" refers to a software system that happens to have another programming language hidden away inside.

By common definition: Yes! Yes! Yes! Embedded systems are generally called such because they're a computing system embedded in something that isn't a general purpose computer (or where the ES isn't the cpu at least). The above is just a slight semantic difference in which parts the term usually considers part of the ES. Embedded controllers often tie into most of the circuitry and functions so they'll seem more invasive than e.g. an extension plugin language.

Could anyone write a short summary about the typical stages of embedded software development or point out some reliable resource to explain it to someone with generic programming experience?

Depends on a lot of things, embedded systems run the gamut from toasters to PDAs to instruments, etc. However, a key step in many embedded systems developments is bringing up the hardware. In many cases, the hardware (including the embedded computer - CPU, memory, etc) is co-designed along with the software, and a good amount of time is required getting the embedded OS (or some sort of kernel/debugging environment) working on the hardware. This required good systems programming/troubleshooting skills, and can be difficult and unpredictable at times. Even if you use an off-the-shelf embedded OS, like VxWorks or numerous flavors of Linux, making the thing run on your CPU can be problematic.

Application development should be started in parallel, on a simulator. In some cases this may be problematic, if the application is highly dependent on the hardware for its function.

Another problem unique to embedded systems is the host/target separation. Most embedded systems cannot host a development environment, and many cannot even host a sophisticated debugger; so most of the action occurs on a development system that runs on a PC or workstation. Some sort of remote debugging capability is usually provided to allow development tools on the PC to troubleshoot code running on the target. Getting this working, if you don't get it off-the-shelf, can be a pain. PrintfDebugging is far too common in embedded systems - and that assumes that your target has a working console device (most target boards include, at a minimum, an RS-232 port to facilitate low-level communications between the target and the development systems). Luckier embedded systems designers will have a network interface at their disposal.

Another issue is the Move to ROM. Most targets have the capability to boot downloaded code - either over a network interface, a serial interface, or a low-level BDM interface like JTAG or such; this is far more convenient for developers than burning ROMs (even if using EEPROMs) each time. But customers cannot avail themselves of such infrastructure, at some point the target has to be able to boot from its own ROMs. A common embedded AntiPattern is assuming that this migration is easy; it frequently can surprise you, as systems that work when booted in development mode don't work when booted from ROM. Getting this working early is a good idea.

A related issue: Field upgrades. Some embedded systems are not field-upgradeable, or are only upgradeable by a service technician; but many are customer-upgradeable. There are many ways for this procedure to go wrong, and many of them - if not handled carefully - can turn a functioning product into a paperweight (if the ROM contents are clobbered, and the product no longer will boot - including booting to a firmware upgrade mode, to allow a retry).

A final issue: Diagnostics. Since you, as the vendor, provide the BIOS, OS, and app (even if third-party), efficient manufacturing often requires diagnostic development, to help manufacturing operations detect and troubleshoot faulty product. Trust me, you want to catch these before they get shipped to customers; who get annoyed when the product they paid good money for is DOA.

Other than that, embedded systems are fun. No bloody DBAs to deal with, you get to get your hands dirty, and there are opportunities at all levels of the software stack.

[Note: The commonly used term in the industry is "embedded systems." Somebody moved that content over here. Oh, well.]

Yes, but you can't write - "We produce an EmbeddedSystems", but you can write "We work in EmbeddedSystems" Hence using the singular allows, in this case, both natural usages pointing to the same page.

See: EmbeddedSystemsEngineer, FirmwareEngineer, EmbeddedExtremeProgramming, EmbeddedJava, YtwokEmbeddedSystems, ExtremeProgrammingBareMachine, TheManyTypesOfPrograms, IsEmbeddedBehind