Post
As I've been methodically designing my own (hypothetical) USB implementation, I designed a handful of microcontrollers to power your peripherals.
USB hubs deserve their own chip, which detail more than echoing the signals as they move towards or away from the "host" computer. And as of the 20'00s with USB2 they include circuits the host can invoke to automate acknowledgements for slower busses.
Plus there'd be circuits exposing an API to query & manipulate the hub's state.
1/4?
Plenty of USB peripherals can be powered by little, if any, code. So I designed a slight variant of ATMEGA AVR microcontrollers which can expose the address-space (including memory-mapped I/O) to USB1. I'd include the data-ROM in this address-space so it can hold metadata for the host should handle its packets.
I'd offer hardware (powered by the same microcontroller!) for interfacing to this chip's programming & debugging pins. As well as software to prepare its metadata and/or code.
2/4?
The (optional) processor within that microcontroller would focus on manipulating bits & ints. With the ints typically being bound for DACs, ADCs, or counters/timers. It'd be a 8bit machine with 16bit data addresses & separate 24bit code addresses. Each opcode would be 16bit, occasionally 32.
When I turned my attention to (solid state) harddrives I determined that I'd need higher bandwidth & more RAM but not as much compute. A combined flipflop & shift register would be enough of an ALU!
3/4!
Some peripherals however (like optical mice or touchscreens/touchpads) require a fancier microcontroller which can extract the useful info from large amounts of raw sensor data.
So I designed a "Digital Signal Processor" including circuitry for iterating over RAM & a decent grid of floating-point multiply-adders. With I/O happening concurrently.
It'd decompress its USB metadata into a certain memory bank, so it can use certain bits from SETUP packets as a memory address.
4/5!!
The catch is that internally I designed this as a Very-Long-Instruction-Word processor, and as such its machine code would be quite verbose & unstable. So I'd abstract it behind your choice of firmware.
Implementing an interpreter upon that should be quite fast with little effort *as long as* the opcodes are quite high level! We could give them a syntax closely resembling Julia.
With a variant of that interpreter which bundles a virtual debugger.
Or we could merge together RISC-V opcodes.
5/5
Install bonfire.cafe
Get the full app experience
