TCP/IP and RTOS on C167 derivatives from Infineon
by Stefano Costa (see contacts info)
When it comes to performance, ease of development, cost and small footprint in network connections for embedded applications, BlueWind suggests that a 16 bit microcontroller be used together with an Ethernet controller targeted at this kind of environment. The communication software (TCP/IP, FTP, HTTP, SMTP and whatever is needed) should be developed taking into account the need for low memory consumption and robustness: usually, you can't "reboot" this kind of applications like a Personal Computer! This is why the communication library should be coupled with a good and proven Real Time Operating System (RTOS) or Real Time Executive (RTX) especially tailored for the microcontroller being used, so that the maximum performance and efficiency can be obtained. This article describes some hints about using a 16 bit microcontroller for Ethernet communication tasks in embedded designs. We will focus on what we use extensively for this kind of applications:
TCP/IP is no easy stuff to be developed and tuned. U.S.Software and the other software houses did a good
job when writing the libraries available for embedded applications, and USNET is especially designed
to be fully functional when used without any kind of Real Time Executive. So why do you need to spend
more money and time adding an operating system to your application?
First of all, the communication with TCP/IP is normally only a (small) amount of the work assigned to the
microcontroller. The rest of the application can be very different and sometimes it has timings and
relations with hardware that must be absolutely respected. Isolating the communication tasks with the aid
of an operating system helps a lot separating things between real-time and protocols.
Performance in theory should not be affected by using an operating system; but this is only true if you
are so smart while developing the software that you don't create situations when the microcontroller is
needlessly waiting for some protocol event without using it's processing power to carry on other
calculations. It's very difficult to design the application this way, and it can waste a huge amount
of time. It's not true that operating systems are justified mainly for large, complicated and
time-critical projects: sometimes (or very often), the time wasted in a couple of small projects would
easily buy the real time library and its learning curve.
TCP/IP is particularly prone to generating situations, at the application level, where the code stops
waiting for something that will happen very often or never, depending on not-predictable external events.
Just think of an HTTP server task: sometimes waiting seconds or minutes for the user to read the generated
page, some other times processing a request for a large and annoying image inside the HTML page!
USNET is specifically designed to be integrated with various well-known operating systems. The configuration for each
one is available in the library itself, in the form of a bunch of modules (sources and makefiles) that
are already designed and tested for the particular combination of toolchain, microcontroller and operating
system being adopted. When the operating system is to be used in the communication application, it must of
course be configured according to the application's needs and USNET must be switched to "operating system
aware" mode, by changing compilation definitions in makefiles.
The configuration for RTX166 from Keil is not (yet) officially available from U.S.Software, while the
combination of Infineon C167 derivatives and Keil toolchain is one of the options. BlueWind successfully
designed all the configuration modules for RTX166 in USNET, according to the rules dictated by U.S.Software.
The resulting package, examples and knowledge are now available from BlueWind and from some U.S.Software
distributors like Logic Technology (see www.logic.nl) as part of our
consultancy services.
Like with any other operating system, using Keil RTX166 means carefully configuring it's options depending on
the number and kind of tasks that the application needs. When such a complicated protocol stack like TCP/IP
is involved, this step is more delicate, because it's always difficult to forecast all the situations that
your application will be involved in. Things like reserving the correct amount of stack space for each task,
or simply determining the maximum number of tasks that the application will use during its life, become
difficult in such a dynamic environment. In the modules we created, a little help is given by some macros that
calculate the main configuration values (like total heap and stack space) by entering detailed values for
each kind of task.
A few details will be outlined here, about how to design a system where an Infineon C165UTAH 16 bits microcontroller is connected to an Ethernet MAC+PHY component like the CS8900A from Cirrus Logic to build a very cheap and simple TCP/IP-enabled application.
Details
In the following diagram only the relevant connections are shown between the microcontroller
and the Ethernet peripheral, while other few components and connections are required to complete
the design.
At the physical link side (10BaseT) only one tranformer and small passives are needed, this is
well explained in the Cirrus Logic documentation (the only hint here is *do not* mount the protection
1KV capacitors shown in some earlier documents, they will alter the Ethernet levels!).
If you plan to use 10Base2, then a DC/DC and other passives will be mounted.
The CS8900A, like other similar devices, provides some pins and logic to read automatically some
from an EEPROM (Ethernet address, memory configuration etc.) but this is not really
needed in an embedded system, where a microcontroller is available to configure the peripheral. You
will only need to configure the memory access to the CS8900A so that the default values of its
memory map are satisfied; the Decode Logic shown in the diagram below is responsible for doing this,
and for asserting the right control signals depending on the access being performed to the peripheral.
A suitable logic would be something like this one (pseudo code):
IF (A[8..11] == b0011) THEN
IOR = RD * CS2;
IOW = (WRL+WRH) * CS2;
MEMR = 0;
MEMW = 0;
ELSE
IOR = 0;
IOW = 0;
MEMR = RD * CS2;
MEMW = (WRL+WRH) * CS2;
ENDIF
Bluewind developed applications using U.S.Software USNET (both stand alone and with real-time executives like Keil RTX166), ranging from industrial Ethernet as a fieldbus up to a WAP stack for GSM mobile phones, always appreciating the easy hardware and software development that a 16 bits microcontroller platform offers if compared to a traditional 32 bits approach. But of course sometimes the performance of a 16 bits can be a concern; what we have learned is that normally the performance of a TCP/IP link depends more heavily on the final application establishing and using it than the processing power of the serving node. For instance, in a lot of situations what is really needed is a small Web server running on the embedded node, a TELNET server for configuration, and sometimes an FTP server with simulated filesystem for easy parameters and logs transfer. Depending on the application, TCP or UDP links (usually not more than two at the same time) are then established for the exchange of information, but it's usually a "burst" transfer rather than a continuous "stream" of data.
Details
The U.S.Software library is designed in such a way, that the data traversing the different
protocols composing the TCP/IP stack are not needlessly copied between buffers; on the other
hand, the CS8900A component performs most of the job needed at the lowest level to deliver and
decode packets being exchanged, before issuing an interrupt request to the microcontroller. This
results in the microcontroller doing a surprisingly limited amount of work on the data during
the communication, and the application having most of the microcontroller processing power
available.
The performance will never be comparable to a system where DMA
transfer between the CPU and the Ethernet MAC is designed (this could be done with C167 in
theory, but it was never considered necessary) but it's also true that usually the fastest
response of an Ethernet link is appreciated when large files are exchanged between workstations,
and this is not the case in an embedded application.
Stefano Costa, the author of this document is co-founder and design engineer at
Bluewind (www.bluewind.it), a
consulting company based in Italy specialized in the design of electronic systems.
C165UTAH from Infineon (www.infineon.com) belongs to
the well-known family of 16 bits microcontrollers best suited for industrial, automotive
and communication applications.
USNET from U.S. Software (www.ussw.com) is a complete TCP/IP
stack available under different kinds of licences as a source-code library, already ported
to the Infineon C167 family of microcontrollers and Keil toolchain. The product is very well
known here at Bluewind and proved to be a good choice in embedded designs when robustness and
flexibility is a must.
Keil (www.keil.com) is the reference toolchain at Bluewind,
both for 8 bits (all 8051-like derivatives) and 16 bits (Infineon). The C language compilers
and debuggers come with a reduced version of RTX166, the Real Time Executive that in it's full
version is a reliable and complete operating system designed for the same families of
microcontrollers. Both the limited and full versions of RTX166 are available as source code.
Copyright Bluewind. All rights reserved.