Microcontrollers and DSPs - Will the Two Worlds Intersect?
- Microcontrollers and digital signal processors (DSPs) are the main engines of the deeply embedded development world. Microcontrollers are primarily used in control-oriented applications that are interrupt-driven, sensing and controlling external events. DSPs, meanwhile, are traditionally found in systems that require the precision processing of analog signals. As today's systems gain in complexity, microcontrollers are being given some signal processing capabilities while more DSPs are capable of executing real-time event-driven functions, both while still performing their respective primary tasks. At issue here is - where do these worlds intersect, and when if ever will microcontroller engineers start using DSPs for real-time tasks?
By William A. Giovino, President of CPU Technologies Inc.
Microcontrollers and digital signal processors (DSPs) are the main engines of the deeply embedded development world. Microcontrollers are primarily used in control-oriented applications that are interrupt-driven, sensing and controlling external events. DSPs, meanwhile, are traditionally found in systems that require the precision processing of analog signals. As today's systems gain in complexity, microcontrollers are being given some signal processing capabilities while more DSPs are capable of executing real-time event-driven functions, both while still performing their respective primary tasks. At issue here is - where do these worlds intersect, and when if ever will microcontroller engineers start using DSPs for real-time tasks?
A typical control-oriented task for a microcontroller is to control external events. The external environment is detected via input pins, either digital CMOS I/O or analog (A/D) inputs. The source of the signals to these pins comes from switches, analog sensors, pulse generators. Each input represents a piece of information on the status of some outside event. Outputs are sent to actuators, relays, motors, etc. In between is the trusty microcontroller, analyzing the inputs and the present state of the system, determining when to switch on and what to turn off. The software that does all this, that makes these decisions, does so in mostly a conditional fashion; that is, conditional jumps and heavy bit manipulation and shifts are the heavy staples of deep embedded control (I'm counting interrupts as a condition here - program flow is altered upon the occurrence of an external event).
Traditional DSP applications, on the other hand, are as subtle as a freight train - they are brute force mathematical applications, pure and simple. DSP cores are crafted to be number crunchers, and to that end they do two things very well: first, a DSP core can perform math functions, especially multiplies, extremely quickly; and second, a DSP needs to continuously feed the number-crunching computational units so that they can continue to crunch away. It is pursuit of the latter functionality that makes the programming model of a DSP look all so unfriendly when compared to a microcontroller.
In today's embedded world, control-oriented tasks have traditionally contained just a microcontroller, but some applications are adding a DSP accessible to the microcontroller's external memory space to speed processing of math-oriented tasks. Examples include precision motion control, robotics, hard disk drives, certain airbag systems, and some electrical meters. These systems are primarily control-oriented, with the DSP acting as a math co-processor to the microcontroller.
In other applications, the microcontroller and the DSP share the load equally in managing different parts of the system. At present, this is happening in many of the emerging high-growth application areas, such as digital cameras, CCD document scanners, and cellular phones. Note also that, in this case, "high-growth" also translates to "cost sensitive."
So, in these cost-sensitive applications, management harasses the responsible engineers and asks them, "Why can't we do this application with just one processor? Wouldn't that save money? And where did you get that weird screen saver?" After explaining the screen saver, management is told that one core can't be used because either it's technically infeasible given the constraints of the system (real-time could not be maintained), or it would be impractical, and this is often the case. But in reality, many of the emerging applications can be served, and in some cases are being served, using just one core. There are two philosophies to this.
The first is to take a microcontroller and add DSP functionality to it. Examples of this are the Hitachi SH3-DSP and the Siemens TriCore. These will serve where the math is not too intense. The second solution is to use a DSP and have the DSP perform control-oriented tasks while also performing the computations needed for the system. The DSP also needs to have the basic on-board peripheral sets found on most microcontrollers - a UART, SPI for I/O expansion, and at least one timer. In systems where the computations are leaning towards the hard-core math oriented, the most cost-effective solution may be to use a DSP.
Microcontroller software engineers shudder at the thought.
Why is it that traditional microcontroller engineers shy away from using DSPs? Two main reasons. First, the DSP does not have as friendly a memory model as a microcontroller. By friendly I don't mean the DSP will take the engineer to the cafeteria and buy him a coke; "friendly" in this case translates into either a.) lots of general-purpose registers or b.) a small number of specialized ones. DSPs have lots of specialized registers and multiple buses - Ugh! Second, to the software engineers, the microcontroller or DSP is not just a square piece of plastic. In engineering reality, to the software engineer the core is their PC screen and keyboard and all the development tools that are connected to it - compiler, debugger, emulator, etc. The programming model of the core exists as fantasy in the pages of the databook; it comes alive only in the development tools. And the big hit here is that the quality of DSP development tools is not up to par with some of the excellent microcontroller development tools available today. And as we all know, the quality and the features of the development tools directly translates into time-to-market.
The shift is happening. Some DSPs, notably selections from Texas Instruments and Zilog, are now finally integrating peripheral sets commonly found in microcontrollers. Also, under close observation, DSPs have some capabilities that microcontroller software engineers have always dreamed of. Features such as zero-overhead loops, hardware buffer management, barrel-shifters, and bit-reversing hardware are DSP features that microcontroller software engineers would love to see in their favorite micro. However, while technical features of the core (number of buses, register architecture, etc.) help early on the evaluation process, the final selection criteria when choosing a new core is based on real-world usability - that is, development tools. And that is where the real selection criteria lies. Compilers that are easy to use, with emphasis on stability, optimizations, and quality of code; emulators and debuggers with emphasis on stability and usability rather than features. Nowadays, these are the things that really make a difference when choosing a core. If you're like me (which would be a scary thing indeed), you prefer development tools that focus on stability and basic functionality, rather than sacrificing them on the altar of new (buggy) features that make a great sales brochure.
It comes down to development tools. Many microcontroller engineers would rather not get too close to that DSP architecture so they'd prefer to program the DSP in C rather than assembly. Therefore, to reach a microcontroller developer an efficient C compiler is a must. A powerful debugger and emulator, one that gives visibility to all of the DSPs internal buses, is also required. Alas, we are getting there, but DSP development tools are still not up to the standards of today's top-of-the-line microcontroller development tools, though tool suites like Go-DSP's Code Composer are rapidly closing the gap.
So, what it comes down to is, for a microcontroller software engineer to use a DSP in his application the DSP has to look like his friendly microcontroller (or at least buy him a coke).
William A. Giovino is President of CPU Technologies Inc., a consulting firm specializing in tracking technical trends in the microcontroller industry. He manages Microcontroller.com, and has over twenty years experience in the embedded industry in both technical and product development roles. Giovino holds a BSEE from Syracuse University. When he's not working on his website, he is usually out driving his SHO somewhere really fast.
Click to Learn More
Created:8-Nov-2002,
· Views: 33291 › ClickThrus: 10464
Related Categories
Follow @BGiovino
Technical Writing Services
Creative Technical Writing services offered. Easygoing, experienced professional looking for clients.
Looking for an experienced technical writer to capture your target audience? A writer that is comfortable meeting your schedule and can be trusted with your business objectives?
Writing is like golf; most people can do it, but few can do it proficiently and professionally.
Resources
Microcontroller.com values users' privacy and doesn't share user data with third parties
LEGAL GIBBERISH: Copyright ©
1996-2024 CPU Technologies.
All Rights Are Really Reserved, so please contact us for usage and copy permission, O.K.? Some statements are covered under the United States Fair Use act.
And thanks for reading these tiny red letters.
"Semper excretio, solo profundum variat"
All Rights Are Really Reserved, so please contact us for usage and copy permission, O.K.? Some statements are covered under the United States Fair Use act.
And thanks for reading these tiny red letters.
"Semper excretio, solo profundum variat"