-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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. While the Windows client is just able to fetch the MKBL directly after two small attempts. 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 could also try using SnoopyPro under native Windows. It would be > worthwhile to compare that log with the usbmon log. Did you see the first Portlog output? Though I am personally lacking a native Windows, I'll ask if someone can give it a shot. > I'm not familiar with the FTDI protocol, but this seems like an awful > lot of activity. Do the output parts contain your magic string? The above was basically; send magic string a few times, reply with 0xAA, see if MKBL is present, if not, redo it until you find it. After that send 't', this will results two bytes 0xe0, 0x00. The protocol states that I now have to send 'T' with the first byte as board identifier (so: 0x54, 0xe0) then the board replies 0x0d = everything ok. >> eeff5680 0.874709 S Bo:3:004:2 - 1 = 54 >> eeff5500 0.874833 S Bo:3:004:2 - 1 = e0 >> eeff5680 0.875224 C Bo:3:004:2 0 1 > >> eeff5500 0.875230 C Bo:3:004:2 0 1 > > > Those two bytes appear to be the write you mentioned above, except that > the second byte is 0xe0 instead of 0x0e. Is this a typo in your > program or in the text above? Typo in my text, sorry I saw that later. What I send should reflect what comes back from the board. >> *** ef16e980 0.890224 C Bi:3:004:1 0 3 = 31600d *** >> >> ef16e980 0.890233 S Bi:3:004:1 - 512 < >> eeff5500 0.890706 S Co:3:004:0 s 40 02 0000 0000 0000 0 >> >> - ---> it seems the following is the actual read(fd, output, 1) > > Not directly, no. This is a record of all the USB traffic passing > between your computer and the device. Some of that data may be > returned to your program in response to the read() call, but read() > does not in itself cause anything to be sent or received. > - ----- >> eeff5500 0.892225 C Co:3:004:0 0 0 >> eeff5500 0.892337 S Co:3:004:0 s 40 01 0300 0000 0000 0 >> eeff5500 0.895224 C Co:3:004:0 0 0 >> ef16e980 0.895230 C Bi:3:004:1 0 2 = 0160 >> ef16e980 0.895235 S Bi:3:004:1 - 512 < >> ef16e980 0.896236 C Bi:3:004:1 -2 0 My point is; if i do *not* do the read I will *not* get the above; the 0x0d is send before a read ever took place. And will always be send so matter a read was done or not. >> Could anyone maybe elaborate how I get 0x0A as output? > > Or are you asking what part of this usbmon log corresponds to a 0x0a > character your program received? Again, I don't know -- it doesn't > look like there are any 0x0a characters in the log. Perhaps the line > discipline introduced 0x0a when it received 0x0d. 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. > It might help if you could provide a description of all the bytes sent > by your program and all the bytes it received. 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) Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkpjzC4ACgkQYH1+F2Rqwn0uNQCeKpbEsyQU1o0Sm6XeDPiqnpsh szwAn1c/UGGlTb6TWkYnUArzB1htXf49 =We+9 -----END PGP SIGNATURE----- -- 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
