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

[Nominal Animal]

... 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.

Yup.  I would use an ARM because I have several from different vendors/families, and know they could do this.  Probably should have worded that better, sorry.

I do have a Teensy 2.0++, which has an AT90USB1286 microcontroller, but instead of DFU, a proprietary HalfKay bootloader (uses HID for firmware updates).  The '1286 does not support USB Host; only the AT90USB647 and AT90USB1287 do, from the same family (AT90USB64x , AT90USB128x).  I'd feel very cramped to implement both USB Serial host, as well as the test suite, on an AVR, though.  32-bit ARMs tend to be faster, and have more memory, and thus be easier to work with for this.

If you have used AVRs in the Arduino environment, then many ARM-based microcontrollers have Arduino cores.  The main difference is the way you access GPIOs and periperals, but using existing libraries helps with that.

[nctnico]

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.

The simplest way forward is probably to use a serial port USB emulation with the SPI slave interface as the data sink/source. Probably with some buffering on top. You dump data into the serial port which then gets buffered in the controller. When an SPI transfer occurs, the data is transmitted to the SPI master and the data received is send to the serial port. Note that baudrate doesn't exist in the world of a virtual serial port; the USB transfer speed is what limits the throughput.

From the application side (which likely has knowledge about the amount of data transferred) you can keep the path from the PC to the SPI interface filled with enough data to transmit.

[wb0gaz]

I had given initial though to something like a serial/SPI adapter, however, the data volume (250K bytes/second) seems far higher than I'd be able use a physical serial port. Am I missing something in your idea?

[nctnico]

I had given initial though to something like a serial/SPI adapter, however, the data volume (250K bytes/second) seems far higher than I'd be able use a physical serial port. Am I missing something in your idea?

Yes, you have missed that baudrate doesn't exist in the world of a virtual com port! I have done >300kbytes through a virtual USB com port. There is no UART involved at any point in the data transfer chain.

[wb0gaz]

Thanks, nctnico. Yes, the irrelevance of baud rate in the USB world I had forgotten to consider.

I suspect with a project solution based around a microcontroller which itself can act like a USB device, that emulation of a serial port device (that would, ideally identify and emulate as a widely supported serial device such as ftdi ft232 series), would provide a readily accessible solution not requiring drivers or any additional libraries.

For a slave role, I think the only signaling needed (other than the data itself) would be the assertion and subsequent de-assertion of the slave select signal; and in the general case, a mechanism to represent the specifics of SPI interface (clock polarity and phase relationships.)

Dave

[NorthGuy]

This MCU which works as a SPI master. Do you have any control over it? Perhaps you can modify it so that it does USB instead of SPI?

[nctnico]

Thanks, nctnico. Yes, the irrelevance of baud rate in the USB world I had forgotten to consider.

I suspect with a project solution based around a microcontroller which itself can act like a USB device, that emulation of a serial port device (that would, ideally identify and emulate as a widely supported serial device such as ftdi ft232 series), would provide a readily accessible solution not requiring drivers or any additional libraries.

Virtual com port is a standard CDC serial device emulation; drivers comes standard with any modern OS (Windows 7 and lower need some persuation but only in the form of a text / .inf file telling it the USB device is a CDC serial port  ). Trying to emulate an FTDI FT232 is the worst idea ever; the Windows drivers are actively trying to determine whether they are talking to a real device and fail silently if they don't. Stick with CDC virtual serial device mode.

[wb0gaz]

OK thanks for the pointers re CDC. If this becomes a development project at that level of detail, then that approach makes sense.

Much appreciate the comments and discussion.

While I'm surprised that no clear commercial tool emerged from the discussion (I investigated two that were possibilities, neither responded to a pre-sales inquiry after several days, which suggests that poor post-sales support would be likely ensue.)

The FT4222 (suggested early in this discussion) seems to be the path of least resistance at this point given absence of an off-the-shelf solution; that seems likely to entail only modest hardware effort and adaptation from a small example program furnished by FTDI.

[PCB.Wiz]

I had given initial though to something like a serial/SPI adapter, however, the data volume (250K bytes/second) seems far higher than I'd be able use a physical serial port. Am I missing something in your idea?

There are other issues with doing UART-SPI adapter.
With SPI, you have exact MCU control over data coming from the USB side, assuming the buffer is pre-filled.
With UART, you would need to add a handshake line, so the MCU can pause the buffer TX, until your MCU is ready.
Even there, the UART byte needs time to send, before the spi side can get valid data. The SPI side handshake needs further timing care to allow for that.


With SPI, you have true full duplex, and the clock you provide means no creepage.
With UART, things get trickier.  A Baud rate of 2.5Mbd gives you 8 bits every 4.0us, nominally your 2MHz SPI, but baud matching is not precise.
A skew of even 0.1% means every 1000 chars, you have one more or one less to manage in each direction.

It could work with a flow system that requested 1k or 10k bytes, that tolerates such skews with a small dead band.
eg 3MBd Duplex UART, with handshake lines to moderate agreed buffer bursts to 2MHz SPI average might work.
There, you would likely need a FT232H or similar HS-USB UART, as FS-USB USB UART's will be pushed to maintain 3Mbd full duplex, plus your custom UART-SPI bridge device will need development and tuning..

It's not impossible, but unless you intend to make 10,000's +, you are probably better to work with more headroom/simpler.

FT232H/FT2232H can sustain 12MBd full duplex, and the FT4222H can manage SPI directly.
I'd look at UART-SPI only if FT4222H fails, and then maybe rework your SPI side to just be 3MBd UART+HWHS instead ?   Is it Hw locked to be SPI ?

[PCB.Wiz]

This MCU which works as a SPI master. Do you have any control over it? Perhaps you can modify it so that it does USB instead of SPI?

... or even change it to 3MBd UART interface ?

[wb0gaz]

Yes, it's effectively locked to SPI.

Target is a simple microcontroller (lots of memory, adequate CPU resource, not much else.) I can't think of any other comparable bandwidth interface solution that has the same simplicity of operation (as SPI) from a microprocessor firmware perspective. Extremely high speed serial isn't in the cards, as async typically needs 16X clock speed (making it asynchronous) and there's no option for a 48 MHz serial clock here (and at  that point I'd be searching for a 3 Mbps USB/Serial interface, which I suppose could be found, but at some point while the range of options is fascinating, a practical first pass seems to be the FTDI part, and if it fails to perform, there's plenty of fodder in this discussion for alternatives.

I had looked a couple of Ethernet peripherals such as what Wiznet has to offer (which in turn are usually interfaced by SPI, as I2C is not fast enough nor full duplex.) After SPI, I2C and Serial, that's the end of the menu for the target device. Ethernet adds quite a bit of complexity so that wasn't looking promising at all. Changing the target device (such as to STM32 or similar with USB support) isn't in the cards.

I suspect a gadget like I envision fails to be a mass-market device and hence not easy to find, as it's primary use wouldn't be used to flash cell phones, reprogram communications and computing gear, or do any of the other things that seem to be the target for low-cost (master-only) USB-SPI adapters.

[MarkF]

If you are willing to spin your own firmware for it, take a look at this module from DLP Design:
   https://www.dlpdesign.com/usb/232PC.php

It has a PIC18F2410 which you can program the SPI interface as needed.
This PIC only has one SPI channel.  Is that enough?
I started with an older version many years ago and have since spun my own custom module for my model railroad.
They provide their firmware sources after a purchase that you can customize.

[PCB.Wiz]

... Extremely high speed serial isn't in the cards, as async typically needs 16X clock speed (making it asynchronous) and there's no option for a 48 MHz serial clock here...

16X was largely true some time back, today many MCU have more options.
What is the target MCU here, and do you control the code in it ?

[NorthGuy]

I can't think of any other comparable bandwidth interface solution that has the same simplicity of operation (as SPI) from a microprocessor firmware perspective.

Direct USB is not much more complex. Once you enumerate your device, there's not much work you need to do. To transmit, all you need to do is to put the data into a buffer and tell the USB module in your MCU to send it. Or, you get a signal that an incoming packet has arrived and you parse it. Everything else is done in hardware.

Many many MCUs have hardware support for USB.

It is sort of silly to use two MCUs with SPI in between, when you can use one which supports USB directly.

[wb0gaz]

OK, I've reached the "thank you for all of the ideas and discussion" point.

Thank you, and I'm grateful for the enthusiastic discussion and great ideas.

I've got a plan (FT4222) and will report back should that not pan out as expected.

... and while it may be silly to someone that I'm using a device without USB support, porting thousands of lines of existing code to another target seems more silly when a 32-pin device can provide a solution that appears pragmatic ...

[voltsandjolts]

...
Many many MCUs have hardware support for USB.
It is sort of silly to use two MCUs with SPI in between, when you can use one which supports USB directly.

Agreed, but that's because we are both comfortable using USB stacks.
If the FT4222 gets the job done for the OP, with a minimum of time and effort invested, then great.
If the OP was looking to use USB for other projects then I would say it's worth the effort learning to use a USB MCU.

Myself, if I was integrating ethernet into a product I would probably go with a WizNet device, which provides a fairly easy SPI interface to ethernet.
That's because I'm not familiar with embedded ethernet stacks and don't see myself requiring emb ethernet much in the near future.
It's just not worth my time selecting and learning to use a MCU with ethernet interface.
So, same argument as the OP for using SPI interface to USB.

[SiliconWizard]

... and while it may be silly to someone that I'm using a device without USB support, porting thousands of lines of existing code to another target seems more silly when a 32-pin device can provide a solution that appears pragmatic ...

I don't blame this approach. Changing a working solution "at the last minute" is rarely a good idea.
Another point is that, I don't know what your design is for exactly, but you might actually have uses for it using SPI connected to other things than a computer through USB. (One could reply that you could implement both interfaces.)

You should be able to work something out with a FT4222H. Just be aware of its quirks. Not worried whatsoever about data throughput, but the doc says it adds a dummy 'zero' byte automatically upon the transfer of the RX (or TX? I don't remember exactly, read the doc) buffer, which could be annoying. Depending on which side it is, it might require modifying your MCU code. So, take a close look.

Otherwise, as I already mentioned, I have now used TinyUSB on a couple projects, and I'm pretty sold so far. It's very easy to use, and makes porting the USB part to any of the supported MCUs a breeze. So, that could definitely be an option if the FT4222H route fails.

[PCB.Wiz]

...
I've got a plan (FT4222) and will report back should that not pan out as expected.

Sounds good, just check you have a rev D device, for the testing.  Sometimes Eval Boards can sit on the shelf longer...

[wb0gaz]

Parts are enroute - I'm just going to reflow one onto a DIP adapter and have at it. Definitely will heed the "rev D" concern, however, these are coming from large US distributor so if not suitable, issue should be readily corrected.

I appreciate the alternatives should problems ensue.

[PCB.Wiz]

I've got a plan (FT4222) and will report back should that not pan out as expected.

... and while it may be silly to someone that I'm using a device without USB support, porting thousands of lines of existing code to another target seems more silly when a 32-pin device can provide a solution that appears pragmatic ...

Yes, the FT4222H would be my first Plan A.    Looking at the  order codes, it looks like UMFT4222EV-D  means D rev part.

Just looking across the FTDI FT1248 parts, and that is a slave clocked serial interface, that is 'not quite SPI', but has a few advantages, and  if you control the code and HW pins in your device, that 'not quite SPI' may be tolerable ?

Quite a few FTDI parts support FT1248 interface and a quick scan of the data shows these advantages over a 'plain SPI'
* You have  access to TXE# and RXF# signals, so a proper HW handshake is possible  (claims 500kBytes/sec or 1MBytes/sec on the FT220X /  FT221X, tho it also claims up to 12MHz in on SCLK pin on both parts)
* There are commands to Read modem bits RTS and DTR & write status bits: DCD, RI, DSR, CTS, so some PC signaling is supported, outside the data link
* It can operate as a virtual COM port, which can simplify support.
* Multiple parts choices, in FS-USB and HS-USB speeds. ( I think FS-USB parts can SCLK to 12MHz and HS-USB parts can SCLK to ? 50MHz ) peaks.

[wb0gaz]

Thanks, PCB.Wiz...

Quick initial reading of AN206 --- "The FT220X is the slave device and the external FPGA/MCU is the bus master."

At first glance it looks like an promising solution, however, it may not match the existing requirement close enough --- the definition of MIOSIO likely precludes using the SPI hardware peripheral in the microcontroller, and "SCLK ..... may be up to 1MHz" suggests that a 4-bit-wide (nybble?)-banged interface might be required to get enough transfers per second.

The microcontroller I'm working with wouldn't have enough gas to bit (or nybble-)-bang the interface, as it's busy doing lots of other stuff. That was what made SPI attractive, that the application could just exchange the next byte once per interrupt and move on.

I appreciate your research and suggesting this kind of solution - FT1248 method may not solve this particular application, but knowing now that this exists, and possibly could be used with garden variety FT232 (I think, from reading this), makes for an interesting tool in the toolkit.

Thanks much,

Dave

[PCB.Wiz]

... and "SCLK ..... may be up to 1MHz" suggests that a 4-bit-wide (nybble?)-banged interface might be required to get enough transfers per second.

I don't see that AN206 or wording ?

Addit : found it as AN_206   - I think that is a typo, as the data sheet states differently for SCLK Period

The FT221X specs SCLK < 12MHz * (83.33ns), so they may be mangling the 1MBytes/sec limit, for 8b wide FT1248, which expects 8Mbit from the USB, and so you could not sustain > 1MHz in 8bit mode.

--- the definition of MIOSIO likely precludes using the SPI hardware peripheral in the microcontroller

You may need a SPI pin merge resistor and another pin for the status readback.  ie it would be SPI port + resistor + 1 pin.

I appreciate your research and suggesting this kind of solution - FT1248 method may not solve this particular application, but knowing now that this exists, and possibly could be used with garden variety FT232 (I think, from reading this), makes for an interesting tool in the
toolkit.

The FT232H / FT220X support FT1248, I think the ancient FT232 does not ?

* Addit: FT232H data is sparse on FT1248 Max MHz, but AN_167 says FT1248 CLK is good to 30MHz

[SiliconWizard]

From what I know, the FT1248 mode is associated with a specific protocol which precludes it from being a 'transparent' SPI link. You'd have to add a layer on top of your current protocol. Pretty annoying.

[wb0gaz]

I doubt FT1248 is going to help this particular application, however, I'm interested in playing with it at some point when time allows, as it's probably very small matter to accommodate the various requirements, and having a high bandwidth connection from very low-end microcontroller to a PC would be handy capability.

FT232RL seems to be the garden-variety part I have around here; question is whether the cheap-o break-out boards I have bring the needed control signals out to make up the interface, and of course whether it's in the FT1248 support space.

Interesting stuff indeed............

[westfw]

Many of the Arduino boards should be able to do it.  Something like a Seeeduino Xiao or Adafruit QT-Py would probably be great.

But you may be underestimating the difficulties in creating PC-side SW to interface to the SPI port.  AFAIK, there's no standard SPI driver, so you're faced with either writing a custom driver, or interfacing to your device over either some standard protocol (CDC.)  FTDI might already have something for their chips - drivers have always been an FTDI strength.