6
\$\begingroup\$

I would like to interface a battery-powered device to USB, without requiring users to install drivers. Data transfer requirements are moderate, so the ~60kbytes/sec of HID mode would be fine, but I don't want to be much slower than that. The main processor is probably going to be powered by batteries even when a USB cable is plugged in, so I would like to have that processor sleep any time the PC is not actively communicating.

I've been considering using a USB-to-serial bridge, but the ones I've seen would with most microcontrollers require the data rate to be slow enough to accommodate the worst-case serial-port-interrupt response time. Further, while all of the ones I've seen allow a controller to indicate whether it's ready to receive data, none have any means of asking an "unready" controller to get ready. All the USB-to-SPI bridge chips I've seen are limited to acting as SPI masters, which would make things even worse for any microcontroller connected to them.

A USB interface which acted as an SPI slave with an interrupt pin would seem ideal, since it could communicate very quickly when the main processor wanted to communicate, and could tell the main processor when it needed attention, but wouldn't lose data even if the PC were to send it just as the main processor was wanting to go to sleep (the interrupt would trigger a wakeup within a 100 microseconds or so, whereupon the controller could ask what happened and then receive data). Unlike USB-to-serial or USB-to-SPI-master bridges, which need non-volatile configuration storage, a USB-to-SPI-slave bridge could be configured by the SPI master to which it is connected, possibly reducing silicon requirements.

It should, if nothing else, be possible to use a cheap USB-compatible microcontroller and program it to act as a bridge; if someone has done such a thing and released it as open-source, I'd just as soon use that as re-implement it. It might be possible to use a UART instead of SPI if the device supported handshaking and had a pin which would indicate when it had data to send (even when held off); such an approach might be necessary when using a microcontroller as the bridge, since most microcontrollers make lousy SPI slaves. On the other hand, if such a thing is available as an inexpensive off-the-shelf part, that would seem easier than having to buy microcontroller chips and then program them. Does anyone have any recommendations?

Addendum

I should perhaps have clarified that I'm trying to find something really cheap, and am evaluating the possibilities of either using a main controller with integrated USB versus using some sort of bridge. Using a bridge may allow the use of a cheaper main processor than would otherwise be required, and may simplify power supply design (since the bridge could be USB powered without having to ensure that the processor would receive power from the +5V USB rather than the +6V battery when both supplies were available); even if bridge+CPU ends up being a dime or two more than a USB-capable main CPU, separation of the USB from the other CPU functions could still end up being a "win".

Of the designs I've built so far, my favorite used an FT245 in combination with a CPLD located in a keyboard/display/USB board which communicated to the main board via 3-wire SPI-style interface (two wires from the main board; one wire going back). When the clock and data were both in the idle state, the CPLD would use the data return to indicate when the main CPU needed to service it (because a button was pushed, data arrived on the USB, the USB was plugged/unplugged, etc.) The main CPU could then, at its relative leisure, wake up, ask the CPLD what exactly it wanted, and do whatever needed to be done. I really liked that style of communication, but the FT245 and CPLD together cost too much. Further, being able to use HID rather than CDC could improve the end customer experience.

Conceptually, it would seem that a chip that was designed to serve as a bridge between USB and a CPU that was designed to talk to it could be electrically simpler and cheaper than the USB-to-other-things interfaces I've seen since it wouldn't need any sort of non-volatile configuration storage and wouldn't require very many configuration options--mainly enables for the various endpoints, possibly some timeouts, and a memory for data to feed the host on the control endpoint. Most other logic would be handled by the connected processor. Unfortunately, I don't know of any such devices that are actually for sale.

\$\endgroup\$
  • \$\begingroup\$ Maybe the FT232H USB to multi-protocol serial chip, can do what you want. \$\endgroup\$ – Gerben Jun 19 '14 at 10:42
  • \$\begingroup\$ Maxim Integrated offers MAX3421E USB serial interface engine, controlled through an external microcontroller's SPI port. Buy or sample MAX3421EEHJ+ direct from manufacturer: maximintegrated.com/en/products/interface/controllers-expanders/… Evaluation kit and Application Notes available. ( Disclosure : I work at Maxim. This is an older part I think we're not actively promoting, but it's still available. You mention using HID device driver, see app notes 3936 and 3937.) Hope this helps. \$\endgroup\$ – MarkU Jul 31 '14 at 8:46
  • 1
    \$\begingroup\$ Most any USB-enabled microcontroller could do this, at least to the degree to which it can be done at all. While micros tend to "be happier" acting as SPI masters, most can be slaves too. \$\endgroup\$ – Chris Stratton Oct 6 '14 at 15:39
  • \$\begingroup\$ Would something like Atmega8U2/16U2 be too expensive? \$\endgroup\$ – Dmitry Grigoryev Jul 2 '18 at 13:26
1
\$\begingroup\$

FTDI USB to Serial converter followed my a MCU in SPI slave mode.

Firmware would simply transfer data between the SPI in port to the Tx line to be sent via the FTDI to the USB port.

Similarly firmware would cache Rx data from the USB/serial port and place in the SPI Tx buffer waiting to be read back.

Two IC simply solution to achieve USB to SPI slave.

\$\endgroup\$
  • \$\begingroup\$ Do you know any controllers with a decent SPI slave mode? All of the ones I've seen would require the SPI byte rate to be set slow enough that the time between bytes will always exceeds the longest time the controller might need to devote (uninterrupted) to some other task. \$\endgroup\$ – supercat Sep 8 '14 at 14:08
  • \$\begingroup\$ which ones have you looked at? No speed limitations with PIC's as far as I am aware. You get an interrupt when there is data received complete, copy the value from the buffer and clear the interrupt, job done. Then your main loop can parse if required, prepare response if required, or squirt the data up stream to the FTDI which will pipe it over a USB/serial tunnel. Opposite for downstream data, main difference is when you receieve data from the PC, you may need to store it in a buffer waiting for the SPI master to extract the data. \$\endgroup\$ – smashtastic Sep 30 '14 at 19:11
1
\$\begingroup\$

I think, from a cost and board space point of view, a USB-capable uC (e.g. the ATTiny85) would be the best approach. You could customize it to whatever protocol you want your main CPU to see, it comes with a few hundred bytes of RAM to buffer while the wake-up interrupt is processed, and it's a SOP-8 that costs literally a few cents.

\$\endgroup\$
  • 1
    \$\begingroup\$ ATTiny85 is not USB capable. \$\endgroup\$ – dim Jul 2 '18 at 13:24
  • \$\begingroup\$ @dim you're right, sorry.. i completely forgot that these tiny modules are actually a two-chip solution with a separate USB transceiver. \$\endgroup\$ – WooShell Jul 4 '18 at 9:30
0
\$\begingroup\$

This FTDI chip works as an I2C slave, and seems to be relatively cheap:

http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT200XD.pdf

And this one works as an SPI slave:

http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT220X.pdf

\$\endgroup\$
  • \$\begingroup\$ I believe the FT220X requires their royalty-free drivers and doesn't act as a HID. \$\endgroup\$ – rkagerer Aug 11 at 14:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.