amescon / raspicomm-module

raspicomm kernel module with tty driver support for rs485 (raspicommrs485.ko)
12 stars 14 forks source link

using raspicomm rs485 causes input overruns on the rs232 serial port #6

Open bbinet opened 9 years ago

bbinet commented 9 years ago

We are using amescon raspicomm extension board to be able to use both rs232 (baudrate of 38400 bit/s) and rs485 (baudrate of 1200 bit/s) at the same time. But it doesn't work very well: when both rs485 and rs232 are activated, we always get "X input overrun(s)" messages dumped to syslog and the application which is communicating over rs232 fails to decode some messages (probably because parts of these messages are dropped).

Here is a excerpt from syslog:

Mar 25 16:14:37 hl-mc-4-dev kernel: [25924.781649] ttyAMA0: 1 input overrun(s)
Mar 25 16:14:45 hl-mc-4-dev kernel: [25932.673028] ttyAMA0: 1 input overrun(s)
Mar 25 16:14:45 hl-mc-4-dev trserver: Error decoding tracker ID from tracker: #0150,0,0,0,0#012
Mar 25 16:15:32 hl-mc-4-dev kernel: [25979.919178] ttyAMA0: 1 input overrun(s)
Mar 25 16:15:32 hl-mc-4-dev trserver: Error decoding data from tracker: #015B2,3,0,0,0,0,0,0E3,0,0,0,12,1,84,-9999#012
Mar 25 16:15:35 hl-mc-4-dev kernel: [25982.313622] ttyAMA0: 1 input overrun(s)
Mar 25 16:15:45 hl-mc-4-dev kernel: [25992.947961] ttyAMA0: 1 input overrun(s)
Mar 25 16:15:45 hl-mc-4-dev trserver: Error decoding data from tracker: #015B3,1,1,0,0,02,258,0,1#012
Mar 25 16:15:52 hl-mc-4-dev trserver: Error decoding data from tracker: #015B2,2,0,0,0,0,0,2A2,3,0,0,0,0,0#012
Mar 25 16:15:52 hl-mc-4-dev kernel: [26000.096681] ttyAMA0: 1 input overrun(s)
Mar 25 16:15:57 hl-mc-4-dev kernel: [26004.244391] ttyAMA0: 1 input overrun(s)
Mar 25 16:15:57 hl-mc-4-dev trserver: Error decoding data from tracker: #015B0,2,0,0,0,0,0,0A0,3,0,0,0,0,0#012

Also please note that when rs485 is disabled, everything is fine.

So do you know why using rs485 causes these "ttyAMA0: X input overrun(s)"? and how we can fix those so that we can use both rs232 and rs485 at the same time? Maybe this is due to some busy-wait operations in the rs485 driver source code?