... 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.
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.
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?
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.
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?
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?
... 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...
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.
...
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.
... 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've got a plan (FT4222) and will report back should that not pan out as expected.
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 ...
... 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 definition of MIOSIO likely precludes using the SPI hardware peripheral in the microcontroller
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.