Arduino Nano Every support

[explicite]

I want to add support for Arduino Nano Every board and ATMega4809 chip.

Will start after #88

@Rahix should I wait and implement other tickets? I can start in first week of November.

[Rahix]

You're free to do whatever you want :) That said, I fully support adding Nano Every support, if you want to go for that, that's great!

[explicite]

I start review of this board. Looks like there is inconsistency in chip and board clock setup https://github.com/arduino/Arduino/issues/9017 Not sure how we should support this. @Rahix, should we setup by default 16MHz or speedup to max 20MHz?

[Rahix]

I'd stick with 16 MHz for the default. If someone wants to reconfigure the MCU, they can always do that in their application code.

[svenfoo]

I'm interested in getting board support for this hardware, and I'd be willing to help.

I saw that support for ATmega4809 has been added to avr-device. What are next steps, can I somehow support the effort?

[Rahix]

As the ATmega4809 is the first newer generation AVR device we will support, there are lots of things that need to happen. For starters, the entire architecture of the API needs to be redesigned to allow easy support for both the old and the new hardware peripherals under a common API. I've started experimenting with a possible design in #116 and others are looking at different parts in #114.

We'll first need to get those designs sorted out. Once that is done, there are a lot of different things where you could help, as all HAL drivers need to be converted. For now, I think the best thing we could use is feedback on the changes we're doing and asking questions to see whether the new designs that are being tested are really bullet proof ;) Or, if you're adventurous, you could try hacking on the PRs themselves like e.g. trying to add ATmega4809 support to #116 as an experiment (Not sure how feasible this is at this point) ...

[Rahix]

Okay, unfortunately we're hitting a bit of a road-block with this board right now: The version of avr-libc that's distributed most commonly does not contain the CRT (C runtime) for avrxmega3. The version shipped by Arduino does, but telling people they need to use a custom compiler/toolchain will probably not end well.

So, to move forward with this, I think the next logical step is something that was inevitable anyway: To get rid of our dependence on the C runtime and instead rewrite it in Rust (yay). I'll look into this eventually, but I want to get #129 rolling first, so I'll have to push this back a little, unfortunately.

Maybe we can find a way to hack around this by using a different CRT in the meantime...

[Rahix]

Okay, I was able to get a blinky working by using a CRT for a different MCU + architecture but this feels super fragile and is not something I'd want to label as "proper support" in any way... So I think waiting for the non-C runtime is probably the better solution here...

[leo60228]

I believe Arduino uses Atmel's fork of avr-libc: https://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en611560

[Rahix]

Well possible... In any case we want to drop our dependency on avr-libc and roll an implementation of our own in avr-device. I think working on that will be the most straight forward path, instead of trying to depend on a forked version of a C runtime.

[TobiasDeBruijn]

Hey there,

Thanks for all the effort on avr_hal. I just purchased a bunch of Every's and wanted to toy around with them. Nothing serious, Is there any update to getting this working? Currently I can't get avr_hal to even program the Every:

/dev/ttyACM0 - Arduino_LLC_Arduino_Nano_Every_025D4E0D515146544E4B2020FF0D0D2F

$ cargo run -- -P /dev/ttyACM0
    Finished dev [optimized + debuginfo] target(s) in 0.02s
     Running `ravedude nano -cb 57600 target/avr-atmega328p/debug/arduino-client.elf -P /dev/ttyACM0`
       Board Arduino Nano
 Programming target/avr-atmega328p/debug/arduino-client.elf => /dev/ttyACM0
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00

Not sure if I'm missing anything, but

[leo60228]

avrdude's support for newer AVRs is very buggy and from what I've seem it's borderline unmaintained. Adding support for pymcuprog in ravedude might be nice. That's Microchip's official open-source CLI programmer for PIC and AVR, which generally works better than avrdude when supported, but only has partial support for older AVRs and has limited programmer compatibility.

[leo60228]

Though, it looks like you're building a binary for avr-atmega328p. That definitely won't work.

[TobiasDeBruijn]

I'll be honest, I've not got a clue what it is I'm doing :joy:

[leo60228]

In that case, you probably don't want to be using Rust on AVR, especially on a currently unsupported platform like the Nano Every. It's currently very early. Hopefully it'll improve with time, but if you want something you can use with Rust now then I'd recommend either following the Embedded Rust Book with an STM32F3DISCOVERY or using atsamd-rs with any ATSAMD board, preferably one compatible with cargo-hf2 like the Adafruit Feather M0. Even if you get a board like the Arduino Nano 33 IoT that doesn't support cargo-hf2 officially, you might be able to install a bootloader that supports it. cargo-hf2 isn't required, though, but it does make things easier.

[TobiasDeBruijn]

Oh I'd love to. Unfortunately I'm 'stuck' with the every. For now I'll use C then, and move to rust as soon as it's supported.

Thanks!

[agausmann]

The version of avr-libc that's distributed most commonly does not contain the CRT (C runtime) for avrxmega3. The version shipped by Arduino does, but telling people they need to use a custom compiler/toolchain will probably not end well.

I've encountered this same issue while working on #357. I also was able to get it working with the toolchain provided by Arduino.

Looks like upstream avr-libc added support for this family earlier this year (https://github.com/avrdudes/avr-libc/commit/960a359d854001399b8fb445a9ad0ce3ea80f4d0) so it will probably be in the next release.

@Rahix If you don't want to merge #139 / #357 to main yet, then in the meantime, would you consider creating a feature branch for avrxmega3 to make collaboration easier? We both wrote the same crate independently 😅. I also saw some discussion about making an unstable feature flag, I would also be okay with that.

[Rahix]

I also was able to get it working with the toolchain provided by Arduino.

Yes, they do ship the support because they need it for the Nano Every.

Looks like upstream avr-libc added support for this family earlier this year (avrdudes/avr-libc@960a359) so it will probably be in the next release.

Interesting! That's good news! But I'm still in favor of dropping the dependency on avr-libc entirely as soon as possible. But at least this means we'll have a stop-gap solution soon.

would you consider creating a feature branch for avrxmega3 to make collaboration easier?

I also saw some discussion about making an unstable feature flag, I would also be okay with that.

Hm, actually I think I'd be fine with merging directly to main. With #139, I just didn't want to do it yet because it was all way too brittle still. But if you/we can build a proper version, I wouldn't hesitate merging it to main. We should just add a disclaimer about using the Arduino toolchain with instructions on how to do that.

[dominikwilkowski]

Hi,

Not sure if Nano Every is the same as the Nano I have (maybe that's even newer?) but I'm getting the same issues described above:

λ cargo run        
    Finished dev [optimized + debuginfo] target(s) in 0.04s
     Running `ravedude nano -cb 57600 -P /dev/tty.usbserial-A10LWGNO target/avr-atmega328p/debug/led.elf`
       Board Arduino Nano
 Programming target/avr-atmega328p/debug/led.elf => /dev/tty.usbserial-A10LWGNO
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00

This is what I got:

[mrbell321]

Not sure if Nano Every is the same as the Nano I have (maybe that's even newer?) but I'm getting the same issues described above:

It is not. The Nano you have is based on the ATMega328 while the Nano Every is based on the ATMega4809. From my understanding The core processor architecture is the same, but most of the built in peripherals and bootloader are different.

[Rahix]

Some good news: https://github.com/avrdudes/avr-libc/issues/890 was fixed upstream. Once the fix trickles down into distro packages, we can maybe move forward on the Nano Every support.