embedded-hal-bus with rtic v2 in embedded-hal 1.0.0 #886
Comments
|
You may look at: https://docs.rs/rtic-sync/latest/rtic_sync/arbiter/i2c/index.html |
|
Hi! The recommended way to share buses in RTIC (or embassy) is to use the following: https://docs.rs/rtic-sync/latest/rtic_sync/arbiter/i2c/index.html Ping us if you have questions! |
|
Thank you @perlindgren and @korken89 . I have a couple of simple quick questions: I am assuming Could you briefly explain this loop: It seems like |
|
It awaits access for shared I2C. If I2C is currently used by some other device in another task (like reading some I2C temp sensor) then it awaits until I2C resource becomes available. let mut i2c = i2c.access().await;In this particular example there is The thing is when we created let eco2 = cx.local.ens160.eco2().await;has to await until it gets its access, but it newer does (if we do not use scope to drop it) because |
|
I'm confused about what "sensor driver that wants to use I2C directly" means in the pseudo-code at https://docs.rs/rtic-sync/latest/rtic_sync/arbiter/i2c/index.html . Is that supposed to be some sensor that for some reason cannot use Below is my attempt at an example that uses two After finally figuring out that I have to use I have managed to get to something fairly close to compiling. It is set up to compile with Click to expand error messagesIf I remove the lifetime argument then errors are much worse. Click to expand codeClick to expand Cargo.toml |
|
Well "sensor driver that wants to use I2C directly" is probably a quick hack or badly written proof of concept driver. Suppose you just have an single async function to write some bytes to I2C. Notice here pub async fn reset(i2c: &mut I2c) -> Result<(), i2c::Error> {
let mut read = [0; 1];
i2c.write_read(ADDRESS, &[Registers::Ctrl2 as u8], &mut read).await?;
i2c.write(ADDRESS, &[Registers::Ctrl2 as u8, read[0] | 0x80]).await?;
Mono::delay(3.millis()).await;
Ok(())
}Do use such function you have to give it a I2C which can be done using Arbiter : // Request access to shared I2C bus.
let mut i2c = i2c.access().await;
// Here we have access to I2C, at the same time nobody else can use it.
// If some other task is doing `.access().await;`
// then it awaits until we have finished with our `i2c` (meaning our `let i2c` variable is dropped).
asensor::reset(&mut I2c).await.
// Notice we did not use `drop(i2c)` or scope `{....}` above.
// This means that `i2c` variable still has exclusive access to I2C and
// this waits forever to get also access to I2C because
// underneath it uses Arbiter
// `let ens160 = Ens160::new(ArbiterDevice::new(i2c_arbiter), 0x52);`: https://docs.rs/rtic-sync/latest/rtic_sync/arbiter/i2c/index.html
let eco2 = cx.local.ens160.eco2().await;
// To fix this we should drop `i2c` so access to I2C would be released
// and other tasks doing `.access()` could then continue
drop(i2c);
let eco2 = cx.local.ens160.eco2().await;
// or if you wanna use scope
{
let mut i2c = i2c.access().await;
asensor::reset(&mut I2c).await.
} // i2c will be dropped automatically when scope ends
let eco2 = cx.local.ens160.eco2().await;Notice how Arbiter I2C also uses There seems to be multiple issues with your projects, for example In this example embassy stm32 I2C is used: https://docs.rs/rtic-sync/latest/rtic_sync/arbiter/i2c/index.html. That is why there is Could you add your full example to github so it can be cloned and built. |
|
Oh |
|
I added a repo with the example here: https://github.com/pdgilbert/ens160x2_arbit . I have been planning to play with |
|
I have been trying to compile the There is a problem with an unsatisfied trait bound for Click to expand codeClick to expand compiling errorSuggestions appreciated. Also, a pointer to an example that is tested would be nice. |
|
embassy-stm32 is preferable async HAL for STM32. |
|
@pdgilbert, I did a demo for F4 how to use it: https://github.com/andresv/rtic_arbiter_demo/blob/93dc3169ad993d330853f292837a32c25b773207/src/main.rs#L54-L65. |
|
Thank you @andresv . Your demo is helpful and I will explore I will close this issue now because the discussion has shifted a long way from the original subject. |
|
Yes
|
|
Thank you very much for the summary. I was waiting for the |
I have several examples that share devices on an
i2cbus. Bothrtic(v2) versions and non-rticversions worked previously using crateshared-bus. Converting toembedded-hal_1.0.0I am also converting toembedded-hal-busto share thei2cbus.With help and considerable patience from @bugadani I now have a working non-
rticversion of an example using cratesssd1305,ads1x1x, andina219. Attempting therticversion I have run into two stumbling blocks. The first is that I cannot get theRefCellDeviceargument to live long enough. I think I need to specify that the lifetime isstaticbut I have not managed to do that correctly. I get the same error with bothstm32fxx_halandstm32h7xx_hal. The code and error messages are below.Click to expand code
Click to expand Cargo.toml
Click to expand compile errors with stm32f4xx_hal
The second problem is because there is a need for types rather than impl traits in the fields of
SharedandLocalstructures. (It would be nice if that is wrong, please let me know.) I use setup functions to deal with small differences among hal crates. In the above code I have used types to indicate the results of thesetup_from_dp. In the non-rticcode I can useimpl I2cto indicate the result of thesetup_from_dp. If I do that in therticcode, and specify types in theSharedandLocalstructures, the compiler complainsexpectedI2c, found opaque type. Is there a way to useimpl I2cfor the result ofsetup_from_dpand then a type in the structure fields?Related to this, @eldruin 's
ads1x1xworks with impl traits in the non-rticcode but is commented out in the code above because some of the actual types are private, so it does not get as far as the lifetime problem in therticversion.The text was updated successfully, but these errors were encountered: