Conversation
|
This looks good to me if the intention around the error type is to have details perfectly suited to specific transports (that is not clear to me from its docs; those only refer to the corresponding std type). If that is not the intention, would more abstract errors work? Overrun fits that pattern, but "FrameFormat" could be a more generic "ConfigurationMismatch" error ("In the communication with the data source/sink, the peer behaved in a way that indicates that the peers are configured differently."), "UnreliableConnection" ("The received data was internally erroneous in a way that indicates that the underlying connection is unreliable, eg. due to failing CRC or parity checks"). "Noise" can fall in either category, but then again, not all UARTs distinguish those in the first place, and it might suffice to lump them in with UnreliableConnection. |
|
My first approach was to have something (or anything) which can be used to model low-level errors related to UART operations and which is more precise that More abstract errors would work as well and your suggestions sound reasonable. |
|
For understanding how to place the Noise error in more abstract categories: What'd be the criterion for something to be noise, and how does it differ from parity checks or configuration mismatch? AIU, if the line goes low for a gltichy short moment, a simple single-sampling UART RX for 8-E-1 would read the wire as 0-11111111-1-1 (dashes just for grouping), and that'd look like a parity error, whereas a double-sampling UART RX would read the start bit twice, seeing it as 01 (or 0111 for quad sampling), and could conclude that the peer is sending at a faster baud rate. |
|
To be honest, I am not even sure where I got the Noise variant from. A lot of UART peripherals can detect frame, overrun and parity errors though. It probably should be documented that parity errors can be mapped to |
2 participants
Related issue: #577