Need suggestion for USB SPI adapter that can work as full duplex SPI slave - Page 1
Forum section: electronics / general

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 16, 2022, 02:24:50 pm
content: 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!

author: RoGeorge
author_rank: Super Contributor
timestamp: January 16, 2022, 02:50:50 pm
content: 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.

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 16, 2022, 03:03:11 pm
content: 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.

author: mon2
author_rank: Frequent Contributor
timestamp: January 16, 2022, 03:40:52 pm
content: Maybe TotalPhase has a suitable tool ?https://www.totalphase.com/products/aardvark-i2cspi/

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 16, 2022, 03:50:54 pm
content: 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.

author: Foxxz
author_rank: Regular Contributor
timestamp: January 16, 2022, 05:07:28 pm
content: The FT2232H can do synchronous SPI bus work over USB

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 16, 2022, 05:10:18 pm
content: Quote from: Foxxz on January 16, 2022, 05:07:28 pmYep. And unless you really need 2 channels, you can use the FT232H instead, which is definitely cheaper.

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 16, 2022, 05:16:21 pm
content: 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 16, 2022, 05:23:58 pm
content: 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?

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 16, 2022, 05:48:55 pm
content: 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

author: Foxxz
author_rank: Regular Contributor
timestamp: January 16, 2022, 06:29:00 pm
content: Quote from: wb0gaz on January 16, 2022, 05:16:21 pmAhh I missed that. The FT4222H claims it can be synchronous in slave mode

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 16, 2022, 06:36:03 pm
content: 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.

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 16, 2022, 06:48:42 pm
content: 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#p810290I'm now digging in to the datasheet for the FT4222H...

author: RoGeorge
author_rank: Super Contributor
timestamp: January 16, 2022, 06:53:51 pm
content: Quote from: wb0gaz on January 16, 2022, 05:48:55 pmSeems that Raspberry Pi doesn't really work in SPI slave mode, sorry.http://offis.github.io/raspi-directhw/group__spisl.htmlhttps://forums.raspberrypi.com/viewtopic.php?t=230392https://sigmdel.ca/michel/ha/rpi/spi_on_pi_en.html

author: PCB.Wiz
author_rank: Super Contributor
timestamp: January 16, 2022, 06:56:49 pm
content: Quote from: wb0gaz on January 16, 2022, 02:24:50 pmThe 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

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 16, 2022, 07:17:19 pm
content: 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: January 16, 2022, 07:28:51 pm
content: Quote from: wb0gaz on January 16, 2022, 07:17:19 pmThe 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

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 16, 2022, 08:09:11 pm
content: 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

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 16, 2022, 10:40:25 pm
content: 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).

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 16, 2022, 11:58:11 pm
content: Quote from: wb0gaz on January 16, 2022, 08:09:11 pmI 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.

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 17, 2022, 01:32:59 am
content: 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

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 17, 2022, 08:23:33 am
content: 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'sTSPISlave(LC, 3.x) orSPISlave_T4(4.x) libraries. (These can all do 8 Mbit/s or 1 Mbyte/s over USB Serial interface, using the ArduinoSerial.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).

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 17, 2022, 02:15:48 pm
content: 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

author: NorthGuy
author_rank: Super Contributor
timestamp: January 17, 2022, 02:55:54 pm
content: Quote from: wb0gaz on January 17, 2022, 02:15:48 pmDoesn't have to be ARM. Any MCU family you're familiar with should have something with USB.

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 17, 2022, 03:11:46 pm
content: 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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 17, 2022, 03:45:41 pm
content: Quote from: NorthGuy on January 17, 2022, 02:55:54 pmYup.Iwould 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.

author: nctnico
author_rank: Super Contributor
timestamp: January 17, 2022, 10:15:49 pm
content: Quote from: wb0gaz on January 17, 2022, 03:11:46 pmThe 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.

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 17, 2022, 10:20:10 pm
content: 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?

author: nctnico
author_rank: Super Contributor
timestamp: January 17, 2022, 10:38:09 pm
content: Quote from: wb0gaz on January 17, 2022, 10:20:10 pmYes, 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.

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 17, 2022, 11:51:15 pm
content: 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

author: NorthGuy
author_rank: Super Contributor
timestamp: January 18, 2022, 12:12:22 am
content: 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?

author: nctnico
author_rank: Super Contributor
timestamp: January 18, 2022, 12:33:20 am
content: Quote from: wb0gaz on January 17, 2022, 11:51:15 pmVirtual 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.

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 18, 2022, 02:00:11 am
content: 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: January 18, 2022, 02:02:47 am
content: Quote from: wb0gaz on January 17, 2022, 10:20:10 pmThere 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 clockyouprovide 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 notimpossible, 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 ?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: January 18, 2022, 02:08:37 am
content: Quote from: NorthGuy on January 18, 2022, 12:12:22 am... or even change it to 3MBd UART interface ?

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 18, 2022, 02:19:03 am
content: 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.

author: MarkF
author_rank: Super Contributor
timestamp: January 18, 2022, 03:16:27 am
content: 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.phpIt 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: January 18, 2022, 03:17:53 am
content: Quote from: wb0gaz on January 18, 2022, 02:19:03 am16X 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 ?

author: NorthGuy
author_rank: Super Contributor
timestamp: January 18, 2022, 05:41:18 am
content: Quote from: wb0gaz on January 18, 2022, 02:19:03 amDirect 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.

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 18, 2022, 06:15:56 am
content: 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 ...

author: voltsandjolts
author_rank: Unknown
timestamp: January 18, 2022, 09:37:41 am
content: Quote from: NorthGuy on January 18, 2022, 05:41:18 amAgreed, 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 18, 2022, 06:00:07 pm
content: Quote from: wb0gaz on January 18, 2022, 06:15:56 amI 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: January 18, 2022, 06:44:01 pm
content: Quote from: wb0gaz on January 18, 2022, 06:15:56 amSounds good, just check you have a rev D device, for the testing. Sometimes Eval Boards can sit on the shelf longer...

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 18, 2022, 08:23:05 pm
content: 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: January 18, 2022, 09:27:37 pm
content: Quote from: wb0gaz on January 18, 2022, 06:15:56 amYes, the FT4222H would be my first Plan A. Looking at the order codes, it looks like UMFT4222EV-DmeansDrev 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.

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 18, 2022, 10:06:49 pm
content: 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

author: PCB.Wiz
author_rank: Super Contributor
timestamp: January 18, 2022, 10:44:29 pm
content: Quote from: wb0gaz on January 18, 2022, 10:06:49 pmI 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 forSCLK PeriodThe 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 > 1MHzin 8bit mode.Quote from: wb0gaz on January 18, 2022, 10:06:49 pmYou may need a SPI pin merge resistor and another pin for the status readback. ie it would be SPI port + resistor + 1 pin.Quote from: wb0gaz on January 18, 2022, 10:06:49 pmThe 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 18, 2022, 11:07:07 pm
content: 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.

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 18, 2022, 11:16:22 pm
content: 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............

author: westfw
author_rank: Super Contributor
timestamp: January 19, 2022, 12:55:26 am
content: 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.

author: wb0gaz
author_rank: Frequent Contributor
timestamp: January 19, 2022, 01:27:05 am
content: For the FT4222, there are drivers (PC-side), library and demo application, so there's a starting point there (the demo application seems very simple, and perhaps can be adapted, or at least provide some proof of concept.)That's the environment I'm starting with, because it's got more of the needed elements defined than anything else that's been mentioned so far.Tks,Dave