Skip to content

2.2.8 - Important bugfixes
Compare
Choose a tag to compare
@SpenceKonde SpenceKonde released this 21 Feb 16:41
· 60 commits to 2.2.x since this release
2.2.8
185de99
This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

I had hoped that 2.2.7 was stable enough to take my eyes off megaTinyCore, but no such luck. A few critical bugfixes had to get released ASAP.

  • Burn bootloader for Optiboot boards when using the pyupdi style programer (ie, serial adapter with resistor) would report success but not actually write the bootloader to flash. A combination of a defect in the core and a bug in the tooling. We are waiting for a fix on the tooling bugs but in the meantime it was found to be possible to prevent to bug from manifesting by correcting the recipe used to build the command.
  • 2.2.7 introduced a regression in constrain() that caused this macro to not compile. This issue has been corrected.
  • The TCD "no glitch" feature added a few versions ago introduced a regression in the handling of the INVEN (INVert ENable) bit, whereby digitalWrite on a pin used by TCD0 for PWM would unset that bit, in order to properly turn off PWM output which might be outputting 100% HIGH while still connected to the timer, which we do in order to avoid having to briefly stop the timer so we can access the TCD0.FAULTCTRL register; we want to unset it if its set when we turn off PWM.... but not if the user has set it for some other reason! This bug is corrected now - it will only touch INVEN if it is disconnecting pin from timer at same time.
  • Found a nasty bug in the routines for TCA0 PWM - has been there for ages, but first glance over how the compiler implemented it, it could have a dramatic effect on the performance of analog and digital writes to pins - problem came down to a "variable shift" - if you ask for 1<<7 that will get optimized to a constant with that value at compiletime. But if you do 1<<x and x is not known at compiletime... that is a LOOP! At least 4 cycles per iteration assuming it's a byte; more for larger datatypes. I definitely hadn't realized that when I wrote the code in question. By looking up the bitmask instead of bit position, substantial performance improvement was realized, as well as flash savings.

In an effort to control hosting costs which I think are being driven by the github actions CI testing, I've tried attaching the avr-gcc toolchain version used by megaTinyCore and DxCore to this. Let's see if they let me get away with this....

Assets 3
Loading