Microcontroller Applications -> Software vital in Net-linked MCU apps

Software vital in Net-linked MCU apps
By David Hudson, Principal Software Engineer, Ubicom Inc., Mountain View, Calif., EE Times
May 21, 2001 (2:19 p.m. EST)
URL: http://www.eetimes.com/story/OEG20010521S0063

Developing Internet-connected device applications is a daunting task for embedded-systems designers. Few have more than a limited knowledge of the Internet Protocol and the various related protocols that form a working IP stack.

A wide range of IP stacks and embedded operating systems is available for use in such applications. But in many instances the integration of several third-party products with silicon from one or more suppliers and, finally, with the application software can prove a trying experience.

When the same requirements are applied to 8-bit systems, the potential permutations of microcontrollers, peripherals and software become staggering. In many instances, because of cost-imposed constraints on memory, processing and I/O resources, different projects will often need to use different hardware and software combinations.

When designing the Ubicom IP2022 Internet processor and its ipModule software, we set out to pro vide a complete platform with which to implement such device applications while eliminating much of the associated complexity. That requirement has, in turn, led to some architectural features that are not found in more conventional designs.

A primary goal in the design of this 8-bit microcontroller was that it support fully deterministic software execution; that is, every instruction would execute in a specific, predictable amount of time, usually one clock cycle. Additionally, however, interrupts may occur at any clock cycle, including midinstruction during longer operations. The benefit of this strategy is that when combined with a 100-MHz CPU clock speed and a set of shadow registers that eliminates the need for most save and restore operations, the design can deterministically process very large volumes of interrupts (more than a million interrupts/second is feasible).

The ability to accurately handle such high volumes of interrupts allowed us to eliminate many of the on-chip hardware pe ripherals typical of traditional microcontrollers, substituting software-based virtual peripherals (VPs) for the hardware. A VP software module uses some source of interrupts-either an on-board timer or a source external to the device-to sequence I/O pins in the same way that a hard peripheral would in other architectures.

While soft implementations of such features are possible in many microcontrollers, they have usually been secondary to integrated hardware implementations because of the high processing costs and low levels of performance conventionally associated with them. Typical uses for VPs are such functions as UARTs, I2C buses or pulse-width modulators (PWMs).

Among the peripheral functions that we did include on-chip in silicon, because of their importance to the design of the chip as an Internet processor, were two serializer/deserializer (Serdes) units. The units pr ovide the ability to implement a wide range of serial-bus types, including 10 Base T Ethernet, USB and GPSI. In addition, they may be used to support UARTs or high-speed SPI channels with very low processing overhead.

But rather than implement serializer/deserializer hardware specific to particular application requirements, the two Serdes units use the same strategy as the VPs, relying extensively on deterministic software to handle much of the complexity associated with whatever serial bus is being used. A major benefit from the use of software is that a VP can provide a great deal of design flexibility. A VP implementation can employ software to provide compatibility with devices that implement different versions of serial-bus standards or that exhibit minor design quirks.

Boosting performance

Given that we wanted the new microcontroller to support general-purpose IP networking and VPs in addition to a device's own application software, there was some pressure to maintain hig h performance. In addition to selecting instructions that efficiently execute software written in C and using process technology that would allow it to operate at a peak throughput of 100 Mips, we designed the IP2022 with quite large amounts of on-chip memory: 64 kbytes of flash and 4 kbytes of SRAM. Since the flash is unable to support operation at 100 MHz directly, an additional 16 kbytes of RAM is also provided and may be used for code execution at full speed or as a data space for such functions as network packet buffering.

A number of elements of the instruction set are unusual, but one of the most noteworthy is that all accesses to the on-chip data SRAM take only one CPU cycle. That has some surprising consequences. For example, using a C function-call/parameter stack proves more efficient than the more conventional use of registers for passing parameters to functions. That characteristic is helpful when developing software because engineers can concentrate on solving problems rather than on ho w to move data around in the fastest way. Memory bandwidth for our device exceeds that of a lot of 16-bit processors and even some low-end 32-bit ones.

Having designed the instruction set to run C code efficiently, there was a need for a C compiler, assembler, linker, debugger and so on. In this instance the tools selected were GNU tools, most notably the C compiler (gcc), assembler (gas), linker (ld), library manager (ar), object-code inspection tools (objdump) and debugger (gdb). While the choice of what is traditionally viewed as a 32-bit tool set may seem a little unconventional, the GNU tools provide a well-known development environment that is able to produce efficient, reliable object code and subsequently debug it.

Porting the gcc C compiler has presented some interesting challenges, because elements that are conventionally single instructions on 32-bit platforms often require between four and eight instructions with an 8-bit target such as the IP2022. While that makes such a port a l ittle problematic, it also presents significant opportunities for optimizations. One interesting aspect is that gcc's pattern-matching code generation has made it possible to identify and implement such optimizations very effectively. An advantage of developing software with a free-software tool such as gcc is that the IP2022, as it continues to evolve, will quickly be able to take advantage of any new features or optimizations.

The use of the gdb debugger is also noteworthy. Unlike many 8-bit platforms, the IP2022 was designed so that a developer could debug a working system without the need to use simulation targets or in-circuit emulators. One particularly useful example is that run-time assertions provided within the Ubicom software environment can be configured to trigger a break in execution and subsequent post-mortem analysis.

The final requirement for a fully integrated Internet-connectivity solution was a set of software modules and an RFC-compliant IP stack (the requests for comment being the Internet Protocol standards). Fairly early on, it became clear to us that rather than just provide an IP stack alone, we should also deliver a small operating system to provide standard services to bind together the IP stack, peripheral support and other services.

Resource limits

A key problem in supplying the OS and IP stack software for an 8-bit processor is that resource constraints within the target CPU require design compromises. Typically, such software starts with a set of limiting assumptions about how many tasks might run within a pre-emptive multitasking OS or how many Transmission Control Protocol (TCP) sockets should be available.

When assessing many of the available third-party software solutions, we concluded that most would be unable to meet our requirements for flexibility. One application, for example, may not have any tight real-time requirements and could thus use a simple polling loop instead of tasks, but might need to support 10 concurrent TCP connections. In another application, however, the requirement might be for only one or two User Datagram Protocol (UDP) ports, but five prioritized tasks may need to be arbitrated to meet some real-time objective.

A further complication when considering third-party solutions was that the virtual peripherals present some unusual considerations. Most notably, while it is possible to mask all interrupts within the IP2022, doing so removes some of the determinism that makes the VPs so effective. In many circumstances (for example, in a UART), a few clock cycles of jitter may not matter, but in others the same jitter may lead to problems. All of the conventional OS solutions that we identified relied on periods during which interrupts needed to be masked and were thus unsuitable.

Another early decision was the adoption of the ipModules concept. The ipModules are libraries that implement a particular type of functionality, currently providing core operating systems services, an IP stack, support fo r an Ethernet VP, and other I/O services and a Web server.