This is an article that I wrote for QEX , The ARRL Experimenter's Exchange. It appeared in Issue No. 162, August 1995, p:14-20. (ISSN:0886-8093 USPS 011-424). This is copyrighted material.
This article is about the Motorola DSP56002EVM - a low cost, powerful DSP evaluation module (EVM) intended for those experimenting with digital signal processing (DSP). It is ideally suited for filtering CW and EME signals, audio processing applications such as denoising and autonotching, DSP modem work for HF digital, VHF/UHF modems for use in terrestrial and satellite applications. The article covers hardware and resources for application development and presents a collection of advanced DSP applications ready for amateur radio experimentation.
One way to learn about new computer hardware, especially processor chips, is to actually try your hand at programming them. Unfortunately, for an amateur experimenter with limited resources, mastering a complex processor like the Motorola 56002 DSP, is a formidable task. This is not something for the faint of heart.
Recent introduction of lowcost EVMs by DSP chip manufacturers, however, has helped in making DSP technology available for experimentation. These EVMs include sufficient educational materials to get you started, i.e., a small printed circuit card that contains the DSP chip, software to develop and evaluate educational programs, and further essential technical reference material. In an amateur radio environment where cost and availability are major factors, these EVMs have been received with great enthusiasm. The DSP56002EVM is Motorola's entry into this market.
The DSP56002EVM may be used either as a DSP development platform or for a freestanding application when using its onboard E(E)PROM memory. The DSP chip used on the EVM has an impressive track record in communications engineering. Considering that its DSP chip is from the same Motorola DSP family as DSP chips used in the HAL PCI-4000 (8), AEA DSP 1-232, DSP 2-232 (9), and the DSP-12 (10) - even commercial military products. If judged by these success stories, the M56002 presents splendid opportunities as it offers higher clock speed besides the advantages of its on- chip hardware emulator.
The computing engine of the DSP56002EVM is a 40 MHz M56002 DSP. This is a 24-bit processor, meaning that each instruction is 24-bits wide. Instruction code is kept in a separate memory space, called the "P"-space, short for program space. Two separate independent data spaces, "X" and "Y" are available. This is called Harvard architecture; the type of memory arrangement where the data and code spaces are separated. This is quite different to Von Neumann architecture as used for example on the 80x86 processors. Harvard architecture, however, is typical for DSP's and allows for extensive instruction parallelism.
The value of this parallelism becomes evident when one considers that the strength of DSP processors lay in their ability to multiply and accumulate (MAC) very efficiently. The M56002 scores high in this regard. It can multiply two operands, accumulate the result, fetch two new operands from its two independent data spaces, do address adjustment, and fetch the next instruction - all in one clock tick. For a 40 MHz M56002 this happens at a rate of 20 million times per second. Other DSP chips may have similar features, however, having two data spaces and a 24-bit code/data architecture is a distinquising feature of the M56000 family.
The 24-bit architecture of the M56002 allows for a richer instruction set than comparable 16-bit DSP's. It also allows for an impressive selection of extended addressing modes. These addressing modes are available in one-word instructions also two- word instruction format. These choices eventually become a tradeoff between ease of programming and programming for efficiency for which instruction format to use. Obviously additional dynamic range of a 24-bit wide data path (144.5 dB) over a 16-bit wide data path (96.3 dB) may prove valuable in certain applications. Higher computational accuracy, or perhaps the ability to detect weaker signals buried in noise, is possible.
The M56002 allows for a considerable degree of flexibility in interfacing configurations. Access by the outside world to the DSP is through several I/O pins, arranged as general-purpose I/O ports named, "PA", "PB", and "PC". Depending on the application, however, several of these I/O pins double up for use as signals for onboard peripherals such as a synchronous serial interface (SSI), or serial communications interface (SCI). When using these on-chip peripherals in applications, some of these I/O port pins become dedicated and are no longer available for general- purpose I/O. Port PB in the DSP56002EVM is available at header J7, and is available for the user's interface. Initialization and use of these peripheral devices are documented in the 56002 User's guide (please see reference 2(b)). Other DSP's have similar peripherals, particularly with respect to their capability to directly interface high-speed CODECs. The M56002 SCI and OnCE peripherals, however, are unique for the class of fixed-point DSP's.
The M56002 user-programmable phase lock loop (PLL) determines the DSP clock rate. A 4 MHz crystal clock is available for this purpose. This clock, incidentally, also serves as the clock for the onboard 6805 OnCE-interface microcontroller. Such a programmable system clock may serve several purposes, i.e., allow to meet a variety of internal timing constraints, however, for portable equipment, may be used for power management. This is possible because the DSP consumes more power at higher clock rates than lower rates. Power consumption may thus be regulated by selecting the lowest internal clock rate that meets the requirements of the application.
One extremely useful feature of the M56002 is the inclusion of on-chip sine lookup ROM that comes in handy for use in communications applications, especially numerically-controlled oscillators (NCO) for demodulators.
Figure 1 shows a much simplified overview of the basic hardware components for the DSP56002EVM.
A CS4215 coder-decoder (CODEC) handles analog signal conversion. This chip is intended for high-quality multimedia audio purposes and capable of converting two analog signals to 16-bit digital values (A/D). It also contains two 16-bit digital- to-analog (D/A) convertors. These A/D-D/A convertors forms the analog input and output capabilities of the EVM. The CS4215 is a flexible device, capable of a variety of user-programmable data conversion rates, programmable input gain, and programmable signal output attenuation. The CODEC interfaces with the DSP via the DSP's SSI through a minimum of interface signals. DSP software then have to initialize the serial clock rate and framing method of the SSI for the particular CODEC. Additional control lines for reset, and data/control select, are required to fully command and control the CODEC. In the EVM's case, these control signals are assigned from peripheral port "C". These are shown in Table 1.
Please note that the DSP56002EVM only implements a subset of the CS4215's capabilities. Of particular importance is the following: There is only provision for "Mike" input as the line input is disabled. Only one crystal is used, i.e., 24.576 MHz that is connected to the "XTAL2" position of the CS4215 - this normally is reserved for a 16.9344 MHz crystal. XTAL2 must be selected when initializing data sampling rates. Typically 8, 9.6, 16, 27.42857, 32, and 48 KSPS rates are available. These are commonly-used rates for communications applications.
| M56002 Port C | Functionality | |
| 0 | SCI Receive (host port) | |
| 1 | SCI Transmit (host port) | |
| 2 | CODEC Data/Control (D/C) | |
| 3 | Not used (used for DCD in Leonid code) | |
| 4 | CODEC reset | |
| 5 | CODEC Frame synchronization | |
| 6 | CODEC Serial clock | |
| 7 | CODEC Receive (SSI Rx) | |
| 8 | CODEC Transmit (SSI Tx) |
Table 1. DSP56002EVM assignment of M56002 peripheral port "C" control lines.
A M6805-family microcontroller greatly simplifies the OnCE debugging interface. This single-chip solution not only saves board space, but also helps to keep costs down. Its purpose is to translate the commands, received via the serial interface from the PC-hosted debugging software, into parallel control commands for controlling OnCE operation. The low-level OnCE interface logic is very intricate, consisting of several hand-shaking strobes and intricately-timed pulse sequences - not an easy task to program. The 6805 microcontroller takes care of all this low- level complexities and hides a great number of details from the user without restricting the capabilities of the OnCE, perhaps only to a small extent - speed. The microcontroller, in its present form, is only capable of operating at a maximum speed of 19200 baud. At this speed, larger DSP programs may take a while to download.
Although it is not crucial for a developer to know about the low-level debugger interface protocol to use the DSP5600EVM, it may be valuable when embedding OnCE capability into your own programs, or even makes it possible to use the EVM on other non- DOS platforms. A summary of the OnCE interface protocol follows (please see reference 3 also):
Communication with the M6805-family microcontroller is eight bit serial at 19200 baud. The host issues a command code that may consist of a single byte or may be multiple bytes, depending on the command. The response from the microcontroller is also coded - sometimes consists of a single byte or mulltiple bytes in cases where the response requires multiple bytes. In certain situations, there is no response, such as reset for example, in which case the host should confirm that the EVM is in a usable state by a status query. Table 2 summarizes the command structure.
| HOST (Hex) | Purpose | EVM Response (Hex) |
| A0 Rx | Read OnCE register Rx | D7 RaRbRc (4 bytes) |
| A1 Wa | 1-byte write | D1 - success |
| D2 - failed | ||
| A2 WaWbWcWd | 4-byte write | D1 - success |
| D2 - failed | ||
| A3 | Reset 6805 and DSP | no response |
| A4 | Reset DSP | no response |
| A5 | Force OnCE into debug | D3 - DSP dead |
| D5 - success | ||
| A6 | Release OnCE | D4 - success |
| A7 | Read DSP status | D7 Sa (2 bytes) |
| A8 | Not used | |
| A9 | Reset the 6805 | no response |
| AA-AB | Not used | |
| AC | Check if 6805 is alive | D6 - 6805 responding |
| AD | Obtain what code level | La - code level |
Table 2. OnCE command structure.
The OnCE port is mainly used for debugging purposes, however, a more traditional serial interface is provided by the SCI. The DSP56002EVM provides a host connector (an optional feature) for this purpose. When the SCI interface is used, PC0 is programmed for SCI data receive and PC1 programmed for SCI data transmit. These assignments are also shown in Table 1. Applications that use this interface for communicating with a host may use either ASCII, or KISS (6) format. In standalone mode, the SCI port is the only means for communication with the EVM. Note that there is no provision for hardware flow control on the DSP560902EVM in its present form - communications need to provide for software flow control when needed.
The M56002 DSP has 1024 24-bit words of static RAM (SRAM) on chip that is divided as 512 words P-memory, 256 words X-memory, and 256 words Y-memory. This on-chip memory runs at processor speed and usually is reserved for code that needs to run at the fastest possible speed, such as critical interrupt handlers, or variables that need to be accessed very often.
An additional 32K words of SRAM is provided by three (32K x 8) M6206A SRAM chips. Dealing with address decoding logic for these fast DSP chips is very tricky due to the short access times and propagation delays in decoding logic. The EVM designers opted to use a simple, but effective, method for partitioning the address space. In this case, address lines 14, 15, and enables X/Y~, effectively allows for two addressing schemes. These are selected by jumper J12 (16K/32K). The resulting memory layouts are shown in Figure 2.
Both schemes lead to compromises - for example the "32K" scheme have P, X, and Y all reside in the same physical space. The programmer then has to guard against aliasing sideffects of P, X, and Y. For example address P(220) is the same physical RAM location as X(220) or Y(220). In the "16K" scheme, on the other hand, P and X share the same space, with Y being independent. In this case the programmer should watch out for aliasing P and X RAM locations. In addition, memory locations above 4000 are "shadow" RAM, i.e., address decoding does not allow distinguishing between locations in the range (0000 - 3FFF) and corresponding locations in the range (4000 - 7FFF).
These peculiarities have lead programmers to taking advantage of the hardware in a clever manner. One such programming trick that is often used to speed up DSP algorithms for the M56002, is to use a single location pointer for addressing two equally-sized I/O buffers. For example, let one buffer be used as a data source and another for a data destination. If X and Y are then used such that the corresponding elements of the input and output buffers reside at the same numeric address, for example,
Input(10) is at address X(080), Output(10) is at address Y(080),
then a common single pointer register (R2 in this case) do fetching and storing of data at the appropriate locations.
move X:(R2),x0 ; Input comes from X move y0,Y:(R2) ; output goes to Y
An example of how this is used will be shown in the Leonid kernel's CODEC interrupt handler where code efficiency is crucial. Some of these peculiarities becomes an important consideration when porting M56002 code across different platforms. The amateur radio applications software in this article all uses the "16K" memory mapping.
One fact that is often overlooked, pertain to external RAM: No matter which scheme is used, any data accessed in off-chip RAM involves multiplexing/demultiplexing of the address and data busses - the ultimate penalty is speed of execution. It is thus imperative that time-critical code must reside in the on-chip RAM, if possible at all.
The DSP56002EVM includes an option to use an E(E)PROM for booting. This is essential for standalone applications. An EPROM such as a 27C256 would be suitable, however, this assumes that the user has access to all the necessary tools to convert 56002 object code to a form suitable for booting the DSP. A much more elegant and useful alternative is to use an EEPROM, such as the Atmel At29C256PC FLASH PROM. It is relatively easy to program this device in place using the software tools supplied with the DSP56002EVM.
Besides the DSP, CODEC, and 6805 OnCE interface, very little additional logic is required to make a functional system. Shifting RS232 levels to logic levels are handled by a MAX232 - both transmit and receive pairs for the OnCE and host interface port is provided for. The M56002 reset logic also requires additional attention as the DSP can be forced into one of several operating modes at reset time by presenting the hardware with a special reset signature. For the DSP56002EVM a 74LS157 chip is used to present a binary "100" pattern to IRQA~, IRQB~, and NMI~ that places the DSP in "EPROM BOOT" mode (please see reference 2(b) for details). Upon recognizing this state, and if a valid E(E)PROM device exists, the DSP's internal boot ROM then performs a bootstrap from this ROM, regardless of whether the OnCE port debugger is used or not.
The DSP56002EVM ships with the Motorola 56002 version 5.3.2 assembler, Domain Technologies version 1.02 debugger (please see reference for further), and some (minimal) coding examples. The assembler, as far the author could tell, is very similar to Motorola's professional edition. It generates COFF-format object code. No loader, i.e., a program that combines several preassembled objects, is used. This implies that all assembly code is assembled in one step - something that may become awkward when dealing with large projects. The generous use of "include" statements to read in different source code modules, is one solution that helps. However, some public domain software that includes a C language compiler, assembler, linker, and 56000 simulator is available that may be of interest. Please see reference (7) for further details.
Domain Technologies, Inc (please see reference 1) developed Debug-EVM for the DSP56002EVM. This debugger bear similarities to professional in-circuit emulators both in appearance and capabilities. Such sophistication is made possible by to the M56000 OnCE interface (Section 10 reference 2(1)) that, effectively, provides in-circuit emulation capabilities on silicon. Debug-EVM provides access and control over the internal workings of the DSP, memory, and peripherals, during the debugging process.
Debug-EVM is a DOS-based program that interfaces to the DSP56002EVM through a serial port at 19200 baud. Well-organized multiple-window displays allow for viewing data, program code, DSP registers, and processor status in various formats. During the debugging stages of code development, DSP code and data is downloaded from the host PC to the DSP's memory. The developer can then manipulate registers, data, and place breakpoints as required. It also is possible to interact with a running DSP in a non-intrusive manner. This means that the DSP may be running at full speed. The debugger offers the following features:
The software examples that come with the DSP56002EVM contain only the bare minimum to get you started. One of the included routines is a CODEC support routine, CODEC.ASM. This routine contains a collection of functions that initialize and gets the CODEC up and running. It is a complicated piece of code that require the programmer be knowledgeable of both how the CODEC chip works, but also all the intricacies of the M56002 SSI interface. The use of "define" statements makes the setting up of the CODEC a fairly routine procedure. Transferring data to and from the CODEC is fully interrupt driven using agreed-upon buffer locations.
To make the DSP56002EVM more useful to other experimenters, the author has put together a program package of useful additional programs. A listing of programs included in the package is listed below.
Native DSP56002EVM applications (KC7WW)
INOUT ASM -- CODEC talk-through test
RTTY ASM -- KC7WW's HF RTTY/AMTOR/Pactor (use with PCTOR)
RCOEFFS ASM -- filter coefficients for above
TTYCD ASM -- CODEC support for RTTY modem
EVM56K PLT -- KC7WW's EVM radio interface schematic (HPGL)
EVM56K PS -- KC7WW's EVM radio interface schematic (PS)
Ported applications based on the Leonid kernel
Original work by the Alef Null group: Jarkko Vuori, OH2LNS
Kaj Wiik, OH6EH and associates
TALK ASM -- INOUT equivalent for Leonid BIOS
BIOS ASM -- The source for the ported Leonid kernel
BIOS CLD -- loadable module
INTEQULC ASM -- essential include files
IOEQULC ASM
LEONID ASM -- KC7WW's ported Leonid include file
FSK ASM -- Jarkko's 1200 baud Bell 202 modem for the EVM
BANDPASS ASM -- Jarkko's narrow CW filter
COEFF ASM -- filter coefficients for above
QRMQRN ASM -- a slightly modified version of Jarkko's LMS
denoiser
Contributed programs by Pawel Jalocha, SP9VRC
CORELNW ASM -- Correlation-based CW filter
FFT-CUT ASM -- Denoiser based on the spectral subtraction
PARLL1 ASM -- Early experimental 12-tone OFDM HF modem
The native DSP56002EVM programs works with the code that came with the EVM - the Leonid kernel is not used. As the simplest code example, INOUT.ASM program is particularly useful to a beginner to verify the operation of the EVM and carry out some experiments with the CODEC. RTTY.ASM is a bit more advanced and requires further background in FIR filter design. Note that it uses a modified version of the CODEC support routines. The program contains a thorough description of how the DSP modem works. A schematic for a radio interface is included for use with this program.
One code module that may be of general interest, is the author's port of the Leonid kernel. This module runs some exciting amateur radio programs developed by the Finnish Alef Null group (please see note (5) for further details on the Alef Null group). The Alef Null group has been active in the development of DSP projects since 1992 - the DSP CARD 4 is their fourth generation DSP card. The DSP CARD 4 is very similar to the DSP56002EVM in many respects, except that it uses a M56001. However, the DSP CARD 4 is a forerunner of the DSP56002EVM. The striking similarity in hardware and software allowed the author to port the Alef Null software to be used on the DSP56002EVM.
Porting Alef Null programs, only minor changes are necessary: pay careful attention to the CODEC input source, P, X, Y and L memory allocation. Then, pre-load BIOS.CLD before loading the Alef Null application, and finally start the application using "GO 0". This then allows the last-loaded application to gain access to the low-level kernel services. Please review the included code examples the experimenter's package.
The experimenter's package would not have been complete without the inclusion of Pawel Jalocha's (SP9VRC) contributions. These include several excellent examples for advanced DSP experimenters. Pawel has been particularly helpful by including assembly directives that makes his programs run on both platforms.
A DSP "kernel" is loosely defined as a sort of "command module: a collection of DSP-resident code functions that control, manage, and interact with a user's DSP application. An in-depth overview of a complex piece of DSP code, the size of the Leonid kernel, is unfortunately beyond the scope of this article, however, the reader is encouraged to obtain the Alef Null documentation (please see note (5)) and read together with BIOS.ASM. The code is reasonably-well commented.
It should be noted that the Leonid kernel consists of two parts: The low-level BIOS and a higher-level abstraction that contain several macro calls. The low-level BIOS is contained in BIOS.ASM, while the higher-level macro calls are contained in LEONID.ASM. Please make sure not to mix the ported versions with the original Alef Null code - these are not quite compatible.
The Leonid kernel contains several critical components necessary for amateur radio networking applications. A low-level routine handles HDLC protocol for assembly and disassembly of AX.25 data packets. In addition, KISS protocol is used together with the HDLC routines. It is thus possible to use the DSP56002EVM with a network operating system (NOS) program without any further hardware. i.e., all that is required is the radio, EVM, and PC running NOS. Besides these support routines, additional low-level support is also included for timeout detection and carrier detect - necessary requirements to successfully operate in a network environment. Jarkko's Bell 202 compatible 1200 baud FSK modem (FSK.ASM) is a good example for further insight how this all is put together.
A few hints may come in helpful to follow the interrelation of the different program modules. Figure 3 illustrates how a user program interacts with the kernel. Please read this in conjunction with the TALK.ASM example that is a simple example to illustrate how to use the Leonid code and BIOS. The TALK program starts by initializing the CODEC using the "ctrlcd" call (step 1 in Figure 3). This is a macro call (defined in LEONID.ASM) that primes the CODEC's buffers and prepare various pointers and registers that work with the CODEC. The parameters used in the example to initialize data buffers, are as follows:
r2 -- Use R2 as a data pointer for reading/writing to the
CODEC's buffers.
buflen -- Defines the internal size of the CODEC's circular
buffers.
MIC -- A define that activates the microphone as input
source.
0.0, 0.0 -- Sets the left/right input gain (please see
CS4215 data sheet).
LINE|HEADP -- Defines that activate line/headphone output.
0.0, 0.0 -- Sets the left/right output gains (please see
CS4215 data sheet).
The CODEC is started in step 2 using the "opencd" call. This macro requires two parameters: the first is the sampling rate (i.e., 16 means 16 KSPS), the second is whether the on-chip high- pass filter is required or not (please see the CS4215 data sheet for its implications). Note that this macro includes a jump instruction to P-address 0028. This location is part of a jump table that routes the command to the appropriate section within the BIOS. This jump table is shown in Table 4(b) as part of the low-order P-address space. The jump to P(0028) will be routed to the CODEC startup code that in turn will bring the CODEC to life. It is imperative that once the CODEC comes alive, it's interrupt vector and all associated pointers and data buffers are ready otherwise the code would crash and burn. Jarkko implemented a very efficient CODEC interrupt handler in the BIOS routine by using the so called "fast interrupt" feature of the M56002. The way this works is; instead of a proper interrupt handler routine, two instructions are placed in the interrupt vector address. When a CODEC interrupt occurs, only these instructions are executed and program execution resumes. These fast interrupts are shown in Table 4(a). The actual instructions in the interrupt vector locations are indirect read/write via register R7. It is thus imperative that the user reserve R7 for this purpose. Similarly R3 is used as a SCI buffer pointer (the reader is encouraged to look at the SSI interrupt vector in BIOS.ASM for further insight).
Actual data collection occurs in step (3). The "waitblk" macro requires three arguments: R2, here indicates that register R2 is to be used for an input/output buffer pointer. "buflen" is the name of the input/output buffer to be used and "batch" contains the blocksize. The blocksize feature allows for a flexible programming environment. This is illustrated by the following example: If the user needs to process one sample at a time, then blocksize will be one. However, keep in mind that the data collection process occurs as a background task - often it may take longer to process a block of code before a CODEC interrupt comes along. By working with chunks of data at a time, data collection can continue in parallel with processing. This remains valid since processing time is shorter than the time to acquire a new block of data, i.e., not overflowing the I/O buffers. A further example to illustrate this method of data acquisition is doing real time FFT processing. Assume for example that 256-point blocks are acquired, processed, and 256 points written back out. It is found that it takes longer to process a 256-point FFT than the time inbetween CODEC data interrupts. Clearly, it is then not possible to output a continuous stream of processed FFT data, however, collecting a chunk of data first, the FFT calculation can now proceed to completion before the next 256-point chunk arrives. It can be seen how a continuous stream of data can be collected, processed, and written back out, without gaps. However, there would be certain time delay of time duration equal to the time to fill a block, between input and output, that need to be tolerated. A number of additional function calls are available that deals with the SCI, timer, KISS, and HDLC interface routines. These are listed in below.
| Interrupt Vectors: P(0000-001F) |
| Reset vector |
| Stack Error vector |
| Trace vector |
| Software interrupt vector |
| IRQA vector |
| IRQB vector |
| SSI Tx ------- Fast interrupt |
| SSI Tx error vector |
| SSI Rx ------- Fast interrupt |
| SSI Rx error vector |
| SCI Rx vector |
| SCI Rx error vector |
| SCI Tx vector |
| SCI Tx error vector |
Table 4(a): Simplified block diagram for low-level BIOS functionality: Interrupt vector table.
| Jump Table | ||
| P-Location | Function | Description |
| P(0020) | opensci | Opens serial interface. |
| (a)=KISS command routine address else | ||
| (a)=0 for regular 8-bit serial I/O | ||
| (b)=Tx on/off routine address. | ||
| P(0021) | putc | Places a character in output queue |
| (x0)=argument | ||
| returns Z is buffer full, NZ otherwise. | ||
| P(0022) | getc | Retrieves a character from the queue |
| returns with argument in (x0) | ||
| returns C if no data available, else NC | ||
| P(0023) | tstc | Checks state of queue |
| returns C if no data available, else NC | ||
| P(0024) | endc | Terminates a KISS frame. |
| P(0025) | rejc | Rejects the current KISS frame. |
| P(0026) | putbit | Places bit in C into host tx queue. |
| P(0027) | getbit | Gets next bit to be sent |
| returns with bit in C | ||
| Z if end of transmission. | ||
| P(0028) | opencd | Opens CODEC at a specified sample rate |
| Sample rate code is in (x0). | ||
| P(0029) | closecd | Shut CODEC down. |
| P(002A) | stimer | Request a specified time delay |
| (x0) contains number of (1/baud) ticks. | ||
| P(002B) | putio | Writes to port PB |
| LSB of (x0) contains argument. | ||
| P(002C) | caron | Set transmission "in progress" state. |
| Subject to persistence and DCD logic. | ||
| P(002D) | caroff | Set "end of transmission" state. |
| Subject to persistence logic. | ||
| P(002E-003D) | - not used | |
| P(003E) | Illegal interrupt | |
Table 4(b): Simplified block diagram for low-level BIOS functionality: Jump table.
This article has shown that the DSP56002EVM is in a class of its own - outstanding in flexibility and capability that would be hard to beat for some time to come. It is capable of serving the needs of beginners and advanced experimenters in DSP. Amateur radio experimenters in DSP can also take advantage of an established base of applications.
Jarkko Vuori and the Alef Null group's permission to use and publish their code is gratefully acknowledged. This contribution is an outstanding achievement in software engineering. It was a pleasure to work and discover many new aspects about the M56002 with Pawel Jalocha. His advice, assistance, and permission to use and publish his code is acknowledged. The author is also indebted to George Hawkins, KI5X, and the folks at Motorola Digital Signal Processor Systems, for their keen support.
© Johan Forrer,1998-2002