Sorry, running from memory on dusty neurons. I'd consider the 6805 to be a 6800, though yes, more than 1 MHz. It's no 6809, anyway. And the SE uses an early PIC, if I recall. But man, the 8041 really got around, didn't it?
I think the concern was actually more the USB interfering with the ADB; his problem was that the crappy USB stack from Microchip ate up 50 us at interrupt time, which is more than enough to completely destroy ADB timing. If you're running the ADB off of timers (for both send and receive), you should be able to make it work much better, especially if you put the timer interrupts at a higher priority than the USB interrupt (and especially if you just DMA the USB data and process it at non-interrupt time, since it's much less time critical).
If you're running the ADB off of timers (for both send and receive), you should be able to make it work much better, especially if you put the timer interrupts at a higher priority than the USB interrupt (and especially if you just DMA the USB data and process it at non-interrupt time, since it's much less time critical).
Right, that's pretty much exactly what I hope to do. And from my cursory look at the USB interrupt handler, it doesn't do very much at interrupt time. For a USB transfer finished interrupt, it marks the transfer as complete in some data structure, which is later polled or generates an event at non-interrupt time. Then it begins transmission of the next packet in the frame (if any). For the 1ms timer interrupt, it generates the USB SOF packet, then begins transmission of the first request packet. Actual data transmission is handled by DMA and the hardware USB peripheral.
As for the PIC32, yeah, so far the tools haven't been great. But the big thing going for it is that it's the only mcu I've found that supports USB Host (not just USB Device) and has hub support in the USB stack, which is required for simultaneous keyboard and mouse. And it has working examples of reading multiple HID devices simultaneously through a hub, which I've already tried successfully. I'm willing to put up with a lot of hassle in exchange for that. I gather that any mcu with USB Host support could technically support hubs, and cascaded hubs. But I'm a complete newbie at USB, so I'm really hoping to avoid having to modify anybody's USB stack to add hub support, or (shudder) writing my own.
Wow, input capture. I'd never even heard of this concept before! It looks like I have a 4-deep capture FIFO to play with, and can configure it to capture only rising edges, only falling, or both. Capturing only falling edges and with the 4-deep FIFO, there should only be an interrupt once every 400 microseconds during receipt of an ADB transmission. That's not so bad...
Edit: actually it looks like the input capture module can be chained to the DMA module to capture long input sequences without running any code. This would be perfect for a passive ADB sniffer, but for a real ADB device it still needs code to execute immediately after receipt of the first ADB stop bit. This code needs to decide whether to take over the bus and send a response, or to pull the bus low briefly (ADB's service request signal), or to do nothing. So in practice I don't think I can use the DMA.
Maybe not for everything. I think you need to be judicious in how you use it; you probably want to do something more along these lines:
1) Set up the capture unit for interrupt use. Wait for the interrupt; the capture should tell you whether it was ~800 us (Attention) or more (an error, or Reset if >3ms).
2) Set up the DMA unit to capture pulses (not sure if low pulses or both edges would be good). Set the DMA to capture 8 bits' worth before interrupting.
3) Handle the incoming command preparation (data marshalling, etc.) while the stop bit is processing. If you need to do a Service Request, do it now.
You could probably do this at interrupt time instead, though, bit-by-bit (use a state machine, you'll thank yourself later). Interrupt service time on an ARM Cortex-M devices is pretty quick, not sure what it is on the MIPS core that PIC32 uses.