2.6.0 withdrawn, 2.6.1 will be released soon.
Hence 2.5.11 is again latest.
This fixes two critical bugs that were present in 2.5.10.
- First, and foremost, it fixes the attachInterrupt bug with the new implementations.
- Secondly, It fixes a related issue in the SPI library which led to horrible bloat of the SPI library; this was intended to go in at the same time as the attachInterrupt changes, but the porting from DxCore was missed. It removes support for disabling a single specific interrupt only during an SPI transaction. Note that you are free to manually do so, and the result will take far less than the 800 bytes wasted by the general implementation. And could be used on any interrupt(s) not just a single pin interrupt that was attached (one should try to avoid attachInterrupt entirely if possible as it is both slow and inefficient. This allows the attachInterrupt changes to reap the full flash size benefits that motivated it.
Additionally few other significant changes went in:
- By unanimous demand of users (a large discussion yielded many voices in favor of this change, and not one against it), pinMode no longer emulates classic AVR behavior (where turning on the pullup set the output register, so when then flipped to output, the pin would be HIGH. The consensus in that thread was that a sketch relying on that behavior is in the thing acting in error.
- Fixes several issues with the compatibility macos provided to paper over microchip's crazed need to alter the names of their registers and bitfields without changing their function.
- The asset names for the Microchip board definitions was broken (exported hex/lst/map files)
- Apparently, a small number of libraries expect to be able to pick up our hardware serial class from HardwareSerial.h and expect the class to be named HardwareSerial - that's never been what it was called on modern AVR cores, however rather than being addressed at the core level, this was being handled on an adhoc basis by individual libraries - we now provide a "band-aid" header to fix this issue in the form of HardwareSerial.h - which #defines HardwareSerial to USARTClass and includes USART.h.
- Updates to tinyNeoPixel to improve technical correctness of assembly. During this investigation, I realized that while the timing cannot be made perfect, it can still be made good enogh down as low as 4 MHz. No, I'm not sure what someone would be doing running at 4 MHz with a string of neopixels connected - clearly they don't care about power consumption, because neopixels are power hogs even when off, and it is implausible that 8-10 MHz wouldn't be within spec at any voltage that would successfully drive neopixels - but the technical challenge was small and there was no penalty imposed on users running a other speeds.
- The API for the USERSIG libraries on the tinyAVR and Dx-series parts had been incompatible. It is now possible to write portable code for that library without #fdef's wrapping calls to USERSIG.flush() etc. Functions specific to the erase granularity (or lack thereof) of te DX-series parts were mirrored here. This is explained in detail in the USERSIG library docuementation.