FT232RL and PIC24FJ64GA004 serial com speed test

[Wimax]

Hello Everybody !

Has anyone had a chance to test the maximum serial communication speed between a 32 MHz PIC24FJ64GA004 and the PC via FT232RL ?
The datasheet of the micro shows 1 Mbps at 16 MIPS, theoretically well supported by the FT232RL.
Any tests with Positron16 ?

[tumbleweed]

You could get that speed on the UART end, but I doubt you get anywhere near that throughput on the USB side.

1Mbps is roughly 10us/byte so you'd almost be required to use hardware handshaking (RTS/CTS) or DMA on the receive side. Depends on the rest of your code and how you implement it...

[Wimax]

Hello everybody 

I finally have been able to carry out some tests. Both the micro and the FT232 are mounted on a dedicated pcb, the USB data lines travel on balanced differential pairs, the PIC24 operates at 32 MHz with PLL via external quartz.
I implemented a simple XModem protocol to transfer binary files from an SD to the PC.  Transfers always go flawlessly with the UART configured up to the maximum speed of 1 MBAUD, although at some point I think both the processing and reading speed of the SD and the limited buffering (1 KByte) put an upper limit at just over 260 KBAUD. Still, I am quite satisfied with this little monster 

[keytapper]

Baud rate are a huge difficulty in most of computer clock. I wonder why they keep the obsolete standard.
In the case of synchronous transfer, it doesn't matter the clock, as the master is driving the transfer speed.

[tumbleweed]

There's a big difference between a synchronous and an asynchronous scheme.
You typically need more lines, and signal integrity is usually very important since glitches on the clock are a disaster.

Nothing "obsolete" about an async UART link... after all it's in the name.
 

[Wimax]

As mentioned in my previous post, the micro does quite a bit of work, not least calculating a CRC16 for every 1KB packet, and what I got doesn't seem bad at all to me .

Just out of curiosity, with a bit more time on my hands I'd like to stress the transfer by disabling the read from SD by always transmitting the same packet, just to see if the SD is the real bottleneck  .