The Board has 3 independent RS232 and a RS232/485 multiplexing port. However, a problem occurs during actual testing. 1 and 2 ports can work normally (and later I found that there was a problem, but I could not fully read the sensor data ), however, three or four ports are very strange.
The main features are:
1. input and output are supported.
2. Slow input/output speed
3. It is found that the data is in the cache and can only output about 12 characters at a time (uncertain length ).
It was not found at the beginning. Later, I consulted other technical personnel. It is estimated that the problem was interrupted.
I found the following article by Google: the original source, the problem solved, and I am very grateful to the experts for their guidance. Unfortunately, we have not had time to go deep.
By default, Linux supports four serial ports: COM1 (ttys0), com2 (ttys1), com3 (ttys2), and com4 (ttys3) (cuax is no longer used in newer Linux to differentiate inbound and outbound traffic.) In general, COM1 and com3 use irq4, and com2 and com4 use irq3 together.
Although Linux supports the shared interrupt technology, it cannot detect actual physical interrupt conflicts. In the above circumstances, com3 and com4 cannot be used properly due to interruption conflicts. This article describes how to use com3 and com4 in the red hat 8.0 environment.
Because the current development project needs to use four serial ports at the same time, and there are exactly four IPC Used for development, which saves the trouble of buying multiple cards and uses com3 and com4 for direct programming. During the test, the problem occurs: com3 and com4 are very slow to send and receive data. It takes 10 or 20 seconds to send or receive data of several bytes at the communication rate of 115.2k, it cannot meet the application requirements at all.
Check the data to confirm that this is a typical interruption conflict fault. The usage is as follows:
Setserial/dev/ttys2 IRQ 0
Using the communication program, there is no obvious delay in data transmission. This is because when com3 is set to irq0 interrupt, the device does not actually use the interrupt, but uses the polling technology, which proves that the fault is caused by the interruption mechanism and conflicts occur.
The patch cords of com3 and com4 on the motherboard indicate that irq5 and irq7 can be used, so the jumper is set and run.
Setserial/dev/ttys2 IRQ 5
Setserial/dev/ttys2 IRQ 7
Using the communication program, we found that the fault still exists and suspected that there was still a conflict. Irq5 and irq7 are usually used in parallel, but they are not used in the current system. Enter the bios and find that the parallel port is set and irq7 is occupied. Disable the disable option. Seems to have little to do with irq5, found that irq5 and 7 in the settings is "PCI/isa pnp", changed to "legacy Isa" mode, restart, COM1--COM4 can be used normally.