The Buzz on Embedded Development Productivity

Any embedded development discussion is going to be a discussion about  the "process": How does the programmer define the sequence of  operation; how does the CPU interpret the definition for execution; what  hardware architecture will be chosen; what preexisting aids, i.e.  hardware/software tools are available; and how do you manage it all, and  deliver a well-executed, properly operating target. All of this is what  I mean by the “process” i.e. “what is used, and how it’s used”.

"The  search for the Holy Grail" in embedded development is a search for a  more productive process. Recently, the buzz about this issue has been  about as subtle as a F-14 on full after-burner. Everyone is looking for a  way to improve the process, and there's been a lot of press on the  subject.

Historically, most process improvements have fallen into one of the following areas:

• Language:  higher levels of abstraction such as C, C++, JAVA; industry specific  such as Relay Ladder programming; ease of use for "normal" people such  as BASIC or functional block (flow chart) type programming

• Target  hardware: memory density; flash memory; higher throughput; lower cost;  improved functionality (peripherals); increased integration; etc.

• Development tools: assemblers; compilers; emulators; simulators; debuggers; integrated development environments; etc.

• Methodology: this has to do with the definition, and implementation of methods shown to provide productivity gains

A  discussion on the virtue of these “improvements” is difficult because,  among other things, the word improvement implies the “newer” thing is  “better”. For example I’ve almost never seen an article that says that C  is better than C++, yet on small, cost constrained systems, this might  likely be the case. Frequently people using the “latest” technology feel  that the improvement is universal, and should be applied universally.  This is a source of some of the zeal that sneaks into discussions  concerning language and processors. The truth is more complicated, and  requires a broader view of the objectives.

Recently there’s been  some buzz on a couple of "new ideas" that are significant: System on  Chip (SoC); and Platform Development. (SoC implies a single chip  implementation, platforms are more general and aren't necessarily single  chip) With both, you start with a known, pre-determined  hardware/software base. You then make changes and additions required for  the intended application. The improvement in productivity comes from  the fact that your starting point is pre-done, and is (hopefully)  trouble free. Also, as the platform is reused repeatedly, the developer  gains familiarity (productivity). And finally, if the platform covers a  wide application base, and is low enough in cost, it is possible to use  the platform to cover an entire range of product offerings. This "single  processor, single platform" approach provides a huge productivity  opportunity, as it makes it possible for a single embedded engineer to  design and support a wide range of products. (The alternative is having  the developer support multiple products using multiple processors, a  tall order, or having an embedded team, which is costly)

The  “platform” concept is not really new. Many will recognize that a PC  (embedded or not), with any commercial OS, is a platform. The difference  is that neither the PC hardware, nor most OS's, were originally  designed for the purpose of embedded controls. These newest SoC and  Platform architectures are being designed from the ground up for  embedded use.

The WRD ProductMaker is a development platform  designed specifically for the embedded controls market. Having spent an  entire career designing embedded control systems, its clear how  important reusability and system architecture is.

The ProductMaker  is a highly flexible hardware/firmware platform based on a powerful yet  inexpensive 8 bit microprocessor (Z180), pre-engineered schematics  (which cover most embedded control requirements), and an automated  firmware configuration process which not only contains all peripheral  drivers, task scheduler, floating point routines, & ISR's, keyboard  scanning, LCD/LED displays, Rom monitor, etc., but integrates these into  a seamless custom control engine that lets the system designed  concentrate on the application instead of the integration details.

This  platform is used extensively at WRD, and is key to WRD's ability to  provide high quality, high functionality, low cost custom embedded  controls, with short development times and low NRE.