Software Utilities

Hardware and software form an integral unit in any realtime application. This is especially true on a DSP system, where blocking functions or excessive data copy instructions will almost certainly lead to realtime violations, resulting in data loss and erroneous results.

The carefully fine-tuned hardware and software of a D.Module provides optimum performance and user-friendliness. The goal is to provide a consistent and intuitively usable programming interface for the D.Module hardware, encapsulating hardware dependences and avoiding common programming pitfalls - the key note of the D.Module.BIOS.

Field maintenance and serviceability, as well as convenient upgrade paths, are additional musts for a competitive end product. D.Modules do meet these requirements already at the board-level: The built-in firmware supports program uploads, logic reprogramming, and configuration changes via a RS232, USB, or Ethernet.

Maintenance is further improved by the Module Config File, a text file, which allows to define installation-specific data like network settings or algorithm parameters. Should modification be required, simply change the Module Config File, no recompilation of the application program is required.

Initialization and programming algorithms for all on board resources

Setup Utilty
USB- and RS232-based field maintenance tool for program and data uploads, User-CPLD reprogramming, diagnostics

Module Config File
ASCII configuration file for application-specific settings

micro-line DSP Systems


The D.Module2.BIOS functions are an integral part of the module, permanently stored in the Flash Memory and booted at power-up or reset. To use the D.Module2.BIOS in your program, only a header file must be included, containing prototypes, pre-defined parameters, and call addresses. The BIOS handles initialization and programming of all the module´s peripheral devices. Because this programming interface is consistent throughout the D.Module family, upgrading (and downsizing) to different modules is much simplified. The table below shows an excerpt of the available functions.

The software engineer doesn´t have to struggle with hardware configuration options, timing constraints, and figure out the profundities of each device - instead the BIOS allows concentration of the actual task: implementing a signal processing algorithm.

Targeting industrial applications, it is necessary to ensure many years of delivery, service, and replacement. Yet several components of a DSP system are reliant on consumer mass market conditions. This is especially true for memories and communication devices. Some parts may become obsolete in future and need to be replaced by similar, but slightly divergent, parts, requiring modified initialization or programming. Consequently this leads to software adaption, resulting in wasteful administration of multiple hardware and software versions.

The D.Module2.BIOS copes with this situation: Hardware changes will not become visible to customers, their effects are handled in the BIOS without having to change the application program code.

Board initialize and configure DM2_busConfig (DM2_BUS_SYNC);
Interrupts configure DM2_intMap (DM2_INT_USBCPU, 4)
Boot Loader boot load program from Flash Memory DM2_bootload (0x30000);
UART initialize, configure, data transfer DM2_uartWriteStr (h_uart0, "hello world!", 0);
USB initialize, configure, data transfer cnt = DM2_usbReadBlock (dstbuf, ENDPOINT2);
Flash erase, program, read, Intel-Hex upload DM2_flashWriteBlock (0x30000, srcbuf, 1024);

D.Module.Setup Utility

Field maintenance and update options are frequently demanded for industrial systems, mostly required for installing bug fixes and adaptation to installation changes. The D.Module firmware includes a Setup Utility which readily meets these requirements.

Communicating via a RS232 serial link or USB (no need for specialized emulators or programming cables!) you are able to upload program and data files, change configuration files in the module´s Flash Memory, reprogram the reconfigurable logic devices, and execute diagnostic functions. If your system is expanded with a D.Module Ethernet Daughter Card this functionality is available via network too.
Since the Flash Memory capacity of the D.Modules is sufficient to store multiple programs you are able to include diagnostic programs or calibration routines, which are not part of the default application, but can be invoked by a service technician on demand. Data and parameter files stored in ASCII or binary format help to simplify adaptations. Only the parameter set needs to be replaced, no need to modify the program code itself.

Intel-Hex Upload upload executable programs to the Flash
ASCII, Binary and Configuration File Upload upload data and parameter sets
Intel-Hex, ASCII and Configuration File Download download parameter, log and report files
CPLD Program File Upload reprogram the User-CPLD (e.g. to accommodate interface changes)
read and write memory basic debugging
load and execute programs execute programs other than the default application, e.g. diagnostic or calibration programs


The Configuration File is an ASCII file stored in the module´s Flash Memory, used to store system configuration and start-up options. User-defined sections can of course be added too. Below is a sample configuration file.

The most obvious advantage is to store installation-dependent data in the Configuration File. Any program using the UART or an Ethernet interface can read it´s settings from the Config file, resulting in only one central data base to maintain. End-customers can make changes on their own without access to the program code.

Customers are strongly encourage you to add their own user-defined sections for installation-dependent parameter storage, such as calibration data, signal processing coefficients, etc. Should one of these parameters need adjustment during product lifetime, only the Module Configuration File needs to be changed. The program code itself is not affected - invaluable especially after upgrading the highly optimizing Code Generation Tools, where new versions are prone to produce different code size and different optimization results, which may involve expensive software validation cycles.

A Sample Module Configuration File

[DSP] ; DSP Configuration
core clock = 720000000 ; DSP core clock in Hz (480, 600, or 720 MHz)
bus clock = 133000000 ; DSP EMIF clock in Hz (83, 100, 125, or 133 MHz)
endian = 0 ; DSP endianess (0:little, 1:big)
mac = 1 ; DSP Ethernet MAC (0:disabled, 1:enabled)

[UART0] ; UART 0 communication parameters
baud rate = 115200
data bits = 8 ; 5, 6, 7, or 8
stop bits = 1 ; 1 or 2
parity = N ; N:none, O:odd, E:even, 1:forced-1, or 0:forced 0
flow control = X ; N:none, X:Xon/Xoff, or R:RTS/CTS
xon code = 0x11 ; hex and dec notation allowed, typically 0x11
xoff code = 0x13 ; hex and dec notation allowed, typically 0x13

[UART1] ; UART 1 communication parameters
baud rate = 9600
data bits = 8 ; 5, 6, 7, or 8
stop bits = 1 ; 1 or 2
parity = N ; N:none, O:odd, E:even, 1:forced-1, or 0:forced 0
flow control = X ; N:none, X:Xon/Xoff, or R:RTS/CTS
xon code = 0x11 ; hex and dec notation allowed, typically 0x11
xoff code = 0x13 ; hex and dec notation allowed, typically 0x13

[APPLICATION] ; Application program
; boot address = 0x30000 ; hex and dec notation allowed
boot address = 0x20000 ; hex and dec notation allowed

[ETH] ; Network Settings
mode = A ; A=autonegotiation
hostname = dsp.company.net
IP =
gateway =