From time to time on comp.arch.embedded the discussion turns to the definition of embedded system . The thread sometimes lasts for several weeks before devolving into flaming shock and awe. Perhaps more difficult than defining an embedded system is the problem of defining an embedded system developer . Where it gets sticky is in defining the scope of a developer's responsibilities and expertise.
Most embedded developers boast a BSEE, even though their primary job may be firmware rather than hardware design. One thing is certain: they have to be Renaissance people: they are manifestly cross-discipline individuals with expertise in a broad range of skills embodying hardware and software design. At Embedded Systems Conferences, that point is driven home by the number of people attending courses that range from C++ to Verilog and from 8051 programming to SoC design.
This week Embedded.com features an article offering tips for reviewing schematics written by a firmware developer. As is so often the case, there are people outside of the hardware design group who have valuable insights to offer because their perspectives differ from those of hardware designers. Since those perspectives are tempered by a degree of hardware expertise, their contributions can be valuable.
Speaking of cross discipline, Jim Turley rhapsodizes this month over a processing beast that seems to have an Ethernet interface, a USB controller, both PCI and ISA bus interfaces, a PCMCIA slot, a synchronous DRAM controller, and an assortment of UARTs. In point of fact, the chip has none of that hardware. It's all done in software, as you will discover in “Soft peripherals.”
While Jim describes a processor that opts for software solutions in places where hardware is typically implemented, Niall Murphy, in a chronicle of his experiences with CAN makes the case that a more comprehensive hardware solution, such as CAN, leads to simpler, and hence more reliable, software.