Discussion
Now that I've established a microcontroller debugging protocol & a terminal through which to interact with it... How'd we implement the firmware for its UI?
I'd specifically chose a terminal UI which tools like GDB (with minimal tweaks) understand, which necessitates a checksum, hex-parsing (cheap thanks to our swap-nibbles opcode!), & acks via "+". None of which should be needed with USB, which provides better alternatives I'd hardwire. But might as well!
1/4?
"c" for continue, "i" for running the next instruction, "D" for detach-debugger, "m" for read-memory, "M" for write-memory, "^" or "vCtrlC" for stop-execution, "z" for add-breakpoint, & "Z" for remove-breakpoint would have corresponding commands in our single-wire debugging protocol.
Include variants of "c" & "i" for injecting a CALLI opcode representing an interrupt, or to use a spare breakpoint to take effect at a certain address.
2/4?
With the memory commands I'd want notation for humans to differentiate data-memory from instruction-memory, perhaps just via their length? Whilst for GDB's sake I might pretend the 16bit-addressed data bus is in the 24bit-addressed instruction bus.
I'd also include "x" & "X" commands for other computers to transfer this data in binary, otherwise I'd use hex.
Furthermore I'd have "g", "G", "p", & "P" interface to the 1st 32bytes, where the CPU registers are.
3/4?
I'd include multiple types of breakpoints: "z1" breaks on executing an instruction, "z2" upon write, z3 upon read, & z4 upon read or write. Meanwhile I'd have "z0" overwrite the opcode with BREAK saving the old instruction to inject later. Now "D" needs to restore these.
I'd let hosts assemble opcodes to inject for filtering whether the breakpoint's reported, & what actions to take when its hit.
I don't think including an assembler ourselves is a priority.
4/5!
"R" would trigger interrupt #0, representing a reboot. Whilst "t" would inject opcodes which iterate over instruction memory from the PC, bitmasking opcodes looking for a certain result.
And I'd handle every CALL/RET to track the stackframes in our own stack. Upon which I'd build "f" to output this stack & "o" to skip over a function call.
With this interface, GDB pretty much as-is should be able to work with this debugger! Or I'll design a reimplementation later.
5/5 Fin for today!
A space for Bonfire maintainers and contributors to communicate
