e-hal@v1 support

[brainstorm]

Hey, I saw you starred my recent Rust AVR AS5600 repo using your crate and now I just saw this issue! :)

Would it make sense to implement traits from embedded_hal_async I2c instead. I'm targetting embassy and perhaps a non-blocking impl could be more interesting for this use case and also in general?

/cc @jubeormk1

[barafael]

Both make sense

[barafael]

I'm going over my driver crates and this one is next! Unless PR :)

[brainstorm]

Please go ahead, I think it'd take me more time to understand how to integrate sync and async I2C and PR than if you implement it. I'm currently reading some resources and it's unclear (to me) which route to take and how to implement it properly:

https://github.com/therealprof/display-interface/pull/48 https://github.com/rust-embedded/embedded-hal/issues/50 https://ferrous-systems.com/blog/async-on-embedded/#from-blocking-to-non-blocking

/cc @jubeormk1

[barafael]

upcoming crates.io release 0.7.0 with e-hal (blocking) support @brainstorm

[barafael]

@brainstorm the v0.8.0 release has the feature "async". Please let me know if it works for you!

[brainstorm]

Thanks heaps for adding this in record speed! Unfortunately I'm still facing a panic when querying the u16 angle value both when the sensor is connected to my Atmega2560 I2C pins and when there's no sensor connected at all... I suspect it's not a problem with your crate though, I'll have to keep investigating and/or ask Rust AVR experts like @Rahix:

$ cargo build
WARN rustc_codegen_ssa::back::link Linker does not support -no-pie command line option. Retrying without.
    Finished `dev` profile [optimized + debuginfo] target(s) in 0.16s

$ simavr --mcu atmega2560 target/avr-atmega2560/debug/embassy-avr-as5600-encoder.elf
Loaded 10124 .text at address 0x0
Loaded 3242 .data
Reading angle.
Firmware panic!..
  At src/main.rs:63:38..
^Csignal caught, simavr terminating

The code above is essentially trying to read the sensor angle on the loop:

(...)
    loop {
        ufmt::uwriteln!(&mut serial, "{}", "Reading angle").unwrap();
        let status = encoder.angle().unwrap();
        ufmt::uwriteln!(&mut serial, "{}", "Angle has been read").unwrap_infallible();
        ufmt::uwriteln!(&mut serial, "{}", status).unwrap_infallible();
    }

[barafael]

Can you not unwrap the results and print them instead? If that doesn't work because of ufmt, then match on the result and print at least which variant it was

[brainstorm]

Thanks! Just did that and seems to be about comms (as5600::error::Error::Communication), doesn't panic now. I've attached the oscilloscope and I can see the 0x36 I2C packet sent by the board but no response from the sensor.

Tomorrow I'll solder the 100nF & 1nF caps recommended by the datasheet and try again :)

[barafael]

I thought so. Likely the Comms error will be an underlying i2c nak error. Btw of course it doesn't panic if you don't unwrap :) you have pull-ups in place?

[brainstorm]

I thought so. Likely the Comms error will be an underlying i2c nak error. Btw of course it doesn't panic if you don't unwrap :) you have pull-ups in place?

Heh, yes indeed I should have written the match before asking... I should check whether embassy::main accepts Result<(), Error> as return as it'd make the code cleaner (using the ? operator and no unwraps)... but I've not come across no_std examples using result on main perhaps it's not supported or portable? Learning as I go, thanks for your insights! :)

Probably Result is not common in no_std because it complicates the unwind logic and has a major storage (code) footprint? I don't know enough about this topic :-S

Anyway, yes, I'm using a RAMPS 1.4 hat so it does have a couple of 4K7 resistors installed for pull-ups (on D20/D21):

https://reprap.org/wiki/File:RAMPS1.4schematic.png

[barafael]

I don't think returning a result from main in embedded is a good idea. Where does it return to?

Unless you make it another function and call that one from main of course.

But it sounds like you have different problems rn :) let me know how it goes :)