The Axis hardware includes ten serial ports, two are legacy RS232 ports corresponding to the normal serial ports found on most x86 PC hardware. The Linux serial driver detects these and associates them with the first two serial device minor numbers. By convention recent Linux kernels (since 2.2) give asynchronous UARTS an entry in /dev of the form /dev/ttySn, where n is number. The first serial device is called ttyS0, the next is called ttyS1. In most common kernels ttyS0 is the device DOS users will remember as com1, ttyS1 com2.
Note: While the Axis system does not implement hardware at the addresses normally associated with com3 and com4 the kernel does reserve slots for these devices.
Axis provides another 4 UART channels (optionally 8 if a second UART device is fitted to Axis main board). The UARTs are 16550A devices. The Axis driver hands over responsibility for these devices to the Linux serial subsystem. This system allocates tty numbers to the Axis UARTs, in most systems the first Axis UART appears as serial device 4 (ttyS4).
This allocation can be confirmed by checking the /proc file /proc/tty/driver/serial.
If they do not exit create entries for the serial devices:
mknod -m666 /dev/ttyS0 c 4 64 mknod -m666 /dev/ttyS1 c 4 65 mknod -m666 /dev/ttyS4 c 4 68 mknod -m666 /dev/ttyS5 c 4 69 mknod -m666 /dev/ttyS6 c 4 70 mknod -m666 /dev/ttyS7 c 4 71 mknod -m666 /dev/ttyS9 c 4 72 mknod -m666 /dev/ttyS10 c 4 73 mknod -m666 /dev/ttyS11 c 4 74 mknod -m666 /dev/ttyS12 c 4 75
The Axis UARTs can now be used in the same way as a normal Linux UART. If the second optional quad UART pack is fitted then TX, RX, RTS, and CTS signals for ttyS9 - ttyS12 appear at TTL levels on the backplane.
Note: Only the TX, RX, CTS, and RTS signals of any UART are exported off the Axis main board. The signals DSR, DTR, CD, and RI are not.
The signals from the first quad UART are routed though the Axis hardware and these signals can then be routed to specific interface hardware. Routing options include: RS232 level signals, RS485 signals, TTL outputs and ccTalk compatible interfaces.
The driver allows the routing associated with an individual UART to be dynamically modified, however only certain combinations of routes are allowed. Only one UART can be routed to each interface and each interface will only accept routes from two UARTs.
The simplest way of viewing the system is to regard it as two independent systems each with two UARTS and four destinations. The first system controls routing for the first pair of UARTS ttyS4 and ttyS5. It allows each of these to be routed to one of the following destinations:
A second logical system allows the UARTs ttyS6 and ttyS7 each to be routed to one of the following destinations:
Note: Individual interfaces can enabled or disabled.
To allow this to be configured dynamically the /proc/axis_00/serial directory contains twelve entries; eight associated with interfaces and four associated with UARTS.
The entries of the form CCTALK_A, CCTALK_B, RS232_A, RS232_B etc. control enabling interfaces. Writing the ASCII value 1 will enable the interface the value 0 will disable it.
The command:
echo -n 1 > /proc/axis_00/serial/RS485_B
will enable the RS485_B interface.
The command:
echo -n 0 > /proc/axis_00/serial/RS485_B
will disable the RS485_B interface.
Reading the entry shows the current state.
The entries of the form ttyn_Route allow the routing to be manipulated. The commands CCTALK, TTL RS232 and RS485 if sent to these entries will setup routes.
The command:
echo -n CCTALK > /proc/axis_00/serial/tty7_Route
will route tty7 to the CCTALK_B interface.
Reading the entry will display the current route and whether the target interface is active.
cat /proc/axis_00/serial/tty7_Route
will return:
CCTALK active
Showing that ttyS7 is routed to a CCTALK interface and that interface is active.
Given that most applications need only a static configuration an alternative mechanism to setup suitable set of routes is to redefine the default route setup installed by the Axis driver as it loads. This involves a very simple modification to one of the driver source files but once done the driver will setup the desired routing each time its loaded.
The default routing is defined using a set of #defines in the file serial_io.h. Each line is associated with an individual UART. UART1 becomes ttyS4.
#define UART1_DEFAULT ((ROUTE_TO_RS232|UART_ENABLE)<<FPGA_UART_1_SHIFT) #define UART2_DEFAULT ((ROUTE_TO_CCTALK|UART_ENABLE)<<FPGA_UART_2_SHIFT) #define UART3_DEFAULT ((ROUTE_TO_RS232|UART_ENABLE)<<FPGA_UART_3_SHIFT) #define UART4_DEFAULT ((ROUTE_TO_RS485|UART_ENABLE)<<FPGA_UART_4_SHIFT)
The format should be self explanatory. If this approach is taken the /proc/axis_00/serial entries can be used to verify that the correct routing has in fact been setup.
The file /proc/axis_00/serial_routing will show all the current routes associated with each UART in turn.