Electronic – Are any USB-to-SPI *slave* bridge chips readily available

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.