Navigation bar
  Start Previous page  12 of 15  Next page End Home  2 3 4 5 6 7 8 9 10 11 12 13 14 15  

Copyright Ó 2001 Microcontroller.com. All Rights Reserved.
March 2001
Contact Microcontroller.com for reprint and copy permission
Systems that require only basic control, used to determine which path of data flow the
program will take, are simple and commonly implemented in many digital signal
processing systems. All that is required is efficient implementation of program control
routines (conditional jumps and test instructions) and an I/O port for control and
detection of external events.
However, there is a serious gating factor that prevents most DSPs from being used in
real-time control: lack of necessary peripherals for perform external control and
communications. Most light-duty real-time control systems require a minimum peripheral
set of a reload timer for software control loops, UART for external serial
communications and debug, & an SPI for serial memory expansion and control of
external drivers. 
Real-time control in a DSP can be enhanced in a number of ways:
ü
General-purpose registers to streamline control software flow and 
facilitate ease of programming
ü
Quality development tools for efficient control logic implementation
ü
In-system debugging features for product verification of control processing
ü
MCU peripherals such as watchdog timer, multifunction timers, UART, and
SPI allow communications and external control & expansion, part of hard-
core microcontroller functionality.
ü
True bit manipulation (set, clear, test), not just on core registers but on
ports and SFRs significantly enhances data throughput and reduces code
size dramatically.
The challenge with 8- and 16-bit DSPs is to perform the entire application, which
includes both signal processing and real-time control, in the DSP. A DSP software
engineer will not hesitate to incorporate control-oriented software into the DSP of a
signal processing system, provided at the outset the engineer is convinced that the
critical processing and flow of digitized data will not be affected. This is a simple issue.
However, a microcontroller engineer, despite market surveys to the contrary, will have
to be convinced before moving to a DSP for their next project. As stated before, an
engineer totally familiar with DSPs is willing to make a choice mostly based on technical
merits. But for a microcontroller engineer, there are significant business and
development issues that far outweigh device technical merits.
A microcontroller engineer prefers a regular memory model that has many general-
purpose registers. A DSP has mostly special-purpose registers. The most friendly way
to program such a memory model is in C. However, a traditional DSP programming
model does not lend itself to C compiler efficiency; quite the contrary, the typical DSP
programming model works against implementing significant code size optimizations. In
addition, the quality of C compilers available for DSPs vary greatly: Many produce
stable code with simple optimizations; some compilers seem O.K. at first look, but as
with many development tools flaws may be discovered six months into development,
and some DSP C compilers seem unable to compile even once without generating
errors.
Microcontroller.com White Papers Previous page Top Next page