Application Examples
DSP Source Code Interfaces include DSP and math library routines and also real-time,
interrupt-driven structures that allow foreground and background processing in
conjunction with analog I/O or digital I/O sample interrupts. Initially, the source code
supports standard Hypersignal operation, including instrumentation displays, continuous
transfer to/from disk, and file-based function acceleration, with no programming required.
In other words, if you were to assemble and link the source code for a specific DSP chip
as it was shipped, without any changes, you would end up with the distribution object
file that is sent with every basic Hypersignal package. However, the source code could
then be modified and/or added to in order to enhance the baseline Hypersignal operations
or add new functions entirely. Changes can be as simple as interfacing to new analog
converters or as complicated as simulating and testing complete algorithms by transferring
data between the DSP board and Hypersignal software resources (including hard disk and
video display) using pre-defined buffer-switching mechanisms and real-time interrupt
structures.
A simple example might be to create user-written DSP source code that might perform some
algorithm or feature extraction. Following this, Hypersignal can be instructed to use
the new executable DSP file(s) as needed, causing the new user-written algorithm(s) to
execute. This type of modification process basically allows you to concentrate on the
problem at hand, since the Hypersignal high-level host software performs all of the
housekeeping associated with controlling the DSP board, downloading executable code, and
transferring blocks of real-data between host and DSP board memory. Furthermore, if you
maintain compatibility with internal Hypersignal data and waveform file formats, then more
housekeeping tasks such as file creation, graphical analysis, etc. can be left to
Hypersignal.
Following are some more detailed examples of using the DSP Source Code Interface. Lets
suppose that you had one of the DSP boards that is supported by Hypersignal, but needed
to interface the board to a target analog section of your own design. If you had the DSP
source code for the appropriate chip family, this would be trivial. First, you would
change the interrupt service routine for the Hypersignal function that you wanted to get
working. Depending on the chip family there is generally a few different interrupt
service routines for each function, organized by board manufacturer. The changes you
would make here would be minor: ensuring that the code read your A/D port address instead
of the supported board's standard address. Next, you might have to change the system
initialization module if the interrupt source/level for your analog hardware is different.
Everything else would be left alone: buffering of the data, transfer to the high-level
host software, and processing of the data (although you might want to change that, too,
at some point). Next, you would assemble the modules changed using the "ASM" batch file
provided for each chip family. Finally, you would invoke the "LNK" batch file, and copy
the resulting linker output file (".OUT" is default output filename extension for linkers
provided by most DSP chip manufacturers) to your working Hypersignal directory. When you
next invoked Hypersignal, this file would be ready for downloading and subsequent
execution without any further effort.
As another example, let's suppose you wanted to take a supported board, and working with
the board's standard analog I/O, implement all or part of a time domain algorithm on the
board and stream the real-time results to hard disk for later evaluation and display. If
you first make the assumption that when running this function from Hypersignal you will
ask for two-channel operation, you could simply alter the foreground processing to apply
your algorithm to every other sample in the input buffers as they become ready. This is
possible because multichannel data in Hypersignal is always transferred and processed in
interleaved form; indeed, the high-level host software can be instructed to
acquire/generate N channel data whether the board has N channels or not. Whether this
works depends totally on the low-level DSP source code. After modification of the
foreground module, and/or addition of new, user-defined routines, subsequent execution of
Hypersignal with 2-channel operation specified would produce raw input data on the first
channel, and processed data on the second channel. FFT operation on such a waveform
would be automatic, since Hypersignal still thinks this is a "stereo" waveform, allowing
convenient comparison viewing and evaluation in the frequency domain as well.
As a third example, consider using a supported board to simulate an entire project,
maintaining just enough of the Hypersignal interface and real-time data transfer
mechanism to allow real-time display of data, debug modes, and possible streaming of data
to disk. After transferring code to your target system (via EPROM), there can be no
doubt as to whether encountered problems are due to the software or the target hardware
design--the Hypersignal simulation can always be easily run at any time as a check against
the software design.
Other examples include adding DSP source code to support multiprocessing, interconnections
between multiple boards, and other peripheral bus standards such as DT-Connect, measuring
algorithms or parts of algorithms against a particular real-time sampling rate,
evaluating the effects of finite word-length, and more.
Source Code Overview
In addition to basic DSP and math routines and analog I/O drivers for supported boards,
DSP Source Code Interfaces also include basic "modes" of real-time or file-based
acceleration operation shown below:
-
