Resolve some issues with the UART applet's auto-baud detection.

[attie]

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.

[attie]

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 0x00 frames (32x edges), it would change the baud rate all the way out to ~11.1% of the current baud rate (e.g: 115,200 -> 12,800).

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? ... and if so, perhaps this should be made clear in the help?

---

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:

{signal: [
  {name: 'Frame',  wave: 'h43333333351', data: [ 'Start', 0, 1, 2, 3, 4, 5, 6, 7, 'Stop']},
  {name: '1/2 (0xE6)',  wave: 'hl.h.l.h....'},
  {name: '1/2 (0xCC)',  wave: 'hl..h.l.h...'},
  {name: '1/2 (0x98)',  wave: 'hl...h.l.h..'},
  {name: '1/2 (0x30)',  wave: 'hl....h.l.h.'},
  {name: '1/3 (0x1C)',  wave: 'hl..h..l..h.'},
  {name: '1/4 (0xF8)',  wave: 'hl...h......'},
  {name: '1/5 (0xF0)',  wave: 'hl....h.....'},
  {name: '1/6 (0xE0)',  wave: 'hl.....h....'},
  {name: '1/7 (0xC0)',  wave: 'hl......h...'},
  {name: '1/8 (0x80)',  wave: 'hl.......h..'},
  {name: '1/9 (0x00)',  wave: 'hl........h.'},
]}

[attie]

I've moved the parity fix into a separate PR - #261.

[whitequark]

Are we content with the auto-baud feature requiring a burst of data to automatically raise the baudrate?

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.

[whitequark]

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?

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...

[attie]

I don't think it's possible to make a different implementation because of the ambiguity inherent in the UART framing.

Agreed, I think that's where I left things too.

We should probably document it though...

I'll see if I can address that.

[whitequark]

I'll see if I can address that.

Thanks much! Are you on IRC at all these days?

[attie]

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...