dht-multi-hals example and Cargo.toml, etc, changes to run with different MCUs

[pdgilbert]

This example (examples/dht-multi-hals.rs) has setup() functions so it can run with different HALs and MCUs. Building and running is explained in comments in the file. The changes to Cargo.toml,.cargo/config, and the addition of directory memoryMaps and file build.rs are all to support running with different MCUs.

The root file memory.x is moved to directory memoryMaps/STM32F042/. This makes it necessary to specify a feature to find a memory.x file. For example

cargo build --features stm32f042
cargo build --target thumbv6m-none-eabi  --features stm32f042 --example stm32f042  --release 

That was not needed when memory.x was in the root.

[michaelbeaumont]

Thanks so much for the PR and all the examples, @pdgilbert! I love having them but I don't think they and the linker scripts and dependencies fit in this repo, which I'd like to keep as lean as possible. In fact, I think the current .cargo/config, memory.x, nucleo.cfg and openocd.gdb can probably be removed too.

However, if you want to maintain the examples in another repo (I think separate source files per mcu is more readable), we can put a link from README.md to it/the examples, what do you think?

[pdgilbert]

Ok, I understand wanting it mean and lean. One advantage of examples is that they also provide an integration test, but there is overhead. I'll just leave it in my fork and you could point to it there if you like. I will also run it with examples at https://pdgilbert.github.io/eg_stm_hal/, put the hope there is to have stable crates to check recent hal changes. Most users would probably prefer the examples that run with released hals.

More immediately, I cannot figure out how to cancel the pull request, and so you are unnecessarily running all my attempts to learn workflows.

[pdgilbert]

I think I see how to cancel the pull request.

[michaelbeaumont]

No worries, Github covers running the workflows 😃 thanks again for the PR!