On Mon, 20 Jul 2009, Stefan de Konink wrote: > Alan Stern wrote: > > Do you have any reason to think this is timing-related? > > I was unable to get into the boot sequence without going into FNDELAY. Why not? Can you provide a usbmon log showing what happens when you don't use FNDELAY? > While the Windows client is just able to fetch the MKBL directly after > two small attempts. Your previous usbmon log shows the Linux program had no problem getting the device to send MKBL either. ... > But when I see the USB output now I have doubts, because it is clear > that the USB receives the byte, thought it never arrives at the tty. You're talking about the 0x0d byte? > You can clearly see that the part marked with *** returns 0x0d; it never > arrives at the tty. What does arrive at the tty is 0x0a. Now I really do > not care about this 0x0a, what I do care about is why this 0x0d is never > buffered (?). I don't know if that is the good word for it. I don't know what's going on with the tty. Presumably you mean that when your program tries to read this byte it obtains 0x0a instead of 0x0d. This sounds like the kind of transformation done by a tty's line discipline (changing RETURN to NEWLINE). > Oki here we go: > - - options are set > - - FNDELAY > - - read everything what is in the buffer > - - write reset string: 0x23,0x61,0x52,0x40,0x53,0x0D,27 > - - wait 20ms > - - write 0xaa > - - read output > - - wait 80ms > - - compare if MKBL was found > > If we found it: > - - read everything what is in the buffer > - - F_SETFL > - - 't' > > 0xe0 0x00 > - - 'T', 0xe0 > > 0x0a (should be: 0x0d) Okay, this all agrees pretty much with the usbmon log except for the last byte. And that would not have been changed by the USB serial drivers; any changes would occur later -- in the TTY layer, for example. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
