On Sun, 19 Jul 2009, Stefan de Konink wrote: > Hi all, > > > Abstract problem; I'm trying to communicate to an external device using > an FTDI usb serial interface. The 'common' communication with this > device is using Windows. Obviously I am not running Windows and trying > to develop some alternative tools for it. > > > Basic outline. > > The device should respond 0x0d after the sequence 0x54, 0xE0; in any > proper configured Windows C#, Delphi whatever program it just works that > way. > > Thanks to our friends from Seattle we can show this: > > 3020 0.00000000 MikroKopter-Too IRP_MJ_WRITE VCP0 Length 1: 54 > 3020 0.00029976 SUCCESS > 3021 0.00000000 MikroKopter-Too IRP_MJ_WRITE VCP0 Length 1: E0 > 3021 0.00006733 SUCCESS > 3022 0.00000000 MikroKopter-Too IOCTL_SERIAL_PURGE VCP0 Purge: RXCLEAR > 3022 0.00000391 SUCCESS > 3015 0.27185690 SUCCESS > 3023 0.00000000 MikroKopter-Too IOCTL_SERIAL_WAIT_ON_MASK VCP0 > 3024 0.00000000 MikroKopter-Too IOCTL_SERIAL_GET_COMMSTATUS VCP0 > 3024 0.00000251 SUCCESS > 3025 0.00000000 MikroKopter-Too IRP_MJ_READ VCP0 Length 1 > 3025 0.00000419 SUCCESS Length 1: 0D > > > It is not that difficult to write a program using Linux doing exactly > the same; using interceptty the following output is gathered. > > < 0x54 (T) > < 0xe0 > < 0x56 (V) > > 0x30 (0) > > 0x33 (3) > > > It is not that the read call is too short or maybe even to slow; there > is just no data for any 'command' that is build from two or more bytes. > As you can see, a single byte command 'V' is actually picked up and > returns data. > > > Reading into the WINE sources I have actually added the RXCLEAR, as > tcflush(fd, TCIFLUSH); but still no luck. I have also experimented with > FNDELAY to do everything manually so far no luck. > > > It is clear that this device is picky; it is unclear to me why it > preferences Microsoft as its only master. Though this problem seems not > to be unique; in 2006 someone wrote that sending an exact sequence in > Linux results in a different output on Windows after interacting with a > device. http://wiki.clug.org.za/wiki/Novatel_Status_Port > > > > My main problem is that I need an (open source) Flash utility for this > external device, that we have now written in C# on Windows after my > hopeless attempts to get this to work under Linux in C. In that respect, > pragmatically I have what I need. But since this issue shows that there > might be more issues: > > What can we do to debug this on a more fundamental level? Is there > anything that can be measured or investigated to make Linux more like > Windows? Serial wise that is ;) Your real problem is that you are trying to deal with four or five different layers of software and hardware all at once. That isn't going to work. You need to separate out the effects of: The device itself; The kernel's USB serial drivers; The kernel's TTY layer; WINE; C#; and maybe more. Work on these one at a time; then there will be some hope of making progress. Since this is a USB-oriented mailing list, the people reading your email are best able to help you with the USB serial driver part of the problem. My advice is that you use usbmon to find out what's going on at the USB level. It's roughly equivalent to using SnoopyPro on Windows. See the kernel source file Documentation/usb/usbmon.txt for instructions. 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
