Auto-get atpacks, get+process DA-series atpack, files for recent issues (but see within - I don't know how to make it use them)

[SpenceKonde]

This includes modification to scripts that go and grab the specified atpacks from microchip website with wget (not sure why this wasn't done before? other than the extra / in URL?) instead of requiring manual downloading and conveying them to build server.

Also grabs the DA-series atpack and processes the files in it and adds lines to io.h

This also includes the FILES to fix #66 and #67, and a problem with eeprom.h - but I just don't know how to make the scripts use those replacement versions of the files.... I have checked that things seem to work with those versions of the files work with those versions of the files.... Let me know if any questions!

[SpenceKonde]

The key files are in the descriptively names "alsoneeded" directory...

[facchinm]

Hi @SpenceKonde ,
I really like this PR and I'd merge it directly but I have a couple of doubts:

1. replacing the files in this way is a bit extreme; it would be better to provide patches over microchip's sources instead, to be applied after the files are extracted in the correct place
2. I'm still not sure that wgetting the atpacks from microchip website and bypassing their license agreement is legal, but I'll ask our contacts.

Said that, I'd be glad to build this toolchain using our CI infrastructure; let me know if you can target issue 1 (for the second I'd create a build anyway while waiting for news)

[SpenceKonde]

1. I agree that it is an extreme method, and that patching is better. However, I don't know how to do that - it looks like you use some tool for automatically patching files from the releases, but I'm not familiar with it (I imagine it's probably something common or widely used - but because I don't do much non-embedded programming, that's not so surprising).. But I do know how to modify files so they work, and test that they do. I didn't really expect you to merge it without doing something to make that better (at least a script to replace them, or that patch thing you use, which is probably a better method.

Anyway, yeah, since I didn't know how to do the last step, I dumped it in your lap >.>

2. I mean, the license they make you click through if using a web browser (which is just client-side JS) is an Apache open source license which says "You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications".

[facchinm]

Hi @SpenceKonde ,
I rebased your script, moved the files into proper patches and merged in staging. The build is running, but I'd send you a preview before going live.
Which OS do you prefer?

[facchinm]

In fact I couldn't wait and published them in megaavr json; feel free to test from there and report any issue you may find, thanks!

[SpenceKonde]

Awesome! Thank you! I will check it out tonight and let you know! Very exciting, especially since I'm planning to drop the initial DACore release within a week.

[SpenceKonde]

Hmm - unfortunately it doesn't seem to include the fixes to the linker scripts (changes to avrxmega3.* is needed to make most of the tinies work correctly, avrxmega4.* for AVR-DA), nor does it include AVR-DA stuff...

[SpenceKonde]

Ooooooh! The json is still pointing to arduino6 not arduino7

[SpenceKonde]

Hmm, I tried editing it and hosting it myself with it pointing to arduino7 avr-gcc package, and pointing the IDE to that json file in preferences, but it doesn't want to show the new version when I do that... Can you switch your json file to point to arduino7 to use the new compiler package, and I'll give it a spin with DA-series hardware? Thanks

[facchinm]

@SpenceKonde done, 1.9.9 now points to toolchain 7.3.0-atmel3.6.1-arduino7 😉

[SpenceKonde]

Awwww yeaaaaah!
Now we're cooking with gas! 🤘

eeprom.h, power.h look good, linker scripts look good, and I can compile for DA-series parts!

[SpenceKonde]

3208/3209/1608/1609/808/809 compile too!

So #66 and #67 should be sorted out by this!

[SpenceKonde]

Is there any reason I can't start pointing new versions of megaTinyCore to the arduino7 toolchain package?

[facchinm]

No reason except it's not yet in the official json, so you need to duplicate it instead than just referencing 🙂 I'll move to the right json as soon as I finish rebuilding the arm64 toolchain

[facchinm]

@SpenceKonde the toolchain is now in official package_index.json, so you can simply add it to your core by specifying

          "toolsDependencies": [
            {
              "packager": "arduino",
              "name": "avr-gcc",
              "version": "7.3.0-atmel3.6.1-arduino7"
            },

without any dependency on other jsons

[facchinm]

I'm closing the PR since the commits were manually merged