Johan Hovold wrote on 7/3/20 5:01 PM:
On Fri, Jul 03, 2020 at 09:45:39AM +0200, Johan Hovold wrote:
Would you mind giving the below a try and see how that works in your
setup?
With this patch you'd be able to use PARMRK to be notified of any parity
errors, but I also wired up TIOCGICOUNT if you prefer to use that.
Also, could try and see if your device detects breaks properly? Mine
just return a NUL char.
Johan
I tried your patch. It detects the parity error correctly for my
application. Unfortunately I'm not able currently to verify a break
reception due to holiday, I'll probably try it next week when back at work
(I need to recompile the device firmware).
An interesting thing that your patch don't report any overrun. I'm not able
to create a real overrun (any idea?) but it doesn't report any fake overrun
compared to GET_COMM_STATUS.
The question could be a value of CP210X_ESCCHAR. You selected 0xFF and this
value can be quite common in received data because an erased flash memory
is full of 0xFF. When I read an empty memory it means double USB bandwidth
so for example 0xFE seems be better... but I understand that it depend on
application and it is hard to globally select this value.
I'll do some more tests but your solution seems be fully acceptable for my
needs. For me TIOCGICOUNT is enough (I just resend request when an error
detected) but for other situation it would be very nice to know exactly
which byte was malformed through PARMRK.
Jerry
