On Sun, Jan 10, 2021 at 04:15:41PM -0600, Joe Abbott wrote: > > Look for the set-line-request control request: > > > > bmRequestType 0x21 > > bRequest 0x20 (SET_LINE_REQUEST) > > wValue 0 > > wIndex 0 > > wLength 7 > > > > the data stage should contain the corresponding 7 bytes of request data > > for 110/cs7/parenb: > > > > d5 0e 00 80 00 02 07 > > Windows wireshark URB_CONTROL_OUT packets > using putty set to at 110 baud 7E1 > > The windows usb captures have these 7 bytes for 110 baud: > a8 a6 01 80 00 02 07 Interesting... > and these 7 bytes for 9600 baud: > 80 25 00 00 00 02 07 0x2580 = 9600 > > -------------------------------------------------------------------- > Linux wireshark URB_CONTROL_OUT packet > using stty 110 evenp > > usb capture for 110 baud 7E1 > d5 0e 00 80 00 02 07 > > I tried hard coding the first four 110 baud bytes into buf[0] - buf[3] > in the divisor subroutine and > 110 baud work fine. Possible problem in the divisor routine? Or rather a new feature which do not yet support (or understand). I tried hardcoding the same request with a HXD and it doesn't give me 110 baud. Instead the unsupported bits appears to be ignored and the current divisor algorithm is applied so that a8 a6 01 80 00 02 07 gives the same result as if a8 06 00 80 00 02 07 had been requested (~35720 baud). So in any case, we'd need to key this off of the device type. I noticed that 12000000 / 0x1a6a8 ~= 110.9 Possibly just a coincidence, especially as 0x1aa22 would be closer match. But perhaps you can try a few more rates not in baud_sup and see if you can figure it out. Johan
