You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
that is it includes the following functionality (rightfully) not included in cargo:
Building with the "correct" target platform
Dumping binary and disassembly from the ELF output
Upload to the device
Additionally, I still have to create the following .cargo/config file in each crate root:
[build]
target = "cortex-m3"
The configuration file can be dropped once xargo has built the necessary libcore (deceptive, because you only run into that issue when starting a new project from scratch), but I have not found a way to omit it yet.
All this leads me to consider creating a cargo embedded subcommand (we might consider embed or em as well) that takes care of some of these things at least. It might be useful to introduce a custom configuration section inside Cargo.toml to avoid duplication of some information like the flash's starting address, but it might be more elegant to parse the linker script or resulting ELF binary to find it out. A tool like this could also help in storing/generating the files from #1.
The text was updated successfully, but these errors were encountered:
Right now, most of my projects use a Makefile that looks about like this:
that is it includes the following functionality (rightfully) not included in cargo:
Additionally, I still have to create the following
.cargo/config
file in each crate root:The configuration file can be dropped once xargo has built the necessary libcore (deceptive, because you only run into that issue when starting a new project from scratch), but I have not found a way to omit it yet.
All this leads me to consider creating a
cargo embedded
subcommand (we might considerembed
orem
as well) that takes care of some of these things at least. It might be useful to introduce a custom configuration section insideCargo.toml
to avoid duplication of some information like the flash's starting address, but it might be more elegant to parse the linker script or resulting ELF binary to find it out. A tool like this could also help in storing/generating the files from #1.The text was updated successfully, but these errors were encountered: