Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo integration #2

Open
mbr opened this issue Sep 24, 2016 · 0 comments
Open

Cargo integration #2

mbr opened this issue Sep 24, 2016 · 0 comments

Comments

@mbr
Copy link
Member

mbr commented Sep 24, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant