|
| Home |
|
|
Module RTComModule RTCom offers interrupt-driven communication through serial ports. Some of RTCom's features:
The interface for RTCom is given in include file Rtcom.h and is documented in the RTKernel-32 Reference Manual. RTCom supports both polled and interrupt-driven communication. In general, interrupt-driven communication should be used for better performance. In interrupt-driven mode, data is buffered up to a user-defined limit before data is lost. In polling mode, no data is buffered. If a 16550A UART chip is used by a serial port, its internal 16-byte buffer is used. If interrupt-driven communication is desired on a "standard" port (i.e., a port not on a DigiBoard, Hostess card, or other interrupt-sharing card), the following steps should be taken:
Function COMEnableInterrupt allocates both receive and send buffers with the same size. If you need different sizes, call COMAllocateBuffers first; COMEnableInterrupt will not allocate buffers again. If polled communication is desired, the following steps should be taken:
ProtocolsBy default, RTCom uses no protocol to prevent overflow errors. In this mode, it is assumed that all communication participants are ready to accept data. If a receive buffer of RTCom overflows, the error COM_BUFFER_FULL is reported. In interrupt-driven mode, RTCom also supports protocols XOn/XOff, RTS/CTS, and DTR/DSR. These protocols can prevent buffer overflows. A receiver checks after each byte received whether the receive buffer has filled up to a dangerous level. If so, the sender is informed to stop sending. As soon as the receive buffer has been emptied to a safe level, the sender is allowed to continue sending. The XOn/XOff protocol uses special ASCII control characters to send the necessary information to the sender. It can only be used if the actual data stream never contains XOn/XOff characters. Protocols RTS/CTS and DTR/DSR use handshake lines. However, they require that the corresponding lines are actually connected in the cable used. RTCom supports these protocols in Passive and Active modes. In Passive mode, RTCom will understand and adhere to XOn/XOff characters or CTS or DSR signals, respectively. In this way, a buffer overflow error can be prevented on the remote device. The local receive buffer can still overflow if the receiving task does not collect the data fast enough. In Active mode, RTCom will also protect its own receive buffer. If a buffer fills to more than 70% of its size, an XOff is sent to the remote device (or signal RTS or DTR is reset). In this case, the remote device should stop sending. A protocol task in RTCom will then periodically check whether the buffer is filled to less than 30% of its size. If so, the remote device is allowed to continue sending (by sending an XOn to it, or by setting the RTS or DTR signal). Hardware ConfigurationRTCom expects the following IRQ settings for COM1 to COM4:
Please make sure that your serial I/O board actually supports interrupt sharing. If it does not, you cannot use COM1 and COM3 or COM2 and COM4 simultaneously in interrupt-driven mode. COMSetIRQ may be used to define different IRQs for ports COM1 .. COM6. Interrupt sharing can be defined for any IRQ, but only for port pairs COM1/COM3 and COM2/COM4. Best performance is achieved when every port has its own IRQ. DigiBoard Cards (PC/x)Before you can use one or more DigiBoard cards, you have to inform RTCom about the card type, the status register address, the interrupt request to be used, and which port number you would like to assign to the first port on the board. Please note that the card(s) must be configured to use only one interrupt request. If you have several cards installed, they should all use the same address for the status register. For example, if you have set the status register to 0x140, the IRQ to 7, and you would like the ports on your card to start at COM5, you should include the following statement in your program before the card can be used: COMSetBoardType(COM_BOARD_DIGIBOARD, 0x140, 7, 4); Subsequently, the I/O address of each port must be individually defined using COMSetIOBase. If you have a card with four ports and you have left the I/O addresses at factory settings, the following statements would be required: COMSetIOBase(4, 0x100); COMSetIOBase(5, 0x108); COMSetIOBase(6, 0x110); COMSetIOBase(7, 0x118); After this initialization, ports 4 through 7 can be used as explained above. Both interrupt-driven and polling modes are supported. Hostess CardsBefore you can use a Hostess card, you have to inform RTCom about the card type, its base address, the interrupt request to be used, and which port number you would like to assign to the first port on the board. Cards with four or eight ports are identified by card type COM_BOARD_HOSTESS. Cards with 16 ports have card type COM_BOARD_HOSTESS_16. For example, if your board with four ports is installed at address 0x280 and uses IRQ 7, and you already have COM1 and COM2 in your computer, then you should include the following statement in your program before the card can be used: COMSetBoardType(COM_BOARD_HOSTESS, 0x280, 7, 2); Then, the I/O address of each port must be defined individually using COMSetIOBase. Using the example above, the following statements would be required: COMSetIOBase(2, 0x280); COMSetIOBase(3, 0x288); COMSetIOBase(4, 0x290); COMSetIOBase(5, 0x298); After this initialization, ports 2 through 5 (COM3 .. COM6) can be used as explained above. Both interrupt-driven and polling modes are supported. Other Interrupt Sharing CardsDigiBoard and Hostess cards have a special status register used to identify the port that has generated an interrupt. If your I/O card does not have such a register, you can use the COM_BOARD_GENERIC type. It checks all ports on the card at every interrupt. Before you can use a generic card, you have to inform RTCom about the card type, the interrupt request to be used, which port number you would like to assign to the first port on the board, and how many ports the board has. For example, if your board with four ports uses IRQ 7 and you already have COM1 and COM2 in your computer, then you should include the following statement in your program before the card can be used: COMSetBoardType(COM_BOARD_GENERIC, 4, 7, 2); Then, the I/O address of each port must be defined individually using COMSetIOBase. Assuming the first port uses I/O address 0x280, the following statements would be required: COMSetIOBase(2, 0x280); COMSetIOBase(3, 0x288); COMSetIOBase(4, 0x290); COMSetIOBase(5, 0x298); After this initialization, ports 2 through 5 can be used as described above. Both interrupt-driven and polling modes are supported. Please note that DigiBoards and Hostess cards show better performance than generic cards thanks to their hardware support for interrupt sharing.
|
