JoNil
commented
1 year ago Next time i play around with a pico i can test and merge this, not doing any such project currently. Will leave this open until then
Open alexferro opened 2 years ago
JoNil
commented
1 year ago Next time i play around with a pico i can test and merge this, not doing any such project currently. Will leave this open until then
This is motivated by my usecase, wherein I have a tool that needs to convert elf to uf2, but does not want to call an external tool. I figured that while I could just vendor the changed code, I'd try improving it and upstream it, in the event there is anybody else who might benefit.
The main logic is unchanged, but I've factored the elf2uf2 function out of main.rs and into lib.rs, as well as its dependencies. Additionally, I have changed elf2uf2 such that the rp2040 is not hardcoded within the function. While my application is for the RP2040 as well, I wanted to leave the code being more general and able to support other families. This all necessitated not only changing elf2uf2 and downstream functions to not use the global options struct, but elf2uf2 now takes two closures to determine chip and usecase specific logic. The binary that was the original form of this crate still exists, and is still the same tool, specialized for RP2040 use.
To support this split crate, a default, "binary" feature is provided that enables all the features needed to make a usable binary. However, with "default-features = false", this only requires the minimal set of libraries.
At the current time, this library assumes that the ELF MUST be an ARM32 Little Endian binary, that does not use hard float. I'm not sure why the No Hard Float requirement exists in elf.rs, but I've left it alone in case it's important. However, I suspect that it should be removed (or put in the provided closure), for broader compatibility with other targets.
Additionally, as I understand it, having a single crate with both a (non-trivial) binary, as well as the library backing it is not recommended, due to needing to play the games with cargo features. However, as splitting into two crates is a greater logistical challenge, I have not done that here. My testing shows the dependency graph is appropriately pruned by not including the default features.