Rodrigo Rosa wrote:
>> I've been taking the commands (0x6E, etc) from AN108.
Yes, I'm just saying that 0x6E is not as easy for me to understand, as it
doesn't really document whether the length is in bits or bytes. If you
think it's the right command, great. Since your concern is that it returns
all 0xFF's, maybe you could check that by tying the "TDO/DI" (the name of
the pin being sampled by the FTDI, according to docs) permanently low, and
then repeat with it tied permanently high? If it's clocking it on the wrong
edge or something, maybe it misses a brief transition?
>> i was doing the sync, but not correctly. I was only reading once. Now i
>> write 0xAA and read a lot, check through what was read to see if i find
>> what i wanted. if not i write again and repeat. seems to work ok.
Ok, I'd fiddle with this some more until I started reading exactly how many
bytes I want 99% of the time (it probably won't be 100% of the time,
particularly if the latency timer and timeout are configured aggressively,
which seems pretty necessary for reasonable turnaround, at least with the
synchronous API), and then abstract it in a function. Let me know when
you're getting exactly how many bytes you expect most of the time.
Note that bad commands can't be interpreted until the previous one finishes,
so it will hopefully help you identify the correct value of length (and I
don't know what that is for 0x6E).
>> >> returns: input_buff = [0xcc, 0x33, 0x0, 0x0, 0x0 ...]
You said below you're getting all 0xff's. What is the 0xcc and 0x33 then?
>> i put in a loop to make the scope work easier, i was just
>> testing if the code had any effect on the TDI pin.
Fair enough, but it would help to know if it behaves differently on each
consecutive loop. If you were getting out of sync, then you would expect
different answers each time around.
>> ok, my bad, i'm just getting started with this.
>> the code above returns numBytesRead == 3, with all the reading set to
0xFF
>> (the other values of input_buff are not modified during reading).
>> from AN108 describing 0x6E "The TDO/DI pin is sampled for the duration
>> of TMS and a byte containing the data is passed back at the end of TMS
clocking"
>> shouldn't i get at least one reading different from 0xFF?
>> the scope shows that TDI goes 0 1 0
See above about tying the pin one way or the other. That would rule out any
clocking issues, I think.
I have to say that I'm confused by their notation "TDO/DI" versus "TDI/DO",
as far as which is which...possibly a stupid question from me, but is it
possible that the pins are swapped? Probably not, but I need to ask...
>> i'm working at 20kHz, verified that.
Ok, so you're saying that one cycle is 50 microseconds, and that your +width
is 12.5 microseconds (25%)? If so, how many bits are high? Or are you
saying one bit takes 50 microseconds to go out and that one period is 200
microseconds? Alternatively, could you tell me what your code set the
divisor to? I guess what I'm saying is "20kHz" is a vague statement without
further qualification -- it could be your periodic waveform, or it could be
your bitrate.
Regards,
Michael
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
