Right now, most of my projects use a Makefile that looks about like this:
PROGRAM=dmxblinky
TARGET=cortex-m3
TARGET_ARCH=arm-none-eabi
START_ADDR=0x8000000
# values below rarely need to be changed
ELF=target/${TARGET}/release/${PROGRAM}
OBJCOPY=${TARGET_ARCH}-objcopy
OBJDUMP=${TARGET_ARCH}-objdump
BIN=${PROGRAM}.bin
DAS=${PROGRAM}.das
SYMS=${PROGRAM}.symbols.txt
all: $(BIN) $(DAS) $(SYMS)
${BIN}: ${ELF}
${OBJCOPY} -Obinary $< $@
$(ELF):
xargo build --release --target=${TARGET}
$(DAS): ${ELF}
${OBJDUMP} -m arm -d $< > $@
$(SYMS): ${ELF}
readelf --symbols $< > $@
upload: ${BIN}
st-flash --reset write $< $(START_ADDR)
clean:
xargo clean
.PHONY: $(ELF) $(DAS) $(SYMS) $(BIN) clean all
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.
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/configfile 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 embeddedsubcommand (we might considerembedoremas well) that takes care of some of these things at least. It might be useful to introduce a custom configuration section insideCargo.tomlto 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.