TP/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 rely upon an underlying operating system which provides buffer space and schedules events, but many DSP applications cannot tolerate the overhead and latency 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 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 countervail the advantages.
D.SignT therefore decided to develop their own TCP/IP stack for the D.Module, D.Module2, EVM and DSK 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.
|ZeroConf/Auto-IP||automatic client configuration (IP address assignment)|
|ARP||Address Resolution Protocol, resolves the IP address to a hardware MAC address. No user action is required. If an address is unknown, an ARP request is generated automatically.|
|IP||Internet Protocol. All data transferred by DNS, DHCP, ICMP, UDP and TCP is automatically packed into IP packets.|
|ICMP||Internet Control Message Protocol. The D.SignT.TCP/IP protocol stack responds to "ping" requests to test a connection|
|UDP||User Datagram Protocol, provides a one-to-one or one-to-many connectionless data path. Data transmitted via UDP is not guaranteed to reach its destination. This protocol has very low overhead and is especially useful for transmitting non-critical data like audio and video streams, or any other realtime data where retransmissions cannot be tolerated.|
|TCP||Transmission Control Protocol, provides reliable, connection-oriented, one-to-one connections. All data is acknowledged by the receiver and retransmitted automatically if required. This protocol should be used for critical data like software uploads, commands, etc.|
|DHCP||Dynamic Host Configuration Protocol. This protocol has been developed to ease maintenance of a TCP/IP network. A DHCP server manages the allocation of IP addresses and provides additional network configuration data like gateways, DNS servers etc. The TCP/IP stack integrates the client functions required to obtain an IP address, DNS server, and gateway.|
|DNS||Domain Name System. This protocol allows to use symbolic host names instead of numerical IP addresses. The TCP/IP stack integrates the client functions to query a DNS server to resolve a host name.|
|FTP||File Transfer Protocol, based on TCP. A FTP server library exists, which allows to upload programs and parameters to the module´s Flash Memory, or download log files and data from the DSP. The FTP server is widely configurable: users, passwords, directories, files, and access restrictions are maintained in a simple data structure.|
|HTTP||Hypertext Transfer Protocol, based on TCP. We do provide a HTTP server framework, which passes GET and POST parameters to a user-defined callback function, hence providing the required flexibility for dynamic data. The DSP can send static HTML pages and images as well as inserting the current value of variables, generate images from data acquisition buffers, etc. on demand.|
|TELNET||Terminal-based communications for maintenance and updates|
|SMTP||Simple Mail Transfer Protocol. Send and Email message or notification|
|SNTP||Simple Network Time Protocol. Obtain the current time from a network/Internet server|
|net_init||initialize the TCP/IP stack|
|net_set_gateway||configure the default gateway for connections outside the local network|
|socket_open||create and open a new socket|
|socket_close||close a socket|
|set_socket_option||specify non-default socket options, e.g. disable UDP checksum|
|install_icmp_socket||install a socket for ICMP messages (ping)|
|net_send||non-blocking send function|
|net_send_ready||blocking send function (binary data)|
|net_send_string||blocking send function (ASCII streams)|
|net_recv||non-blocking receive function|
|net_recv_ready||blocking receive function|
|net_isq||main networking function, must be called periodically in your program main loop, from a timer interrupt, or as a task in a RTOS|
|connect||establish a TCP connection|
|shutdown||shutdown a TCP connection|
|gethostbyname||host name resolution|
|accept||test if a TCP socket is connected|
Typical memory requirements (including ARP, IP, ICMP, UDP, TCP, DHCP and DNS) vs. DSP architecture. A minimum configuration (UDP only, no DHCP) will reduce the code size by approx. 25 percent.
|TMS320F2812/28335||27.4K bytes||5.6K bytes + 604 bytes per socket|
|TMS320C550x||35K bytes||8K bytes + 640 bytes per socket|
|TMS320C6xxx||72K bytes||7.2K bytes + 604 bytes per socket|
|TMS320VC33||15K words||2.7K words + 151 words per socket|
|ADSP-21065||12.4K words||1.9K words + 224 words per socket|