Projectdescription Internet protocol on microcontrollers.

Goal: "The ultimate connectivity"
The realization of Internet connection for microcontrollers.
The implementation of a user-interface, based on HTML-pages, to simple controllers.
The control of home-installations or professional machines, with Internet technology.
The realization of a HTTP-server with a low cost microcontroller like a 8051 with 32k ROM en 32k RAM.
Examples: The project is a practical approach of the inplementation of TCP/IP protocols on microcontrollers. It is an original implementation without the use of existing software and has, by no means, the intention to serve as model or even to be practical and/or efficient. In the making, however, knowledge is collected on the protocollevel and of "real-time" operating systems. Comment is invited.

  1. Projectstatus
  2. Operating system
  3. Implementation
  4. Protocols
  5. Used product
terug verder Projectstatus:
The general applicability of the protocol is the main reason why this project is started with PPP.
Up to now, the project targeted the operating system, which has been used in an application with 4 serial ports and some specific communication protocols. Problems were solved using inter-process communications: the sharing of data by processes through the use of blocks and the activation of a multitude of processes with the same code as device-drivers to different serial ports. A set of subroutines and macros resulted as a basis for continuing with TCP/IP-protocols. It became clear that upgrading to a 80C251 with 128k flashcode will make things easier, especially when larger applications must be served, however the basic specification: 8051 with 32k/32k will be supported as long as possible. Minimal implementation of IP en icmp: only the distributionfunction of IP is implemented; routing is not used in a "host", fragmentation will be implemented later. UDP-process generates icmp message: protocol not available.
Buildup of several Telnet sessions in a "socket-pool".
The most difficult part: the TCP-protocol.

Operating system:
The user normally is not aware of the functions of the operating system. The only thing he should know is that the operating system controls the hardware in supporting the applications. To the programmer, however, it is the key to the system. Until for several years, when live was easy, every designer made his own software from scratch. At present an operating system is used to deal with overall increased complexity. In embedded systems operating systems are often marked as "real-time", indicating they: react on external events or attention in a predictable way in a virtual immeasurable time related to the frequency of the occurences.
In this project the use of an operating system is no necessity however for reasons of easy software debugging and application implementation a totally original operating system is designed with the following characteristics.
Process-layers.
In the spirit of a "real-time" system a strategy is chosen to separate the time-critical events and other tasks. For instance in TCP/IP, as in some communications in general, the complete and correct reception of data is far more important than a short response time.
In priority order:
  1. interrupt driven datatransmission to/from fifo-buffers "time-isolate" communications.
  2. timerinterrupt driven processing (with lower priority) of TCP/IP protocols and applications.
  3. background handling of usercommands and batch files.
The difference with other real-time operating systems is the separation of datatransmission in "own" interrupt routines that communicate with buffers and the use of these buffers in timer-interrupt driven processes. Most systems use single processes to attain this. The chosen method is, to my opinion, better suited for, relatively slow, asynchronous communication protocols. With less o.s.-overhead the most important task is attended: the correct processing of all information.
A just-in-time operating system so to speak.
Processes are run, based on a single timer expiration, in a frequency in the order of its processnumber. Process_0 is run every other timer-tick, process_1 2x slower etc. This method has the advantage of low O.S.-overhead however experiences with process interactions learned that every process should have is own, independant, timer. At the expence of one word in internal memory for every process. Every timer-tick decrements all active process-timers and the process with timervalue 0 will be scheduled.
Every process has to give control back to the operating system however can run as long as it likes. The designer has to guarantee that every process runs as short as possible and can not corrupt the controller; this is achieved by making every process a finite state-machine. The benefits are low overhead on context switches; simple inter-process communication: a process can adapt every others' process-parameters directly.
Databuffers.
The basis of the system are two kinds of databuffers that are used for communications between different events: The blocksize of 256 bytes is mandadory when speed is an issue on a 8051. The O.S. has subroutines for the handling of data to and from the databuffers: The targetsystem for development and testing the software has 5 full-duplex serialports. Every port can be initialized with a connection to an input- and an outputfifo (data handled in the 1st process-layer). The "edit"-process can be attached to these fifos and has the function of making a block from typed-in characters (2nd process-layer). This block is passed to the scheduler through the scheduler-fifo. The scheduler interprets all these "scheduler-messages" as commands: it passes the variables in the line to the module with the command-name and executes the command-code in the 3rd process-layer. A scheduler-message contains the blocknumber of the command-line and the fifonumber for textoutput. Several edit-processes can be activated with different serial-port connections thus creating a "multi-user" system.
Commands.
In the code-memory of the micro, commands are formatted in a special way. Basically it is a piece of code identified with a header containing startaddress, name, manual etc. This module enables the microprocessor, at startup (or by command: init), to detect all available modules and to manage these in a "directory". Compare it to a disk-drive. Several classes of commands exist: the most important being the "executable" and the "batch-file". With the system-input commands can be executed and batch-files created. A batch-file is, on execution by the scheduler, split into new commands in the scheduler-fifo (one for each line). By this mechanism a batch-file can run itself repeatedly while terminalcommands and other batch-files can be run as well. All commands are placed into the scheduler-fifo and executed in line.
Commands serve an important role in monitoring the system. As the targetsystem also is the developmentsystem commands like displayram can, on line, monitor the processes when all system variables (pointers, buffers, etc.) are placed in external ram.
The fifo-pointers, which are used in the 1st process-layer, can better be placed in internal memory for speed's sake. Systemgeneration makes a choise between internal/external memory so, after debugging, optimization can be done.

Processes are also formatted in the special module-form to make them visible in the memoryspace of the microcontroller. The systemterminal-input recognizes the "hexload" format and thus processes, but also commands and batch-files can get loaded in code-ram. Processes are activated with the command: "proces". This command signals the O.S. that a process needs to be activated with number and name of the process, the timer-value and other parameters. Every process gets its own memoryblock of 256 bytes that can be used for the parameters and run-time variables. This block has gotten the function of the internal memory of a "single-proces" system. Every process has one 'mailbox'; this is a 16-bytes fifo for accepting short bytes-messages from other processes.(store- en getpointer of 4 bits= 1 byte in internal ram; data on fixed location in external ram)
September 1996
An important set of commands controls the databuffers and communicationcontrollers; the basic performance of the system can be controlled on-line. In rom a batch-file: "startup" exists which does the basic configuration: initialize fifo's, serialports and start process: "edit". It also runs the batchfile: "userstartup" which can be placed in code-ram, by the user, and contains further configuration (start user-processes etc.).

terug verder Implementation
October 1996
Overview protocols:
In this figure an overview is given of possible protocols in the Internet Controller. A clear insight in the functioning and interrelation of the TCP/IP protocols can be obtained by tracking the stream of data in the figure. To start at the bottom, at the network connection, there are the incoming and outgoing datastreams. Messages are labeled, like a parcel with an address, by a protocol- and a portnumber destined to one of the protocols. Each protocol delivers a typical service in the totality: telecommunications. The HDLC-layer is divided in a receive- and a transmitprocess. The receiving process checks a message on errors and transfers it to one of the processes: lcp, ipcp en IP. While building a PPP-connection the lcp-process first activates the negotiation of parameters controlling the low-level connection facilities between both points (for instance the Internet Controller connected to a terminal-server of a Unix-system).
After reaching consensus the ipcp-process becomes activated and starts the same procedure for the IP-protocol. In this way several protocols can activate a "link" between both communication points.
The figure shows components of the IP-protocol.
After connecting the "link" IP-messages can be exchanged. The IP-protocol transfers messages to icmp, UDP or TCP which each has its own set of target processes.
Lcp, ipcp en icmp serve a controlfunction in the connectionphase and in the signalling of communications-problems. IP handles the transport of data over the network (fragmentation and routing) while TCP realizes the reliable datatransport. Protocols like http, ftp en telnet use the reliable connection of TCP to communicate their own data between "client and server" or "peer and peer".

Configurations with the Internet Controller:

Remote control:

Heating installation:

Private answering machine for email:

Datalogger:

Alarm:


Dataformat:



terug verder Protocols
The PPP-protocol:


IP/icmp
Minimal implementation of IP en icmp: only the distributionfunction of IP is implemented; routing is not used in a "host", fragmentation will be implemented later. UDP-proces generates icmp message: protocol not available.

Telnet/rlogin/chat
Buildup of several Telnet sessions in a "socket-pool".

The TCP-protocol.

terug R.G.Logchies homepage