the `bind_interrupts` macro creates a `struct` for the interrupts. it
was so far not possible to document those (except for STM32) and there
was no generic documentation being generated/added either, thus the
`missing_docs` lint was triggered for consumers which enabled it.
with this change it is now possible to manually add a comment on the
`struct` being defined in the macro invocation.
to show that this works one RP example has been modified accordingly.
rp235x firmwares need an Image Definition if they want to be called
from the rp235x bootrom.
Currently this Image Definition is manually added to each project/example,
but for most users it will always be the default (Secure Exe).
This commit adds crate features to allow users to configure this, with the
default of including a Secure Exe Image Definition in.
Just like the boot2-* features, this includes an opt-out (imagedef-none)
to allow the user to not make use of this included Image Definition.
The 2350 doesn't have a boot2 like the 2040, but it does have the
concept of a xip setup function that could be customized. By default the
bootrom searches for the attached flash chip and provides an xip setup
func at the base of the bootram. That bootram is not executable, so it
still needs to be copied to ram like boot2 would be.
Currently does not use inline assembly.
Also switch to picotool, as elf2uf2 has not been patched to support the
2350.
Many thanks to @thejpster for his work on the rom_data!
Working around boot2 is currently a bit hacky for the rp235x, that will
improve in upcoming rp235x flash pr.
this lets us treat pins and the temperature sensor uniformly using the
same interface. uniformity in turn lets us add more adc features without
combinatorial explosion of methods and types needed to handle them all.
this removed the RelocatedProgram construction step from pio uses.
there's not all that much to be said for the extra step because the
origin can be set on the input program itself, and the remaining
information exposed by RelocatedProgram can be exposed from
LoadedProgram instead (even though it's already available on the pio_asm
programs, albeit perhaps less convenient). we do lose access to the
relocated instruction iterator, but we also cannot think of anything
this iterator would actually be useful for outside of program loading.
using these will require some linker script intervention. setting the
core0 stack needs linker intervention anyway (to provide _stack_start),
having it also provide _stack_end for the guard to use is not that much
of a stretch.
