Systems Development

 

History & Development

With memory, input and output system components, integrated into the same chip as the processor, Microcontrollers find applications where a general-purpose computer would be too costly. A comparatively low-cost microcontroller may be programmed to fulfill the same role as a large number of separate components. Although in this context an Embedded System is usually more Complex than a traditional solution, most of the Complexity is contained within the microcontroller itself. Very few additional components may be needed and most of the design effort is in the software. Software prototype and test can be quicker compared with the design and construction of a new circuit not using an Embedded processor. An early mass-produced Embedded System was the Autonetics D-17 guidance computer for the Minuteman missile, released in 1961. Since then, Embedded Systems have come down in price and there has been a dramatic rise in their processing power and functionality.

 

Processors in Embedded Systems

Whereas ordinary microprocessors (µP) use separate integrated circuits for memory and peripherals, Microcontrollers (µC) have many more peripherals on chip, reducing power consumption, size and cost. Many different basic CPU architectures are used. Both Von Neumann as well as various degrees of Harvard architectures are used. RISC as well as non-RISC processors are found. Word lengths vary from 4-bit to 64-bits and beyond, although the most typical remain 8/16-bit.

 

Ready made computer boards

PC/104 and PC/104+ are examples of standards for ready made computer boards intended for small, low-volume Embedded and ruggedized systems, mostly x86-based. These are often physically small compared to a standard PC, although still quite large compared to most simple (8/16-bit) Embedded Systems. They often use MSDOS, Linux, NetBSD, or an Embedded real-time operating system such as MicroC/OS-II, QNX or VxWorks.  However, most ready-made Embedded Systems boards are not PC-centered and do not use the ISA or PCI busses.

 When a System-on-a-chip processor is involved, there may be little benefit to having a standardized  bus connecting discrete components, and the environment for both hardware and software tools may be very different. One common design style uses a small system module, perhaps the size of a business card, holding high density BGA chips such as an ARM-based System-on-a-chip processor and peripherals, external flash memory for storage, and DRAM for runtime memory. The module vendor will usually provide boot software and make sure there is a selection of operating systems, usually including Linux and some real time choices. Gumstix product lines are a Linux-centric example of this model.

Tools

As with other software, Embedded System designers use compilers, assemblers, and debuggers to develop Embedded System software. However, they may also use some more specific tools:

•             In circuit debuggers or emulators (see next section).

•             Utilities to add a checksum or CRC to a programme, so the Embedded System can check if the programme is valid.

•             For systems using digital signal processing, developers may use a math workbench such as Scilab / Scicos, MATLAB / Simulink, EICASLAB, MathCad, Mathematica,or FlowStone DSP to simulate the mathematics. They might also use libraries for both the host and target which eliminates developing DSP routines as done in DSPnano RTOS and Unison Operating System.

•             A model based development tool like VisSim lets you create and simulate graphical data flow and UML State chart diagrams of components like digital filters, motor controllers, communication protocol decoding and multi-rate tasks. Interrupt handlers can also be created graphically. After simulation, you can automatically generate C-code to the VisSim RTOS which handles the main control task and preemption of background tasks, as well as automatic setup and programming of on-chip peripherals.

•             Custom compilers and linkers may be used to optimize specialized hardware.

•             An Embedded System may have its own special language or design tool, or add enhancements to an existing language such as Forth or Basic.

•             Another alternative is to add a real-time operating system or Embedded operating system, which may have DSP capabilities like DSPnano RTOS.

•             Modeling and code generating tools often based on state machines

Software tools can come from several sources:

•             Software companies that specialize in the Embedded market

•             Ported from the GNU software development tools

•             Sometimes, development tools for a personal computer can be used if the Embedded processor is a close relative to a common PC processor

As the Complexity of Embedded Systems grows, higher level tools and operating systems are migrating into machinery where it makes sense. For example, cellphones, personal digital assistants and other consumer computers often an open programming environment such as Linux, NetBSD, OSGi or Embedded Java is required.

Debugging

Embedded debugging may be performed at different levels, depending on the facilities available. From simplest to most sophisticated they can be roughly grouped into the following areas:

•             Interactive resident debugging, using the simple shell provided by the Embedded operating system (e.g. Forth and Basic)

•             External debugging using logging or serial port output to trace operation using either a monitor in flash or using a debug server like the Remedy Debugger which even works for heterogeneous multicore systems.

•             An in-circuit debugger (ICD), a hardware device that connects to the microprocessor via a JTAG or      Nexus interface. This allows the operation of the microprocessor to be controlled externally, but is typically restricted to specific debugging capabilities in the processor.

•             An in-circuit emulator (ICE) replaces the microprocessor with a simulated equivalent, providing full control over all aspects of the microprocessor.

•             A complete emulator provides a simulation of all aspects of the hardware, allowing all of it to be controlled and modified, and allowing debugging on a normal PC.

•             For SoC designs, the typical approach is to verify and debug the design on an FPGA prototype board. Tools such as Certus  are used to insert probes in the FPGA RTL that make signals available for observation. This is used to debug hardware, firmware and software interactions across multiple FPGA with capabilities similar to a logic analyzer.

Unless restricted to external debugging, the programmer can typically load and run software through the tools, view the code running in the processor, and start or stop its operation. The view of the code may be as HLL source-code, assembly code or mixture of both.

Because an Embedded System is often composed of a wide variety of elements, the debugging strategy may vary. For instance, debugging a software- (and microprocessor-) centric Embedded System is different from debugging an Embedded System where most of the processing is performed by peripherals (DSP, FPGA, co-processor). An increasing number of Embedded Systems today use more than one single processor core. A common problem with multi-core development is the proper synchronization of software execution. In such a case, the Embedded System design may wish to check the data traffic on the busses between the processor cores, which requires very low-level debugging, at signal/bus level, with a logic analyzer, for instance.

Developing Embedded Systems - A Tools Introduction

Developing software and hardware for microcontroller based systems involves the use of a range of tools that can include editors, assemblers, compilers, debuggers, simulators, emulators and Flash/OTP programmers. For  a newcomer to microcontroller development it is often not clear how all of these different components play together in the development cycle and what differences there are for example between starter kits, emulators and simulators.

 

Beehive Multiprocessor System

Recently the chip-multiprocessor (CMP) architectures have arisen in consequence of both the difficulty to continue integrating the microprocessors and the increasing performance of the system-on-chip technologies such as FPGA. To accomplish with the Moore law, it is necessary to move from the “smaller and smaller” to “more and more parallel”. Beehive is the multiprocessor system build with single Honeycomb processors.

 

To continue increasing the speed of processors, instead of reducing the size of microprocessor’s resources, these resources can be used to integrate simple, small components that can operate in parallel, with the objective of   building a large, reconfigurable CMP system, made of small components that are not necessarily fast but are small.