This product is no longer available.
The DSP56002EVM is a low-cost Evaluation Module (EVM) designed by Motorola to familiarize engineers and experimenters with the Motorola DSP56002 Digital Signal Processor (DSP) chip. The DSP56002EVM is very popular with Amateur Radio enthusiasts interested in DSP techniques. The EVM has been programmed to perform as a 1200 AFSK modem, 9600 bps FSK G3RUH modem, and various filters, just to name a few.
The DSP56002EVM was made popular by Johan Forrer, KC7WW, in the August 1995 QEX article entitled "Using the Motorola DSP56002EVM for Amateur Radio DSP." Johan created a software package for the DSP56002EVM.
Greg Jones, WD5IVD, President of TAPR, arranged for TAPR to have access to a large number of evaluation units from the Motorola DSP group. The purpose was to distribute these units to the amateur radio community for the support of DSP related research and development. Over a three year period, TAPR provided over 500 evaluation units into the amateur radio community.
The DSP56002EVM was discontinued by Motorola, but EVMs do appear on eBay or amateur radio for sale web pages.
- Using the Motorola DSP56002EVM for Amateur Radio DSP Projects
- The DSP Experimenters Homepage
- TAPR DSP Software Archives
- KC7WW's Collection of Utilities and Application Package for the DSP56002EVM
- Danie Brynard, ZS6AWK Interface
- Jabi Aguirre, EA2ARU Interface
For technical documentation on the DSP56002 and other DSP chips manufactured by Motorola. Visit the Motorola Digital Signal Processing web page. The DSP56002 Technical Documentation page has a link to DSP56002EVM Documentation and an overview of the DSP56002 chip.
Prentice Hall has published a text book entitled "Digital Signal Processing Applications With Motorola's DSP56002 Processor, 1/e" by Mohammed El-Sharkawy, Copyright 1997, ISBN 0-13-569476-0.
Using the Motorola DSP56002EVM for Amateur Radio DSP Projects
Motorola's low-cost DSP evaluation module covers all the bases for amateur use and development.
By Johan Forrer, KC7WW
Originally published in QEX August 1995
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
and DSP modem work for HF digital and VHF/UHF modems for use in terrestrial
and satellite applications. I'll cover hardware and resources for application
development and present a collection of advanced DSP applications ready
for amateur experimentation. (See the Collection of Utilities and Application Package for the DSP56002EVM that appeared with this article.)
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.
The recent introduction of low-cost EVMs by DSP chip manufacturers, however, has helped make DSP technology available to experimenters. These EVMs include sufficient educational materials to get you started: a small printed circuit card that contains the DSP chip, software to develop and evaluate educational programs and 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 free-standing application when using its onboard E(E)PROM memory. The DSP chip used on the EVM has an impressive track record in communication engineering. Its DSP chip is from the same Motorola DSP family as the chips used in the HAL PCI-4000 , AEA DSP 1-232, DSP 2-232  and the DSP-12 --and even in commercial and military products. If judged by these success stories, the 56002 presents splendid opportunities as it offers high clock speed and the advantages of its on-chip hardware emulator.
A Peek at the 56002 DSP
The computing engine of the DSP56002EVM is a 40-MHz 56002 DSP. This is a 24-bit processor, meaning that each instruction is 24 bits wide. Data and instruction words are kept in separate memory spaces. Instructions are stored in the "P"-space, short for program space. Two separate, independent data spaces, "X" and "Y" are available. This separation of data and instructions is called a Harvard architecture. This is quite different from the Von Neumann architecture used, for example, in the 80x86 processors. The Harvard architecture is typically used in DSPs and allows for extensive instruction parallelism.
The value of this parallelism becomes evident when one considers that the strength of DSP processors lies in their ability to multiply and accumulate (MAC) very efficiently. The 56002 scores high in this regard. It can multiply two operands, accumulate (sum) 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 56002, this happens 20 million times per second. Other DSP chips may have similar features, but having two data spaces and a 24-bit code/data architecture is a distinguishing feature of the 56000 family.
The 24-bit architecture of the 56002 allows a richer instruction set than that of comparable 16-bit DSPs. It also allows an impressive selection of extended addressing modes. These addressing modes are available in one-word instructions and also in a two-word instruction format. Which instruction format to use becomes a trade-off between ease of programming and programming for efficiency. Obviously, the additional dynamic range of 24-bit data (144.5 dB) over 16-bit data (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 56002 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, 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/0-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.  Other DSPs have similar peripherals, particularly with respect to their capability to directly interface high-speed CODECS. But the 56002 SCI and OnCE peripherals are unique for the class of fixed-point DSPs.
The 56002 user-programmable phase-locked loop (PLL) determines the DSP clock rate. A 4-MHz crystal clock is available on the EVM to drive the PLL. This clock, incidentally, also serves as the clock for the on-board 6805 OnCE-interface microcontroller. Such a programmable system clock may serve several purposes. It may allow the designer to meet a variety of internal timing constraints. Or for portable equipment, a variable clock rate may be used for power management. 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 56002 is the inclusion of an on-chip sine-lookup ROM that comes in handy for use in communication applications, especially numerically controlled oscillators (NCO) for demodulators.
An Overview of the DSP56002EVM
Figure 1 shows a much simplified overview of the basic hardware components of the DSP56002EVM.
CODEC Interface (SSI)
A Crystal Semiconductor CS4215 coder-decoder (CODEC) handles analog signal conversion. This chip is designed for high-quality multimedia audio purposes and is capable of converting two analog signals to 16-bit digital values (A/D). It also contains two 16-bit digital-to-analog (D/A) converters. These A/D and D/A converters form 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 using a minimum of interface signals. DSP software must 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," as shown in Table 1.
M56002 port C
|SCI Receive (host port)|
|SCI Transmit (host port)|
|CODEC Data/Control (D/C)|
|Not used (used for DCD in Leonid code)|
|CODEC Frame synchronization|
|CODEC Serial clock|
|CODEC Receive (SSI Rx)|
|CODEC Transmit (SSI Tx)|
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, 24.576 MHz, which is connected to the "XTAL2" position of the CS4215--this normally is reserved for a 16.9344MHz 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.
On-Chip Emulation (OnCE) Interface
A 6805-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 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 handshaking strobes and intricately-timed pulse sequences--not an easy task to program. The 6805 microcontroller takes care of all this low-level complexity and hides a great number of details from the user without restricting the capabilities of the OnCE, or 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, large 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 to make it possible to use the EVM on other, non-DOS platforms. A summary of the OnCE interface protocol follows. 
Communication with the 6805-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, consisting of a single byte or multiple bytes. In certain situations, such as reset, there is no response, 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.
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 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)|
|A9||Reset the 6805||no response|
|AC||Check if 6805 is alive||D6 - 6805 responding|
|AD||Obtain what code level||La - code level|
Host Port Interface (SCI)
The ONCE port is mainly used for debugging purposes. 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 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 format.  In stand-alone mode, the SCI port is the only means of communication with the EVM. Note that there is no provision for hardware flow control on the DSP560902EVM in its present form--applications must provide software flow control when needed.
Static RAM Memory
The 56002 DSP has 1024 24-bit words of on-chip static RAM (SRAM) that is divided as 512 words of P-memory, 256 words of X-memory, and 256 words of 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) 6206A 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, effective method of partitioning the address space. Address lines 14 and 15 and enables X/Y effectively allow 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 has P, X and Y all residing in the same physical space. The programmer then has to guard against aliasing side-effects. 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, that is, address decoding does not distinguish between locations in the range (0000 to 3FFF) and corresponding locations in the range (4000 to 7FFF).
These peculiarities have led programmers to take advantage of the hardware in clever ways. One programming trick that is often used to speed up DSP algorithms on the 56002 is to use a single location pointer for addressing two equal-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 set 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) does both 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 can be found in the Leonid
kernel's CODEC interrupt handler, where code efficiency is crucial. Some
of these peculiarities become important considerations when porting 56002
code across different platforms. The amateur-radio application programs
in this article all use the 16K memory mapping.
One fact that is often overlooked pertains 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 reside in the on-chip RAM if at all possible.
The DSP56002EVM includes an option to use an E(E)PROM for booting. This is essential for stand-alone applications. An EPROM such as a 27C256 would be suitable, but 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.
Other Miscellaneous Glue Logic
Besides the DSP, CODEC and 6805 OnCE interface, very little additional logic is required to make a functional system. Shifting RS-232 levels to logic levels is handled by a MAX232--both transmit and receive pairs for the OnCE and host interface port are provided for. The 56002 reset logic also requires 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.  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.
Development Software and Tools for the DSP56002EVM
The DSP56002EVM ships with the Motorola 56002 version 5.3.2 assembler, Domain Technologies version 1.02 debugger and some (minimal) coding examples.  The assembler, as far as I can tell, is very similar to Motorola's professional edition. It generates COFF-format object code. No loader (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. 
Domain Technologies, Inc, developed Debug-EVM for the DSP56002EVM. This debugger bears similarities to professional in-circuit emulators in both appearance and capabilities. Such sophistication is made possible by the 56000 OnCE interface that effectively provides in-circuit emulation capability 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 stage of code development, DSP code and data is downloaded from the host PC to the DSP's memory. The developer can then manipulate registers and 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 debugged at full speed. The debugger offers the following features:
- fully symbolic (data and code labels)
- source level debugging
- on-screen editing
- mouse support
- built-in assembler/disassembler
- character graphics (for plotting memory arrays)
- multiple memory display modes
- trace with count
- single step with count
- subroutine jump
- true real-time hardware breakpoint
- up to 128 software breakpoints
- up to four memory windows
- requires no on-chip monitor code
Amateur-Radio Applications for the DSP56002EVM
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 the CODEC and get it up and running. It is a complicated piece of code that requires that the programmer be knowledgeable of both how the CODEC chip works and also all the intricacies of the 56002 SSI interface. Fortunately, the use of define statements makes setting up 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, I've put together a program package of useful additional programs. A listing of the programs included in the package is shown in Table 3.
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)
EVM.PS -- KC7WW's EVM radio interface schematic (Postscript)
Ported applications based on the Leonid kernel
|TALK.ASM -- INOUT equivalent for Leonid
BIOS.ASM -- The source for the ported Leonid kernel
BIOS.CLD -- loadable module
INTEQULC.ASM -- essential include files
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 Jalocha, SP9VRC
|CORELNW.ASM -- Correlation-based filter
FFT-CUT.ASM -- Denoiser based on the spectral subtraction
PARLL1.ASM -- Early experimental 12-tone OFDM HF modem
The native DSP56002EVM programs work with the code that came with the EVM--the Leonid kernel is not used. As the simplest code example, the 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.  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 56001. 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 the DSP56002EVM.
Porting Alef Null programs requires only minor changes: pay careful attention to the CODEC input source, P, X, Y and L memory allocation. Then, preload BIOS.CLD before loading the Alef Null application. Finally, start the application using "GO 0." This allows the last-loaded application to gain access to the low-level kernel services. Review the included code examples in the experimenter's package for further details.
The experimenter's package would not have been complete without the contributions of Pawel Jalocha, SP9VRC. These include several excellent examples for advanced DSP experimenters. Pawel has been particularly helpful in including assembly directives that makes his programs run on both platforms.
A Brief Overview of the Leonid Kernel
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 beyond the scope of this article. I encourage you to obtain the Alef Null documentation and read it together with BIOS.ASM. The code is reasonably well commented.
The Leonid kernel consists of two parts: the low-level BIOS and a higher-level abstraction that contains several macro calls. The low-level BIOS is contained in BIOS.ASM while the higher-level macro calls are contained in LEONID.ASM. Be 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 the HDLC protocol for assembly and disassembly of AX.25 data packets. In addition, the KISS protocol is used together with the HDLC routines. It is thus possible to use the DSP56002EVM with a TCP/IP (NOS) program without any additional hardware. All that is required is the radio, EVM and a PC running NOS. Besides these support routines, additional low-level support is also included for time-out 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 that gives further insight into how this all is put together.
|(1) Initialize CODEC:
|(2) Start CODEC:
opencd 16, NOHPF
Jump via P(0028)
|(3) Collect data from the CODEC:
waitblk r2, buflen, batch
A few hints may help you follow the interrelation of the different program modules. Figure 3 illustrates how a user program interacts with the kernel. Examine this in conjunction with TALK.ASM, a simple example that illustrates 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 prepares various pointers and registers that work with the CODEC. The parameters used in the example shown are as follows:
1--initialize data buffers.
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 (see CS4215 data sheet). 
LINE|HEADP--defines that activate line/headphone output.
0.0, 0.0--sets the left/right output gains (see CS4215 data sheet).
The CODEC is started in step 2 using the "opened" call. This macro requires two parameters: the first is the sampling rate (ie, 16 means 16 kSPS), the second is whether the on-chip high-pass filter is required or not (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, its interrupt vector and all associated pointers and data buffers are ready. Otherwise, the code will 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 56002. 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, then 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, so it is imperative that R7 be reserved for this purpose. Similarly, R3 is used as a SCI buffer pointer (see the SSI interrupt vector in BIOS.ASM for further details).
|Interrupt vectors: P(0000-001F)|
Stack Error vector
Software interrupt 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
|opencsi||Opens serial interface.
(a)=KISS command routine address else
(a)=0 for regular 8-bit serial I/O
(b)=Tx on/off routine address.
|putc||Places a character in output queue
returns Z is buffer full, NZ otherwise.
|getc||Retrieves a charater from the queue
returns with argument in (x0)
returns C if no data available, else NC
|tstc||Checks state of queue
returns C if no data available, else NC
|endc||terminates a KISS frame.|
|rejc||Rejects the current KISS frame.|
|putbit||Places the current KISS frame.|
|getbit||Gets next bit to be sent
returns with bit in C
Z if end of transmission.
|opencd||Opens CODEC at a specified sample rate
Sample rate code is in (x0).
|closecd||Shut CODEC down.|
|stimer||Request a specified time delay
(x0) contains number of (1/baud) ticks.
|putio||Writes to port PB
LSB of (x0) contains argument.
|caron||Set transmision "in progress" state
Subject to persistence and DCD logic.
|caroff||Set "end of transmission" state.
Subject to persistence logic.
Actual data collection occurs in step (3). The "waitblk" macro requires three arguments: "R2" indicates that register R2 is to be used as an input/output buffer pointer, "buflen" is the name of the input/output buffer to be used and "batch" contains the block size. The block size feature provides a flexible programming environment. This is illustrated by the following example: If you need to process one sample at a time, the block size will be one. But keep in mind that the data collection process occurs as a background task--often it may take longer to process a block of code than the period between CODEC interrupts. By working with chunks of data at a time, data collection can continue in parallel with processing. This remains valid as long as the time it takes to process a block of data is shorter than the time to acquire a new block of data, so the I/O buffers won't overflow. A further example to illustrate this method of data acquisition is doing real-time FFT processing. Assume that 256-point blocks are acquired and processed and 256 points are written back out. Now suppose it takes longer to process a 256-point FFT than the time between CODEC data interrupts. Clearly, it is 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. Thus, a continuous stream of data can be collected, processed and written back out, without gaps. There would, however, be a time delay between input and output of duration equal to the time it takes to fill a block.
A number of additional function calls are available that deals with the SCI, timer, KISS and HDLC interface routines. These are listed in Table 4(b).
This article shows that the DSP56002EVM is in a class of its own--outstanding in flexibility and capability that should 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 56002 with Pawel Jalocha. His advice, assistance and permission to use and publish his code is acknowledged.
I am also indebted to George Hawkins, K15X, and the folks at Motorola Digital Signal Processor Systems for their keen support.
1 PCI-4000. HAL Communications Corp, PO Box 365, Urbana, IL 61801, tel: (217) 3677373.
2 DSP-1232 and DSP-2232. AEA Advanced Electronic Applications, Inc (AEA), PO Box C2160, Lynwood, WA 98036, tel: (206) 774 5554.
3 DSP-12 Multimode Communications Controller. L.L. Grace Communications Products, Inc, 41 Acadia Drive, Voorhees, NJ 08043, tel: (609)751-1018.
4 The following literature may be ordered through Motorola's Literature Distribution Center, PO Box 20912, Phoenix, Arizona 85036 (Phone: 1-800-441-2447). Please note that some of these materials are free, others not:
DSP56000 Family Manual (DSP56K FAMUM/AD).
DSP56002 Digital Processor User's Manual (DSP56002UM/AD).
DSP5600010SP56001 Digital Signal Processor User's Manual (DSP56000UM/AD).
5 EVM56002 EVM ONCE Interface, Rev 1. 1. Craig Heller et al, Motorola Digital Signal Processing Division, Semiconductor Products Sector, 6501 William Cannon Drive West, Austin TX 78735-8598. This software is supplied with some versions of the kit.
6 Chepponis, M. and Karn, P. "The KISS TNC: A simple Host-to-TNC Communications Protocol," Proceedings of the Sixth ARRL Computer Networking Conference, ARRL 1988.
7 Domain Technologies, Inc, 1700 Alma Drive, Suite 245, Plano, TX 75075. Developers of the Debug-EVM. Version 1.02 was shipped with the author's system. An updated version, 1.0402, is available for downloading from Domain's BBS (214) 587-1090. Domain also offers a professional version of the debugger, the LINK-56002 development system. In addition, a 56002-based, ISA-bus development card is also offered. Domain Technologies may be contacted via the Internet at: email@example.com.
8 Public-domain software for the 56000-family is available from several Internet locations. One such location is ftp://nic.funet.fi in file /pub/ham/dsp/dsp56k-tools/gcc5616.tar.Z. This program is the work of Andrew Sterian and was intended for the 56116/56156 DSP but, with some reservations, is useful for the 56002. There also is a C language compiler for the 56002, by the same author. This one is named gcc56k.tar.Z. The Alef Null software package mentioned in Note 9, includes a (somewhat dated) assembler, linker, and simulator. These were placed in the public domain because they are not the latest official Motorola versions. However, they all work well. Another useful source for software is Motorola's Dr. Bub BBS (512) 891-3771 or (512) 891-3773.
9 Kaj Wiik, OH6EH and Jarkko Vuori, OH2LNS. Alef Null DSP CARD 4, User's Manual. Manual and software package available for downloading from jeeves.hut.fi. Look in the alefnul directory for program libraries and documentation.
10 CS4215 16-bit Multimedia Audio Codec. Crystal Semiconductor Audio Databook. Crystal Semiconductor Corporation, PO Box 17847, Austin TX 78760.
11 "KC7WW's experimenter's code package for the DSP56002EVM is available for downloading from: ftp://ftp.tapr.org/ hfsig/upload/EVM56Kl.ZIP.
KC7WW's Collection of Utilities and Application Package for the DSP56002EVM
Note: The latest firmware based on the KC7WW code is available at Doug Braun, NA1DB, website at http://www.dougbraun.com
Radio InterfaceJohan designed a daughter board that provides a radio interface for the DSP56002EVM.
Collection of Utilities and Application Package for the DSP56002EVMVersion 3 - March 1996
Johan Forrer, KC7WW (firstname.lastname@example.org)
The code, schematics, and examples in this package are provided for personal use without any warranty on an "as is" basis -- "what you see is what you get." The code examples or schematics may not be used for resale or in any commercial or government applications without written concent of the author(s). The author and authors of the included software examples are not liable for any mishaps due to the use and/or abuse of this software package.
This version of the package accompanied the article in the August 1995 issue of QEX:
Using the Motorola DSP56002EVM for Amateur Radio DSP
by Johan Forrer, KC7WW
This package will get you started developing amateur radio applications with the Motorola DSP56002EVM. It assumes you have some prior experience with the DSP56002EVM, i.e., have assembled code and used the debugger a little bit.
The package evm56k3.zip is available from ftp://ftp.tapr.org/dsp/Motorola/dsp56002/evm56k/kc7ww/
Native EVM56002 Applications (KC7WW)
Applications based on the LEONID kernel port
Pawel's (SP9VRC) Programs
Danie's (ZS6AWK) Programs
(NOS) a collection of notes for running the EVM with NOS
The bulk of the more interesting applications are based on the work of the Alef Null group. I acknowledge the efforts of Jarkko Vuori (OH2LNS), Kaj Wiik (OH6EH), and their associates, for their excellent work. I am also most grateful for Jarkko Vuori's permission to port and post the Leonid monitor code for the EVM56K.
I recommend that the documentation of the Alef Null Project be obtained for reference purposes from ftp://jeeves.hut.fi in the alefnull directory. There are several components: source, tools1, and doc. It contains an appropiate introduction to what DSP is and also discusses modem theory as applied to the various software modules in the package. Makes for interesting reading.
Some exellent examples from Pawel Jalocha (SP9VRC) are included with his kind permission. Thanks Pawel for sharing your fine workmanship! I can recommend all the modems, denoiser/filters, and FSKIFACE works wonderfully with JVFAX7.1 (another outstanding program).
I also include a contribution by Danie, ZS6AWK - I am sure that this will also be appreciated by others.
NOTE: Using this interface to your EVM requires NO modifications to your EVM.
I included the schematic of my radio interface for the EVM56K. This schematic is basically adapted from the DSP4 and simplified to the bare essentials. The reader is referred to the DSP4 documentation for further details.
Also note that if you want to use the interface schematic, that a few jumpers need to be changed:
- J8 should have all four jumpers in standard mode, i.e., parallel to the short edge of the PCB.
- J10 should have PC0 and PC1 jumpers installed.
Just a note about FLASH EPROM: I have used the Atmel chip and have had good luck with it. To program the FLASH EPROM, first load your code using the debugger, then load the FLASH program supplied with the kit. Finally execute the FLASH program. The start address is given in the FLASH program, just look at the source code. When all is done, remove the debugger and push the "reset" button. The DSP will then boot from the FLASH EPROM.
EVM and DSPCARD4
The EVM56002 and the DSPCARD4 are very similar in many respects - deceptive differences, however will puzzle the beginner and expert alike. When porting the code between these two platforms be mainly aware of the following:
1. The DSP4 has seperate spaces for P, X, and Y - the EVM56K only has P/X, and Y. Be careful with X memory allocation. Also be aware of tricks that use a common address pointer that addresses both X and Y at the same time. The DSP4 software examples occasionally uses this method.
2. There is only one audio source connected on the EVM, i.e., "MIKE" input. The DSP4 allows a selection. Thus make sure that any code that you port has "MIKE" selected. You may optionally put the 20dB pad in if you need more gain at the cost of poorer audio quality. Also note that there is only one crystal on the CODEC, i.e. 24.5MHz, and it is connected to the WRONG crystal port, i.e. where the 16MHz crystal is supposed to be. This is no problem, though when you initialize th CODEC, make sure it looks for the 16MHz crystal - the 24MHz crystal is then selected and all is fine.
3. To use the Leonid monitor on the EVM, first load "BIOS", then your application(s) and finally "go 0" to start the code. If you plan to use the "SPY" program, or any other program that use the SCI, for that matter, you need to switch to the "terminal" port on the EVM as all communications using the EVM's SCI port is through that port.
4. Please look at the code for BIOS.ASM before using it:
a) You may wish to change the SCI baudrate to another value than the 9600 baud that I used.
b) For a faster EVM clock, enable the speed you wish. I have been using 40 MHz to maintain compatibility between several old and new systems. My EVM will run quite happily at 80 MHz.
This goes for the 1200 baud FSK modem as well. In that case you also need to make sure that you use a program that can talk in "KISS" mode, i.e. something like NOS will do just fine.
Note there are two experimental 1200 baud modems in the package. The OH2LNS version, FSK.ASM, is somewhat sensitive to audio input level - set this not more than 180 mV. Pawel's modem, FSK1200.ASM, is fairly insensitive to the input level.
5. If you are not a NOS guru, the following commands will let you monitor raw traffic (make sure you have the appropiate serial port, attached in your autoexec.nos file).
trace ax0 211 (then push F9, I assume "ax0" is your ax25 device)
6. When NOS is used, ensure that NOS and the EVM is communicating at the same baudrate. Please check the baudrate that Leonid is using by the setting in "baud" (line 182) - set it to the required rate and re-assemble BIOS.ASM.
7. You must use my version of the leonid.asm include file when building programs that use the Alef Null Leonid monitor calls.
Other Hints & Kinks
The EVM has only a provision for using MIC input -- LINE inputs are grounded through a capacitor. If you wish, these LINE inputs can be enabled, though this modification should only be attempted by a skilled person. You will need to work under good lighting and use a magifier glass to inspect your work. This one voids your warranty - beware!
Step 1). Referring to the CODEC: find the track running from pin 18, towards C207. Cut it close to C207. The LINE inputs are now disconnected from ground.
Step 2). Turn the EVM upside down and find the feed-thru tracks from pins 15 and 16. Between these two feed-thru holes, is a "L" shaped short track that feeds through to pin 16. This "L"-shaped track ties LINEL and LINER together - cut it. Now LINEL and LINER are independant.
Step 3). If you wish to connect LINEL and LINER to an independant input conditioning circuit, you may wish to use the feed-though holes on the bottom of the EVM for solder pads to gain access to LINER (pin 16) and LINEL (pin 18). I choose to bridge these pads so that MICR/LINER and MIRL/LINEL becomes connected.
I did this modification only to maintain software compatibility with some programs the use LINE as input. Otherwise it is best to leave this alone.
I trust that this collection of examples is of use. Please let the authors know that you are using their software and that you appreciate their indivdual efforts. The main thing is - please contribute your own efforts so that we all can grow in our experiences.
73, Johan, KC7WW
Danie Brynard, ZS6AWK
Danie, BRYD@KIDD.CO.ZA, has been experimenting and using the DSP56002EVM for a variety of projects. He has built upon some of Johan's work and added a few of his own. Here is Danie's contribution.
ICOM IC820H Radio Interface
Index of Software
Danie maintains an index of software for the EVM. It is available as evmindex.txt.
Jabi Aguirre, EA2ARU
Jabi, email@example.com, has also been experimenting and improving upon Johan and Danie's work. Here is his contribution.
Photos of the pcb design Jabi modified from Danie, ZS6AWK's design.
Photos of the case Jabi has made for his EVM.
For more information on the pcb and case, contact Jabi at his email address above.