Johan Hovold wrote on 7/6/20 3:59 PM:
On Mon, Jul 06, 2020 at 01:47:50PM +0200, Jerry wrote:
Johan Hovold wrote on 7/3/20 5:01 PM:
Also, could try and see if your device detects breaks properly? Mine
just return a NUL char.
I've done some experiments with CP2102 receiving a break.
It seems that chip always receives 0x00 for the start of break (with
correct parity when even parity set, wrong for odd parity) and later
(probably after 250 ms) it also sets break flag in GET_COMM_STATUS.
I don't see any indication of the break event in data. I tried to change
some things in your solution but without success.
I also haven't ever seen Frame error (neither way). I tried several ways
(different tx/rx baudrate, receive a parity data without parity enabled,
generating shorter breaks) and I suppose that CP2102 can't indicate framing
error.
Luckily I haven't found any problem with parity checking. :-)
I noticed that I can get comm-status to report a break condition when
event-insertion mode is disabled, but it just results in a NUL char in
event mode (the error flag isn't set then).
Perhaps buggy firmware, unless there's some other command for masking
events. Haven't quite understood how the EVENTMASK requests are supposed
to be used. Replacing the break char (SET_CHAR) didn't help at least.
Neither I understand EVENTMASK in AN571 but I suppose that it is used for
W32 API WaitCommEvent() because of very similar flag list
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-waitcommevent
maybe somebody else can explain possible usage...
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.
Yeah, I noticed that too, although I had a feeling the fake overrun
didn't even always show up when sending while closed here either.
You are right, the fake HW overrun in GET_COMM_STATUS isn't reported always
but very often.
Thanks,
Johan
Jerry
