MCU examples

[pdgilbert]

(I merged my fork's examples-testing branch into my master branch, but the suggestion seems to be to do the PR with the topic branch?)

This PR has example code that runs on multiple MCUs. Documentation is mainly in comments in examples/lora_spi_send.rs. To support linking, the directory memoryMaps has been added. It has memory.x files for several MCUs. The build.rs, run by cargo, selects the memory.x based on the feature identifying the MCU. The workflow changes (.github/workflow/rust.yml) test the build successfully for several MCUs.

I have also tested the examples running on a bluepill (stm32f103) and blackpill (stm32f411) using an RFM95 style radio board and a GPS board with ublox chip. Issues are

• the code must be compiled --release for the bluepill or it is too large for memory.
• all examples work with --release on bluepill but thehprintln of the received message in lora_spi_receive prints the received message twice.
• with blackpill (stm32f411) the code compiles and runs in both dev and release modes with the double printing of received messages as above. In addition, lora_spi_receive in release mode prints many "poll error Aborted" messages but otherwise works.

I will eventually test other configurations but may first improve the handling of errors so that is is easier to distinguish hardware errors from code problems. (For above boards I have relatively stable setups with jumper wires directly to pins soldered on the boards. For others I am working with breadboards and more loose wire issues.)

The Cargo.toml section [patch.crates-io] has a reference togithub.com/ryankurte/rust-radio.git. I'm not sure if this is something that can/should be changed to a release repository somewhere?

[ryankurte]

nice work!

(I merged my fork's examples-testing branch into my master branch, but the suggestion seems to be to do the PR with the topic branch?)

usually yeah, but it really doesn't make any difference. is it possible to squash these commits for the PR so it's a little less large? then i'll have a review of it all / check out some of the issues.

The Cargo.toml section [patch.crates-io] has a reference to github.com/ryankurte/rust-radio.git. I'm not sure if this is something that can/should be changed to a release repository somewhere?

this should be able to use radio-hal@0.8,1 directly now i think, it wasn't published for a little while for reasons that escape me.

[pdgilbert]

Ok, I'm treading in new territory again.

• I think when you say "is it possible" you are suggesting I do the squash rather than asking if you can do it when you do the merge. Right?
• Since I've done a PR does that amount to having pushed a branch to upstream? That seems to affect what sort of squash I can do?
• Is it easier if I cancel the PR and do the squash first?
• Would there be any advantage to squashing on my master vs example-testing branch? (They are merged at this point.)

BTW, the unsuccessful workflow has to do with libusb which I think is already failing in your master. I had libusb commented out in Cargo.toml because I didn't use it with no_std.

[ryankurte]

Ok, I'm treading in new territory again. ...

yeah, ahead of time, you can always overwrite things so in this instance (on your master branch, assuming you have the rust-iot/... repo as a remote called upstream) you should be able to:

• git rebase -i upstream/master to start a rebase, then follow the instructions to rebase, pick the first commit and squash the rest
• git push --force to update the branch to the new rebased commits

there will be some unfortunate conflicts to deal with along the way, but at the end you should have one commit with all the changes in

BTW, the unsuccessful workflow has to do with libusb which I think is already failing in your master. I had libusb commented out in Cargo.toml because I didn't use it with no_std.

ohh, yeah this is inexplicably (and unreliably) cursed on the actions workers and i haven't worked out why yet :-/

[pdgilbert]

I did the rebase/squash and push. The rebase/squash was pretty ugly, probably because of the steps I went through on my fork. (When I decided I needed to go back to e-h-0.2.4 to get examples working again I was already on a detached head, so I made a new branch from the earlier point and then merged my original work on my fork, then merged master. ) The rebase had conflicts all the way back to the detached head. It would have been easier just to start a new branch and copy over all the changed files.

Anyway, I'm down to two commits. One is the result of the the rebase/squash/conflict resolution and the second is the cleanup of some bad conflict resolution. The second also has a better commit message, since the first got clobbered by some of the conflict resolution.

I pushed the second to my fork's master and that sees to have moved it into the pull request. So all the workflow is building again, except for the libusb problem.

[pdgilbert]

Got up my courage and squashed the two remaining commits into one, and even managed to get the commit message to be something somewhat meaningful. As previously, the CI is failing only on the libusb.

I thought the rebase might get rid of my detached head but it seems not. I still get a message about [detached HEAD 28e2216] in the output.

I see the usefulness of git rebase when wanting to keep a few main commits in place, that is, pick more than one. In my case I was trying to squash everything to one, and just a diff between my head and the remote head seems like it would have been way simpler and less error prone than a cumulative rolling up of all the commits. Is there a git utility that does it that way?

[pdgilbert]

I think I better close this, cleanup my fork, and re-submit the PR. This PR seems to think it is working with my branch examples-testing whereas I thought it was working with master.