Closed brunob45 closed 2 years ago
@valeros @ivankravets isn't it time to step up the game, update your toolchains and finally get proper AVR-Dx support to PlatformIO? I haven't heard from you in almost a year readring this topic. AVR-DA/DB/DD's are the latest and greatest AVRs, and it looks like Microchip is only focusing on these and the tinyAVR-2 series from now on.
DxCore has the latest toolchain with AVR-Dx support, use these binaries.
The framework package is already published in the registry https://registry.platformio.org/tools/brunob45/framework-arduino-megaavr-dxcore
Is it possible to path existing toolchain with missed files? https://registry.platformio.org/tools/platformio/toolchain-atmelavr
It is great that a community-based package can be used, but isn't it kind of important that the next generation AVRs gets added to PlatformIO with official support?
It has been a while since I looked into this, and it looks like @brunob45 did a lot more work with this PR than I did in #18.
The current toolchain needs to be patched or updated. I'm not sure where he keeps the sources, but I know @SpenceKonde's toolchain works (used with the DxCore boards manager install) on all platforms and supports all current AVR DA and DB series. It's just the Arduino toolchain with a (few?) additional Microchips packs applied.
Hi all,
First, thanks for acknowledging my work.
@ivankravets The package was also published in the registry by someone at platformio : https://registry.platformio.org/tools/platformio/framework-arduino-megaavr-dxcore but it is outdated. Any idea why there hasn't been any update for more than a year?
The way I patch atmel's toolchain is with a python script, callable from inside a pio project as pio run -t fixtoolchain
.
This script will
As you can see, all the examples compile fine in the github workflow.
To make things even better, I'd like to know if there is a way to run a python script automatically right after installing a package. That way, I could execute the patching script without the need for the user's manual intervention.
Or even better, we should use a toolchain that is up to date. Maybe SpenceKonde has the answer on this one.
I've said like a million times, y'all are welcome to use the toolchain packages that I supply for DxCore.... And as new parts come out, I update it, so every time there is a significant change that impacts megaTinyCore or DxCore, I make a new version of the toolchain package (using the latest atmega, attiny, dx-series and automotive AVR ATpacks), and it shows up in m board manager json.. I haven't had to do that in quite a while now - The current versions are
"systems": [
{
"size": "41351111",
"checksum": "SHA-256:a0b8a6327a4ce0b2aee3e559a71ea0b61ccecc48e358ec5fac50ba10710981a0",
"host": "i686-mingw32",
"archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino4b-i686-w64-mingw32.tar.bz2",
"url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4b-i686-w64-mingw32.tar.bz2"
},
{
"size": "37878659",
"checksum": "SHA-256:23becaaf746e8cf3b23ebcd261bf52d5eebcc094c3500fe8d533f0911b870c60",
"host": "aarch64-linux-gnu",
"archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino4a-aarch64-pc-linux-gnu.tar.bz2",
"url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4a-aarch64-pc-linux-gnu.tar.bz2"
},
{
"size": "34220996",
"checksum": "SHA-256:dacef5c90b38e6728e2cd161a54133b008352ff6f6513e67ab71f3117331c758",
"host": "arm-linux-gnueabihf",
"archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino4a-arm-linux-gnueabihf.tar.bz2",
"url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4a-arm-linux-gnueabihf.tar.bz2"
},
{
"size": "36887243",
"checksum": "SHA-256:a3f4833034b5526a7375b20fed7031e5fd0ff6956703e7b4bcf48e914fb94d6c",
"host": "i686-linux-gnu",
"archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino4a-i686-pc-linux-gnu.tar.bz2",
"url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4a-i686-pc-linux-gnu.tar.bz2"
},
{
"size": "37530243",
"checksum": "SHA-256:61c9ad88f9e75664fc6b96350dd4b3f95946e1c6eeca2158504aecc515f475a3",
"host": "x86_64-apple-darwin14",
"archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino4a-x86_64-apple-darwin14.tar.bz2",
"url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4a-x86_64-apple-darwin14.tar.bz2"
},
{
"size": "37412841",
"checksum": "SHA-256:60d879e7052db01383cd89c54e46fa20c81ca180e20a8c0a681ffecec20c24d8",
"host": "x86_64-linux-gnu",
"archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino4a-x86_64-pc-linux-gnu.tar.bz2",
"url": "https://github.com/SpenceKonde/DxCore/releases/download/1.3.4/avr-gcc-7.3.0-atmel3.6.1-azduino4a-x86_64-pc-linux-gnu.tar.bz2"
}
The files that you need only rehost somewhere and use are thus: https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4b-i686-w64-mingw32.tar.bz2 https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4a-aarch64-pc-linux-gnu.tar.bz2 https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4a-arm-linux-gnueabihf.tar.bz2 https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4a-i686-pc-linux-gnu.tar.bz2 https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4a-x86_64-apple-darwin14.tar.bz2 https://github.com/SpenceKonde/DxCore/releases/download/1.3.4/avr-gcc-7.3.0-atmel3.6.1-azduino4a-x86_64-pc-linux-gnu.tar.bz2 (the x64 linux i hosted on github because 99% of it's extremely heavy use is from the automated CI tests - it's to githiub's distinct advantage to keep it within their network as I understand it.
I don't know what's needed to host files, but is there a reason why we can't host all the toolchains as part of Github releases, just like your version for x86 Linux?
All I could find is that individual files must be under 2GB, and there are no download quota... https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases#storage-and-bandwidth-quotas
Sorry if I missed something obvious...
Thanks @brunob45 for the PR, merged with slight modifications according to the latest changes in DxCore v1.4.5.
Hello
Any idea for a date with latest DXCore versions supporting AVR_DD parts?
Regards Ltr
Basically the same thing as #18, but I changed the link to the framework to my own repo (a branch of DxCore), so everyhing is working correctly.
I made this example to test easily.
I don't want to steal @MCUdude's work, I just happened to work on the same thing, and wanted to use the framework right now. Maybe we can help eachother?