An embedded system is just a computer buried inside some other product. Surprisingly, you can know a great deal about programming and computing and still get lost in the arcane world of embedded systems hardware software firmware differ. In the world of embedded systems programming, countless details — both hardware- and-related — make the development process seem like a path that few have traveled and even fewer have survived. How do software,firmware and hardware? How in the world does a 100,000-line program end up inside a device smaller than my fingernail? What is flash memory and why do I need a cache? What is the difference between a task and a process? Do I need to worry about reentrancy? As we progress through Embedded Systems Firmware Demystified, you will come to see that these questions are not as complex as they first appear.

Embedded systems programming spans a wide range of activities from building programmable logic at the most concrete end to writing a UNIX process at the most abstract end. Bracketed by these poles, the industry has exploded in the last 20 years. In the late seventies, assemblers were considered luxuries. A typical embedded system used less than 64Kb of system memory (bits, not There was no hardware hand-off to the firmware developer. The same person that drew the schematics and soldered the prototype also wrote the firmware that pulled the whole thing together. By the time Intel introduced the 8085 chip, it was clear that those pesky microprocessors were here to stay. In the eighties, the Motorola versus Intel CPU wars started, and C became a popular choice for the elite few who dared to mess with a high-level language and an EPROM programmer. Today, microprocessors are everywhere and range from the 4- and 8-bit workhorses still dominating the industry to 1GHz 64-bit processors that almost need a freezer (microprocessor-controlled, no doubt) to keep them cool.

Over the years, the complexity of these systems has snowballed. The industry has transitioned from programming a DEC PDP machine with binary codes on the front panel to applying object-oriented design to a microcontroller in a toaster. If you let the trend get to you, the changes can seem frazzling. There are microprocessors and microcontrollers; RAM, DRAM, and SDRAM; pipelining and superscalar; EPROM and flash memory; RISC and CISC; and RAS and CAS and cache — and that’s just the beginning.

Now, everything from toothbrushes (no kidding) to fighter jets are likely to have a version controlled by a microprocessor of some kind. With this trend come tools and technologies. One can easily be overwhelmed by the available choices in hardware (integrated circuits that the firmware must make work) and software (tools that are used to build the firmware application).

In my opinion, coding is growing up to a wild range in this world.

somebody writes code that runs on 8051 mcu;

somebody writes code that runs on arm;

somebody writes code that runs on rtos...real time operation system...ucos-ii, ecos,uclinux,vxworks...

somebody writes code that runs on os...windows xp, linux, unix...

In the past years, i write code with 8051 mcu to make products. my code need to access each special funtion register in 8051,then 8051 mcu works, and then the platform works.

the term firmware used to mean that code runs on a plateform without a os. Before os runs, there must be a firmware runs on that plateform. it just like bios in a mainboard.(bios is firmware that runs on mainboard will check cpu,chipset,hd,floppy,sdram....when every thing is ready bios will go to load os image into sdram to run that whole os.)

the term software used to mean that code run on os. you don't need to take care hardware level issue. just only need to call functions that are built in os.

i think this is the major difference between firmware and software.

in 8 bit mcu world, os is not needed. and code called firmware runs on it.

in 32 bit mcu world, os is needed. and code called software runs on os that runs on the platform. before os image loaded to run, there need a bootloader to load os image into sdram. this bootlaoder is a firmware, and its job is to load os image into sdram. after this job is done, bootloader becomes useless and is like a piece of garbage in memory.