Closed pdgilbert closed 2 years ago
I seem to have fallen into dependency version hell with the switch to embedded-hal 1.0.0-alpha.4
yep, you'll need to be running exactly the same version of the alpha hal everywhere as the traits are not compatible (and the errors, difficult to interpret). cargo tree -i embedded-hal
is your friend for diagnosing this, and you should be able to patch stm32f4xx_hal
to use https://github.com/stm32-rs/stm32f4xx-hal/pull/144 (or maybe https://github.com/stm32-rs/stm32f4xx-hal/pull/172 but really this should be closed in favour of the former).
I am confused about whether the push of a branch on my fork automatically made a pull request upstream. If so, I did not intend to do that yet
PRs are only created when you click something to do so, pushing to a your fork will output a link you can open to the correct page to do so but not create a PR itself. You can also always open a PR as a draft to indicate it's for discussion / not ready for merging.
i haven't looked at the example yet but, i think the first comment should help. fyi when you do attach big outputs / logs / sources / whatever to GH issues i'd generally recommend either an uploaded text file you use collapse tags like i have edited above.
Sorry to be a bit slow, I thought I could "patch" stm32f4xx_hal
to use stm32-rs/stm32f4xx-hal#144
by putting something like
stm32f4xx-hal = { git = "https://github.com/maxekman/stm32f4xx-hal/tree/update-to-try-functions"}
or
stm32f4xx-hal = { git = "https://github.com/stm32-rs/stm32f4xx-hal/commits/", rev = "a1316e83dcb1e92fb52cc1d5d04a5bd066f14575"}
in my Cargo.toml, but I tried several variations which all give 404 errors. How does one do this "patch"? (And thanks for the hint about collapsing large attachments.)
you're super close, need to split the git path and branch. should be something like:
[patch.crates-io]
stm32f4xx-hal = { git = "https://github.com/maxekman/stm32f4xx-hal", branch="update-to-try-functions" }
So in my forked version of rust-radio-sx127x
I have
[dev-dependencies] # for examples
cortex-m = "0.6.0"
cortex-m-rt = "0.6.8"
panic-halt = "0.2.0"
panic-semihosting = "0.5.2"
cortex-m-semihosting = "0.3.3"
stm32f4xx-hal = { git = "https://github.com/stm32-rs/stm32f4xx-hal", branch = "master" }
[patch.crates-io]
# Patch for radio-hal to update embedded-hal version
radio = { git = "https://github.com/ryankurte/rust-radio.git", branch = "master" }
stm32f4xx-hal = { git = "https://github.com/maxekman/stm32f4xx-hal", branch="update-to-try-functions" }
when I do cargo update
I get
Updating git repository `https://github.com/stm32-rs/stm32f4xx-hal`
warning: Patch `stm32f4xx-hal v0.8.3 (https://github.com/maxekman/stm32f4xx-hal?branch=update-to-try-functions#a1316e83)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
and if I rm Cargo.lock
and run cargo update
again I get the same warning.
I think the warning may be something I should worry about?
(It is surprising how much time one can spend with a computer being "super close".) Thanks for your help.
Possibly I have to apply the patch to a specific (release?) version of stm32f4xx-hal rather than the latest git version? When I specify stm32f4xx-hal v 0.8.3
there are no warnings, just a conflict between e-h alpha versions:
Updating crates.io index
error: failed to select a version for `embedded-hal`.
... required by package `stm32f4xx-hal v0.8.3 (https://github.com/maxekman/stm32f4xx-hal?branch=update-to-try-functions#a1316e83)`
... which is depended on by `radio-sx127x v0.10.1 (/home/paul/githubClones/rust-radio-sx127x)`
versions that meet the requirements `= 1.0.0-alpha.1` are: 1.0.0-alpha.1
all possible versions conflict with previously selected packages.
previously selected package `embedded-hal v1.0.0-alpha.4`
... which is depended on by `driver-pal v0.8.0-alpha.0`
... which is depended on by `radio-sx127x v0.10.1 (/home/paul/githubClones/rust-radio-sx127x)`
failed to select a version for `embedded-hal` which could resolve this conflict
I do seem to be getting closer.
After more careful reading of the appropriate section of The Cargo Book (https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html) I see I should be doing either
[dev-dependencies]
...
stm32f4xx-hal = "0.8.3"
[patch.crates-io]
...
stm32f4xx-hal = { git = "https://github.com/maxekman/stm32f4xx-hal", branch="update-to-try-functions" }
#stm32f4xx-hal = { git = "https://github.com/maxekman/stm32f4xx-hal", branch="update-to-try-functions", rev = "https://github.com/stm32-rs/stm32f4xx-hal/commit/dd14acca71a5fcfdfd77bf531a30ab33b7dd2c0a"}
or
[dev-dependencies]
...
stm32f4xx-hal = { git = "https://github.com/stm32-rs/stm32f4xx-hal", branch = "master" }
[patch."https://github.com/stm32-rs/stm32f4xx-hal"]
stm32f4xx-hal = { git = "https://github.com/maxekman/stm32f4xx-hal", branch="update-to-try-functions" }
#stm32f4xx-hal = { git = "https://github.com/maxekman/stm32f4xx-hal", branch="update-to-try-functions", rev = "https://github.com/stm32-rs/stm32f4xx-hal/commit/dd14acca71a5fcfdfd77bf531a30ab33b7dd2c0a"}
or one of the commented out alternatives. All give the conflict reported in the comment just above.
If I understand correctly, the problem is that the patch is moving the stm32f4xx-hal dependency on e-h to alpha.1 but rust-radio-sx127x needs it moved up to alpha.4. I don't see any way to make either part of this into a caret specification on the alpha version. Is there a way to do that, or do I have to make my own patch?
Would it be useful or not for me to do a PR as a draft?
If I understand correctly, the problem is that the patch is moving the stm32f4xx-hal dependency on e-h to alpha.1 but rust-radio-sx127x needs it moved up to alpha.4. I don't see any way to make either part of this into a caret specification on the alpha version. Is there a way to do that, or do I have to make my own patch?
ahh, yes that'd do it. there's a loose preference to use strict matches for alpha releases because they can be breaking, the side-effect in this instance is that the stm32f4xx-hal
branch also needs to be updated to this
I seem to have similiar issues with stm32l1xx-hal
$ cargo tree -i embedded-hal:1.0.0-alpha.4
embedded-hal v1.0.0-alpha.4
├── driver-pal v0.8.0-alpha.2
│ └── radio-sx127x v0.10.1 (https://github.com/rust-iot/rust-radio-sx127x?branch=master#8a976033)
│ └── iM880B-L v0.1.0 (C:\dev\projects\rust-iM880B-L)
└── radio-sx127x v0.10.1 (https://github.com/rust-iot/rust-radio-sx127x?branch=master#8a976033) (*)
embedded-hal v0.2.4
├── cortex-m v0.7.1
│ ├── cortex-m v0.6.7
│ │ ├── cortex-m v0.5.11
│ │ │ ├── stm32l1 v0.5.0
│ │ │ │ └── stm32l1xx-hal v0.1.0
│ │ │ │ └── iM880B-L v0.1.0 (C:\dev\projects\rust-iM880B-L)
│ │ │ └── stm32l1xx-hal v0.1.0 (*)
│ │ └── iM880B-L v0.1.0 (C:\dev\projects\rust-iM880B-L)
│ ├── cortex-m-semihosting v0.3.7
│ │ └── panic-semihosting v0.5.6
│ │ └── iM880B-L v0.1.0 (C:\dev\projects\rust-iM880B-L)
│ └── panic-semihosting v0.5.6 (*)
├── embedded-spi v0.5.8
│ └── iM880B-L v0.1.0 (C:\dev\projects\rust-iM880B-L)
├── radio v0.7.0
│ ├── iM880B-L v0.1.0 (C:\dev\projects\rust-iM880B-L)
│ └── radio-sx127x v0.10.1 (https://github.com/rust-iot/rust-radio-sx127x?branch=master#8a976033)
│ └── iM880B-L v0.1.0 (C:\dev\projects\rust-iM880B-L)
└── stm32l1xx-hal v0.1.0 (*)
extern crate stm32l1xx_hal as hal;
let mut lora = Sx127x::spi(
spi,
cs_pin.into(),
busy_pin.into(),
ready_pin.into(),
reset_pin.into(),
delay.into(),
&CONFIG_RADIO,
).unwrap();
Leads to:
error[E0277]: the trait bound `hal::spi::Spi<hal::stm32::SPI3, (PB3<Input<Floating>>, PB4<Input<Floating>>, PB5<Input<Floating>>)>: embedded_hal::blocking::spi::transfer::Default<u8>` is not satisfied
--> examples\radio.rs:135:20
|
135 | let mut lora = Sx127x::spi(
| ^^^^^^^^^^^ the trait `embedded_hal::blocking::spi::transfer::Default<u8>` is not implemented for `hal::spi::Spi<hal::stm32::SPI3, (PB3<Input<Floating>>, PB4<Input<Floating>>, PB5<Input<Floating>>)>`
|
= note: required because of the requirements on the impl of `embedded_hal::prelude::_embedded_hal_blocking_spi_Transfer<u8>` for `hal::spi::Spi<hal::stm32::SPI3, (PB3<Input<Floating>>, PB4<Input<Floating>>, PB5<Input<Floating>>)>`
= note: required by `Sx127x::<driver_pal::wrapper::Wrapper<Spi, SpiError, CsPin, BusyPin, ReadyPin, ResetPin, PinError, Delay, DelayError>, SpiError, PinError, DelayError>::spi`
yeeah, you'll need to run a version of stm32l1xx_hal
that implements the v1.0.0-alpha.N
embedded-hal
traits. it doesn't look like there's a fork you can just, use, but it's reasonably straightforward to create one (you can look at the l4xx branches linked above as an example)
wrt. [patch."https://github.com/stm32-rs/stm32f4xx-hal"]
, the trick is that you need to patch the -source- of the crate, so if you have a git include it has to be done in this form, looks like you've got it tho!
I was having similar problems so wrote a quick adapter that might help you here, you should hopefully be able to .compat()
any types that don't match.
This looks like the problem I was having in December before I had to put it aside to deal with some other things. Hoping to get back to it in the next few days so please keep posting progress/problem reports.
heads up i've published releases against embedded-hal@1.0.0-alpha.5
now, and have an embedded-hal-compat
crate that lets one wire things between the previous and alpha hals, so hopefully this is resolved / feel free to reopen or create a new issue if not ^_^
I seem to have fallen into dependency version hell with the switch to
embedded-hal 1.0.0-alpha.4
. I think the main problem is that the spi setup usingstm32f4xx_hal
, which still usesembedded-hal 0.2.4
, does not mix well with theSx127x::spi()
use of thespi
. One problem was that themode
argument forstm32f4xx_hal::spi::Spi::spi1
wants the older version. I fixed this by importing these fromstm32f4xx_hal
rather than fromembedded-hal
. (I suppose that is probably the correct way to do it anyway.)The next problem I think is related but I don't really understand it. There is lots of trouble satisfying traits and I think this is because of the mix of
embedded-hal
versions being used in the callSx127x::spi
is using the new version ofembedded-hal
whilespi,
is set up with the old version.I have tried to get this to work two different ways, one with my usual setup which allows me to specify the version of
embedded-hal
my code uses, and the other by forkingrust-radio-sx127x
and putting an example in an examples-testing branch at https://github.com/pdgilbert/rust-radio-sx127x. (BTW, I am confused about whether the push of a branch on my fork automatically made a pull request upstream. If so, I did not intend to do that yet.) The latter way seems to force using the sameembedded-hal
as specified in the crate. Trying to build the example forced some Cargo.toml changes in the branch of the fork. Most notably I had to comment out thecolor-backtrace
dependency because I could not get it to stop looking forstd
and thus failing. (Possibly there are other more notable changes that I don`t recognize which are causing the example build failure?)The example has been stripped down to remove the
setup()
function that causes additional difficulties, and some warnings are caused by not using imports for that. PossiblyInputPin
andOutputPin
are getting messed up by no longer having a v2 reference? The error seem to be pretty much the same for the two different ways:Build output
``` $ cargo build --target thumbv7em-none-eabihf --no-default-features --features="stm32f411, stm32f4xx" --example lora_spi_send Compiling radio-sx127x v0.10.1 (/home/paul/githubClones/rust-radio-sx127x) warning: unused import: `blocking::delay::DelayMs` --> examples/lora_spi_send.rs:36:20 | 36 | use embedded_hal::{blocking::delay::DelayMs, | ^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `#[warn(unused_imports)]` on by default warning: unused import: `Error as WrapError` --> examples/lora_spi_send.rs:41:50 | 41 | use driver_pal::{wrapper::Wrapper as SpiWrapper, Error as WrapError}; | ^^^^^^^^^^^^^^^^^^ warning: unused import: `radio_sx127x::Error as sx127xError` --> examples/lora_spi_send.rs:47:5 | 47 | use radio_sx127x::Error as sx127xError; // Error name conflict with hals | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0277]: the trait bound `stm32f4xx_hal::spi::Spi