Resolve some issues with the UART applet's auto-baud detection. #260
Conversation
When receiving a single frame that is at a faster baudrate than is currently configured, it is possible that you won't see a frame or parity error, especially if no parity is selected. This is because the line idles high, which looks identical to a stop bit. Even if you have parity enabled, there is a non-zero chance you'll see the high line state, and consider it to be a "valid" parity bit, when in fact it is the idle state. When receiving a stream of frames in quick succession, there is a higher probability that you will look for a stop bit in the next frame, and will thus see a frame error (or parity error).
… window Because we are now updating the bit time whenever it changes, it is possible to get a lot of "switched to __ baud" messages, even if the change is minor and well within tolerance. This patch will only report baudrate changes when they exceed a +/- 5% window vs the previously reported baudrate.
There was a problem hiding this comment.
When I went to bed from your stream yesterday, my brain didn't, but came up with this issue instead:
You now always change the baudrate when you determine a new bit-length, not only when you saw a frame or parity error.
So consider the auto-baud being was locked to the right baudrate. No change in the baudrate at the sender side. But now the sender sends many bytes that don't have a single bit set, for example a 0xCC, so you can't measure single bit pulses on the line.
The hardware will now erroneously change to a slower baudrate, even if the one we detected is correct.
So maybe require a frame or parity error when changing to a slower baudrate, and only change to a faster baudrate without frame or parity error?
Another idea would be to run a second uart decoder with a baudrate under consideration for some time when a new bittime is detected. Only actually change the baudrate when the baudrate under consideration checked out without frame or pairty errors for some time. But that complicates the design of course.
|
Yes, good point... I was a little uneasy about this and came to the same conclusion... Consider the following frames (8N1): When receiving a series of 16x Most of these are non-print characters (0x30, 0x1C, 0x00 being the exception), but I'm not sure how relevant this is. Are we content with the auto-baud feature requiring a burst of data to automatically raise the baudrate? If parity is enabled, then it's possible that the prevelance of this issue is reduced, as the data and parity bit would need to work together, but I've nof drawn out any frames to think about it harder yet... Wavedrom source: |
|
I've moved the parity fix into a separate PR - #261. |
That's how autobaud generally works. I don't think it's possible to make a different implementation because of the ambiguity inherent in the UART framing. |
This works reasonably well but it's very non-tolerant of glitches. I think the status quo is a reasonable tradeoff. We should probably document it though... |
Agreed, I think that's where I left things too.
I'll see if I can address that. |
Thanks much! Are you on IRC at all these days? |
I'll see messages in #glasgow / #amaranth via the 1b2 bridge, but I've never really got on with IRC unfortunately... |
When receiving a single frame that is at a faster baudrate than is currently configured, it is possible that you won't see a frame or
parity error, especially if no parity is selected. This is because the line idles high, which looks identical to a stop bit.
Even if you have parity enabled, there is a non-zero chance you'll see the high line state, and consider it to be a "valid" parity bit, when in fact it is the idle state.
When receiving a stream of frames in quick succession, there is a higher probability that you will look for a stop bit in the next frame, and will thus see a frame error (or parity error).
This PR also addresses the resulting extra / unwanted announcements to minor adjustments of the baudrate, as well as a mistake in the nMigen update of the UART gateware.