Page 247 - Embedded Microprocessor Systems Real World Design

an occasional synchronization message that says something like “processor 1 just
counted tick number 1024” to keep everything together. Since clock drift is often
temperature dependent, two processors that are remotely located with respect to
each other will be more prone to cumulative errors.

Extreme Isolation In a multiprocessor design, it is tempting to isolate functions
so that one processor handles all of one function, independent of the other proces-
sors in the system. This makes for a modular design. However, in a design where
there is a chance that things might change, make provision for the master control
CPU (if there is one) to alter parameters. In the wood block example, the planer
might plane the blocks to a certain smoothness. However, once in production, it
may be necessary to change that parameter. This might be because a new type of
wood is encountered or because a sensor went out of production and the new
sensor isn’t quite identical.
In a case like this, it is a good idea to make the smoothness parameters (however
they are measured) modifiable. You might have the system reset to the default pa-
rameters, but allow the master CPU to change them if necessary. Of course, it is
difficult to predict what might change, but some effort in this area often pays off.
This approach is especially helpful in a system in which the master controller is
a PC with software that can be downloaded or upgraded via CD-ROM, while the
lower-level controllers are PROM-based microcontrollers. For many companies,
changing the microcontroller code means sending out a service engineer (which
is expensive), while the host PC code might be upgraded just by sending the soft-
ware to the customer.
For the same reasons, you may want to consider adding hardware that would
allow the master controller to reprogram the lower-level processors. This implies
the use of microcontrollers that are capable of incircuit programming, of course.

Locking Problems I have already mentioned data corruption in DPRAM
systems, but let’s look at a specific example here. I got a call one day about a
dual-processor system that had been designed by an outside design house. When
the firmware was upgraded, an intermittent problem suddenly showed up. It did
not take long to determine that the problem was corruption in the DPRAM. One
processor was attempting to perform a read-modifj-write operation on a sema-
phore. Occasionally, the other processor would attempt to write to the semaphore
in between the read and write operations of the first processor. This corrupted the
memory.
The processors had a lock output that indicated when the CPU was attempting
an operation that could not be interrupted; the DPRAM controller was supposed
to lock out the second GPU while the first was accessing the memory. However,
a design flaw in the controller allowed the second CPU access to the memory

228 Embedded Microprocessor Systems