The issue is I can't get the data out of hub quick enough to feed the FT2232H.
Just crunching the numbers a bit to see how this all fits together.
It turns out getting the data out of the hub is not the issue.
The overhead comes from sending the byte to the smartpin itself.
The following code takes 195mS to Tx 120_000 bytes
rep @.loop,##120_000
rfbyte adra '2 clocks : total = 3ms
pinsety adra,#dummy '18 clocks : total = 27ms
waitedg '108 clocks : total = 162mS
pinack #dummy '2 clocks : total = 3mS
.loop
Rich
Just connect VBUS to VCC, 3V3 o VIO and hey presto, speedy dual comms!
BTW. I'm blasting 240000 bytes @8M baud into PC in 195mS! using both channels.
Hete's some pinout diagrams I made to clear things up a bit.
Cheers
Brian
The overhead comes from sending the byte to the smartpin itself.
The following code takes 195mS to Tx 120_000 bytes
rep @.loop,##120_000
rfbyte adra '2 clocks : total = 3ms
pinsety adra,#dummy '18 clocks : total = 27ms
waitedg '108 clocks : total = 162mS
pinack #dummy '2 clocks : total = 3mS
.loop
Another poster was asking about 100Mbd, which seems a little OTT, but 50MBd should be a valid target.
I'd guess that 8MBd handshakes at 8b, are going to time very similar to 32Mbd handshakes at 32b which indicates even 32b is going to be SW constrained.
Some better buffering/timing is needed here.
I wonder if that waitedg signal can be earlier, given there is a finite time before the COG-PIN can send new data.
ie if it was a OK_to_send, rather than Tx-Done, the loop could be tighter,
Of course, Tx-Done is also useful in RS485 direction change applications...
In this use, it should be at end of Tx stop bit.
I wonder how much buffering is actually there.
eg If you use a preload before the loop, what happens ?
The overhead comes from sending the byte to the smartpin itself.
The following code takes 195mS to Tx 120_000 bytes
rep @.loop,##120_000
rfbyte adra '2 clocks : total = 3ms
pinsety adra,#dummy '18 clocks : total = 27ms
waitedg '108 clocks : total = 162mS
pinack #dummy '2 clocks : total = 3mS
.loop
Another poster was asking about 100Mbd, which seems a little OTT, but 50MBd should be a valid target.
I'd guess that 8MBd handshakes at 8b, are going to time very similar to 32Mbd handshakes at 32b which indicates even 32b is going to be SW constrained.
Some better buffering/timing is needed here.
I wonder if that waitedg signal can be earlier, given there is a finite time before the COG-PIN can send new data.
ie if it was a OK_to_send, rather than Tx-Done, the loop could be tighter,
Of course, Tx-Done is also useful in RS485 direction change applications...
In this use, it should be at end of Tx stop bit.
I wonder how much buffering is actually there.
eg If you use a preload before the loop, what happens ?
FYI Just for a point of reference I switched from smartpin tx to a bit bang tx @ 8M baud.
120_000 byte chunk tx time went from 195mS to 156mS.
A tx_ok_to_send would work well with a 2 level tx buffer.
Still it's nice to be able to blast data out at these speeds.
Is there any way to get these faster USB-to-serial chips to send 32-bit words, instead of 8-bit words?
I ask because I'm going over the serial mode in the smart pin and it looks like a big pain to make it deal with four bytes per long SETPINY/GETPINZ. It's hard because I've got the synchronous serial melded into the whole thing and the integration almost broke my brain the first time around.
FYI Just for a point of reference I switched from smartpin tx to a bit bang tx @ 8M baud.
120_000 byte chunk tx time went from 195mS to 156mS.
A tx_ok_to_send would work well with a 2 level tx buffer.
Still it's nice to be able to blast data out at these speeds.
That's gone from 3 added Stop bits, to 0.4 added stop bits.
Bit-bang (Tx only) is just ok at 8MBd, but 50MHz Tx and Rx, no gaps, should be possible with the hardware tuned right.
Is there any way to get these faster USB-to-serial chips to send 32-bit words, instead of 8-bit words?
FT2232H (and FT232H) only sends 8 bits @ 60MHz in the fast 245 mode. Maybe you can use a CPLD to join four 8-bit words into one 32-bit word @ 15 MHz. This is something I wanted to test on P1 (can the P1 send COG RAM data to pins at that speed? and is there room left for any other processing?).
Another option is to use the USB 3.0 devices FT600/FT601. I remember they have a 16-bit or 32-data bus width at 100 MHz and 66 MHz (but the programming manual was not clear about this 'slower' 66 MHz frequency).
Is there any way to get these faster USB-to-serial chips to send 32-bit words, instead of 8-bit wordsmith .
Not serially.
There is a Fast Serial mode on HS USB FT parts good to 50 MHz, ASYNC data framed, with clk.
For that, can P2 support sysclk/2 async ?
FIFO modes use handshakes, that could work with the streamer? (8 16 32 b)
Fast Serial Mode uses a simple 1 wire handshake on P2 -> FT232H only, and data flow is half duplex, on TXD & RXD pins. It expects P2 to be able to swallow bytes as they come.
Seems the handshake in FT -> P2 direction is by Pause of the FCLK, driven from P2.
(stalls bytes, and delays START bit )
Data does not show packed bytes case, or indicate how many clocks are needed for FT -> P2, but the waveforms suggest 13~14 for each P2 -> FT byte
Tubular brought to my attention a glitch in the XGA timing that produced a jaggered image.
I tweaked the numbers a bit and found the following change seems to clear things up a bit.
m_bs long $CF000000+24 'before sync
m_sn long $CF000000+136 'sync
change to
m_bs long $CF000000+32 'before sync
m_sn long $CF000000+123 'sync
Thanks for your help. I finally quit fiddling with the PropCam long enough to set up the mini-ft2232h. Your photo and diagrams were extremely helpful.
First, I set up a loop to bounce a received character back out to tx. This works fine with the regular Propeller 1-2-3 USB, pins 62 and 63, at 3Mbaud using the Parallax Serial Terminal.
I then changed my pin assignments to the mini-board pins and changed the setb to dira (rather than dirb as for the normal USB).
The Windows Control panel sees the mini-ft and tells me it is working normally on COM7 and COM8.
I have connected rxb and txb on the mini to my rx/tx pins on the P2v, etc. (And I have tried reversing the order, just in case this was wrong:)
I am getting nothing... not a single return. I'm set up for smartpin async... which works fine with through the 1-2-3's usb.
I'm at a loss.
In the picture I noticed that you have the mini-ft reset-pin (#8 on CN2) hooked up to the P2V, but I don't see in your code how you are handling it... ?
Rich
My Ft2232H is currently not connected to my A9 but here's the connections anyway.
CN3 Pin 1 VBUS to CN3 Pin 3 VCC
CN2 Pin 1 V3V3 to CN2 Pin 11 VIO
Be careful of the old trap of TXD/RXD directions may be the opposite to what you think.
I will fire it up again tonight and confirm the operation
Rich
Checked above connections Ok.
Only thing I left out was you also need the following jumper for Channel B to work.
CN2 Pin 3 V3V3 to CN3 Pin 12 VIO
I had a connection: CN2 pin 1 to cn3 pin 12 VIO. I have fixed that.
My normal USB still works. With the new pinouts, I get a correct character returned followed by a several "y" with two dots over it in a stream:) When I disconnected the reset on cn2, I get a constant stream of the same strange "y". I tried tying the reset high and low through 1K resistors, no help
I moved from b_tx and b_rx on CN3 over to a_tx and a_tx on cn2... see below
At 115200 kbaud
When I change my program to send a particular character "o" after it receives anything from the serial terminal, it does so every time through the loop... so I get the character I expect... but as a constant stream of that particular character. It isn't waiting to receive a character... it acts as though it is receiving a character, when it shouldn't be.
So, the problem seems to be that the mini-ft correctly sends what it gets from the P2v... but is sending a constant stream of characters to the P2, even when the serial terminal is doing nothing. OR TX works and RX doesn't with this board configuration.
I tried taking the acknowledge out of the send_rx routine... no good. The thing is... the code works just fine with the onboard USB. Makes no sense to me:)
And for those reading this... P2v serial works just fine. We are having a little configuration issue... that is one step above my pay grade:)
Rich
I was able to replicate the fault you are seeing.
The character "y" that you are seeing is ascii code $FF.
The bug seems to be when the FT2232H uart is idle the smart pin keeps receiving "FF''s."
The issue appears to have been solved by the new FPGA image Version 8.
Just an update on my mini-ft ... following the v8 update.
I now have it working, but when I hook it up to my PC Program the sent characters from the PC have noise in them...
For example, sending a picture from PC to P2 gives me a slightly corrupted image... all the pixels arrive, but there are minor pixel sized errors spread throughout. Using the 1-2-3's normal USB, with same software = no problem.
3MBaud
I still have to stall the tx routine by 4000 clocks to get things to work right with my software. I ripped the pc software apart to see if some of the libraries(such as Kinect) were causing the problem... I couldn't find anything.
Just an update on my mini-ft ... following the v8 update.
I now have it working, but when I hook it up to my PC Program the sent characters from the PC have noise in them...
For example, sending a picture from PC to P2 gives me a slightly corrupted image... all the pixels arrive, but there are minor pixel sized errors spread throughout. Using the 1-2-3's normal USB, with same software = no problem.
3MBaud
I still have to stall the tx routine by 4000 clocks to get things to work right with my software. I ripped the pc software apart to see if some of the libraries(such as Kinect) were causing the problem... I couldn't find anything.
The one thing that changed in the serial smart pin was that, after a start bit edge, we verify that the start bit is still there at the halfway point. If it is no longer there, we go back to waiting for a low, otherwise, we proceed to read in the timed data bits. Maybe that's causing some trouble?
Just an update on my mini-ft ... following the v8 update.
I now have it working, but when I hook it up to my PC Program the sent characters from the PC have noise in them...
For example, sending a picture from PC to P2 gives me a slightly corrupted image... all the pixels arrive, but there are minor pixel sized errors spread throughout. Using the 1-2-3's normal USB, with same software = no problem.
What chips are involved in each of these pathways ?
I still have to stall the tx routine by 4000 clocks to get things to work right with my software. I ripped the pc software apart to see if some of the libraries(such as Kinect) were causing the problem... I couldn't find anything.
Which device is this ? FT2232H / FT223H should have no issues at 3MBd, other parts are a little more variable....
Had to step out. Sorry about the delay. I have no idea. I would like Brian to try it out and see what he gets.
I was sending 76800 byte chunks and it was pretty obvious... looked like bits were low when they should have been high.
So, send a nice bright image.
Remember... no problem if I use the 1-2-3's USB... except for having to stall the TX. I think this is on the compute side, since Brian has successfully gone beyond 3MBaud.
Earlier, I grounded my reset pin on the mini-module and also tied it to 3.3v... just to see what would happen:)
I have no respect for hardware. Only problem is I usually order two so I can destroy one. In this case, I only have one.
So, I might have an injured module... not dead, but maybe not healthy.
Comments
Just crunching the numbers a bit to see how this all fits together.
It turns out getting the data out of the hub is not the issue.
The overhead comes from sending the byte to the smartpin itself.
The following code takes 195mS to Tx 120_000 bytes
This would shave ~22mS of the total time.
(120000*13)/8M = 0.195
I guess the same effect will occur in SPI modes, and those can be expected to go much faster than 8Mbd.
Looks rather like improved buffering is needed ?
That may remove the extra stop bits on only some of the bytes ?
It also makes handshake harder to manage ?
Thanks for the info. When I look for FT2232 modules, all I find are breakout boards with about 40 pins hanging off of them.
What are you using... what is the hook-up?
Thanks again,
Rich
Rich, yes that's the module i'm using. (FT2232H mini module)
I'm going to get one... have no idea why it has so many pins or what I should do with it:)
Ask and ye shall receive.
Thanks
Just connect VBUS to VCC, 3V3 o VIO and hey presto, speedy dual comms!
BTW. I'm blasting 240000 bytes @8M baud into PC in 195mS! using both channels.
Hete's some pinout diagrams I made to clear things up a bit.
Cheers
Brian
I'd guess that 8MBd handshakes at 8b, are going to time very similar to 32Mbd handshakes at 32b which indicates even 32b is going to be SW constrained.
Some better buffering/timing is needed here.
I wonder if that waitedg signal can be earlier, given there is a finite time before the COG-PIN can send new data.
ie if it was a OK_to_send, rather than Tx-Done, the loop could be tighter,
Of course, Tx-Done is also useful in RS485 direction change applications...
In this use, it should be at end of Tx stop bit.
I wonder how much buffering is actually there.
eg If you use a preload before the loop, what happens ?
FYI Just for a point of reference I switched from smartpin tx to a bit bang tx @ 8M baud.
120_000 byte chunk tx time went from 195mS to 156mS.
A tx_ok_to_send would work well with a 2 level tx buffer.
Still it's nice to be able to blast data out at these speeds.
I ask because I'm going over the serial mode in the smart pin and it looks like a big pain to make it deal with four bytes per long SETPINY/GETPINZ. It's hard because I've got the synchronous serial melded into the whole thing and the integration almost broke my brain the first time around.
Bit-bang (Tx only) is just ok at 8MBd, but 50MHz Tx and Rx, no gaps, should be possible with the hardware tuned right.
Nice work Ozpropdev. Worked on all the monitors I tested.
FT2232H (and FT232H) only sends 8 bits @ 60MHz in the fast 245 mode. Maybe you can use a CPLD to join four 8-bit words into one 32-bit word @ 15 MHz. This is something I wanted to test on P1 (can the P1 send COG RAM data to pins at that speed? and is there room left for any other processing?).
Another option is to use the USB 3.0 devices FT600/FT601. I remember they have a 16-bit or 32-data bus width at 100 MHz and 66 MHz (but the programming manual was not clear about this 'slower' 66 MHz frequency).
Not serially.
There is a Fast Serial mode on HS USB FT parts good to 50 MHz, ASYNC data framed, with clk.
For that, can P2 support sysclk/2 async ?
FIFO modes use handshakes, that could work with the streamer? (8 16 32 b)
Fast Serial Mode uses a simple 1 wire handshake on P2 -> FT232H only, and data flow is half duplex, on TXD & RXD pins. It expects P2 to be able to swallow bytes as they come.
Seems the handshake in FT -> P2 direction is by Pause of the FCLK, driven from P2.
(stalls bytes, and delays START bit )
Data does not show packed bytes case, or indicate how many clocks are needed for FT -> P2, but the waveforms suggest 13~14 for each P2 -> FT byte
I tweaked the numbers a bit and found the following change seems to clear things up a bit.
Thanks for your help. I finally quit fiddling with the PropCam long enough to set up the mini-ft2232h. Your photo and diagrams were extremely helpful.
First, I set up a loop to bounce a received character back out to tx. This works fine with the regular Propeller 1-2-3 USB, pins 62 and 63, at 3Mbaud using the Parallax Serial Terminal.
I then changed my pin assignments to the mini-board pins and changed the setb to dira (rather than dirb as for the normal USB).
The Windows Control panel sees the mini-ft and tells me it is working normally on COM7 and COM8.
I have connected rxb and txb on the mini to my rx/tx pins on the P2v, etc. (And I have tried reversing the order, just in case this was wrong:)
I am getting nothing... not a single return. I'm set up for smartpin async... which works fine with through the 1-2-3's usb.
I'm at a loss.
In the picture I noticed that you have the mini-ft reset-pin (#8 on CN2) hooked up to the P2V, but I don't see in your code how you are handling it... ?
My Ft2232H is currently not connected to my A9 but here's the connections anyway.
CN3 Pin 1 VBUS to CN3 Pin 3 VCC
CN2 Pin 1 V3V3 to CN2 Pin 11 VIO
Be careful of the old trap of TXD/RXD directions may be the opposite to what you think.
I will fire it up again tonight and confirm the operation
Checked above connections Ok.
Only thing I left out was you also need the following jumper for Channel B to work.
CN2 Pin 3 V3V3 to CN3 Pin 12 VIO
Progress.
I had a connection: CN2 pin 1 to cn3 pin 12 VIO. I have fixed that.
My normal USB still works. With the new pinouts, I get a correct character returned followed by a several "y" with two dots over it in a stream:) When I disconnected the reset on cn2, I get a constant stream of the same strange "y". I tried tying the reset high and low through 1K resistors, no help
I moved from b_tx and b_rx on CN3 over to a_tx and a_tx on cn2... see below
hmmm:)
When I change my program to send a particular character "o" after it receives anything from the serial terminal, it does so every time through the loop... so I get the character I expect... but as a constant stream of that particular character. It isn't waiting to receive a character... it acts as though it is receiving a character, when it shouldn't be.
So, the problem seems to be that the mini-ft correctly sends what it gets from the P2v... but is sending a constant stream of characters to the P2, even when the serial terminal is doing nothing. OR TX works and RX doesn't with this board configuration.
I tried taking the acknowledge out of the send_rx routine... no good. The thing is... the code works just fine with the onboard USB. Makes no sense to me:)
And for those reading this... P2v serial works just fine. We are having a little configuration issue... that is one step above my pay grade:)
I was able to replicate the fault you are seeing.
The character "y" that you are seeing is ascii code $FF.
The bug seems to be when the FT2232H uart is idle the smart pin keeps receiving "FF''s."
The issue appears to have been solved by the new FPGA image Version 8.
I now have it working, but when I hook it up to my PC Program the sent characters from the PC have noise in them...
For example, sending a picture from PC to P2 gives me a slightly corrupted image... all the pixels arrive, but there are minor pixel sized errors spread throughout. Using the 1-2-3's normal USB, with same software = no problem.
3MBaud
I still have to stall the tx routine by 4000 clocks to get things to work right with my software. I ripped the pc software apart to see if some of the libraries(such as Kinect) were causing the problem... I couldn't find anything.
The one thing that changed in the serial smart pin was that, after a start bit edge, we verify that the start bit is still there at the halfway point. If it is no longer there, we go back to waiting for a low, otherwise, we proceed to read in the timed data bits. Maybe that's causing some trouble?
Which device is this ? FT2232H / FT223H should have no issues at 3MBd, other parts are a little more variable....
Had to step out. Sorry about the delay. I have no idea. I would like Brian to try it out and see what he gets.
I was sending 76800 byte chunks and it was pretty obvious... looked like bits were low when they should have been high.
So, send a nice bright image.
Remember... no problem if I use the 1-2-3's USB... except for having to stall the TX. I think this is on the compute side, since Brian has successfully gone beyond 3MBaud.
Earlier, I grounded my reset pin on the mini-module and also tied it to 3.3v... just to see what would happen:)
I have no respect for hardware. Only problem is I usually order two so I can destroy one. In this case, I only have one.
So, I might have an injured module... not dead, but maybe not healthy.
Jmg
FT2232h rev 1.1