Support for embedded-hal version 1.0

[tgross35]

Embedded-hal has hit a RC and is looking for final feedback. It may be worth starting to port the stm32 crates to help locate any flaws.

See rust-embedded/embedded-hal#177 (comment)

[tgross35]

This could be possible under a feature flag like esp-hal has https://github.com/esp-rs/esp-hal/blob/07ed22df17f28f1b1890aa47c3ae599182397712/esp-hal-common/Cargo.toml#L23

[pdgilbert]

I tried playing with branch ehal with recent commits by @burrbull. It has some support for embedded-hal-1.0.0 and a few things work but I am getting errors like

106 |   fn setup() -> (impl LED, impl DelayNs) {
    |                            ^^^^^^^^^^^^ the trait `embedded_hal::delay::DelayNs` is not implemented for `SysDelay`

and

7  | pub fn setup_from_dp(dp: Peripherals) ->  (I2c1Type, I2c2Type, LedType, impl DelayNs, C...
    |                                                                         ^^^^^^^^^^^^ the trait `embedded_hal::delay::DelayNs` is not implemented for `stm32f1xx_hal::timer::Delay<stm32f1xx_hal::pac::TIM2, 1000000>`

and

tx1.write(b"\r\n").unwrap();
    |         ----- ^^^^^^^ expected `u8`, found `&[u8; 2]`
    |         |
    |         arguments to this method are incorrect
...
warning: unused import: `Write`
  --> examples/misc/serial_char.rs:44:25
   |
44 | use embedded_io::{Read, Write};

I assume the branch is just not ready for general playing around, but would someone please let me know if these embedded-hal 1.0.0 traits really are available and I just need to get them into scope somehow?

[frere-jacques]

I tried playing with branch ehal with recent commits by @burrbull. It has some support for embedded-hal-1.0.0 and a few things work but I am getting errors like

106 |   fn setup() -> (impl LED, impl DelayNs) {
    |                            ^^^^^^^^^^^^ the trait `embedded_hal::delay::DelayNs` is not implemented for `SysDelay`

and

7  | pub fn setup_from_dp(dp: Peripherals) ->  (I2c1Type, I2c2Type, LedType, impl DelayNs, C...
    |                                                                         ^^^^^^^^^^^^ the trait `embedded_hal::delay::DelayNs` is not implemented for `stm32f1xx_hal::timer::Delay<stm32f1xx_hal::pac::TIM2, 1000000>`

and

tx1.write(b"\r\n").unwrap();
    |         ----- ^^^^^^^ expected `u8`, found `&[u8; 2]`
    |         |
    |         arguments to this method are incorrect
...
warning: unused import: `Write`
  --> examples/misc/serial_char.rs:44:25
   |
44 | use embedded_io::{Read, Write};

I assume the branch is just not ready for general playing around, but would someone please let me know if these embedded-hal 1.0.0 traits really are available and I just need to get them into scope somehow?

I am new to the topic. I read up about the embedded-hal versions and found that, maybe it helps:
https://github.com/ryankurte/embedded-hal-compat

[pdgilbert]

Thanks @8FordPrefect8, that would help if I were trying to get something working with a mix of versions. The crate embedded-hal-compat fits between crates that use different versions of embedded-hal.

What I am trying to do is test things that are using only embedded-hal 1.0. The stm32f1xx-hal branch ehal has some parts of embedded-hal 1.0 but looks like it is not quite ready for use.

[frere-jacques]

Thanks @8FordPrefect8, that would help if I were trying to get something working with a mix of versions. The crate embedded-hal-compat fits between crates that use different versions of embedded-hal.

What I am trying to do is test things that are using only embedded-hal 1.0. The stm32f1xx-hal branch ehal has some parts of embedded-hal 1.0 but looks like it is not quite ready for use.

My idea was zhat you use the regular crate and then this compat crate so that you can use the device hal and your other code relying on embedded-hal 1.0.0. My understanding was that it's specifically for that purpose. But Maybe I misunderstood.

[pdgilbert]

@8FordPrefect8 sorry for the delay. Your understanding is correct. I could use the master branch of stm32f1xx-hal and then embedded-hal-compat to interface with embedded-hal 1.0 code. But what I am trying to do is use the ehal branch so I can test if it is working with embedded-hal 1.0 yet. It does not appear to work yet.

[burrbull]

@pdgilbert Try PR yet one time.

[pdgilbert]

@burrbull Not sure what you mean by "try PR" but I tried again with latest commit. When the ehal branch is a dependency the hal does not compile:

Click to expand

Compiling stm32f1xx-hal v0.10.0 (https://github.com/stm32-rs/stm32f1xx-hal?branch=ehal#8bde191f) error[E0432]: unresolved import `hal::block` --> src/setup_all_stm32f1xx.rs:14:7 | 14 | block, | ^^^^^ no `block` in the root

error[E0412]: cannot find type PA1 in this scope
--> src/setup_all_stm32f1xx.rs:88:37
|
88 | pub type AdcSensor1Type = AdcSensor<PA1, Adc>;
| ^^^
|
::: /home/paul/.cargo/git/checkouts/stm32f1xx-hal-bb9d214e810c7b47/8bde191/src/gpio.rs:982:1
|
982 | / gpio!(GPIOA, gpioa, PAx, 'A', [
983 | | PA0: (pa0, 0),
984 | | PA1: (pa1, 1),
985 | | PA2: (pa2, 2),
... |
998 | | PA15: (pa15, 15, Debugger),
999 | | ]);
| |__- similarly named type alias PA8 defined here
|
help: a type alias with a similar name exists
|
88 | pub type AdcSensor1Type = AdcSensor<PA8, Adc>;
| ~~~
help: consider importing one of these items
|
1 + use crate::setup_all_stm32f1xx::hal::gpio::PA1;
|
1 + use stm32f1xx_hal::gpio::PA1;
|

error[E0425]: cannot find value p in this scope
--> src/setup_all_stm32f1xx.rs:202:9
|
202 | p.USART2,
| ^ help: a local variable with a similar name exists: dp

error[E0152]: duplicate lang item in crate panic_halt: panic_impl.
|
= note: the lang item is first defined in crate panic_semihosting (which rust_integration_testing_of_examples depends on)
= note: first definition in panic_semihosting loaded from /home/paul/githubClones/rust-integration-testing/dev-testing/target/thumbv7m-none-eabi/debug/deps/libpanic_semihosting-141e435be2ae2a00.rmeta
= note: second definition in panic_halt loaded from /home/paul/githubClones/rust-integration-testing/dev-testing/target/thumbv7m-none-eabi/debug/deps/libpanic_halt-4a556159481f0bae.rmeta

error[E0152]: duplicate lang item in crate panic_rtt_target: panic_impl.
|
= note: the lang item is first defined in crate panic_semihosting (which rust_integration_testing_of_examples depends on)
= note: first definition in panic_semihosting loaded from /home/paul/githubClones/rust-integration-testing/dev-testing/target/thumbv7m-none-eabi/debug/deps/libpanic_semihosting-141e435be2ae2a00.rmeta
= note: second definition in panic_rtt_target loaded from /home/paul/githubClones/rust-integration-testing/dev-testing/target/thumbv7m-none-eabi/debug/deps/libpanic_rtt_target-aeb704ce40462b33.rmeta

error[E0152]: duplicate lang item in crate panic_reset: panic_impl.
|
= note: the lang item is first defined in crate panic_semihosting (which rust_integration_testing_of_examples depends on)
= note: first definition in panic_semihosting loaded from /home/paul/githubClones/rust-integration-testing/dev-testing/target/thumbv7m-none-eabi/debug/deps/libpanic_semihosting-141e435be2ae2a00.rmeta
= note: second definition in panic_reset loaded from /home/paul/githubClones/rust-integration-testing/dev-testing/target/thumbv7m-none-eabi/debug/deps/libpanic_reset-ac7090d4e420455f.rmeta

error[E0308]: mismatched types
--> src/setup_all_stm32f1xx.rs:174:49
|
174 | ...ioa.pa11.into_push_pull_output(&mut gpioa.crl), //CsPin ...
| --------------------- ^^^^^^^^^^^^^^ expected true, found false
| |
| arguments to this method are incorrect
|
= note: expected mutable reference &mut Cr<_, true>
found mutable reference &mut Cr<_, false>
note: method defined here
--> /home/paul/.cargo/git/checkouts/stm32f1xx-hal-bb9d214e810c7b47/8bde191/src/gpio.rs:704:12
|
704 | pub fn into_push_pull_output(self, cr: &mut ...
| ^^^^^^^^^^^^^^^^^^^^^

error[E0609]: no field pa2 on type stm32f1xx_hal::gpio::gpiob::Parts
--> src/setup_all_stm32f1xx.rs:204:19
|
204 | ... gpiob.pa2.into_alternate_push_pull(&mut gpiob.crh),
| ^^^ unknown field
|
help: a field with a similar name exists
|
204 | gpiob.pb2.into_alternate_push_pull(&mut gpiob.crh),
| ~~~

error[E0609]: no field pa3 on type stm32f1xx_hal::gpio::gpiob::Parts
--> src/setup_all_stm32f1xx.rs:205:19
|
205 | gpiob.pa3, // probably need alt
| ^^^ unknown field
|
help: a field with a similar name exists
|
205 | gpiob.pb3, // probably need alt
| ~~~

error[E0308]: mismatched types
--> src/setup_all_stm32f1xx.rs:224:63
|
224 | ... rx2, spi1, spiext, delay, clocks, adc1)
| ^^^^^ expected AltDelay, found Delay<TIM3, 1000000>
|
= note: expected struct AltDelay
found struct stm32f1xx_hal::timer::Delay<stm32f1xx_hal::pac::TIM3, 1000000>

Some errors have detailed explanations: E0152, E0308, E0412, E0425, E0432, E0609.
For more information about an error, try rustc --explain E0152.
error: could not compile rust-integration-testing-of-examples (lib) due to 10 previous errors

[frere-jacques]

He did a pull request that is probably connected to your issue.

[pdgilbert]

(I may be very confused, as seems to happen fairly often.) I think the ehal commit I used above is the the same as @burrbull 's PR. As a dependency it does not compile, so I tried with a clone of the hal and that also does not compile (details below). So I looked at the PR to see how "all checks have passed." The details for

Continuous integration / check (stm32f103, stable) (pull_request) Successful in 40s

show

Run actions-rs/cargo@v1
/home/runner/.cargo/bin/cargo test --features=stm32f103 --target x86_64-unknown-linux-gnu --lib

I'm not familiar enough with cargo to understand if x86... target makes any sense with stm32f103 but I think it needs to be checked with --target thumbv7m-none-eabi --features stm32f103.

Click to expand hal crate compile error and warning details

$ git branch * ehal master $ git status On branch ehal nothing to commit, working tree clean $ git remote -v origin https://github.com/stm32-rs/stm32f1xx-hal.git (fetch) origin https://github.com/stm32-rs/stm32f1xx-hal.git (push)

$ cargo build --no-default-features --target thumbv7m-none-eabi --features stm32f103
Compiling stm32f1xx-hal v0.7.0 (/home/paul/githubClones/stm32f1xx-hal)
warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | ...= DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
218 | ... = busy_wait_cycles!(self.wait_after_sent_start(), self.timeouts.star...
| -------------------------------------------------------------------- in this macro invocation
|
= note: #[warn(deprecated)] on by default
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | ...T::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
218 | ...st_ret = busy_wait_cycles!(self.wait_after_sent_start(), self.timeouts.star...
| -------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | ...rted = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
232 | ... = busy_wait_cycles!(wait_for_flag!(self.nb.i2c, addr), self.timeouts.add...
| ------------------------------------------------------------------------ in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | ...T::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
232 | ...t = busy_wait_cycles!(wait_for_flag!(self.nb.i2c, addr), self.timeouts.add...
| ------------------------------------------------------------------------ in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | ...et started = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
246 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, tx_e), self.timeouts.data...
| ------------------------------------------------------------------------ in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | ... DWT::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
246 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, tx_e), self.timeouts.data...
| ------------------------------------------------------------------------ in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | ... let started = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
249 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, btf), self.timeouts.data...
| ----------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | ... DWT::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
249 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, btf), self.timeouts.data...
| ----------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | let started = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
275 | busy_wait_cycles!(self.wait_for_stop(), self.timeouts.data)?;
| ----------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | DWT::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
275 | busy_wait_cycles!(self.wait_for_stop(), self.timeouts.data)?;
| ----------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | ...tarted = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
298 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, rx_ne), self.timeouts.data...
| ------------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | ...WT::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
298 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, rx_ne), self.timeouts.data...
| ------------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | ...tarted = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
301 | ... busy_wait_cycles!(self.wait_for_stop(), self.timeouts.data)?;
| ----------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | ...WT::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
301 | ... busy_wait_cycles!(self.wait_for_stop(), self.timeouts.data)?;
| ----------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | ...tarted = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
313 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, btf), self.timeouts.data...
| ----------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | ...WT::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
313 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, btf), self.timeouts.data...
| ----------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | ...tarted = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
318 | ... busy_wait_cycles!(self.wait_for_stop(), self.timeouts.data)?;
| ----------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | ...WT::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
318 | ... busy_wait_cycles!(self.wait_for_stop(), self.timeouts.data)?;
| ----------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | ...ed = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
332 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, rx_ne), self.timeouts.data...
| ------------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | ...T::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
332 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, rx_ne), self.timeouts.data...
| ------------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | ...tarted = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
336 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, btf), self.timeouts.data...
| ----------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | ...WT::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
336 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, btf), self.timeouts.data...
| ----------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | ...tarted = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
341 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, rx_ne), self.timeouts.data...
| ------------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | ...WT::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
341 | ... busy_wait_cycles!(wait_for_flag!(self.nb.i2c, rx_ne), self.timeouts.data...
| ------------------------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | ...tarted = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
344 | ... busy_wait_cycles!(self.wait_for_stop(), self.timeouts.data)?;
| ----------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | ...WT::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
344 | ... busy_wait_cycles!(self.wait_for_stop(), self.timeouts.data)?;
| ----------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:155:28
|
155 | let started = DWT::get_cycle_count();
| ^^^^^^^^^^^^^^^
...
368 | busy_wait_cycles!(self.wait_for_stop(), self.timeouts.data)?;
| ----------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/i2c/blocking.rs:159:18
|
159 | DWT::get_cycle_count().wrapping_sub(started) >= cycles
| ^^^^^^^^^^^^^^^
...
368 | busy_wait_cycles!(self.wait_for_stop(), self.timeouts.data)?;
| ----------------------------------------------------------- in this macro invocation
|
= note: this warning originates in the macro busy_wait_cycles (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/time.rs:262:23
|
262 | now: DWT::get_cycle_count(),
| ^^^^^^^^^^^^^^^

warning: use of deprecated associated function cortex_m::peripheral::dwt::<impl stm32f1::stm32f103::DWT>::get_cycle_count: Use cycle_count which follows the C-GETTER convention
--> src/time.rs:276:14
|
276 | DWT::get_cycle_count().wrapping_sub(self.now)
| ^^^^^^^^^^^^^^^

error: assigning to &T is undefined behavior, consider using an UnsafeCell
--> src/serial.rs:527:22
|
527 | ...fe { ptr::write_volatile(&usart.dr as *const _ as *mut _, byte) }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: for more information, visit https://doc.rust-lang.org/book/ch15-05-interior-mutability.html
= note: even for types with interior mutability, the only legal way to obtain a mutable pointer from a shared reference is through UnsafeCell::get
= note: #[deny(invalid_reference_casting)] on by default

error: assigning to &T is undefined behavior, consider using an UnsafeCell
--> src/spi.rs:262:18
|
262 | ... { ptr::write_volatile(&self.spi.dr as *const _ as *mut FrameSize, data...
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: for more information, visit https://doc.rust-lang.org/book/ch15-05-interior-mutability.html
= note: even for types with interior mutability, the only legal way to obtain a mutable pointer from a shared reference is through UnsafeCell::get

warning: stm32f1xx-hal (lib) generated 30 warnings
error: could not compile stm32f1xx-hal (lib) due to 2 previous errors; 30 warnings emitted

[burrbull]

(I may be very confused, as seems to happen fairly often.) I think the ehal commit I used above is the the same as @burrbull 's PR. As a dependency it does not compile, so I tried with a clone of the hal and that also does not compile (details below).

It is very easy to use a git branch as dependency:

stm32f1xx-hal = { git = "https://github.com/stm32-rs/stm32f1xx-hal/", branch = "ehal" }

Than do cargo update.

All your text lower then first paragraph is not understandable.
What are you doing? Run github CI?
If you are running it on GHA just show a link on action instead of unreadable text under expander.

If you try to run it locallly... It is nonsense to run it locally.

P.S. You could use https://github.com/burrbull/stm32-template to easy generate projects.

[pdgilbert]

(Maybe I am not quite that confused.) I am using the branch as a dependency and I do that with lots of other hals and device crates too. I cross compile locally all the time, so I know it is not nonsense to do that. (But if there is an efficient way to load compiled code into an stm32f103 using GHA I would be interested in knowing how.) When the ehal branch compiles and works with simple examples I will add it to CI that I have at https://github.com/pdgilbert/rust-integration-testing/actions. It needs to compile before I can test other things.

What I am confused about is what it means to use --features=stm32f103 --target x86_64-unknown-linux-gnu --lib in the GHA. And exactly what has been tested when that passes, as it has in your PR.

But the real problem is that branch ehal does not compile with --target thumbv7m-none-eabi --features stm32f103 which is what is needed for no-std on an stm32f103 such as bluepill. That feature and target triple works with the master branch and with other hal crates. So something seems to be messed up in the branch you propose in the PR. I included a detailed error report above but you might get a better report by trying to compile it yourself.

I'm sorry if I was not clear about the problem, and thanks for all your work on this.

[burrbull]

with simple examples

What exact examples? You've not show any of them. I can't help if I do not understand the issue.
Errors from #473 (comment) I've tried to fix.

What is going in #473 (comment) I can't parse because I don't see the code. Only errors which say me nothing.

Anyway try to compile a project with your example locally without CI first as most of people do.

[pdgilbert]

I discovered that my toolchain was broken and was causing the failure to compile stm32f1xx_hal. My apologies for the distraction.

I am now back to testing examples, and hopefully will soon be able to provide more useful feedback. At the moment I am struggling with a large number of examples failing with stm32f1xx_hal branch ehal. (A relatively small number of problems can cause a large number of failing examples.) Following @eldruin 's example at https://github.com/eldruin/ads1x1x-rs/blob/master/examples/all_channels.rs, I have many examples that use ads1x1x and using stm32f1xx_hal they fail with messages like

  --> examples/misc/oled_temperature.rs:144:40
    |
144 | ... mut adc = Ads1x1x::new_ads1015(adc_rcd, SlaveAddr::defau...
    |               -------------------- ^^^^^^^ the trait `embedded_hal::i2c::I2c` is not implemented for `I2c<I2C1, (Pin<'B', 6, ...>, ...)>`, which is required by `embedded_hal_bus::i2c::RefCellDevice<'_, rust_integration_testing_of_examples::setup::I2c<I2C1, (rust_integration_testing_of_examples::setup::Pin<'B', 6, rust_integration_testing_of_examples::setup::Alternate<rust_integration_testing_of_examples::setup::OpenDrain>>, rust_integration_testing_of_examples::setup::Pin<'B', 7, rust_integration_testing_of_examples::setup::Alternate<rust_integration_testing_of_examples::setup::OpenDrain>>)>>: embedded_hal::i2c::ErrorType`
    |               |
    |               required by a bound introduced by this call
    |
    = help: the following other types implement trait `embedded_hal::i2c::I2c<A>`:
              <&mut T as embedded_hal::i2c::I2c<A>>
              <BlockingI2c<I2C, PINS> as embedded_hal::i2c::I2c>
              <I2cStub as embedded_hal::i2c::I2c>
              <embedded_hal_bus::i2c::CriticalSectionDevice<'a, T> as embedded_hal::i2c::I2c>
              <embedded_hal_bus::i2c::RefCellDevice<'a, T> as embedded_hal::i2c::I2c>
    = note: required for `RefCellDevice<'_, I2c<I2C1, ...>>` to implement `embedded_hal::i2c::ErrorType`
note: required by a bound in `ads1x1x::construction::<impl Ads1x1x<I2C, Ads1015, Resolution12Bit, ads1x1x::mode::OneShot>>::new_ads1015`
   --> /home/paul/.cargo/git/checkouts/ads1x1x-rs-bbbb6dc8bfa9c063/00830f4/src/construction.rs:39:1
    |
39  | impl_new_destroy!(Ads1015, new_ads1015, destroy_ads1015, ic::Resolution12Bi...
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^-----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    | |                          |
    | |                          required by a bound in this associated function
    | required by this bound in `ads1x1x::construction::<impl Ads1x1x<I2C, Ads1015, Resolution12Bit, OneShot>>::new_ads1015`

and

error[E0277]: the trait bound `rust_integration_testing_of_examples::setup::I2c<I2C1, (rust_integration_testing_of_examples::setup::Pin<'B', 6, rust_integration_testing_of_examples::setup::Alternate<rust_integration_testing_of_examples::setup::OpenDrain>>, rust_integration_testing_of_examples::setup::Pin<'B', 7, rust_integration_testing_of_examples::setup::Alternate<rust_integration_testing_of_examples::setup::OpenDrain>>)>: rust_integration_testing_of_examples::setup::stm32f1xx_hal::embedded_hal::i2c::I2c` is not satisfied
  --> examples/driver-examples/ccs811-gas-voc-display.rs:90:46
   |
90 |     let interface = I2CDisplayInterface::new(i2c1); //default address 0x3C
   |                     ------------------------ ^^^^ the trait `rust_integration_testing_of_examples::setup::stm32f1xx_hal::embedded_hal::i2c::I2c` is not implemented for `I2c<I2C1, (Pin<'B', 6, Alternate<OpenDrain>>, Pin<'B', 7, Alternate<OpenDrain>>)>`
   |                     |
   |                     required by a bound introduced by this call
   |
   = help: the following other types implement trait `rust_integration_testing_of_examples::setup::stm32f1xx_hal::embedded_hal::i2c::I2c<A>`:
             `&mut T` implements `rust_integration_testing_of_examples::setup::stm32f1xx_hal::embedded_hal::i2c::I2c<A>`
             `BlockingI2c<I2C, PINS>` implements `rust_integration_testing_of_examples::setup::stm32f1xx_hal::embedded_hal::i2c::I2c`
             `I2cStub` implements `rust_integration_testing_of_examples::setup::stm32f1xx_hal::embedded_hal::i2c::I2c`
note: required by a bound in `I2CDisplayInterface::new`
  --> /home/runner/.cargo/git/checkouts/ssd1306-407b1a92e31533f1/0bae3a6/src/i2c_interface.rs:15:12
   |
13 |     pub fn new<I>(i2c: I) -> I2CInterface<I>
   |            --- required by a bound in this associated function
14 |     where
15 |         I: embedded_hal::i2c::I2c,
   |            ^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `I2CDisplayInterface::new`

If you recognize these problems then I would appreciate suggestions. Otherwise I will eventually make a more simplified and self contained test.

For reference, my tests are at https://github.com/pdgilbert/rust-integration-testing/actions. stm32f1xx_hal testing is currently only in dev workflows. The CI jobs are not useful until more things are working. At the moment the most useful cases are probably the Ex... jobs. Those that fail for bluepill but work for other hals suggest either my setup for stm32f1xx_hal is bad, or there is a problem with the hal. Of 72 examples that I had working with embedded-hal 0.2 I now have

• 67 are working on stm32g4xx-hal branch "hal-1" (on fork)
• 60 are working on stm32f4xx-hal
• 42 are working on stm32h7xx-hal branch "eh-v1.0"
• 10 are working on stm32f4xx-hal branch ehal

BTW, stm32f4xx_hal, stm32g4xx_hal branch hal-1 and stm32h7xx_hal branch "eh-v1.0" all provide block as a root level module with pub use nb::block; in src/lib.rs, but stm32f1xx_hal does not. (There is an easy work-around of course.) As in https://github.com/eldruin/ads1x1x-rs/blob/master/examples/all_channels.rs, I have many examples that use something like

block!(adc.read(channel::SingleA0)).unwrap()

I am not sure if block!(...) should be needed with embedded-hal 1.0. If not, I could remove it. But I do want to be sure it is not needed before I do that.

[FaezBarghasa]

is there any news about stm32f1xx_hal version 0.11.0 for supporting embedded-hal version 1.0 ?
i need to use non-blocking i2c .