`megaavr` support

[Floessie]

Hi Phillip,

I recently got hold of some AVR128DB28. Though they are pretty new, Spence Konde already supports them with DxCore. They belong to the megaavr family of controllers that feature a PIT instead of a WDT.

I'm trying to port the Arduino_FreeRTOS_Library to the PIT and have started a branch here. It's completely WIP, but already compiles and runs for a few ticks.

The first nicety I came across was that megaavrs have a "Timer/Counter type B" which is defined as TCB_t in the toolchain headers. :unamused: I've thus renamed FreeRTOS' TCB_t, but there must be a better workaround.

Now the problem is the premature halt after some ticks. Seems like the serial freaks out although there's no output from the blink task, then the PIT interrupt stops. Can you give me some hints concerning debugging or architectural differences between avr and megaavr?

Best, Flössie

[feilipu]

Hi Flössie,

I'd suggest to have a look at the FreeRTOS port specifically for Mega0. This came in #101. It would give some guidance on how the newer Timer capabilities are being configured.

It does raise the philosophical discussion on the rationale for this library. My original thought was (and still is) to keep it really simple for people just starting out with FreeRTOS. So, keeping close to the avr-libc capabilities, and generalised hardware made sense.

I pushed back on older ATmega devices previously, because they don't have WDT interrupt capabilities, even though they are supported by avr-libc. And here we have a case where the Mega0 devices don't have avr-libc support, nor do they have a standard WDT interrupt, which would mean creating a special case just for this variant.

I guess the pragmatic answer is knowing whether or not the Arduino IDE supports the required Timer control libraries without requiring additional cores, or other specialities? And if there is standardised support, perhaps it is worth bringing that in here?

Thoughts?

[Floessie]

Hi Phillip,

I'd suggest to have a look at the FreeRTOS port specifically for Mega0. This came in #101. It would give some guidance on how the newer Timer capabilities are being configured.

Ha, good point. There is even one for the AVR-Dx series.

I pushed back on older ATmega devices previously, because they don't have WDT interrupt capabilities, even though they are supported by avr-libc. And here we have a case where the Mega0 devices don't have avr-libc support, nor do they have a standard WDT interrupt, which would mean creating a special case just for this variant.

PIT is the new WDT: :wink:

~/.arduino15/packages/DxCore/tools/avr-gcc/7.3.0-atmel3.6.1-azzy1/avr/include/avr$ rg -l PITCTRLA
iotn817.h
iotn816.h
iotn807.h
iotn814.h
iotn804.h
iotn416.h
iotn414.h
iotn417.h
iotn3217.h
iotn406.h
iotn404.h
iotn212.h
iotn412.h
iotn402.h
iotn3216.h
iotn214.h
iotn202.h
iotn204.h
iotn1627.h
iotn1617.h
iotn1614.h
iotn1626.h
iotn1616.h
iotn806.h
iotn1604.h
iotn1606.h
iotn1607.h
iom809.h
iom808.h
iom4809.h
iom4808.h
iom3209.h
iom3208.h
iom1609.h
iotn1624.h
ioavr32da28.h
ioavr64da32.h
ioavr64da28.h
ioavr32da32.h
ioavr64da48.h
ioavr64da64.h
ioavr32da48.h
ioavr128db64.h
ioavr128db32.h
ioavr128db48.h
ioavr128db28.h
ioavr128da64.h
ioavr128da48.h
ioavr128da28.h
ioavr128da32.h
iom1608.h

My brute port has too many #ifdefs for sure, but this could be organized much cleaner: a set of header and implementation for avr and one for megaavr.

I guess the pragmatic answer is knowing whether or not the Arduino IDE supports the required Timer control libraries without requiring additional cores, or other specialities? And if there is standardised support, perhaps it is worth bringing that in here?

What do you mean by "Timer control libraries"? Something like an RTC lib for the 4809 based Arduinos in the core?

[feilipu]

What do you mean by "Timer control libraries"? Something like an RTC lib for the 4809 based Arduinos in the core?

Just an equivalence for these avr-libc headers and macros, which abstracts for the AVR-Dx series, so that the user doesn't have to wrangle separately them to the Arduino IDE. .

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/sleep.h>
#include <avr/wdt.h>

[AndreiCherniaev]

see also

[feilipu]

Updated email sent to a user.

To answer your question, the ATmega4809 is not currently supported, because it doesn’t have a traditional WDT as found in prior generations of the AVR architecture.

I’m keen to support the ATmega4809 devices found in the newer Arduino Uno and Nano platforms. For some time I was a bit sceptical, as Arduino seemed to be jumping on new hardware on a weekly basis, wherever they could get some sponsorship money from. But now it seems they’ve settled on the ATmega4809.

There are two partner supported ports of FreeRTOS in the repository for the new architecture (one for the AVR_AVRDx specifically), but neither of them are using the Windowed WDT. So I will need to do some further investigation to see whether the Arduino core configures any or all of the platform Timers (0 through 5 RTC), which would clash with the FreeRTOS Tick Timer configuration.

https://github.com/FreeRTOS/FreeRTOS-Kernel-Partner-Supported-Ports/tree/main/GCC

If you like you could play around with merging the code from the AVR_AVRDx port into the Arduino_FreeRTOS_Library? But be aware of config clashes with Arduino core code.

I’m away from computers for the next 3 weeks, and I don’t own a 4809 Uno, so it will be a while before I can actually make any commits to support the board you need. But, I will use my holiday for some background reading, and will order a new Nano Every device to wait for me to return home.

Happy New Year

[feilipu]

While an issue with the ArduinoCore-megaavr code is being resolved, it is possible to use the method described by Tom in his instructions to get FreeRTOS working with ATmega4809 devices. This method will require you to modify the ArduinoCore-megaavr code to be successful.

[feilipu]

It seems that Arduino has given up on 8 bit machines.

The announcement of the Uno R4, including a WIFI option, seems like the final straw.

[Floessie]

Still, the AVR-Dx are often enough. :slightly_smiling_face: