The scenario:

You’ve been assigned the task of designing and producing an embedded device. You’ve been given time, cost and size constraints that impact your design. An initial analysis of the requirements leads you to the conclusion that a 32-bit processor with a relatively small amount of RAM and Flash are required. A bit of research shows that an ARM processor with 2MB of external Flash and 2MB of external RAM will meet your cost and size constraints.

Historically, you would select a SoC or a processor, memory components, and other required peripherals and design a system around them. This system would require a certain amount of low level coding to initialize it and get it ready to accept an application; that coding may be developed in a higher level language, such as C or C++.

Another option that is becoming more and more popular is an embedded module, such as the Digi ConnectME or the EmbeddedFusion Meridian. Although a bit costlier, these modules come with RAM, Flash, and a host of other peripherals. An advantage of these modules is they make PCB design easier, and typically come with an embedded OS, giving you immediate access to an API for your application. The net effect is your hardware design time is shortened and you only have to code in higher level languages, such as C or C++.

Application development is influenced by two primary factors, platform development environment, and language. There are many development platforms available, two of the most popular being Microsoft Visual Studio and the Open Source Eclipse platform. The most common programming languages for embedded development are C, C++, and Managed Code (Microsoft .NET and JAVA).

C is a low level language that gives the developer full control over the hardware, but at a price. It is not object orientated, there are few provisions for code re-use, and there are no built-in protections against common programming errors, such as null pointers, memory leaks, or bad assignments (= instead of == for example).

C++ is an improvement over C, being object oriented and promoting better code sharing and re-use, but it still has the drawback of letting a developer do things unwittingly that they really should not do, resulting in unexpected behavior. Application robustness is typically a function of how much pre-release testing you can afford.

Managed code raises the bar. Most programming errors and many of the programming tasks required by an application are common among all applications. This provides an opportunity for a managed code platform that provides a rich feature set comprised of these common requirements, and a chance to put in protection mechanisms that guard against these common mistakes. Historically, limits on processor speed and memory size have blocked the adoption of these managed code platforms for small embedded device development. Although available to the desktop development community for years, embedded developers have not been able to enjoy the advantages of these advanced platforms.

Recent increases in processor sizes and speeds, and declines in processor and memory costs make it possible to move these advantages into the embedded development space.