>dive under the table every three minutes to hit the reset button

Hah, I feel that pain. Currently hacking some bare-metal Zig on PinePhone, and on top of the USB reconnect power cycle, I am transferring an SD card back n forth. I wonder if I'll be making a similar post in 30 years time.

Anyway, well done, and I look forward to browsing the code for some inspiration. Thanks for making it PD.

▲

jacquesm 5 hours ago | parent [-]

Oh good luck, I really feel your pain :) Consider using an emulator until you're really ready to go to hardware that might save you a lot of time and headache, it also makes observability a lot better. Nothing beats having access to memory from a debugger.

▲

whitehexagon 2 hours ago | parent [-]

Thank-you for the advice. So far it has been mostly SoC stuff, and I recently got side-tracked learning some armv8 assembly, which reminds me somewhat of my 68000 days and has been good fun.

I did try QEMU for the first time last week, but started thinking I'd need some way to mock out all the hardware, and I only got as far as UART. But now that you mention it I'll take another look. There is a lot of multi-core mbox? IRQ stuff I'm about to tackle next, and I dont see why I cant develop all of that independent of the hardware.

I seem to be learning the hard way. I spent the first 12 months debugging via the only thing I could get working, an onboard RGB LED.

	▲	jacquesm an hour ago \| parent [-]
		Multi-core is a level of complexity that I have no experience with, there were some i386 / i486 multi-cpu boards but I don't remember every having one of those. We did have a very early dual CPU pentium, but by that time the OS was already mothballed and we had standardized on Linux.