we need an "arduino8" with the latest atpacks to support the rest of the DA-series and new DB-series

[SpenceKonde]

https://github.com/SpenceKonde/DxCore is here - the DA parts are fully supported at the core library level! Unfortunately the compiler toolchain package we're using (arduino7) doesn't have support for the smaller-flash DA-series parts, nor the new DB parts that are said to be shipping any day now! (it looks like they are nearly identical to the DA-series.... except that they feature "multi-voltage I/O" - sounds like one port can be supplied at a different voltage than the rest of the chip, acting kind of like a built-in level shifter...Should be really nice for people who are stuck with a mix of 5v and 3.3v parts!

[Floessie]

Now that the AVR-DB parts are available, it would be more than welcome if toolchain-avr supported them. 👍

[facchinm]

Hi @Floessie ,
whould you mind submitting a PR with the added support? You can take inspiration from #68 (cleaned up and merged as 1f9005a...050edef )

[MCUdude]

@SpenceKonde since you know this stuff, would you like to provide a PR so we can get AVR-DB support in the official Arduino AVR toolchain?

[MCUdude]

@facchinm is there anything else that needs to be done to pull the latest AVR-Dx Atmel pack other than bumping the version number to arduino8 and bumping the AVR-Dx specific pack version number to the latest version, 1.6.76 as of today? All the other "AVR-Dx infrastructure" is already here because of 1f9005a...050edef.

If a new version and pack number are all that's needed, I'll happily submit a PR. Please correct me if I'm totally wrong here.

(I tried building the toolchain on my mac by following the instruction in the readme, but I was never able to get it working properly.)

[SpenceKonde]

Know it? Dang, am I that successful at projecting an air of competence?

Do you think I'm actually using the build scripts to generate a working toolchain? Cross-compiling for 5 platforms? Hell no! >.< I run your build script with updated ATpacks, no changes other than auto wget of atpacks. Gives me a toolchain that doesn't seem to work when I try to use it as is.. But it's got the .a and .o files, and the new header, and the device specs. That's all that's needed to add the support for new parts. I take that archive that and extract on linux machine, and delete everything that's an executable binary in x86-64,, as well as everything in avr/include/avr except the io headers (all the diffs are reintroducing bugs that we fixed), and all the linker scripts (nothing compiles with the old binaries and the new linker scripts - not sure what's missing., and then copy that (which consists of io headers, and .a/.o device specs... I could dig up the list somewhere) onto the arduino7 toolchains, and recompress them. And they are able to compile for the new chips!

The official Microchip AVR toolchain is using a new version of avrlibc - a 3.6.2; I am wondering if that's what's missing to make the toolchain work. No idea.... I'm going into this with very little clue, and and a lot of manual effort....

Hell, all I was doing is copying files and it took me three tries to get THAT right! (azduino3)....

I don't know much about how build scripts or these "patch" files work.. or really a lot of other baclkground stuff that one kind of has to know to be able to contribute meaningfully - I am just copying around files and running scripts written by other people in the hopes of being able to cobble together a toolchain package to let people use my core with the parts my core supports, so I can go back to writing embedded c and gratuitous inline assembly.... .

I appear to have been successful on this occasion, after a considerable number of frustrating failures, and leaving an EC2 C5 XXL deployed overnight..
I don't even remember why I say the executable binaries don't work - maybe I don't use them just because I can only generate them for x64 unix? That is entirely possible, I think I came to that decision some time over the summer... Long since forgotten the deets.

[brunob45]

@MCUdude To get the tests to compile in platformio/platform-atmelmegaavr#19, I only had to copy the .a, .o, .h, and specs files into the right location, as @SpenceKonde said. The atpack.Dx.build.bash script is very similar to the python script I made to import atpacks to PlatformIO's toolchain.

As I understand it, only the build.conf file needs to change.
The other packs are also behind, should we update them with the new version?
While building the toolchain on my PC (Debian on Docker), I also saw some files that are missing from the .gitignore, so I would change that file too.

I successfully compiled simple programs for various controllers, selected randomly (including AVR DA & DB, megas & tinys).
Here are the changes I made to build the new toolchain.

I don't know if (or where) I should submit the build I made from the proposed changes, for others to validate.

And once the toolchain is compiled once, we only need to run the atpack*.bash files to patch the new version in, I find that really neat.