THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

THE SHARC IN THE C

by Michael Smith

Start ý Register Comparison ý Memory Access ý Modify and Volatile Registers ý Length and Base Registers ý Hardware and Software ý Interrupt Handling ý Sources and PDF

In a recent project that I did, I became interested in developing DSP algorithms suitable for producing an improved sound stage for headphones. Listening to music through a standard headset (see Figure 1) leaves the listener with the impression that the music is inside their head, a different feeling than listening to the same music while using speakers. However, the sound stage of the headphones can be drastically changed if the phase and amplitude of the audio signal are modified before being sent to the ear. For example, the perceived position of a mono-sound signal can be altered by modifying the relative time of arrival of the same sound at the left and right ear.

Figure 1ýThe sound source is perceived in the center of the head if exactly the same sound comes from both left and right earphones. If the sound is delayed before being sent to the left earphone, then the perceived position of the sound source shifts to the right side of the head. Furthermore, modeling of the audio channel using FIR and IIR filters can move the perceived sound out to a virtual speaker in front or back of the listenerýs head. [1]

Creating the effect of a series of virtual speakers with room reverberation can be handled using extensive DSP techniques, such as implementing a series of finite impulse response (FIR) and Comb filters, a cross between FIR and infinite duration impulse filters (IIR). Sampling frequencies must be 44 to 48 kHz for good sound quality. A specialized architecture DSP processor, or sound card, is needed to process one sound bite before the next bite arrives.

For efficient code development, you need to make the appropriate language choice for the various system components. One line of debugged code takes roughly the same time and effort in any language. This means that, other things being equal, developing modules using assembly language should be avoided when higher-level languages are available.

There are a number of different components needed for this sound stage project. Standard C for the GUI interface is used to modify speaker and room characteristics. The DSP components are best handled as independent interrupts using hardware circular buffers and other custom memory addressing to take advantage of special processor architectural features. Setting up the hardware might require calling an assembly code routine directly from the higher-level language.

You must become aware of the interaction between assembly code and the C environment to handle coding in such an embedded environment. This interaction for a CISC processor was detailed in the article I wrote, "Some Assembly Required," (Circuit Cellar, 101). However, interfacing between assembly code and C functions is different on newer DSP chips because of the new architectural features in DSP processors.

On the positive side, additional data and address registers are available. Specialized hardware allows fast switching between subroutines or handling zero-overhead loops. On the negative side, many of the new processor features are not directly describable using the standard C language. Whatýs the syntax for accessing an array using the bit-reversed, circular buffer address register operations? Some of the speed-improving hardware features impose restrictions that canýt be handled through a standard C programming model.

In this article, I look at the assembly code of C and assembly code interfaces on Analog Devicesý 21061 SHARC. These are compared to those found with the Software Development Systemýs (SDS) Motorola 68K CISC C compiler.

The SHARC assembly language is C-like in format, which makes the comparison relatively straightforward. Only C functions calling assembly code functions will be considered. There is little advantage in going in the opposite direction because the whole point of switching to assembly code from a C subroutine is speed.

NEXT