cargo run --bin test-nano168
Finished dev [optimized + debuginfo] target(s) in 0.02s
Running `ravedude nano168 -cb 57600 -P /dev/ttyUSB0 target/avr-atmega168/debug/test-nano168.elf`
Board Nano Clone (ATmega168)
Programming target/avr-atmega168/debug/test-nano168.elf => /dev/ttyUSB0
and then nothing happens
the weired thing is my other project works now with only
cargo run (after I pasted the code from your example)
Oh I found the difference what does
profile=minimal in toolchain.toml do?
on removing that everything works as expected
it shouldn't have an influence whatsoever... here is relevant documentation: https://rust-lang.github.io/rustup/concepts/profiles.html
it just controls whether rustfmt and clippy are installed for the toolchain
especially because it should have influenced the other project exactly the same...
I searched for the difference... and the only issue was... I was still connected to the Serial port in the other window...
So the template works just fine!
alright, then I'll go ahead and get all those changes merged now
Rahix (Rahix) I have ported the blink and the adc example (the second without the temperature) see pr
*ported to the atmega168
rahix - in the pr you requested to change the comment to Nano 168 - shouldn't that be consistent with the verbose naming in the feature doc: "Nano clone (ATmega168)"?
or do you prefer the more readable variant?
honestly it does not matter much at all - I just was a bit weary about reading "Arduino" in code related to a board which is not an official one
so choose whatever you think is best, it's not important ;)
either me or my git allways gets confused... sometimes both... :) I work too much alone...
but now it should be as desired in the pr (force pushed)
what are good settings for rust-analyzer? Currently it is allways failing with the macros like
ufmt::uwriteln! so whenever I open a project or file depending on avr-hal it is complaining about so many problems.
I'm trying to add attiny support to arduino-hal and I was wondering if there's anyone who could help with some of the trickier generics/trait bounds
Although I am not quite sure, what you want to do? attinies by themselves belong into attiny-hal
So I need to figure out how to move the mega-specific stuff into
atmega-hal and make avr-hal-generic generic to allow a corresponding implementation in attiny-hal
what in particular? the only mega-specific things should be contained in the impl_* macros
so for tiny, the idea would be to write a second impl_* macro in avr-hal-generic which can then be used in attiny-hal
Likewise the
adc module has ReferenceVoltage baked into avr-hal-generic, though I think I've already successfully teased that apart.
well Baudrate should stay a type valid for all supported MCUs, not a HAL specific one, IMO. But I agree that we need to maybe move the calculation logic into the mega-specific impl_ macro instead, to accommodate for attinies
If it's a generic type then it shouldn't have ubrr and u2x fields.
1 reply
Shouldn't Baudrate be a trait, with HAL-specific implementations?
Why does that require a concrete type?
As long as the HAL-specific type implements From<i32>...
Here's what I'm noodling with:
Introduce a
UsartHal trait with associated types Event and Baudrate