• Company
  Info
• Support
• Development
  Tools
• Software
• Custom
  Designs
• Standard
  Products

  Home > Software

D.SignT
Software Solutions

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.
Therefore we carefully fine-tune hardware and software of a D.Module to provide optimum performance and user-friendliness. Our 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 or USB connection - or even network-based if an Ethernet daughter card is attached.
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.
The D.FAT file system for SD and MMC cards finally provides a convenient method for mass data storage and offline data exchange between the DSP system and a PC.

The D.Module.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.Module.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 let´s him concentrate on his actual task: implementing a signal processing algorithm.
Since our boards are targeted at industrial applications we have 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.Module.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.

back to top

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.

back to top

The Configuration File is an ASCII file stored in the module´s Flash Memory. It is 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 the Ethernet adapter 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.
We strongly encourage you to add your own user-defined sections for installation-dependent parameter storage, e.g. 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.

[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 = 192.168.1.199
  DNS = 192.168.1.1
  gateway = 192.168.1.1

[END]

back to top

TCP/IP communications on a DSP system greatly differs from the well-known Personal Computer requirements. A DSP does not need to handle hundreds of simultaneous connections as does a PC based server. On the other hand, latencies and resource consumption are much more critical to avoid compromising signal processing performance.
The majority of available protocol stacks rest upon an underlying operating system which provides buffer space and schedules events. Many DSP application´s realtime constraints however are too demanding to tolerate the overhead of an operating system. A common solution is to "outsource" TCP/IP to a companion processor. However, protocol overhead for interprocessor communications is not negligible and about the same order of magnitude as the UDP protocol. Data transfer time to/from a companion processor is comparable to a direct transfer to/from a network controller. The "pro" side of this approach is reducing the DSP´s burden of handling the TCP protocol. On the "con" side, the higher level protocols based on TCP (HTTP, FTP) require complex interactions of DSP and companion processor, which will use up the advantages.
We therefore decided to develop our own TCP/IP stack for the D.Module and DSK Ethernet Adapter boards. It has been carefully tailored to the requirements of DSP systems. Code and data memory size are minimized, and no additional resources like DSP interrupts or timers are required. The D.SignT.TCP/IP protocol stack can be used in a linear C program, just as running as a task in a realtime operating system, e.g. Texas Instruments DSP/BIOS. The stack supports the following protocols:

The following table lists basic TCP/IP stack functions:

The D.SignT TCP/IP stack is available for the following D.Modules, DSKs and EVMs:

back to top

D.FAT is a file system for SD and MMC cards and provides standard compliant data exchange between the DSP system and a Personal Computer. D.FAT currently runs on C6713 and C6203 D.Modules with attached D.Module.91C111.
D.FAT installs low-level drivers for the Texas Instruments stdio runtime library and allows to access files on the memory card using high-level C functions like fprintf() and fscanf().

back to top