Michael Barr: Programming Embedded Systems in C and C++

Of course, the smaller the register width, the more likely it is that the processor employs tricks like multiple address spaces to support more memory. A few hundred bytes just isn't enough to do much of anything. Several thousand bytes is a more likely minimum, even for an 8-bit processor.

Intel's 80188EB processor is a special version of the 80186 that has been redesigned for use in embedded systems. The original 80186 was a successor to the 8086 processor that IBM used in their very first personal computer —the PC/XT. The 80186 was never the basis of any PC because it was passed over (in favor of the 80286) when IBM designed their next model — the PC/AT. Despite that early failure, versions of the 80186 from Intel and AMD have enjoyed tremendous success in embedded systems in recent years.

Of course, the rate of blink is completely arbitrary. But one of the things I like about the 1 Hz rate is that it's easy to confirm with a stopwatch. Simply start the stopwatch, count off some number of blinks, and see if the number of elapsed seconds is the same as the number of blinks. Need greater accuracy? Simply count off more blinks.

Unfortunately, the exact syntax of inline assembly varies from compiler to compiler. In the example, I'm using the format preferred by the Borland C++ compiler. Borland's inline assembly format is one of the best because it supports references to variables and constants that are defined within the C code.

Used this way, the term "target platform" is best understood to include not only the hardware but also the operating system that forms the basic runtime environment for your software. If no operating system is present — as is sometimes the case in an embedded system — the target platform is simply the processor on which your program will be run.

Beware that I am only talking about static linking here. In non-embedded environments, dynamic linking of libraries is very common. In that case, the code and data associated with the library routine are not inserted into the program directly.

It is interesting to note that Borland's C++ compiler was not specifically designed for use by embedded software developers. It was instead designed to produce DOS and Windows-based programs for PCs that had 80x86 processors. However, the inclusion of certain command-line options allows us to specify a particular 80x86 processor — the 80186, for example — and, thus, use this tool as a cross-compiler for embedded systems like the Arcom board.

However, being free, it is also a lot cheaper than a more general locator.

The actual interaction with Turbo Debugger is no different than if you were debugging a DOS or Windows application.

The toggleLed function wouldn't have required a single line of assembly code if the P2LTCH register had been memory-mapped.

This situation gets even more complicated if you consider the various memory models provided by some processors. All of the examples in this book assume that the 80188's large memory model is used. In this memory model all of the specifics I'm about to tell you hold for all pointer types. But in the other memory models, the format of the address stored in a pointer differs depending upon the type of code or data pointed to!

A few processors actually have the first few instructions of the ISR stored there, rather than a pointer to the routine.

In order to make the example in Chapter 2, a little easier to understand, I didn't show any of the initialization code there. However, it is necessary to get the hardware initialization code working before you can write even simple programs like Blinking LED.

128 kilobytes is one-eighth of the total 1-megabyte address space.

The divisor is simply a binary representation of the coefficients of the generator polynomial — each of which is either or 1. To make this even more confusing, the highest-order coefficient of the generator polynomial (always a 1) is left out of the binary representation. For example, the polynomial in the first standard, CCITT, has four nonzero coefficients. But the corresponding binary representation has only three 1's in it (bits 12, 5, and 0).

There is one other potential twist called "reflection" that my code does not support. You probably won't need that anyway.

There is one small difference worth noting here. The erase and write cycles take longer than the read cycle. So if a read is attempted in the middle of one of those operations, the result will be either delayed or incorrect, depending on the device.

Specifically, it represents the number of clock ticks remaining after all of the timers ahead of it in the list have expired.

Astute readers might recall that in Chapter 5, I stated that the PCB was located in the I/O space of the 80188EB processor. However, because memory-mapped registers are more likely in a device driver situation, I've relocated the entire PCB to physical address 72000h, in the memory space. This new location will be assumed for the rest of the book. To see how this relocation was performed, take a look at the constructor for the i8018xEB class.

A word of caution about waitfor: this implementation spins its wheels waiting for the software timer to change to the done state. This technique is called busy-waiting, and it is neither elegant nor an efficient use of the processor. In Chapter 8, we'll see how the introduction of an operating system allows us to improve upon this implementation.

Remember, task creation is one of our scheduling points. If the scheduler has been started, there is also a possibility that the new task will be the highest priority ready task.

Please don't write to complain. I'm not maligning either of these operating systems. In fact, from what I know of both, I would highly recommend them as high-quality, low-cost commercial solutions.

There is a race condition within the earlier toggleLed functions. To see it, look back at the code and imagine that two tasks are sharing the LEDs and that the first task has just called that function to toggle the red LED. Inside toggleLed, the state of both LEDs is read and stored in a processor register when, all of the sudden, the first task is preempted by the second. Now the second task causes the state of both LEDs to be read once more and stored in another processor register, modified to change the state of the green LED, and the result written out to the P2LTCH register. When the interrupted task is restarted, it already has a copy of the LED state, but this copy is no longer accurate! After making its change to the red LED and writing the new state out to the P2LTCH register, the second task's change will be undone. Adding a mutex eliminates this potential.

Recall that the timer hardware is initialized only once — during the first constructor invocation — and thereafter, the timer-specific registers are only read and written by one function: the interrupt service routine.

You might be wondering why this method accepts an integer argument rather than a character. After all, we're sending 8-bit characters over the serial port, right? Well, don't ask me. I'm just trying to be consistent with the ANSI C library standard and wondering the very same thing myself.