On Sun, 19 Jul 2009, Stefan de Konink wrote:
> I'm not using Wine or C#. I have just looked up the commands that come
> out of Portmon for Windows and referenced that to the Wine implementation.
>
> We are talking about a trivial write(fd, {0x54 0x0e}, 2) here. This is
> not rocketscience. If this works out of the box on Windows there might
> be something timing related that prevents Linux from operating.
Do you have any reason to think this is timing-related?
> Since
> this is also observed with other devices the questions related the
> usb-serial layer are valid.
>
> I'll try to execute the C# program using a Virtual Machine and see if
> this works or not.
You could also try using SnoopyPro under native Windows. It would be
worthwhile to compare that log with the usbmon log.
> The output of USB mon regarding to the entire program is the following:
> (Basic working; try to send a reset magic string, if not try again, wait
> till MKBL is in the buffer)
>
> eeff5680 0.637279 S Co:3:004:0 s 40 00 0000 0000 0000 0
> eeff5680 0.639243 C Co:3:004:0 0 0
> eeff5680 0.639464 S Co:3:004:0 s 40 04 0008 0000 0000 0
> eeff5680 0.642230 C Co:3:004:0 0 0
> eeff5680 0.642351 S Co:3:004:0 s 40 03 0034 0000 0000 0
> eeff5680 0.645231 C Co:3:004:0 0 0
> eeff5680 0.645372 S Co:3:004:0 s 40 02 0000 0000 0000 0
> eeff5680 0.648231 C Co:3:004:0 0 0
> eeff5680 0.648330 S Co:3:004:0 s 40 01 0303 0000 0000 0
> eeff5680 0.651229 C Co:3:004:0 0 0
> ef16e980 0.651323 S Bi:3:004:1 - 512 <
> eeff5680 0.651495 S Co:3:004:0 s 40 04 0008 0000 0000 0
> ef16e980 0.654230 C Bi:3:004:1 0 2 = 3160
> ef16e980 0.654241 S Bi:3:004:1 - 512 <
> eeff5680 0.654246 C Co:3:004:0 0 0
> eeff5680 0.654391 S Co:3:004:0 s 40 03 0034 0000 0000 0
> eeff5680 0.657229 C Co:3:004:0 0 0
> eeff5680 0.657339 S Co:3:004:0 s 40 02 0000 0000 0000 0
> eeff5680 0.660228 C Co:3:004:0 0 0
Presumably this part corresponds to your various mode-set commands.
> eeff5680 0.660375 S Bo:3:004:2 - 7 = 23615240 530d1b
> eeff5680 0.661228 C Bo:3:004:2 0 7 >
> ef16e980 0.666230 C Bi:3:004:1 0 12 = 31603f59 3f3f3f3f 4d4b424c
> ef16e980 0.666241 S Bi:3:004:1 - 512 <
> eeff5680 0.680559 S Bo:3:004:2 - 1 = aa
> eeff5680 0.681227 C Bo:3:004:2 0 1 >
> ef16e980 0.682229 C Bi:3:004:1 0 5 = 31604d4b 42
> ef16e980 0.682234 S Bi:3:004:1 - 512 <
> ef16e980 0.698231 C Bi:3:004:1 0 3 = 31604c
> ef16e980 0.698236 S Bi:3:004:1 - 512 <
> ef16e980 0.714229 C Bi:3:004:1 0 2 = 3160
> ef16e980 0.714233 S Bi:3:004:1 - 512 <
> ef16e980 0.730229 C Bi:3:004:1 0 2 = 3160
> ef16e980 0.730232 S Bi:3:004:1 - 512 <
> ef16e980 0.746229 C Bi:3:004:1 0 2 = 3160
> ef16e980 0.746233 S Bi:3:004:1 - 512 <
> eeff5680 0.760716 S Bo:3:004:2 - 7 = 23615240 530d1b
> eeff5680 0.761226 C Bo:3:004:2 0 7 >
> ef16e980 0.762227 C Bi:3:004:1 0 3 = 31003f
> ef16e980 0.762234 S Bi:3:004:1 - 512 <
> ef16e980 0.778229 C Bi:3:004:1 0 11 = 3160593f 3f3f3f4d 4b424c
> ef16e980 0.778236 S Bi:3:004:1 - 512 <
> eeff5680 0.780888 S Bo:3:004:2 - 1 = aa
> eeff5680 0.781224 C Bo:3:004:2 0 1 >
> ef16e980 0.794226 C Bi:3:004:1 0 6 = 31604d4b 424c
> ef16e980 0.794231 S Bi:3:004:1 - 512 <
> ef16e980 0.810228 C Bi:3:004:1 0 2 = 3160
> ef16e980 0.810231 S Bi:3:004:1 - 512 <
> ef16e980 0.826226 C Bi:3:004:1 0 2 = 3160
> ef16e980 0.826229 S Bi:3:004:1 - 512 <
> ef16e980 0.842225 C Bi:3:004:1 0 2 = 3160
> ef16e980 0.842229 S Bi:3:004:1 - 512 <
> ef16e980 0.858227 C Bi:3:004:1 0 2 = 3160
> ef16e980 0.858230 S Bi:3:004:1 - 512 <
> eeff5680 0.861326 S Bo:3:004:2 - 1 = 74
> eeff5680 0.862225 C Bo:3:004:2 0 1 >
> ef16e980 0.874227 C Bi:3:004:1 0 4 = 3160e000
> ef16e980 0.874235 S Bi:3:004:1 - 512 <
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?
> 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?
> *** 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
>
> Could anyone maybe elaborate how I get 0x0A as output?
I don't understand the meaning of this question. Are you asking what
data you need to send to the device in order to make it send back 0x0a?
I have no idea -- it's _your_ device and I don't know how it's supposed
to work.
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.
It might help if you could provide a description of all the bytes sent
by your program and all the bytes it received.
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
