Rahix
This is still blocked on the `avr-libc` problem which is linked above. I'm not aware of any workaround we can take so unfortunately I think it is still going to...
> Could this be added behind an "unstable" feature flag? It should be safe for anyone willing to use the latest git version of avr-libc. @rmsc: Is it actually working...
I went ahead and rebased this branch on the latest `main`. I have **not** done any tests besides trying to compile the examples... @PiemanAU, this is very generous of you....
The `stty` + `echo` command should reset the arduino such that it is ready for receiving a new firmware. I may have some time on the weekend to test it...
Hm, I don't think there is... We should probably add a constant to the HAL crates alongside a proper EEPROM API...
A proper EEPROM driver exists in avr-hal now. Thanks to @flyingyizi!
@RecursiveError unfortunately, it is not quite that simple because an implementation like you suggest can only support delays up to the timer overflow. However, a lot of use-cases need delays...
How about `#[cfg(target_os = "windows")]` (not sure what the exact cfg line was) for the single-byte buffer? Can you send a PR?
Fixed by #433.
@agausmann, sorry for the late reply :( I guess this serves to demonstrate that I'm also not really in the best position regarding maintenance duties... In any case, I'd suggest...