Lpuart Baud Compute Bug

[tprice02]

From my understanding of the common::lpaurt::Baud::compute function, it is meant to test every oversampling rate from 8 to 32, and every modulo divisor from 1 to 8191.

The current code does not reset the modulo divisor value after comparing to an oversampling rate, leading to only one oversampling rate being tested. I've added a test that fails on the current code, but passes in the fixed code, highlighting the issue.

On a separate note, the oversampling rate is tested from 8 to 32, yet the minimum possible value is 4. I suspect that the author of the code found that sampling on both edges of the clock was unstable, or unfavorable for some reason, as this applies at oversampling rates <8. However, starting at the value of 8 limits possible baud rates to a maximum of 3MBd, while I've found higher values to be stable in communication between two Teensy 4.0s (albeit not tested with an oscilloscope). I've thus added a rudimentary fix, where the oversampling rate checking starts at a value of 4 instead of 8 when the baud rate is higher than 3MBd, however it seems simpler to always have it start at 4, so consider this and please state any concerns prior to merging.

[mciantyre]

Sorry for the delay; I lost track of this PR. Thanks for fixing the SBR update.

[...] it seems simpler to always have it start at 4, so consider this and please state any concerns prior to merging.

I agree, but I won't have time to retest on my setups. If anyone else can show that this change works using any of the in-tree examples, I'm happy to merge it.

[mciantyre]

Released in 0.5.8