Discussion
For our hypothetical* chip for interfacing electronics to USB, yesterday I designed a pin for external devices to debug it. So what would want from such a debugging device?
This turns a slightly larger topic than I expected, so I'm just introducing it today.
I'd want to expose a terminal UI abstracting the raw protocol for humans to interact with, possibly via a higher-level tool like GDB abstracting it.
1/3?
*ATMEL AVR variant, which doesn't always need to run software.
I'd expose this terminal to a computer, claiming to be a RS232-adaptor. Or we might as well support plain RS232 as well, if anyone still uses it.
Or we could plug it into a wall outlet instead & have the debugger take over duties as a (limited) USB host, interacting with the HID devices itself. Namely keyboards, UTF-16 inputs, auxiliary displays, & braille teletypes.
And it'd now be appropriate to offer a tool for examining/creating USB HID data packets!
2/3
Finally I'd definitely want to examine the callstack, & any of its individual frames.
For this callstack to be legible our debugger would need to:
* Track where the stackframes begin & end in its own stack
* Decompress a symbol table to consult, from the debuggee's ROM
* Disassemble the machine code being executed.
* Build a decent Text-UI.
This is a non-trivial amount of software, but it should still fit in a processor like the one I'm designing it to debug!
3/3! Tomorrow: USB HID!
A space for Bonfire maintainers and contributors to communicate
