Originally here: Self Bootloading Mod-Chip
Making this it’s own topic to live in though for those interested in the idea or applications of.
Has anyone discussed the idea of simply having the boot loader never release the interrupt table? I’m pretty sure you can do this with ONLY a modified boot loader - and zero support from applications themselves - they wouldn’t even be aware of the boot loader running silently in the background.
But the idea:
Basically the boot loader simply “proxies” all the interrupts to the sketch - instead of transferring the vector table to address 0 (as it typically done). Whatever interrupt Arduino already uses for timekeeping seems like the perfect “systick” interrupt. The bootloader could simply run its own internal code before jumping to the sketch’s own time keeping interrupt.
So essentially every 1ms or so the boot loader code would still be actually running… so any “hardware” functionality you wanted to build in could be be built on top of that. Such as checking for reboot keystrokes, etc… or even sleep/wake at the device level… and this code would live in the boot loader, not the application.
So one idea could be to keep the 4kb boot loader size but expand the functionality with something like this and a bit more “hardware” support… for things like volume, flashlight, boot logo, etc…
Yippy, so you can do it in theory. The boot loader is responsibility for moving the interrupts TO the boot loader (when it starts) and then as it fires up the application it moves the interrupts back into application space. So we’d simply NOT do that last step… and instead proxy them. So then regardless of how the application was compiled or with what libraries it could still have “hardware level” features like flashlight, boot logo, reboot keystrokes, etc… it would be purely a feature of the boot loader.
If an application REALLY REALLY wanted to disable the hardware functionality, they just could relocate interrupts purely to user space themselves, but I don’t know why most people would do that?
This approach would work fine regardless of boot loader size… ie you could do it with a 3kb boot loader too, just with 4kb you’d have more room for hardware functionality I’d think.
Of course it’s all a bit theoretical UNLESS/UNTIL we build new hardware - since it would require a custom boot loader - and AFAIK there isn’t a super easy way to refresh the Arduboy’s bootloader now. So it might be something that only worked on say generation 2 devices.
But when you do that the advantage is: it all “just works”. You have 200 old Arduboy games that know NOTHING about a pause button or sleep/wake… or the “reboot key sequence”… and yet they all would magically support these new features - without needing to be recompiled.