Why is 2.0.0 not available through the Arduino board manager?

[felias-fogg]

Hi,

I am just wondering why the new core is NOT available through the board manager.

Cheers,
Bernhard

[SpenceKonde]

Cause it is not done.
And it appears to be a solo effort so it is taking a very long time for me to complete. I desperately need people to do manual installs and help test it - (it's not like mTC or DxC where the version of the toolchain that the IDE comes with won't work, or where other tools needto be installed by board manager like ), I have no idea whether most parts work at all, and the changes involved were unprecedented and massive, 1.x.x actually consists of TWO cores, which put different things into the variant files, and did all sorts of things differently. I suspect there are many showstoppers that need to be fixed, but I am just not getting any help finding them, and that's really slowing things down.

At least one breaking change was introduced intentionally - analog pin numbers behave differently now (the way analog pins work on 1.x.x is fucked up - analogRead(10) reads analog channel 10, which may be on any pin, instead of reading from the analog channel on digital pin 10, and A10 is simply #defined as 10. Everyone who I explained this to has agreed with my change, and most thought it worked like that already or hadn't noticed because they use An constants - I now have an ADC_CH() macro (for clarity) that bitwise OR's with 0x80, and that's fast to test for in analogRead() - and it provides a way to use up to 127 analog channels, allowing use of differential ADC channels by passing a constant (listed in the part specific documentation) to analogRead instead of a pin number.
And 1.5.4 was inconsistent in it's distribution of the PIN_Pxn defines (for every pin n in port x, we define PIN_Pxn as that digital pin number, so you can use the datasheet or other references that don't assume an arduino pinmapping without constantly crossreferencing which pin is which.) - on some parts it was PIN_xn, which was no good, because Arduino started using PIN_An for "the digital pin number that analog pin number n is on". Now PIN_An should be defined as the Arduino official core does, and the PIN_Pxn defines should all point to the proper pin for all pin mappings

(note that this is just a constant defined to a digital pin number - it's defined in the variants, like on DxC and mTC. Except that we need 18 variants for just 21 parts because there are so stupid many pinmappings - because digital pin numbers and analog pin numbers were user facing and never should have been. That's why I don't put the digital pin numbers onto the pinout diagrams for DxCore :-P The whole concept of user facing pin numbers that are arbitrarily chosen by the core author is a fucking disaster, one of the worst decisions made by the Arduino team (and they make a lot of bad decisions. Very few good ones, actually), and this led to terrible pinmap proliferation on the classic AVRs. And where Arduino made the first move, they fucked it up again on the modern parts. They used the ATmega4809 for the uno wifi rev 2 and the nano every - but with perverse and terrible choices made and no logical order to the whole mess, and then Thinary's m4808 "nano every" used their own stupidass pin numbering scheme, when there an obviously correct numbering scheme on the modern parts (unlike the classic AVRs, where they look to have distributed ports and special functions to the pins by throwing darts at a package diagram while blindfolded, the modern AVRs are if anything TOO consistent in their pin mappings. You can just hear the AVR Pin Czar inside Microchip cracking the whip at any engineer who dared to suggest deviating from the One True Pinout... It seems that the new rules are that the physical<->logical pin mapping shalt not be changed, and that if any part has a peripheral, it shalt be located on it's home pins., and if the part doesn't have those pins, either it doesn't get to have any pins associated with the peripheral (occasionally modern AVR peripherals can still be useful in that case), or a new pin mapping option, selectable through the applicable PORTMUX register, shall must be created and made available on this and all future parts, or if they don't like either of those options, their only option is the copout like they did on the AVR DD-series's ZCD peripheral. The pins that ZCD0, 1, and 2 are on don't exist on the low pincount DD's, but they didn't want to be stuck with alternate input mappings, or maybe there are implementation complications that prevent them from easily moving the ZCD input pins around - whatever the reason, they wanted a ZCD, didn't have the input pin for ZCD0, ZCD1, or ZCD2, and the Pin Czar wouldn't permit them to change the input pin on ZCD's 0-2 for just the DD-series. So what did they do? They made the peripheral "ZCD3" and then they were free to pick whatever pins they wanted - there had never been a part that shipped with a ZCD3, so the Pin Czar had no reason to object to wherever they wanted to put the pins.

Digital pin numbers should never have been user facing, the pin identifiers should be chosen to reduce compiled binary size and improve performance, especially with some of these parts having only 2k of flash.... Bah

[felias-fogg]

I see. Well, I am using your new core and I have not encountered a problem yet (on different parts). But then one probably would like to have a large set of tests and then try them out on all the different parts. If I could be of help, please say so.

[felias-fogg]

Maybe one could set up a test battery of sketches and run them through the simavr simulator (which would need to be extended to cover all the ATTinyCore cores)?

[SpenceKonde]

What we really need is for anyone with hardware to:

• Test bootloaders if that part has em, Upload three different sketches using the bootloader. First sketch must be shortest, the second the longest, and the third the shortest, and it should run each sketch normally.
• Upload sketches that quickly verify that analogWrite() works on all pins is is supposed to with that pin mappen. You can do something like this be reading the PINx register for a port after turning on PWM. Poll that bit until you see a 1, then poll it until you see a 0. if the pin was not changing, this would never exit, you'd like to add a micros timeout to break out after a timeout. If it doesn't timeout, and you in initialization set all the pins output, and have nothing else on the device that would change it's pins, if each part passes without timeouts, that means analogWrite gives you some kind of PWM. You could even go further and count the pwm cycles, so if any of the speeds are way off, it'll flag them too
• It the part is an 841, 441, 1634, try uploading a sketcg like

void loop() {
  if Serial.available() {
    while( Serial.available() ) {
      Serial1.write(Serial,read); 
    }
   if Serial1.available() {
  while( Serial1.available() ) {
    Serial.write(Serial1.read); 
  }
}

in that small number of parts that applies to, it is an excellent test. whatever you throw into Serial should get spit out Serial1 and vise versa. It should work.

Single hardware serial ports should get a loopback test

void loop() {
  while( Serial.available() ) {
    Serial.write(Serial,read); 
  }
}

software serial port]s are a little trickier. as they can't send and receve at the same time...

Compile the most complicated sketch you can maybe something from one of your projects. for which there is no reason it shouldn't build for a given part. Report offending parts and configuration options

The more bugs this can catch the better Good sketches will be used for CI (good as in causes lots of failures if stuff is busted)

Make sure differential ACD readings work, provided the hardware supports it (most tinies do). It's pretty simple, you'd just set up two reference voltages (generated likely with a string of resistor dividers - 3 resistors would get 2 voltages. You would then want to make sure they were within half a volt of eachother for BIN mode using the 1.1v reference). For the super easy option, 10k 1k 10k At 5v, you'd get .238V difference between the two middle voltages, centered on 2.5. Any classic AVR advertising differential ADC should . Read value make sure answer plausible (if you write the sketch with certain resistor values in mind, you can very quickly verify sane values

[felias-fogg]

Sounds like a plan. I guess, we would need a group of people sharing the load, right? Perhaps, we would need a list of sketches (or a program to generate them) and then a list of untested MCUs/bootloaders that need to be tested. Then people could start to go down the list.

Cheers

[SpenceKonde]

Yeah I mean just in the past week we've had 4 bugs reported that are release blockers.

[felias-fogg]

I am thinking about building two Mega shields that can host all the ATiny MCUs. One could then run automatically test scripts on all the parts, whereby the Mega board is controlled by a Mac or Linux machine. I will not be able to start to work on that before October, though.

[SpenceKonde]

Why a mega? Wouldn't you want to use an AVR128DB64 instead?

[felias-fogg]

Well. The Mega board is lying around for some time and wants to do something. And it would be perfectly capable for its purpose.

[SpenceKonde]

Well, I like the idea of using a chip to do ACTUAL HARDWARE TESTS, that's one last thing that we lack. I don't expect to catch subtle things like that, but the bugs that are reported usually lack much semblance of subtlety. Just checking that 1ms was about 1ms, checking for gross defects in the pin mapping, (eg, compiled sketch will try to turn on pins from 0 to NUM_DIGITAL_PINS-1), testmaster expects to see the pins appear in the correct order or the pinmappins aren't consistent. cionfirming that PWM was PWM at a frequency in the vague vicinity of what we expect, that kind of thing, would be a really valuable test setup.

[MCUdude]

Why don't release a 2.0.0-beta1 version? Users will get notified in Arduino IDE, and they will quickly realize that 2.0.0 is in fact a beta release. Some will give it a spin, and hopefully report bugs they find, while others will wait for a stable 2.0.0 release. It is virtually impossible to get to a 100% "bug-free" codebase, but you can get pretty close if users are willing to install the beta version through that 1-click boards manager install.

And Optiboot is a dead horse (okay not dead, dead). I don't see a good reason to continue pushing Optiboot on classic ATtinys when they will brick themselves at some point. Urboot is rock solid, and I'm ready to ditch Optiboot completely and release a 3.0.0 version of MightyCore, MiniCore, MegaCore, and MajorCore.
All the work has been done, I'm just waiting for Arduino to release statically built versions of Avrdude 7.2, which I think my cores deserve. And since the Urboot bootloader supports EEPROM uploads, users can upload content to EEPROM straight from their sketch using the EEMEM attribute.

MicroCore has provided Urboot support since April 2023, and there has not been reported a single bootloader-related issue.
256 bytes for a modern, stable bootloader that "just works" on classic ATtinys? Yes, please!

Stefan (who wrote Urboot) has been very helpful in the migration process, and I'm sure he'll provide ATTinyCore flavored hex files for you if you reach out to him.

[ospilos]

Of course, MCUdude is right. Not releasing V2.0.0 as a beta in the .json is plain stupid idea. Not being in the .json, there will never be enough testers of V2.0.0 beta. Therefore it will not be included in the .json, as it is not thoroughly tested. Catch 22.

[NT7S]

Thanks to @MCUdude for the pointer to Urboot. I tried one of the precompiled bootloaders for ATtiny85 at 8 MHz internal osc, and I've been able to use it with the latest avrdude to successfully manually load sketches created with this board support package and a CH210X UART bridge. It seems rock solid in the small amount of testing that I've done. Please do consider adding support for Urboot. I'll happily test it for you, just ping me if you ever add it.

[MCUdude]

Urboot has been the only bootloader bundled with my cores for a few months now. The only valid complain I've received is that performing a manual reset is trickier than with Optiboot due to the smaller bootloader timeout. But there's no reason to deal with manual reset when auto reset works so well. Actually, when using Avrdude 7.2 or newer, the DTR/RTS line can be connected directly to the AVR reset pin, without the famous 100nF capacitor.

And if manual reset is important, it s just a matter of loading a different pre-compiled Urboot binary with a longer timeout duration.

Bottom line:
Migrate to Urboot. It's rock solid, and solves all issues with the Optiboot bootloader faces on the ATtiny chips. And if Spence would release a v2.0.0 alpha/beta release, the community would do most of the testing, and a stable 2.0 release could actually be within reach in 2024.

Happy new year! 🎉

[NT7S]

Yeah, I connected my CH210X DTR line to reset (through the 100 nF cap) and it still worked like a dream. No manual reset necessary. I'll have to try it with the cap removed.

HNY!