Personal-Data-Acquisition / stm32_sensor_module

A stm32 based sensor module controller.
MIT License
0 stars 1 forks source link

Update to the repo structure and usage of tests. #9

Closed jake-g00dwin closed 5 months ago

jake-g00dwin commented 6 months ago

Sets up a more sane repo layout by using git sub-modules instead of work spaces for now. Also comes with example rust integration tests.

jake-g00dwin commented 5 months ago

X86 compilation

I've changed the build target in the main repo back to the arm one, so we'll just have to manually pass if the target parameter for testing which I added info about in the README file.

Sub-modules The git sub-module lets us partition the code into sub-modules that each can be their own device agnostic repo. This means we can do sensor driver development separately as well as track issues/bugs for those repos instead of having one super giant repo that's flooded with issues that may not be related to the actual micro-controller's code at all.

This also lets us make and test changes to the git sub-modules code on the fly; unlike cargo's crates system we can edit the source code for git sub-modules in place; where as there isn't a good way to read/edit source code for external crates that are marked as dependencies.

EDIT:

So the previously I had set the build target to x86 because I figured it might make more sense to set the most commonly used build target as the default. Assuming we spent most our time developing and testing code instead of flashing production code.

for the old version we would have todo: cargo build --target thumbv7-eabi-none --bin blinky --release

But in exchange that meant we could use: cargo test inside the git sub-modules instead of cargo test --target x86_64-none-linux-gnu

so for the revised changes the second command will be what we use to run sub-module tests.

stackunderfl0w commented 5 months ago

Is there any particular reason you want to switch over to a structure with different modules being broken up into their own repos? I don't see any particular benefit, though I may be missing something. Each module interface should be simple enough to only need one or two files to implement, so having an entire repo for each seems to me to just be adding clutter.

jake-g00dwin commented 5 months ago

Going to cancel the PR, Instead going to include it like the other git dependencies