>> big-bang-mode works. It does not work perfectly (notably sending one
>> byte to it does not set the outputs, but sending 256 bytes does, which
>> J.C. Wren already mentioned a month ago.
>>
>> MPSSE is what I am interested in.
Well, J.C. Wren's thing was with an FT245RL on kernel 2.4. FT245RL does not
support MPSSE, although it does support some other bit-bang modes. We
should be clear when we talk about bit-bang, as it appears there are several
ways to do it, MPSSE being only one. I have had no trouble with the MPSSE
bit-bang on kernel 2.6 on an FT2232D. That's 3 total differences between
what you and I are discussing, and what J.C. Wren did.
Now some folks were discussing "first write" errors. I have put a
higher-level layer down, as I mentioned, to retry on failure, so one-off
errors don't really raise a red flag for me, and perhaps I'm missing it.
I.e., if it's only happening once, and retrying succeeds, I would see a
brief message on the console, but it would just continue. I did not observe
any such messages with the default 16ms latency timer, so I don't *think*
I'm seeing that issue, but I can't be positive. I have
usb_read_timeout=usb_write_timeout=200ms, but I didn't spend much time
optimizing those.
>> Ah, did not know FTDI has source code available. I only found
>> libftd2xx0.4.16.tar.gz for Linux which contains some *.o files,
>> but no source code.
Right, it's newly released (w/in last 6 months), and is Windows code,
however you can still learn from it (check the license first), because it's
an abstraction layer on top of D2XX. D2XX performs a similar role to
libftdi, so such a layer as FTCSPI.DLL would sit between libftdi and your
code. You should, of course, think of it as an example layer, not as the
actual code, since it is d2xx-specific.
>> Related question: if you already worked on the SPI code without FTDI's
>> FFTCSPI.DLL, where did you get the information how to program the
>> MPSSE from?
Well, I had already gotten UART stuff working (not VCP, but what FTDI calls
"d2xx direct") on a previous board, so I modified the code using AN108 to do
SPI with a few bit-bang bits. UART is much simpler, and allowed me to work
some kinks out of my code.
>> AN108 is not exactly easy to understand. I read it and I wonders if
that's
>> enough or if there is more available.
It is enough for SPI & (MPSSE) bit-bang, and presumably enough for JTAG.
I2C is kinda tough (with the ack bit reversing direction mid-byte,
particularly), and so I haven't tried it. In order to use AN108 effectively
for SPI, you need a timing diagram for the chip you're talking to so you
know clock polarity and how clock idles. The FTDI chip is the SPI master.
One thing that I couldn't find in the docs, but figured by trial and error,
is which bit of the bit-bang mode corresponds to which pin. If you need
info on that, I can post it.
>> Maybe I should mention that I am running on non-i386 hardware, thus any
>> binary-only drivers from FTDI for Linux are unusable for me.
Understood, and I was not suggesting you use those. I believe FTDI
distributes *.o to comply with the LGPL.
I need to leave, but maybe in a few hours (when I get back) I'll post a
piece of code to do a simple SPI write.
Michael
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
