Web 51 - Serial line support

P-Code, network  software.html  Processing packets
Serial line support of Web51 respects the following requirements:
  1. TCP support
  2. Low usage of data memory
  3. Compatibility with MS Windows

Let's talk about the individual requirements in more detail:

TCP requires at least minimal support for a TCP stack in Web51, including the ability to repeat transmission of unacknowledged data. Since the RAM is extremely small, it is not possible to simply move the data from serial line buffer to the TCP stack; instead, a more complicated method had to be devised. Old versions would copy data to the TCP stack and wait for acknowledge before removing them from the buffer. Newer TCP implementation (starting with version 1.13) no longer need this, and implementation of the serial line support is only required to use as little RAM as possible.

Usually, a serial line buffer is implemented in ring fashion through a pair of pointers - one points to the data being written, the other points to data being read. However, since each saved byte counts, Web 51 uses linear buffers, controlled as follows:
Transmit buffer uses a single write pointer (slpoint) that points to the first unused byte of the buffer. Address from which data are read and transmitted is fixed and points to the beginning of the buffer. Whenever a character is sent from the buffer to the serial line, the entire buffer is shifted by one char, effectively removing the transmitted one.
Receive buffer used to need a pair of pointers, due to TCP support. The first one (r1point) would point to the first free byte in receive buffer and was used for writing data from the receiver to the buffer. The other pointer (r2point) would point to the first unread char in the buffer and was used to pass the data from the buffer to the application. In case of retransmission, this pointer would be simply moved backwards. If a transmission of n chars was acknowledged, entire buffer would be shifted by n characters, and both pointers would be moved by the same value.
Newer TCP implementations (starting with version 1.13) no longer require repeated copying of data in case of a retransmission. A method similar to transmit buffer is used; that is, only one pointer (r1point) exists, data are read from the beginning of the buffer and removed by shifting the entire buffer.

Cooperation with MS Windows is quite straightforward; however, it needs lots of memory. Windows place no restrictions on the transmit buffer size, so it depends only on the application that runs on Web 51. However, Windows strongly influence receive buffer size, since they take advantage of HW FIFOs of the PC serial port. Flow control requests, both RTS/CTS and XON/XOFF, depend on the state of the FIFOs and may not be honored immediately. This means that Web 51 buffer must be able to receive another full block of data after signalling "stop, I'm full". Size of this block depends on Windows settings, default is 16 bytes. The receive buffer needs to be extended by this number of bytes. Therefore, the transmit buffer usually eats up 16+1 bytes of Web51 RAM and the receive buffer consumes 32+1 bytes.

Web 51 uses interrupts to control the serial line hardware. Interrupt procedure IRIT transfers data between buffers and the transceiver and controls three status bits (rxint, txint, srun). rxint signals that at least one char was received since it was last cleared. txint similarly signals the transmission of at least one char. srun emulates a hardware signal saying "transmitter is transmitting previously written char". Two bits indicate flow control config, and are set during serial line configuration. One of them (rtscts) enables hardware handshake through RTS/CTS. The other one (xonxoff) enables software flow control through XON/XOFF.

If the XON/XOFF protocol is used, another four bits are used to control the finite state machine that controls receiving. flagtxoff bit corresponds to CTS in hardware flow control. If set, data transmission is disabled. It is cleared (or set) whenever XON (or XOFF) is received. With XON/XOFF enabled, the control XON and XOFF chars are not stored into the receive buffer. Receiver uses a similar status bit flagxoff that indicates whether a XON or XOFF was transmitted, enabling or disabling transmission from the other station. Since a XON/XOFF cannot be transmitted immediately (transmitter has to finish current transmission first), another two bits, xonrq and xoffrq are used to signal to the transmit handler that a control character is to be transmitted instead of buffered data.

Sponzored by LPhard Ltd. Graphics by GIMP Created by EasyPad

(c)Copyright 2000 - 2002, HW server & Radek Benedikt
Web51@HW.cz, Web51.HW.cz
P-Code, network  Obsah  Processing packets