Need suggestion for USB SPI adapter that can work as full duplex SPI slave

[wb0gaz]

I have a microcontroller application that functions as SPI master (MOSI/MISO/SCK/SS) at 2 MBPS clock rate, and is intended to transfer data full-duplex (one byte clocked in for each byte clocked out.) The microcontroller application asserts SS, transfers some data (potentially a finite length, potentially open-ended, streaming-style), then releases SS, and will do these transactions "forever".

I need a device that would bridge this full duplex stream to a PC so the stream could be manipulated with an application on a PC (record the output stream to a file, play back a recorded stream from a file, do both of these at once, function as a SPI slave loopback device, etc.) Ideally the device would expose an API that would do things supporting this (notify when SS changes, notify when a byte has been received on MOSI, provide a way to send a byte on MISO that would be clocked out, etc.)

I've been searching for USB SPI adapters, but these seem geared to providing electrical interface for programming SPI flash memory modules and the like (the adapter would serve as SPI master in this case, which isn't useful for my requirement.)

So, any suggestions/ideas that does not involve creating the tool, rather something that can be bought, used, and be supported by vendor or community?

Thanks!

[RoGeorge]

Raspberry Pi is a SBC (single board computer), and it has SPI, so you can connect your microcontroller to the Raspberry Pi SPI pins directly, with wires, without going through USB (beware that Raspbery Pi pins are 3.3V, not 5V - if your SPI works with 5V SPI, then use a level translator instead of direct wires, Raspberry Pi inputs ar NOT 5V tolerant).  There are many models of RPi, from $5 to $100.

RPi is a full computer, so it can run Linux, Python, whatever, and can process your data.  Or, it can just read the SPI data then send that over LAN or Wi-Fi to another computer.

[wb0gaz]

Thank you, RoGeorge.

If I cannot find a commercial product that performs this function, that would be a good alternative, but at the expense of some integration work.

[mon2]

Maybe TotalPhase has a suitable tool ?

https://www.totalphase.com/products/aardvark-i2cspi/

[wb0gaz]

Thank you, mon2. I'll contact the vendor to get help determining suitability (I have questions primarily about latency, jitter and full-duplex SPI getting handled over a USB connection.)

While the thread is open, I'd be grateful for any other suggestions/ideas, as well as any help in pre-qualifying a solution (I'm concerned about how USB 1.1/2.0 (being half duplex) might impact my application which needs continuous full duplex streaming.

[Foxxz]

The FT2232H can do synchronous SPI bus work over USB

[SiliconWizard]

The FT2232H can do synchronous SPI bus work over USB

Yep. And unless you really need 2 channels, you can use the FT232H instead, which is definitely cheaper.

[wb0gaz]

Thanks, Foxxz  and SiliconWizard - I looked at FT2232H application note for SPI, and it contains

"The FT2232H always acts as the SPI master"

(I presume this applies to the single version device too.)

My application requires that the USB/PC interface function as a slave, because it is a signal processing application where clock timing and throughput are dictated by the microcontroller.

I think one occupational hazard of this exploration is that in USB the PC takes on the master role, in my application the microcontroller takes on the master role, and USB is half duplex so there are turn-around issues.

Thanks for your suggestions!

Dave

[SiliconWizard]

If you need SPI slave, then the FTDI parts are not an option indeed.

You could implement this in any reasonable MCU having a SPI slave peripheral and USB. Many, many out there, but firmware to write.
Of course, you'll need to make sure the whole chain can handle the data throughput, but at 2 MB/s, that shouldn't be much of a problem.

I'd be surprised if there wasn't already at least one project doing exactly this. Have you looked that up?

[wb0gaz]

Thanks again, SiliconWizard.

My search didn't turn up very much - it seems the vast majority (all I found so far) of "USB to SPI" are for the purpose of programming flash memory chips and things like that, and are not suited to the slave role and full duplex regime I need to support.

I am trying to avoid re-inventing the wheel; I understand these requirements are not as common as the use cases I've found so far, but certainly the various elements exist.

So far, the closest (but certainly not shrink-wrapped) solution was the first comment added to this thread, which is to use a Raspberry Pi, although I've not yet verified if it's SPI interface can take the Slave role (it's probably more a matter of what drivers exist in the Pi operating system than the physical hardware on the SOC.) The work that will be done in the PC - or PI - end of the circuit is signal processing (somewhat DSP-like) so my original idea of harnessing a PC was just scalability, as certainly at some point there can be sufficient memory and FPU capacity to succeed on that front.

A microcontroller as you point out would certainly handle the SPI interface, but the software stack needed to implement the USB endpoint and test it all almost certainly puts that option squarely opposite the shrink-wrap option...

Thanks,

Dave

[Foxxz]

Thanks, Foxxz  and SiliconWizard - I looked at FT2232H application note for SPI, and it contains

"The FT2232H always acts as the SPI master"

Ahh I missed that. The FT4222H claims it can be synchronous in slave mode

[SiliconWizard]

Just saw the  FT4222H as well. Should do the trick indeed. https://ftdichip.com/products/ft4222h/
You can find breakout boards (such as UMFT4222EV) for this, so testing it should be straightforward.

[wb0gaz]

Thanks for the pointer to the FT4222H ---

I dug around about using SPI Slave on Raspberry Pi, and it seems likely there is not a viable solution (the hardware may be capable, but the drivers appear to be quite simple and operate only as master.)

https://forums.raspberrypi.com/viewtopic.php?p=810290#p810290

I'm now digging in to the datasheet for the FT4222H...

[RoGeorge]

I've not yet verified if it's SPI interface can take the Slave role (it's probably more a matter of what drivers exist in the Pi operating system than the physical hardware on the SOC.)

Seems that Raspberry Pi doesn't really work in SPI slave mode, sorry.
http://offis.github.io/raspi-directhw/group__spisl.html
https://forums.raspberrypi.com/viewtopic.php?t=230392
https://sigmdel.ca/michel/ha/rpi/spi_on_pi_en.html

[PCB.Wiz]

I have a microcontroller application that functions as SPI master (MOSI/MISO/SCK/SS) at 2 MBPS clock rate, and is intended to transfer data full-duplex (one byte clocked in for each byte clocked out.) The microcontroller application asserts SS, transfers some data (potentially a finite length, potentially open-ended, streaming-style), then releases SS, and will do these transactions "forever".

The FT4222H  mentioned above looks like a fit, but full slave SPI may need some GPIO assistance ?
Otherwise, how does the MCU know the USB is active and has valid data ?
You might be able to also use FT4222H i2c master mode, to give more comprehensive commands / handshake to the MCU perhaps like

* Send i2c config and rules from USB to MCU
* Flip mode to SPI slave
* Toggle a GPIO to tell MCU side that USB is all ready
* MCU sends data, with SS as needed

[wb0gaz]

Yes, the Raspberry Pi approach appears to be dead end, but I do appreciate the idea.

I just did a quick cursory scan of the FT4222H documents, and it looks promising, however, I would need to assess suitability for 250 kbytes/second full duplex streaming application and that may require contact with FTDI technical support.

There is a simple protocol (prefix in the data stream to be sent) that can be enabled (one of the operating modes). I think this helps the FT4222H track the intended state of the external master. I have not gone back to re-read any of the sections yet. I did find a Linux example set on FTDI web site, however, I haven't opened the file yet.

It's not immediately clear if full duplex operation is supported or not supported. As SPI is inherently full duplex, I would be surprised if it is not supported. However, this goes back to the problem of USB being the master and controlling the transactions with the attached peripheral.

Other than the vendor evaluation board, I haven't found modules built around this chip except for those intended for SPI memory device programming.

Thanks very much for the lead - there is something to this, I think, although I would still prefer an off-the-shelf packaged solution.

[PCB.Wiz]

I just did a quick cursory scan of the FT4222H documents, and it looks promising, however, I would need to assess suitability for 250 kbytes/second full duplex streaming application and that may require contact with FTDI technical support.

The FT4222H is high speed USB, and data says 4130 bytes of buffer, which is around 8ms of buffering.
Their HS-USB FT232H manages 12Mbd duplex sustained fine, which is 4x what you look for.   FT4222H specs 20MHz in slave SPI CLK which is 10x headroom.

Grab an Eval board, and try it 

[wb0gaz]

Yup, that seems to be the best direction at this point. They have an example in their downloads showing slave operation, however, it's not full duplex (no threads or signals in the application).

Thanks very much; I'm open to any further input on this, and if I can pull this off (or not) I'll return to this thread.

Dave

[wb0gaz]

Did a quick look at the earthpeople module documentation available; it doesn't describe enough detail to ascertain sustained streaming full duplex application. I'll see if they can be reached to answer questions about suitability for the application.

The SPI parameters aren't anything likely to cause problems, and can be adjusted as needed within the limits of the microcontroller's SPI master port configuration.

The host OS is likely to be Ubuntu LTS (20.04).

[SiliconWizard]

Yup, that seems to be the best direction at this point. They have an example in their downloads showing slave operation, however, it's not full duplex (no threads or signals in the application).

I suggest reading the "AN_329 User Guide for LibFT4222" document if you haven't already.

Sure, SPI is by nature full duplex. In slave mode (just like on a MCU), whatever will be in the transmit buffer will get "sent" to the master while the master is clocking. So you need to keep the transmit buffer with enough data. In their example, they call the FT4222_SPISlave_Write() *after* they have received something from the master, which just means that the master will get this data when it'll transfer further data. There's just a shift. You can call the FT4222_SPISlave_Write() before receiving anything, to make sure the buffer will contain data to send when the master clocks data. Again, it's exactly the same if you're implementing SPI slave on a MCU.

As to handling 'events', you can use the  FT_SetEventNotification() function. You'll need to read the D2XX doc to make use of this properly - as I understand, the LibFT4222 is just a library on top of D2XX.
You can absolutely use that to wait on events in a multithreaded context.

So, you'll need to read both this doc and the D2XX documentation.

[wb0gaz]

I've taken a quick pass through both docs (and the sample code and the release notes for rev D of the part, but will need more time to sufficiently absorb the details. So far the docs seem well written.

I need to get a handle on the step-by-step process data takes to get from the host (PC) to the microcontroller and vice versa. What I call "full duplex" just means there's the same number of bytes going in each direction during SPI transfer, so the net volume of raw data going to or from the host PC is the same given nature of SPI (each chunk of raw bytes sent on SPI has a corresponding chunk of raw bytes received on SPI; it's up to how the blocks are formatted whether the actual number of application bytes is also balanced that way. I'm thinking USB 2.0 is alternating upstream or downstream at any given instant, so at some point the FTDI part would to be transferring it's buffer to the PC, then turning the USB channel around, and picking up what is available from the PC at that point into it's buffer, then the cycle begins again. A 4K buffer in the FTDI part suggests to me it's going to work best if the data transfer happens in blocks that are aware of that buffer capacity (I was thinking starting out with 2K) in both directions.

So far the FT4222 seems to be the most promising solution, and doesn't look terribly difficult to implement from a host or SPI perspective (probably about the same work as if there was a shrink-wrapped product I'd have to integrate into the application.)

Thanks for the guidance; I seem to be farther along now than when I posted my inquiry this AM.

Dave

[Nominal Animal]

I would use any ARM-based microcontroller with a native USB interface and sufficient SPI slave support for this.

At 2 Mbit/s, the interface only needs to be Full Speed (USB 1.1, 12 Mbit/s).  At 2 MBytes/s, you do need High Speed (USB 2.0, 480 Mbit/s).

For prototyping and testing, I'd use one of my Teensies (LC, 3.x, or 4.x).  They all have enough memory to use as the SPI data buffer, and writing a suitable "firmware" under Teensyduino is a matter of a few hours, especially if you start with e.g. tonton81's TSPISlave (LC, 3.x) or SPISlave_T4 (4.x) libraries.  (These can all do 8 Mbit/s or 1 Mbyte/s over USB Serial interface, using the Arduino Serial.write(), and you can use a cheap ADuM3160-based USB isolator too.  Teensy 4.x can do 200+ Mbit/s or 25 Mbyte/s over USB Serial, more if using bulk USB transfers, and you can trivially set up say 256k of buffers (say 131072 bytes per direction, as a circular buffer), since it has 2×512k of RAM.)

That way you'll find out the practical requirements.  A suitable MCU might not need many pins at all, and might even have an internally trimmed 48 MHz PLL for USB, so that it'd need only minimal external components (bypass capacitors, maybe current limiting resistors, perhaps a digital isolator chip for the SPI lines to avoid ground loops if the target device is not powered through the USB connection).

[wb0gaz]

Thank you for the very detailed suggestion.

Applying a microcontroller module would certainly be the most adaptable solution and probably meet a wider range of possible needs, however, I currently have zero learning curve on applying ARM-anything so there would be some learning curve for both development environment and the actual application itself.

That said, perhaps this type of need will occur to others more qualified to quickly turn around around the needed development/testing/implementation, and someone could produce a ready-to-use based on the outline of what you propose, which sounds quite solid.

Thank you,

Dave

[NorthGuy]

... I currently have zero learning curve on applying ARM-anything so there would be some learning curve for both development environment and the actual application itself.

Doesn't have to be ARM. Any MCU family you're familiar with should have something with USB.

[wb0gaz]

I agree in principle any suitable USB-equipped microcontroller would be a viable starting point, however, the original intent of my post was to find a solution that was ideally shrink-wrapped, ready-to-buy/use, and as a second-order solution something that would have minimal engineering effort to implement. The problem at hand could *use* such a device/product, not *is* such a device/product. My development history lacks USB implementations so far (typically embedded without USB attachment, as is the nature of the current project target device), so that elevates the risk/effort of those paths.