@Plecra it’ss possible that avr-Hal already handles that (or they rely on what GCC wrote)
however, it could do something similar to what the ruduino crate does now: inspect the target processor, then generate that code at runtime and compile it in
Although, my code is kind of a special case for when you want to write all the device code without any C
Ayke
@aykevl
Also just a note that http://packs.download.atmel.com/ exists, where you can download interrupt vectors (and much, much more) in machine readable format. I use it in TinyGo to generate register access packages, interrupt vector code and linker script fragments for setting the memory size.
I haven't seen it often so just mention it again so people are aware that it exists.
Gregor
@Gregoor
Heya, I have a bit of a beginner question that I had no success googling: When learning new things I like having a tight feedback loop, mostly achieved by printing all kinds of information at runtime. Is that a thing when doing microcontroller development? Or alternatively, what does your workflow look like?
Ben Schattinger
@lights0123
@aykevl that's what @Rahix's avr-device uses that powers avr-hal
Jonah Dahlquist
@jonahbron
@Gregoor Yes definitely. If you've got a serial connection you can print to it as much as you want, and monitor it with screen
Rahix
@Rahix
aykevl: We talked at 34C3 a bit about those ATDF files and even if it's a bit late, I've created the converter for them: https://github.com/Rahix/atdf2svd
shepmaster: avr-device currently relies on avr-libc but I want to get rid of that at some point and ship a completely custom runtime
Your work looks like a great starting point for that :)