Depending on how you might want to use the GPIO pins, this is a clear yes, or no... Traditionally, GPIO is somehow a strange beast when integrated as tightly on

Depending on how you might want to use the GPIO pins, this is a clear yes, or no... Traditionally, GPIO is somehow a strange beast when integrated as tightly on SOCs like the Broadcom on the Raspberrypi. On one side, it's a pretty dumb interface: You put a bit in a memory address and the output changes state. No fancy logic, everything done in software. On the other hand, it's very tightly integrated on the CPU, so you have a very fast path to toggling them. If you really need this tight integration because you want to trigger interrupts from an external source, or want to bit-bang a non-standard serial protocol, you'll have little luck: The USB latency will make it orders of magnitude slower than "native GPIO." and the better solution will be to directly hard-code parts of the logic into the external microprocessor, and speak to this special purpose hardware. If you are only interested in turning on- or off a few lights, one of the popular GPIO expanders via i2c will be cheaper and probably just as slow :-). But: A huge strength of this project would be if the i2c-over-usb and spi-over-usb ports get decent native support in-kernel-support in Linux, because that's where you can get pretty decent performance with the well-defined protocols. That's something that would fill a huge gap in available products, both for the PC and the 'pi. {I've tried to get something running on a special-purpose CH340(?) uart/i2c/spi-to-USB bridge, but unfortunately the two latter modes are severly underdocumented...}