So. I've been trying for several days to get parallel data transfer from a Raspberry Pico through a FT232H to a host computer. I'd like ~25MB/s, which is why I'm trying this route in the first place.
I have a Raspberry Pico W, and two FT232H breakout boards ( https://www.amazon.com/dp/B09KGT5TGJ and https://www.adafruit.com/product/2264 , tested in that order ). I plug the Pico and breakout into breadboards, and then wire the two together. (After a full day of that not fully working, I have switched to ~3 inch breadboard wires directly between the breakout boards, which seems to have reduced the noise I was getting at the time, but the bad data remains.) I have a logic analyzer, and an oscilloscope, but the oscilloscope isn't fast enough to really keep up – it just turns into smooth sinewaves at the time scales involved.
I've several times gotten SOME data fast, but I keep running into these periodic segments of bad data. Like so:
I've set the Pico to count up and output the 7 lowest bits. (Plus or minus some structure to help debugging, and slight variations tried over time.)
I tried for hours to get synchronous FIFO to work, but the 60 MHz clock of the FT232H was a little too fast to respond to in time, even with the Pico overclocked to 280 MHz, especially once I figured out the Pico adds a ~3.5 cycle lag on GPIO inputs (by default). And my attempt to structure the output in a way that would work around the failure to synchronize with the clock still left these weird runs of bad data. Last night I switched to trying CPU FIFO mode, wherein basically I pull down two lines for 30 nanoseconds to write data, which I think may be a slower ultimate speed, but maybe still faster than the other options. On the first breakout I got some data, but also still the runs of bad data. On the second breakout it's just giving an I/O error. For the second board, I've tried simplifying down to the baremost possible, just 0s on all data lines, 0 on A0, pull down CS# for 5 ns, pull down RD# for 30 ns, pull up RD# for 5 ns, pull CS# up and wait for a while. Unless the chip secretly REQUIRES you to e.g. read status or check for incoming data or something, I think the datasheet indicates this should be how you write data. Have some pictures of the output of the logic analyzer. In these pictures (slightly mix-and-matched) I've only actually attached WR#, CS#, and D7 (which should and does stay 0).
And 4ns for that second ledge there, too. That seems to me probably close enough to the specs that it ought to work. (I also tried slightly longer times.) BUT I'm still just getting an I/O error. (If I disconnect the control lines I just get "failed to fill whole buffer".)
The oscilloscope says there's still some noise on the lines, that happens when the Pico is running, but I'm not sure what's exactly causing it, nor how to stop it, nor whether it's the cause of the problem, nor whether my oscilloscope is accurately reporting the noise.
I don't know if the problem is noise, or some kind of timing inaccuracy I've failed to account for, or if the FT232H doesn't like e.g. that I'm only writing and never reading (though the host never writes, so, it SHOULDN'T.). I don't know why one of the breakouts read bad data and the other gave an IO error; I thought they were the same chip. Can anybody shed any light on this? My top remaining option is to design and order a PCB with an RP2040 and an FT232H in close proximity with ground planes and all to try really hard to eliminate noise, but that's not really a great option, since that's a number of hours of design work, ordering a thing that may not actually fix the problem, waiting a week for it to arrive, and the traces will be too small to check with an analyzer or oscilloscope at that point so if there are still problems I won't really be able to debug further. 😐 Anybody see any clear mistake?
Best Answer
That data you posted seems to show inserted data, but no lost data, so WR# is held low for longer than it should be. There's also some cases of the same data twice (e.g. -091 and nearby), so you're not updating the data fast enough, and it's being held for two of the clock cycles.
Have you had a look at the PIO state machines? One of those should be fine for sending data. If you want to receive as well, you'd use another SM.
If you could use the same clock source for both the RP2040 and the FT232H, you'd make all timing easier for yourself too. I think they both use 12MHz oscillators, so it should be straight-forward to share the oscillator clock.
I played with the FT2232H >10 years ago connected to an FPGA, and it was straight-forward because I sync'd everything to the 60MHz clock, and checked/updated all signals on the particular clock edge that meant I didn't have to worry about setup/hold times etc. I can't remember which edge it was, but there's only two to try :)