Closed pdgilbert closed 3 years ago
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.
Ok, I'm treading in new territory again.
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
.
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 restgit push --force
to update the branch to the new rebased commitsthere 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 :-/
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.
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?
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
.
(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 directorymemoryMaps
has been added. It hasmemory.x
files for several MCUs. Thebuild.rs
, run by cargo, selects thememory.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--release
for the bluepill or it is too large for memory.--release
on bluepill but thehprintln
of the received message inlora_spi_receive
prints the received message twice.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?