>> 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 [email protected]
