[crshults]

Important to remember for each data byte in the buffer to also store the LSR along with that data. Windows serial port driver fails to do this, meaning you can tell there was (for example) a parity error on a byte in your fifo, you just don't know on which byte.

[shabble]

How would you implement that though, assuming memory is tight? The simplest would be to just store a multibyte entry for each item in the ring buffer: the actual data, and the status flags set at the time it was copied. But that doubles your memory requirements, and you'll (probably) not need that status info all the time.

I suppose you could define 'normal' and keep a smaller structure which holds only abnormal values, but then you need a way to map which input byte each value refers to, and make sure it's invalidated when the ring buffer rolls around.

Or you could put some of the error-handling logic into your buffering code (but it'd be in an interrupt handler, which you probably don't want), and you might need your higher level framing or packetisation to know how far back you need to invalidate.

I'm not sure there is a single optimal solution (although if you know of one, I'd love to know). Windows getting it wrong is interesting/odd though, unless it just dates to a time when tehy were cpu/memory restricted, adn it's just stuck about for compatibility.

[cnvogel]

I assume that your serial port will run some kind of machine-to-machine protocol, and not just a serial console with user data (for which, frankly, I'll just ignore most errors). These serial prototols (like modbus, or the 10000s of ad-hoc specified "proprietary" protocols many devices speak) are usually very simple.....

And if memory is tight, you'll probably also want to move some part of your protocol handling down the stack, probably up to the interrupt handler, because otherwise you'll needlessly have double buffers (characters, and decoded protocol datagrams). For most stuff running on serial ports the code will be simple enough not to create too many headaches. Then just store the fact that you've encountered a parity error next to your datagram. (msg->flags |= MSGFLASG_PARITYERR );

And yes, I know that this is a "blatant layering violation" for a proper operating system, but on a microcontroller really no one cares that you have two variations of an interrupt handler, specific to your protocol handling.

EDIT/ADDED: It's not only parity errors, but there are also things like RS485 links with 9-bit addresses, BREAK characters with semantic meaning and sometimes your communication protocol might specify when you switch directions of half-duplex links, with hard timing requirements.

[vardump]

You might implement it with a separate bitmap. One bit for each char in buffer. If a parity error occurs, set the corresponding bit on in the bitmap.

[paulannesley]

Line Status Register http://en.wikibooks.org/wiki/Serial_Programming/8250_UART_Pr... Had to look it up, my brain was coming up with Logical Shift Right.