Add Support for AVR-EA

[uwezi]

I would like to use PlatformIO with the AVR-EA series of microcontrollers, using plain-C/C++ without the Arduino framework.
It appears to me that it should be easy to create a corresponding .json file and avr-gcc should already support the chips from this family. Also the DXCore (again, which I don't need) supports the AVR-EAs.

• But where would I need to place such a .json file?
• Or is it possible to just create an appropriate platformio.ini file with all the necessary settings?

[valeros]

Hi @uwezi, take a look at this page.

[uwezi]

Hi @uwezi, take a look at this page.

thanks for the answer, I know that I yeas ago already got lost in the nested configuration scheme of platformio. At that point I wanted to create an environment for me which uses the plain ATmega328 with no Arduino or any other "framework".

Now it's the same case, I don't want to use the dxcore or any other Arduino stuff or framework, just be able to program the AVR chip in plain C directly. Sadly there are neither examples nor documentation on how to achieve this. For the existing AVR64DA28 I found a solution by changing the platformio.ini of the project with the following settings, stripping out the framework= and applyingthe solution to issue #66:

[env:AVR64DA28]
platform_packages = platform/toolchain-atmelavr@^3.70300.220127
platform = atmelmegaavr
board = AVR64DA28
board_build.f_cpu = 4000000UL
upload_protocol = custom
upload_flags = -cserialupdi
  -p64da28
  -PCOM4
upload_command = "C:\Program Files (x86)\AVRDUDESS\avrdude.exe" $UPLOAD_FLAGS -U flash:w:$SOURCE:i

but when trying to modify a copy of the AVR64DA28.json into something like

{
  "build": {
    "core": "dxcore",
    "f_cpu": "4000000L",
    "mcu": "avr64ea28",
    "variant": "28pin-standard"
  },
  "hardware": {
    "oscillator": "internal"
  },
  "frameworks": [
    "arduino"
  ],
  "name": "AVR64EA28",
  "upload": {
    "maximum_ram_size": 6144,
    "maximum_size": 65536,
    "protocol": "custom",
    "flags": "-cserialupdi -p64da28 -PCOM4",
    "command": "\"C:\\Program Files (x86)\\AVRDUDESS\\avrdude.exe\" $UPLOAD_FLAGS -U flash:w:$SOURCE:i"
  },
  "url": "https://www.microchip.com/en-us/product/avr64ea28",
  "vendor": "Microchip"
}

platformio complains

Resolving AVR64EA28 dependencies...
Tool Manager: Installing platform/toolchain-atmelavr @ ^3.70300.220127
UnknownPackageError: Could not find the package with 'platform/toolchain-atmelavr @ ^3.70300.220127' requirements for your system 'windows_amd64'

How does a completely stripped down version of a working .json file look like with just the essentials to invoke the correct version of avr-gcc?

[uwezi]

Tool Manager: Installing platform/toolchain-atmelavr @ ^3.70300.220127
UnknownPackageError: Could not find the package with 'platform/toolchain-atmelavr @ ^3.70300.220127' requirements for your system 'windows_amd64'

but it is already there... the directory C:\Users\uwezi\.platformio\packages\toolchain-atmelavr contains this version, I also made a copy of the complete directory and named it C:\Users\uwezi\.platformio\packages\toolchain-atmelavr@3.70300.220127 yet still PlatformIO always wants to revert to revert to toolchain-atmelavr@1.70300.191015

Please, I don't want to go back to Microchip Studio, nor to manual .make files...

[valeros]

Your board manifest looks fine, the problem is here:

platform_packages = platform/toolchain-atmelavr@^3.70300.220127

It should be platformio/toolchain-atmelavr not platform/toolchain-atmelavr.
The bad news, however, is that the default toolchain doesn't support the AVR-EA series:

avr-gcc: error: device-specs/specs-avr64ea28: No such file or directory

As a workaround you can manually download a proper toolchain package from DXCore that supports the AVR-EA series and replace the default one in this folder C:\Users\YOUR_USER\.platformio\packages\toolchain-atmelavr just keep two files .piopm and package.json.

[uwezi]

Thanks again for your answer - I could swear that I had read that the 3x toolchain supported the AVR-EA chips. I don't seem to find a complete toolchain at the DXCore repository, just the io header files... but there must be a complete toolchain available somewhere, these chips have been on the market now for 3+ years.

I plan to use PlatformIO with my students in the autumn semester, preferably with the AVR-EA chips, since they seem to be more readily available than the corresponding AVR-DA chips right now. But if I cannot manage to get this running, how should they... I guess I have to stay with the AVR-DA and hope to find a supplier in time...

[valeros]

I believe these are the toolchain packages that support AVR-EA:

{
          "name": "avr-gcc",
          "version": "7.3.0-atmel3.6.1-azduino7b",
          "systems": [
            {
              "size": "38113733",
              "checksum": "SHA-256:936e74042f77da04b54723a2f34cf541f02c076d47dba0325f4ccfa3b93650a3",
              "host": "aarch64-pc-linux-gnu",
              "archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino7b-aarch64-pc-linux.tar.bz2",
              "url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino7b-aarch64-pc-linux.tar.bz2"
            },
            {
              "size": "34736688",
              "checksum": "SHA-256:326eed20d14ad28807f2b0e355f79f2570a448073d706e66cfc9a52e20b5b8eb",
              "host": "arm-linux-gnueabihf",
              "archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino7b-arm-linux-gnueabihf.tar.bz2",
              "url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino7b-arm-linux-gnueabihf.tar.bz2"
            },
            {
              "size": "37307286",
              "checksum": "SHA-256:0c448287cd340966f74db9469e8de00ceff49b08d6909568edf64a881a9ac72b",
              "host": "i686-pc-linux-gnu",
              "archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino7b-i686-pc-linux.tar.bz2",
              "url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino7b-i686-pc-linux.tar.bz2"
            },
            {
              "size": "37926737",
              "checksum": "SHA-256:c49b00ec3cf91136944188547696fe93558b20d8e852882b259331f2aacaadde",
              "host": "x86_64-apple-darwin14",
              "archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino7b-x86_64-apple-darwin14.tar.bz2",
              "url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino7b-x86_64-apple-darwin14.tar.bz2"
            },
            {
              "size": "37967368",
              "checksum": "SHA-256:0d4cd92e17c639f5881f784af4ea030765c2a93a2debd42a59710b71c9967512",
              "host": "x86_64-pc-linux-gnu",
              "archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino7b-x86_64-pc-linux-gnu.tar.bz2",
              "url": "https://github.com/SpenceKonde/DxCore/raw/gh-pages/avr-gcc-7.3.0-atmel3.6.1-azduino7b-x86_64-pc-linux-gnu.tar.bz2"
            },
            {
              "size": "41618613",
              "checksum": "SHA-256:c643dd4657bd1a62438b22cfa05790aaf250f620d6cb2e956d193796ec81d5fc",
              "host": "i686-w64-mingw32",
              "archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino7b-i686-w64-mingw32.tar.bz2",
              "url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino7b-i686-w64-mingw32.tar.bz2"
            }
          ]
 }

IMO, it might make sense for you to fork this platform and specify your own toolchain packages that you can convert from the links above. Then your students will need to specify your fork in their platformio.ini files, for example:

[env:avr-ea]
platform = https://github.com/uwezi/platform-atmelmegaavr-avr-ea.git

This will significantly improve overall developer experience, but bear in mind that this approach requires a bit of Python skills to set proper toolchain for each OS and architecture in the platform.py file.

[uwezi]

I found these update packages from Microchip - will try to get it running with these. Plan B is to stick with the AVR-DA for now and hope that Microchip at some point releases a complete toolchain...
https://packs.download.microchip.com/

I will update this topic here with my findings, as well as my homepage and git

[uwezi]

ok, directly using the Microchip packages does not work:

Most of the AVR8 devices are supported by this toolchain. Users can get new devices support from Microchip
Device Family Packs (DFP). Download DFPs from here1.
Using DFPs with this toolchain:
● Download DFP which has required device support. (e.g. ATmega328PB is part of ATmega Series DFP.)
● Unzip downloaded *.atpack file to packs directory (e.g. /home/packs/).
● Invoke avr-gcc with additional option -B to tell gcc where to look for device specific information and -I for
device header include path.
e.g. avr-gcc -mmcu=atmega328pb -B /home/packs/Atmel.ATmega_DFP.1.0.86/gcc/dev/atmega328pb/ -I /
home/packs/Atmel.ATmega_DFP.1.0.86/include/

The following block in the .json file results in a "directory found where file expected" error during the creation of a new project

  "build": {
    "extra_flags": "-B D:/Programming/platformio/packs/Atmel.AVR-Ex_DFP.2.11.221/gcc/dev/avr64ea28/ -I D:/Programming/platformio/packs/Atmel.AVR-Ex_DFP.2.11.221/include/",
    "f_cpu": "4000000L",
    "mcu": "avr64ea28",
    "variant": "28pin-standard"
  },

[uwezi]

Blink blink - success!

• I downloaded and unpacked the toolchain from https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino7b-i686-w64-mingw32.tar.bz2
• I then made a backup copy of the existing "default" toolchain under .platformio/packages/toolchain-atmelavr which contained the 3.7 toolchain
• I replaced the directories within the original .platformio/packages/toolchain-atmelavr with the files from the download
• I used the following board-definition .json:

{
  "build": {
    "f_cpu": "4000000L",
    "mcu": "avr64ea28",
    "variant": "28pin-standard"
  },
  "hardware": {
    "oscillator": "internal"
  },
  "name": "AVR64EA28",
  "upload": {
    "maximum_ram_size": 6144,
    "maximum_size": 65536,
    "protocol": "serialupdi",
  },
  "url": "https://www.microchip.com/en-us/product/avr64ea28",
  "vendor": "Microchip"
}

• I then still got the error message

[8/6/2025, 5:10:57 PM] Unable to resolve configuration with compilerPath "C:/Users/uwezi/.platformio/packages/toolchain-atmelavr@1.70300.191015/bin/avr-gcc.exe".  Using "cl.exe" instead.

since platformio still wanted to access the old toolchain, in spite of two newer ones installed in toolchain-atmelavr and toolchain-atmelavr@3.70300.220127
So I modified platformio.ini

[env:AVR64EA28]
platform_packages = platformio/toolchain-atmelavr
platform = atmelmegaavr
board = AVR64EA28

• this now let me write code with completion and highlighting, I also could compile the code, but the upload failed avrdude: Can't find programmer id "custom"
• it seems that giving the upload settings in the .json file always invokes the older avrdude provided by platformio, which does not support the serialupdi protocol. The "command": settings seems to be ignored.

So back to what worked before, changing the platformio.ini to

[env:AVR64EA28]
platform_packages = platformio/toolchain-atmelavr
platform = atmelmegaavr
board = AVR64EA28

gave me my first blinking LED on an AVR64EA28.

Summary:

• it would be nice if the options and structure of the board.json files and the platformio.ini were documented somewhere in a clear manner. How do settings in the one file correspond to settings in the other?
• the avrdude supplied in packages/tool-avrdude-megaavr is currently still v6.3 and thus does not support the protocol serialupdi yet this protocol is actually referred to in platforms/atmelmegaavr/builder/main.py

[valeros]

since platformio still wanted to access the old toolchain, in spite of two newer ones installed

This is probably because you didn't keep the .piopm and package.json file or replaced a wrong package.

it seems that giving the upload settings in the .json file always invokes the older avrdude provided by platformio

How did you come up with the command field in your json file? It's not possible to set a custom upload command in the .json file. A proper way is to use upload_command that should be used in your platformio.ini if you need a special upload command.

How do settings in the one file correspond to settings in the other?

There is no direct connection between the board manifest board.json and the platformio.ini file. But platformio.ini can be used to override the default settings specified in the .json file.

yet this protocol is actually referred to in platforms/atmelmegaavr/builder/main.py

You need to use a newer version of the tool-avrdude-megaavr package (it still v6.3 but has support for serialupdi):

platform_packages = 
  tool-avrdude-megaavr @ ~3.60300.0

[uwezi]

since platformio still wanted to access the old toolchain, in spite of two newer ones installed

This is probably because you didn't keep the .piopm and package.json file or replaced a wrong package.

Actually, I did...

How did you come up with the command field in your json file? It's not possible to set a custom upload command in the .json file. A proper way is to use upload_command that should be used in your platformio.ini if you need a special upload command.

it was trial-and-error, finger crossing and hopes

How do settings in the one file correspond to settings in the other?

There is no direct connection between the board manifest board.json and the platformio.ini file. But platformio.ini can be used to override the default settings specified in the .json file.

Is there a way to put the desired toolchain into the board.json manifest? I know now that I can add the line
platform_packages = platformio/toolchain-atmelavr@^3.70300.220127

to the platformio.ini, but I would much prefer to have it inside a dedicated board.json file, but neither of the two following attempts did work - the rest of the file, including the upload using "serialupdi" works fine for me now...

{
  "build": {
    "f_cpu": "4000000L",
    "mcu": "avr64da28",
    "variant": "28pin-standard"
  },
  "packages": "platformio/toolchain-atmelavr@^3.70300.220127",
  "hardware": {
    "oscillator": "internal"
  },
  "name": "AVR64DA28 4MHz serial UPDI",
  "upload": {
    "maximum_ram_size": 8192,
    "maximum_size": 65536,
    "protocol": "serialupdi"
  },
  "url": "https://www.microchip.com/wwwproducts/en/AVR64DA28",
  "vendor": "Microchip"
}

{
  "build": {
    "f_cpu": "4000000L",
    "mcu": "avr64da28",
    "packages": "platformio/toolchain-atmelavr@^3.70300.220127",
    "variant": "28pin-standard"
  },
  "hardware": {
    "oscillator": "internal"
  },
  "name": "AVR64DA28 4MHz serial UPDI",
  "upload": {
    "maximum_ram_size": 8192,
    "maximum_size": 65536,
    "protocol": "serialupdi"
  },
  "url": "https://www.microchip.com/wwwproducts/en/AVR64DA28",
  "vendor": "Microchip"
}

I found a workaround by modifying the .platformio/platforms/atmelmegaavr/platform.json file, but I don't know how stable this modification is against possible future updates of PlatformIO...

from

  "packages": {
    "toolchain-atmelavr": {
      "type": "toolchain",
      "owner": "platformio",
      "version": "~1.70300.0",
      "optionalVersions": ["~3.70300.0"]
    },

to

  "packages": {
    "toolchain-atmelavr": {
      "type": "toolchain",
      "owner": "platformio",
      "version": "~3.70300.0"
    },

(I know I must be as annoying by now as I feel sometimes towards users of Manim, where I am helping out with support questions....)

[valeros]

Is there a way to put the desired toolchain into the board.json manifest?

Unfortunately, it's not possible.

but I don't know how stable this modification is against possible future updates of PlatformIO...

Overall, I'd suggest you fork this repo and tweak the code to fit your needs. That way, your students can focus on their projects instead of wrestling with setting up a proper development environment.

[uwezi]

Overall, I'd suggest you fork this repo and tweak the code to fit your needs. That way, your students can focus on their projects instead of wrestling with setting up a proper development environment.

I am afraid I lack the competence to do this....

[valeros]

@uwezi I've prepared a fork for you https://github.com/valeros/platform-atmelmegaavr-ea with all necessary changes. It's basically a dev-platform for the EA series with a custom toolchain. I can transfer it to your account so you can fine tune it for your needs.