Can't write to serial about avr-hal

[Rahix]

Hmm, thanks. What ufmt version and what version of avr-hal are you using? Maybe post the full output of cargo tree if that's possible to seee if this may be an issue caused by incompatible versions...

[BiasedKiwi]

I'm so dumb, now that you made me look at my dependencies I realized I was using an outdated version of ufmt so now I added it as a dependency to my cargo.toml and now the error is gone. Although I do get other weird behavior. I get this when I run the program

thread '<unnamed>' panicked at C:\Users\Alexandre\.cargo\registry\src\index.crates.io-6f17d22bba15001f\ravedude-0.1.7\src\console.rs:35:32:
called `Result::unwrap()` on an `Err` value: Error { kind: InvalidData, message: "Windows stdio in console mode does not support writing non-UTF-8 byte sequences" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[stappersg]

On Wed, Mar 06, 2024 at 12:59:57PM -0800, BiasedKiwi wrote: now that you made me look at my dependencies I realized I was using an outdated version of `ufmt` so now I added it as a dependency to my `cargo.toml` and now the error is gone.

Thanks for reporting back. Please close this issue to prevent that it costs further human energy.

Although I do get other weird behavior.

In a fresh issue. Please. Groeten Geert Stappers -- Silence is hard to parse

[Rahix]

Same behavior on nightly-2023-12-28?

[BiasedKiwi]

Same behavior with 2023-12-28

error[E0599]: the method `do_as_formatter` exists for mutable reference `&mut Usart<Atmega, USART0, Pin<Input, PD0>, Pin<Output, PD1>, MHz16>`, but its trait bounds were not satisfied
   --> src\main.rs:22:5
    |
22  |     ufmt::uwriteln!(&mut serial, "Hello, World!");
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ method cannot be called due to unsatisfied trait bounds
    |
   ::: C:\Users\Alexandre\.cargo\git\checkouts\avr-hal-f3855d5807fdfd57\190f2c3\avr-hal-generic\src\usart.rs:230:1
    |
230 | pub struct Usart<H, USART: UsartOps<H, RX, TX>, RX, TX, CLOCK> {
    | --------------------------------------------------------------
    | |
    | doesn't satisfy `_: UnstableDoAsFormatter`
    | doesn't satisfy `_: uWrite`
    |
    = note: the following trait bounds were not satisfied:
            `avr_hal_generic::usart::Usart<Atmega, USART0, avr_hal_generic::port::Pin<Input, PD0>, avr_hal_generic::port::Pin<Output, PD1>, MHz16>: uWrite`
            which is required by `avr_hal_generic::usart::Usart<Atmega, USART0, avr_hal_generic::port::Pin<Input, PD0>, avr_hal_generic::port::Pin<Output, PD1>, MHz16>: UnstableDoAsFormatter`
            `&mut avr_hal_generic::usart::Usart<Atmega, USART0, avr_hal_generic::port::Pin<Input, PD0>, avr_hal_generic::port::Pin<Output, PD1>, MHz16>: uWrite`
            which is required by `&mut avr_hal_generic::usart::Usart<Atmega, USART0, avr_hal_generic::port::Pin<Input, PD0>, avr_hal_generic::port::Pin<Output, PD1>, MHz16>: UnstableDoAsFormatter`
    = help: items from traits can only be used if the trait is in scope
    = note: this error originates in the macro `ufmt::uwriteln` (in Nightly builds, run with -Z macro-backtrace for more info)
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
    |
5   + use ufmt::UnstableDoAsFormatter;
    |

>rustup show
Default host: x86_64-pc-windows-msvc
rustup home:  C:\Users\Alexandre\.rustup

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc (default)
nightly-2023-12-28-x86_64-pc-windows-msvc

active toolchain
----------------

nightly-2023-12-28-x86_64-pc-windows-msvc (directory override for 'C:\Users\Alexandre\Documents\Projects\arduino\blink-rs-arduino')
rustc 1.77.0-nightly (89e2160c4 2023-12-27)

[BiasedKiwi]

Here's the cargo tree output

blink-rs-arduino v0.1.0 (C:\Users\Alexandre\Documents\Projects\arduino\blink-rs-arduino)
└── arduino-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=190f2c3cb8d29e10f71119352b912369dc5a1fb7#190f2c3c)
    ├── atmega-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=190f2c3cb8d29e10f71119352b912369dc5a1fb7#190f2c3c)
    │   ├── avr-device v0.5.4
    │   │   ├── avr-device-macros v0.5.4 (proc-macro)
    │   │   │   ├── proc-macro2 v1.0.78
    │   │   │   │   └── unicode-ident v1.0.12
    │   │   │   ├── quote v1.0.35
    │   │   │   │   └── proc-macro2 v1.0.78 (*)
    │   │   │   └── syn v1.0.109
    │   │   │       ├── proc-macro2 v1.0.78 (*)
    │   │   │       ├── quote v1.0.35 (*)
    │   │   │       └── unicode-ident v1.0.12
    │   │   ├── bare-metal v1.0.0
    │   │   ├── cfg-if v1.0.0
    │   │   └── vcell v0.1.3
    │   └── avr-hal-generic v0.1.0 (https://github.com/rahix/avr-hal?rev=190f2c3cb8d29e10f71119352b912369dc5a1fb7#190f2c3c)
    │       ├── avr-device v0.5.4 (*)
    │       ├── cfg-if v0.1.10
    │       ├── embedded-hal v0.2.7
    │       │   ├── nb v0.1.3
    │       │   │   └── nb v1.1.0
    │       │   └── void v1.0.2
    │       ├── embedded-storage v0.2.0
    │       ├── nb v0.1.3 (*)
    │       ├── paste v1.0.14 (proc-macro)
    │       ├── ufmt v0.1.2
    │       │   ├── proc-macro-hack v0.5.20+deprecated (proc-macro)
    │       │   ├── ufmt-macros v0.2.0 (proc-macro)
    │       │   │   ├── proc-macro-hack v0.5.20+deprecated (proc-macro)
    │       │   │   ├── proc-macro2 v1.0.78 (*)
    │       │   │   ├── quote v1.0.35 (*)
    │       │   │   └── syn v1.0.109 (*)
    │       │   └── ufmt-write v0.1.0
    │       └── void v1.0.2
    │       [build-dependencies]
    │       └── rustversion v1.0.14 (proc-macro)
    ├── avr-device v0.5.4 (*)
    ├── avr-hal-generic v0.1.0 (https://github.com/rahix/avr-hal?rev=190f2c3cb8d29e10f71119352b912369dc5a1fb7#190f2c3c) (*)
    ├── cfg-if v1.0.0
    ├── embedded-hal v0.2.7 (*)
    ├── ufmt v0.1.2 (*)
    └── void v1.0.2

[Rahix]

I realized I was using an outdated version of ufmt so now I added it as a dependency to my cargo.toml and now the error is gone

Yeah, I suspected as much... Glad you found it!

Unfortunately Rust is really bad at notifying you of such situations where multiple incompatible versions of the same crate are used in the dependency tree... And this has been an issue for years :(