2006-12-29 21:37:56 UTC
I've just been 'browsing' the serial.c code and I have a (hopefully stupid?) query...
At present, the flags buffer takes on one of the values selected from the TTY_* definitions as defined in linux/tty.h
Presently, the defined flags consist of:
TTY_NORMAL, TTY_BREAK, TTY_FRAME, TTY_PARITY and TTY_OVERRUN
My 'opinion' is that it's possible for more than one flag to be relevant on a single received byte.
For example, if someone were to 'disconnect' the serial cable part way through reception of a byte, then that byte could have BOTH a framing error (no stop bit detected) as well as a parity error...
Therefore, I'm questioning whether the TTY_* definitions should be bitmasks that are 'or'd into the flags buffer rather than direct assignments...
If that's not acceptable (for reasons beyond my knowledge), then I am suggesting we check for a framing error BEFORE we check for a parity error in the receive_chars() function. My 'opinion' is that a framing error is a 'higher priority' class of error than a parity error. The current code organization checks for and reports a parity error BEFORE it checks for framing errors and therefore 50% of framing errors will be reported as parity errors (assuming parity is actually in use of course).
What I have _NOT_ checked is whether the UART itself disables the reporting of a parity error when the byte is received with a framing error. However, I'm guessing that at least the 'el-cheapo' UARTs don't mask out this condition if not ALL UARTs...
The reason I'm highlighting this is because I'm working on a project that interfaces to multiple MicroChip microcontrollers using a custom written line-discipline on the serial ports (and I'm converting the RS232 output to RS485, but that's another story). The 'protocol' (if you can call it that) 'packetizes' the data stream somewhat like the existing HDLC ldisc. The *first* byte of each packet is sent / received with the 9th bit (aka the parity bit) set [MARK Parity] and the remaining bytes of the packet are sent / received with the 9th bit (aka the parity bit) unset [SPACE parity]. The MicroChip microcontrollers are able to 'trigger' on the 9th bit being set which enables me to eliminate a significant volume of redundant interrupts on them when a packet is not directly addressed to them... When the first byte of a packet DOES address the microcontroller, either directly or via the 'broadcast' address, the UART on the microcontroller is switched over to receiving _ALL_ the remaining bytes of the packet. If the first byte of a packet DOES NOT address the microcontroller, then it simply ignores all the remaining bytes of the packet without generating any interrupts on the microcontroller. This significantly reduces interrupt thrashing on them. Since the UART in our PC, (8250, 16450, 16550 etc) doesn't directly support 9 bits per byte, the parity bit seemed the logical choice. However, I don't want a parity error reported when in reality the error is a framing error.
As mentioned above, my project uses RS485 (it's for a dragstrip... the cabling in question is therefore over 1320 feet in length!). I've decided to use the DTR or RTS lines to switch the RS485 transceiver between transmit mode and receive mode. (i.e. It will be half-duplex). That means I am going to make certain spurious level changes don't occur on these lines... (For example, the default 'open' code currently asserts DTR and RTS if the baud rate is non-zero). I'm sure I can 'work around' such issues though.
