Shop OBEX P1 Docs P2 Docs Learn Events
USB Bridge Solutions for P2 (and P1) — Parallax Forums

USB Bridge Solutions for P2 (and P1)

jmgjmg Posts: 15,175
edited 2017-06-05 03:26 in Propeller 2
split from HyperRAM Solutions for P2 (and P1)
Ramon wrote: »
The second part or the problem is how to do high speed transfer from P2 into a computer. Mostly I am talking about a PC here, but maybe there are a lot of people right now that would be thinking also in a Rasberry PI, Udoo x86, Odroid, LattePanda, x86duino, Up Board, Olinuxino ... name_your_favorite_SBC_here.

Good question. There are many connection choices, and parallel FIFO is the fastest, but has a somewhat high pin-cost.

I get this table for possible USB Bridge candidates :
             EFM8UB1(MCU) CP2102N    CP2130      XR21B1420  FT245R       FT240X      FT232H       FT2232H      FT4222-C     NUC505DLA(MCU)  FT600           FT93x
Data Rates   3-4MBd       3-4MBd     3~6MHz SPI  ~9MBd      1 MB/s FIFO  1MB/s FIFO  8 MB/s*FIFO  8 MB/s*FIFO  6.725 MB/s   HS-USB,QSPI     SS,HS USB FIFO  HS USB
Price        $0.64/1k5    $1.16/1k5  $1.57/1k    $2.04/3k   $2.65/2k     $1.57/3k    $2.75/1k5    $3.70/1k     $1.530/1k    $1.74/1k        $6.75/1k        $3.65/1k
* Possibly more in SyncFIFO mode

Comments:
Cheapest Bridge is a small MCU, EFM8UB1 (but this needs software installed, tho SiLabs have drivers+Code)
Cheapest std UART is CP2102N, good for 3~4MBd (4MBd with handshakes)
Fastest FS-USB Uart bridge is the XR21B1420, with fractional baud features and close to theoretical FS speed.

At HS-USB, things thin-out a little, and stalwarts FT232H/FT2232H have parallel FIFO modes for fastest, but many pins cost.
(all HS-USB solutions need a crystal or osc, but precise baud control is not a bad thing to have )

The C rev of FT4222 bumps QuadSPI to 6.725 Mbyte/s, so that starts to look interesting.
The NUC505 MCU is the cheapest HS-USB MCU I can find, and highly flexible, and can do QuadSPI too.

I'm looking into FT4222H some more, as this seems to be the lowest cost HS-USB standard bridge solution, and the recent improvements lift it closer to the more expensive FT232H/2232H
Longer term, the NUC505 has appeal, (it could do QuadSPI and UART and i2c and SPI and Debug..) but for now QuadSPI via FT4222H can test pathways, until QuadSPI via NUC505

The FT4222H has 4 chip selects, so it could connect directly to the SPI Flash chip, and so allow fast, direct programming.
It can also use another CS,(SS pin32) to slave FT4222 to P2, and so behave very like a COM port.

Spec gives:
"The maximum SPI interface operating clock can be set up to 40MHz in master mode and 20MHz in slave mode. With (master) quad mode (4-bits) data bus width, the max data transfer throughput can be up to 53.8Mbps." (6.725 Mbyte/s)
Slave mode is 1b only.

SPI Speed choices:
 SCK   Rate      Supported Dividers on Master CLK 
                 1/2   1/4   1/8   1/16    1/32    1/64    1/128    1/256      SlaveCLK 
 80MHz 53.8Mbps* 40M*  20M*  10M   5M      2.5M    1.25M   625K     312.5K     <= 20MHz 
 60MHz 39.7Mbps* 30M*  15M   7.5M  3.75M   1.875M  937.5K  468.75K  234.375K   <= 15MHz 
 48MHz 31.5Mbps* 24M*  12M   6M    3M      1.5M    750K    375K     187.5K     <= 12MHz 
 24MHz 15.8Mbps* 12M*  6M    3M    1.5M    750K    375K    187.5K   93.75K     <= 6MHz


Some SPI chip selects can be traded off for i2c, or GPIO...
" I2C Master/Slave interface....easy configuration of the I2C as either a master or slave, including target operating speed and bus protocol on the I2C bus.
The device can run at common I2C bus speeds, standard mode (SM), fast mode (FM), Fast mode plus (FM+), and High Speed mode (HS).
A higher bit rate on the I2C bus is also configurable up to 6.66Mbit/s. Clock stretching is supported to conform to v2.1 and v3.0 of the I2C specification"


There are also master/slave choices here..
* Slave Selection when QuadSPI acts as SPI master
  – SS0O (pin-17), slave selection to slave device-0
  – SS1O (pin-13), slave selection to slave device-1  also is SCL/GPIO0
  – SS2O (pin-14), slave selection to slave device-2  also is SDA/GPIO1
  – SS3O (pin-15), slave selection to slave device-3  also is GPIO2
* Slave Selection when QuadSPI acts as SPI slave
  – SS (pin-32), slave selection for SPI master control. Must tie high when QuadSPI acts as SPI master
Seems Pin17 can connect to SPI.Flash.CS and Pin32 is used when a running P2 wants to talk to FT4222 ?



i2c Speed Choices
SCL Freq = OperatingCLK/(M*(N+1) M=6 or 8  N=1,2,3..127
IF SCL Freq >= 100 KHz, M=6 else M=8
One example : 60MHz, 2.5MHz SCL -> M=6,N=3

Possible P2 connections:
GPIO -> P2Reset Holds P2 in reset, during code download to Flash
QuadSPI <-> SPI Flash device.
i2c <-> 2 P2 Pins
SS <- P2 Pin, for P2 as master link.

QuadSPI -> Flash also connects
SCK (pin-8)
MISO (pin-9), data transfer from slave to master for single mode, or data bus bit-1 for dual and quad mode
MOSI (pin-10), data transfer from master to slave for single mode, or data bus bit-0 for dual and quad mode

Link pathway is a one-of choice, PS host can request SPIM (SPI master), or SPIS (SPI Slave) or i2c; GPIO seem to have a separate USB interface number in mode0.

So far, this is looking fast and flexible, and low cost. All that is missing is a UART pathway.

Suitable bit packing and unpacking could run 5 SPI bytes as 4 UART bytes.
To avoid RX creep, slave mode may be best, however in this case P2 needs to provide a Baud-clock during the whole TX-RX transaction.
Master mode could avoid 'the P2 provides clock', but creep may be an issue during any long 'P2 replies' phase ?
Possible solution could be a 1GU04, to have P2 clock from the 12MHz Xtal Osc on FT4222 ? (or, a 12MHz OSC module, drives both chips)

Mouser show UMFT4222EV-C Stock: 78 1+ $14.95

Comments

  • Wow, there's a lot to digest here. Thanks jmg for providing that very useful information. In my projects I've been using FT245, FT232 and most recently FT231 but its clearly time to look at other options.
  • jmg,

    I think that you missed the point when I said 'do high speed transfer from P2 into a computer'.

    All those data transfer rates you wrote in the table are for the so called 'Asynchronous 245 FIFO'. Asynchronous FIFO mode allows between 1 and 8 MB/s as you already wrote (1MB/s for FT245/FT240, and 8MB/s for FT232H Asynchronous FIFO mode). Eight megabytes seems quite high, but I consider that rate low speed for a P2.

    What I call high speed is the Synchronous 245 FIFO mode. This mode can transfer up to 40 MBytes/sec. It doesn't matter if the device is a FT232H or a FT2232H (both FT232H and FT2232H only have ONE Synchronous FIFO channel). And this is expected, as it is completely impossible to transfer more than 60 MBytes (480Mbits/s) over a single USB 2.0 cable.

    A device with similar (or higher) high data transfer rate is the Cypress FX2LP (USB 2.0). But this one has a much more complicated configuration/control setup. Devices with higher data rates, USB 3.0, are Cypress FX3 or FTDI FT600 / FT601. But those devices will require a careful high speed PCB layout (5 Gbps) and they are only available in QFN package instead of LQFP (easier to solder/replace).

    The main issue with Synchronous 245 FIFO mode is that the FT232H, or FT2232H (both are the same in this mode) requires the MCU or FPGA to be synchronized to the 60 MHz clock output that it delivers to one pin.

    The question I wanted to ask RJSM was if the P2 can receive this 60 MHz external clock, use it as it's main clock and at the same time 'talk' with the HyperRam IC (that maybe expects 100 MHz or 166 MHz?).

    Some pictures and links attached to help understand this issue in detail:

    http://www.ftdichip.com/Support/Documents/AppNotes/AN_165_Establishing_Synchronous_245_FIFO_Communications_using_a_Morph-IC-II.pdf

    677 x 519 - 55K
    1039 x 534 - 58K
    220 x 532 - 16K
    1068 x 316 - 43K
  • jmgjmg Posts: 15,175
    edited 2017-06-03 20:52
    Ramon wrote: »
    All those data transfer rates you wrote in the table are for the so called 'Asynchronous 245 FIFO'. Asynchronous FIFO mode allows between 1 and 8 MB/s as you already wrote (1MB/s for FT245/FT240, and 8MB/s for FT232H Asynchronous FIFO mode). Eight megabytes seems quite high, but I consider that rate low speed for a P2.
    I was pasting from a FTDI document, so I've modified above.
    One person's low speed, is another's high speed, so readers have no idea what your personal low/high cross over is.
    Instead, I treat HIGH the same as USB tagged, so High speed is HS-USB devices.
    Just how fast a HS-USB part might go, is another topic...
    Ramon wrote: »
    What I call high speed is the Synchronous 245 FIFO mode. This mode can transfer up to 40 MBytes/sec. It doesn't matter if the device is a FT232H or a FT2232H (both FT232H and FT2232H only have ONE Synchronous FIFO channel). And this is expected, as it is completely impossible to transfer more than 60 MBytes (480Mbits/s) over a single USB 2.0 cable.
    http://www.ftdichip.com/Support/Documents/AppNotes/AN_165_Establishing_Synchronous_245_FIFO_Communications_using_a_Morph-IC-II.pdf

    The document you link says " rates up to 35MByte per second."
    Ramon wrote: »
    The question I wanted to ask RJSM was if the P2 can receive this 60 MHz external clock, use it as it's main clock and at the same time 'talk' with the HyperRam IC (that maybe expects 100 MHz or 166 MHz?).

    Those numbers show there are actually 2 issues here, and the CLK is the minor one.

    I think you can use the 12MHz OSC the HS-USB parts use, to drive P2-PLL, and thus at least match the clock frequencies. (Phase is another issue..)
    Addit: actually, smarter might be to drive P2 from CLKOUT, as that removes some delays and 12:60 phase questions, so should give better phase-sync.
    As that 60MHz is not always there, some clock-fail detector starts to look really useful in P2...

    However, those variable data rates of 'somewhat less' than that clock, mean you must also operate a handshake state engine, as clearly not all of those clocks an be used.

    Right now, P2 has no such state engine, making clock question moot.
    (I have previously suggested P2 should have built in, the capability to run parts like FT232H to their top speeds)

    With 120MHz FPGAs this is now in the realms of possible, but it would also need FPGA locked to 12MHz, or alternatively, the P2 (or FPGA) could output 12MHz to clock the HS-USB

    FTDI Specs also are vague on if that 60MHz is variable ?
    I can see this "In Host Bus Emulation mode the clock divisor has no effect. The clock divisor is used for serial data and is a different part of the MPSSE block. In host bus emulation the 60MHz clock is always output and doesn’t change with any commands.", but nothing explicit for SyncFIFO ?
    ie 30MHz may be possible ?
  • jmg,

    This is the fact (from RJSM HyperRAM thread): "I’ve got these latter routines running in ~ 2.6 usec, affording a data transfer rate between HUB RAM and HyperRAM in excess of 50 MB/s."

    So this is not a personal taste issue about what I consider low or high speed.

    Think about all those logic analyzers (Saleae, Openlogic sniffer, ...) that are currently using a FPGA (spartan 6 LX9) + Cypress FX2LP.

    This is about wether the P2 can do the job or cannot (and maybe I need to use FPGA, or something else). At the end, this is about wether the P2 can offer something UNIQUE or not.
  • jmgjmg Posts: 15,175
    edited 2017-06-04 20:56
    Ramon wrote: »
    This is about wether the P2 can do the job or cannot (and maybe I need to use FPGA, or something else). At the end, this is about wether the P2 can offer something UNIQUE or not.
    Of course, I have always advocated for highest usable speeds from P2.

    Currently, however, P2 cannot connect to SYNC-FIFO modes, but we can peel back a little to see what may be needed.

    a) I think Chip's expansions to the PLL can accept a wide range of CLK-IN, so 60MHz can feed into PLL.
    The details of this that follow are
    i) 60MHz is not always present, but maybe that is tolerable for fast PC links ? (some missing CLK handling may be required ?)
    ii) Assuming PLL can lock to 60MHz, there is still phase between SysCLK and CLKIN. This could be improved with a small but deliberate delay in one PFD leg that matches the SysCLK-PIN path delays.

    b) To use SYNC_FIFO, some handshake lines are needed on a streamer.
    These do not exist at the moment, but Chip has recently added a Clock-Enable to the Smart-Pin timer modes, which gets very close.
    It may also be the READY signal can be software managed, if you know the FIFO has space for a given burst.
    That leaves an ACK type handshake

    Of course, if Chip does add Streamer handshakes, the other device to target is the FT600 (added above)

    FT600 uses 30MHz xtal, and says
    "CLK Parallel FIFO bus clock output pin to FIFO bus master, the Frequency can be configured as 66Mhz or 100Mhz for both FIFO bus modes."
    just maybe that 66MHz can run with a 132MHz P2 PLL setting ?
    There are FT600 eval boards now available, and I see a quite recent (Oct 2016) Rev-B fixes these issues....
    All issues listed below have been fixed in Rev B:
    Issue A : A control message in the middle of an internal IN data transfer will cause the transfer to hang
    Issue B : Detach/attach the device during IN transfers requires a power cycle
    Issue C : A ZLP is not sent to the host when the FIFO interface master writes a multiple of full packets and stops while the FIFO buffer has more space
    Issue D : A ZLP is not sent to the host when the FIFO interface master writes a full packet which fills the FIFO buffer and stops before the requested length of data is transferred
    Issue E : FIFO clock disappears when the device enters suspend


    If this is not possible, it is always an option to add a small FPGA between P2 and FTxyz, that manages the handshakes in a way that keeps both chips happy.
  • A 96MHz ARM with high-speed USB for $2.66, could do a custom P2 interface to push the limit.
    http://www.microchip.com/wwwproducts/en/ATSAM3U1C

    Also gives you another 50+ gpios.
  • jmgjmg Posts: 15,175
    tonyp12 wrote: »
    A 96MHz ARM with high-speed USB for $2.66, could do a custom P2 interface to push the limit.
    http://www.microchip.com/wwwproducts/en/ATSAM3U1C

    Also gives you another 50+ gpios.
    Interesting, but comes only in large pin-out packages, TQFP100+, the NUC505DLA in TQFP48 looks a better bridge pairing from a top-layer glance
    NUC505 has QuadSPI support, whilst the ATSAM3U1C has a parallel mode.
    Not such a good sales look, if you have to tell users to add a second, large MCU for fast links...

  • tonyp12tonyp12 Posts: 1,951
    edited 2017-06-05 01:25
    P2 should been created around 480mbit usb2.0 and 270mbit 480p hdmi.
    Figure out what nm that needs and use that as starting point for the whole design.





  • AribaAriba Posts: 2,690
    Maybe the P2 can handle the 60 MHz Interface of the USB3300 Phy (ULPI with 12 signals). This would be a cheap and small solution for Hispeed USB (32pin QFN, ~1$).

    Andy
  • tonyp12tonyp12 Posts: 1,951
    edited 2017-06-05 02:01
    I was thinking that too, smartpins should been created around support of the (12pin need) USB3300,
    Anything else the pins can then also do, is just a bonus.
    http://www.microchip.com/wwwproducts/en/USB3300
    http://ww1.microchip.com/downloads/en/DeviceDoc/00001783C.pdf


  • jmgjmg Posts: 15,175
    Ariba wrote: »
    Maybe the P2 can handle the 60 MHz Interface of the USB3300 Phy (ULPI with 12 signals). This would be a cheap and small solution for Hispeed USB (32pin QFN, ~1$).
    Hmm, interesting idea.
    With no data buffers inside this PHY, that looks a serious design challenge, that would need hardware handshake.
    High rates of PC -> P2 is likely harder than P2 -> PC.

    Microchip mention some Eval Boards, but not for that exact part code.

    They look to have a range of ULPI parts
    Has similar 60MHz clock demands to the FTDI parts, so maybe the FTDI can be a stepping stone ?

  • AFAIK, all those ULPI usb PHYs (TI, NXP, and others also have them in their catalogs) are very cheap, but they are completely useless.

    They are only useful for FPGA designs if you have the several thousands of $$,$$$ that they ask for the encrypted Verilog netlist:

    http://www.slscorp.com/ip-cores/communication/usb-20-device/usb20hf.html

    https://www.altera.com/solutions/partners/partner-profile/system-level-solutions--inc-/ip/usb-2-0-device-with-fifo-interface--usb20hf-.html

    Unlike the FT232H/FT2232H, the ULPI ICs cannot be used directly as FIFO interface because those IC manufacturers do not provide the required ULPI engine/controller/IP (and they do not provide too the drivers for several OS).

    And I don't think that Chip (or anyone else) is going to spend several months implementing the ULPI obex code for free (well maybe chip can do that in the future, if he wanted to and had the time).

    So I think they are not alternatives to the FT232H/FT2232H. FTDI provides a complete FIFO without needing to handle the USB internal protocol, and they provide drivers for several OS. Cypress FX2LP also provides a similar thing, but it is much more complex to handle.

    I would prefer the ATSAM3U1C (or any other cheap USB 2.0 High-speed MCU). Only if it were easier to use than the FT232H, and if it will provide the same OS support (Windows, Linux x86/ARM, and Mac OS). But I think it's not the case.
  • jmg,

    Instead of NUC505DLA, have you seen the NUC505DL13Y?
    2MB Flash, SD Host, USB 2.0 HS, RTC, and also LQFP48 at around US $2
    I only miss Ethernet MAC/PHY. Is this the best P2 coprocessor?
  • jmgjmg Posts: 15,175
    edited 2017-06-05 23:24
    Ramon wrote: »
    jmg,

    Instead of NUC505DLA, have you seen the NUC505DL13Y?
    2MB Flash, SD Host, USB 2.0 HS, RTC, and also LQFP48 at around US $2
    I only miss Ethernet MAC/PHY. Is this the best P2 coprocessor?
    Yes, sure. I was starting with lowest price points, but the 2MB variant is certainly valid.
    The NUC505 has quite large FIFOs on most things, and specs 50MHz Quad SD links.
    It should be able to host a better debug, because of the HS USB.
    However, as you say, a bare-slate MCU design needs more time to complete.

    I downloaded the BSP for NUC505, which has 4510 items in 64MB.. some included useful looking ones are

    USBD_HID_Transfer Demonstrate how to transfer user-defined data – Command / Data Read / Data Write by a HID device.
    USBD_Mass_Storage_SD Implement a mass storage class sample for a SD card reader.
    USBD_Mass_Storage_ ShortPacket Implement a mass storage class sample to demonstrate how to receive a USB short packet.
    USBD_Mass_Storage_SRAM Use internal SRAM as back-end storage media to simulate a 30KB USB pen drive.

    and I see some CDC setup files.
    So maybe the P2-FLASH can appear as Mass_Storage, and COM ports can appear as HID/CDC without too much raw development ?
  • evanhevanh Posts: 16,032
    Ramon,
    Better late than never I guess, but I'll point out that USB2.0 has a history of topping out at around 20MB/s. So don't go expecting to get the max rating on any of the solutions.
  • That doesn't seem to be true.

    FTDI datasheet says at least 35 MB/s, and this has been reported to be true in several forums. (performance depends on OS, Chipset, and buffer or configuration parameters):

    Daveatol -> 30 MB/s WR , 38 MB/s RD (Sustained)
    Marcan -> 42MB/s device->host FT2232H, Linux with USB3 (xHCI) host
    40MB/s with a USB EHCI host
    38MB/s with an older kernel
    https://www.eevblog.com/forum/microcontrollers/ftdi-ft232h-in-synchronous-fifo-questions/

    Ton Giesberts (40 MB/s possible)
    https://www.elektormagazine.com/labs/130542-multipurpose-ft232h-usb-module

    Magnus (He is a forum member) -> 30 MB/s sustained
    http://saanlima.com/forum/viewtopic.php?f=4&t=1258

    Alexis_B -> 32 MB/s
    http://www.alteraforum.com/forum/showthread.php?t=53022&page=2

    And FTDI FT2232H/FT232H is not the highest performing USB 2.0 IC. It has been reported in many other forums that Cypress FX2 can sustain over 40 MB/s. (but this IC is more complex to handle)
  • Useful collection of links thanks Ramon
Sign In or Register to comment.