You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a lot of stuff going on in the packet driver after a byte is received, causing it to miss the next start bit when using over ~200_000 baud
When using two stop bits (tested by changing serial_mingw.c line 101 - this enables 2 stop bits for everything, which is less than ideal...), the maximum stable baudrate increases to about ~450_000.
Empirically, this translates to ~70% faster loads (testing 200_000 baud 1 stop bit vs 450_000 baud 2 stop bits with a ~430K file)
Relatedly: Can the baud rate for File-To-SD become it's own config variable please?
The text was updated successfully, but these errors were encountered:
I don't think there's any major prop-side optimization that can be achieved without cutting functionality (for example, a less expensive packet checksum could be used at the expense of a higher likelyhood of errors - not sure how often the CRC errors out, anyways?) or spinning the packet handling off into a second cog.
As I said, setting 2 stop bits gets a good bit of extra performance out of the current driver.
There's a lot of stuff going on in the packet driver after a byte is received, causing it to miss the next start bit when using over ~200_000 baud
When using two stop bits (tested by changing
serial_mingw.c
line 101 - this enables 2 stop bits for everything, which is less than ideal...), the maximum stable baudrate increases to about ~450_000.Empirically, this translates to ~70% faster loads (testing 200_000 baud 1 stop bit vs 450_000 baud 2 stop bits with a ~430K file)
Relatedly: Can the baud rate for File-To-SD become it's own config variable please?
The text was updated successfully, but these errors were encountered: