Current status

[SpenceKonde]

Right now - things mostly compile again. Unfortunately, that's about it. Behavior is hopelessly hosed.

Timing and serial are both completely broken. I've managed to get serial output, but the characters are coming out in the wrong order.

Okay, I think serial works, at least on transmitting

millis needs to be kept disabled though

[SpenceKonde]

Timekeeping still busted.

Have made some significant improvements in terms of making things compile, though testing coverage on most of the AVR DD line can't be completed until a beta release is made, so that the test scripts can install the compiler version that they need.

I am thoroughly baffled by the myriad bugs that appeared, often in files I didn't know had been changed.

[SpenceKonde]

I have opened a few new issues - if anyone has any background that might help them provide clarity on the "help wanted" issues I just created - at this point the only way I know of to fix the problem is to remove the library, and that's not much of a solution.

I didn't even change these files, so why are they failing on parts that they used to work fine on?!

[ITDiscovery]

Ok…I have two boards parted out, and hooked them up to UPDI. Blink won’t compile. It’s getting late, so stay tuned, but don’t bother commenting until I can get some solid details posted tomorrow.

[SpenceKonde]

It might be picky about the toolchain package version - The most recent one (being used for 1.5.0 dev, and which is used by megaTinyCore 2.6.x, and will be installed with 1.5.0) has different names for a bunch of registers. I tried to catch all of them with macros in core_devices.h, but I may have missed some.

device-spec errors mean a really old toolchain (too old to even have the 64DDs, much less the new names for their registers) is being used

[ITDiscovery]

Whelp..I'm betting that your guess is pretty close. I am indeed using the old ArduinoIDE (1.8.13), but I think it may be that core_devices.h is not catching the config of the AVR64DD28 correctly. I get the error:

Oddly, this didn't change when disabling the "Flash Writing" option.
.../1.4.10/cores/dxcore/core_devices.h:426:4: error: #error "Unrecognized combination of flash size and chip type"#366

From the code, that can only happen in this code block:

#elif   (PROGMEM_SIZE == 0x20000 && (defined(__AVR_DA__) || defined(__AVR_DB__))) || (PROGMEM_SIZE == 0x10000 && (defined(__AVR_DD__) || defined(__AVR_DU__)))
  #define   CORE_PART_ID (CORE_PART_ID_LOW | 0x20) /* 128k DA/DB, 64k DD/DU */
#elif   (PROGMEM_SIZE == 0x10000 && (defined(__AVR_DA__) || defined(__AVR_DB__))) || (PROGMEM_SIZE ==  0x8000 && (defined(__AVR_DD__) || defined(__AVR_DU__)))
  #define   CORE_PART_ID (CORE_PART_ID_LOW | 0x10) /*  32k DA/DB, 16k DD/DU */
#elif   (PROGMEM_SIZE ==  0x8000 && (defined(__AVR_DA__) || defined(__AVR_DB__))) || (PROGMEM_SIZE ==  0x4000 && (defined(__AVR_DD__) || defined(__AVR_DU__)))
  #define   CORE_PART_ID (CORE_PART_ID_LOW | 0x00)
#else
  #error "Unrecognized combination of flash size and chip type"
#endif

So after making sure that I had the latest (at least in this area), I added:

#elif   (PROGMEM_SIZE ==  0x10000 && (defined(__AVR_DD__)))
  #define   CORE_PART_ID (CORE_PART_ID_LOW | 0x10)  /*Specific to 64k DD */

I'm not really following why your conditional doesn't work, but the fix does get it past the "Unrecognized" error (and then I get a whole host of other errors). I did note you've been updating this file recently. I will setup a dev environment on a different box, so that I can test against what your developing against, instead of the current production version. Anyway...looking forward to your continued efforts.

[SpenceKonde]

Yeaaah. There were some ugly versions of that file (and it's gigantic now. because microchip went and changed the name of a bunch of bitfields, and that's where we try to stuff all the part-specific crap. Like changes in abbreviations in the names? Really? You're going to break compatibility for that? Not just once. Three times for some bitfields.

Current version of core in github compiles and now has basic functionality intact on Arduino 1.8.13 with azd6 toolchain.

[ITDiscovery]

I'll check it out. Thanks.

[SpenceKonde]

Having an absolute hell of a time making the improved pinConfigure work with the previous syntax... several hours of work in, i've got it complaining about multiple definitions of functions only defined once, and it's saying there's a problem in digital_pin_to_bit_mask(), won't give me a source line because of LTO, doesn't error without LTO, and.... digital_pin_to_bit_mask is an array not a function!

This and integrating the new pinout images are the only things between now and a 1.5.0 release

[SpenceKonde]

ARGH! It's not properly processing the includeguards for some reason