You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: ChangeLog.md
+16-11Lines changed: 16 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,27 +20,32 @@ These items are in addition to what was listed under changes already in release.
20
20
* If there are *other substantial changes that need to occur* within the core, I am unaware of the complaints and hence have no plans to address them before the heat death of the universe. If you desire changes on a more rapid timeline, please create an issue so that I am aware of the presence of said problem, deficiency, or imperfection. Those form the action item list for core development activity, so if something is not listed there, **it is unlikely to be implemented/fixed/etc** simply due to my being unaware of any concern.
21
21
22
22
## Unreleased changes
23
-
Changes listed here are checked in to GitHub ("master" branch unless specifically noted; this is only done when a change involves a large amount of work and breaks the core in the interim, or where the change is considered very high risk, and needs testing by others prior to merging the changes with master - everything else goes straight into master). These changes are not yet in any "release" nor can they be installed through board manager, only downloading latest code from github will work. These changes will be included in the listed version, though planned version numbers may change without notice - critical fixes may be inserted before a planned release and the planned release bumped up a version, or versions may go from patch to minor version depending on the scale of changes
23
+
Changes listed here are checked in to GitHub ("master" branch unless specifically noted; this is only done when a change involves a large amount of work and breaks the core in the interim, or where the change is considered very high risk, and needs testing by others prior to merging the changes with master - everything else goes straight into master). These changes are not yet in any "release" nor can they be installed through board manager, only downloading latest code from github will work. These changes will be included in the listed version, though planned version numbers may change without notice - critical fixes may be inserted before a planned release and the planned release bumped up a version, or versions may go from patch to minor version depending on the scale of changes.
24
24
25
-
### Planned 2.6.11
26
-
* Pending: New toolchain version.
25
+
The 2.6.11 release is pending, following that the next version will by 2.7.0.
26
+
27
+
## Released Versions
28
+
29
+
### 2.6.11 (release pending)
30
+
* New toolchain version.
27
31
* Make wiring.c have the functions referred to in the doc.
32
+
* Split the three ugly functions that constituted 60% of wiring.c into a separate file, because finding anything else with those #ifdef-hell-spawned abominations is awful.
33
+
* General cleanup of wiring.c and timers.h for maintainability.
28
34
* Fix some of the constants for timers so that all timers can still get uniform codes specifying the portmux and (for non-TCA's) which pin within the mux it is, which matters for the other core.
29
35
* Documentation improvements.
30
-
* Corrected bug sometimes encountered when using serial under atypical cases the causes of which remain mysterious), where it would complain about `__poll_dre_done`.
36
+
* Corrected critical bug in the TCD0 millis option (the default on 1-series parts) (#1243)
37
+
* Corrected bug sometimes encountered when using serial under atypical cases the causes of which remain mysterious), where it would complain about `__poll_dre_done`. (#1226)
31
38
* Correct bug with Comparator (#1236)
32
39
* Correct numerous issues with the microchip board defs. Clearly nobody is using them - since 2 of them didn't compile, and none of the optiboot ones would ever be able to successfully be programmed over the bootloader because selfprogramming wasn't enabled (BOOTEND = 0).
33
-
* Major Bugfix: Correct issue #1164 thanks to John Vasileff. This would cause Serial.flush to hang in one-wire mode.
40
+
* Major Bugfix: Correct issue #1164 thanks to John Vasileff. This would cause Serial.flush() to hang in one-wire mode.
34
41
* Major Bugfix: Correct buffered PWM on all parts.
35
-
* Major Bugfix: Correct PWM on non-default pins on all parts; digitalPinHasPWM.
36
-
* Fix bug with CCL clock source.
37
-
* Fix bug with Comparator
42
+
* Major Bugfix: Correct PWM on non-default pins on all parts; digitalPinHasPWM() macro.
43
+
* Fix bug with CCL clock source selection options.
38
44
* Enhance documentation
39
-
* Removed example of exactly the sort of boneheaded and strictly-worse in a trivial part of Wire. While it was merely a bad example at the time it was written, it is now known to be a bad, dangerous example, because it featured code that demonstrated Strictly Worse access to registers, by loading a vport register to a pointer register, and using that - not only is it stupid and just a less-featureful PORT when accessed that way, avoiding pointer access to the I/O space (64 addresses, - 28 VPORTs and 4 GPIORs in low I/O and SP, RAMPZ (if applicable), CCP (the register used for `__PROTECTED_WRITE()`}), and of course the SREG. And indeed, none of those are registers that anyone should ever access using a pointer, even if it didn't wasn't safe against an incredibly scary bug - the low I/O is all about the bitwise instructions, which need both the register and bit compile time known. `VPORT_t*` is not a type you should ever declare - if you have had to declare it, *you get no benefit* from faster access to it (like you do if you use the compile-time known VPORT's amd access them without pointing. )
45
+
* Correct critical problem with timekeeping on parts with a TCD. (#1243)
46
+
* Removed example of exactly the sort of boneheaded and strictly-worse code I rail against in a trivial part of Wire. While it was merely a bad example at the time it was written, it is now known to be a bad, dangerous example, because it featured code that demonstrated Strictly Worse access to registers, by loading a vport register to a pointer register, and using that - not only is it stupid and just a less-featureful PORT when accessed that way, avoiding pointer access to the I/O space (64 addresses, - 28 VPORTs and 4 GPIORs in low I/O and SP, RAMPZ (if applicable), CCP (the register used for `__PROTECTED_WRITE()`}), and of course the SREG) is necessary due to an erratum effecting all AVRxm parts. And indeed, none of those are registers that anyone should ever access using a pointer, even if it didn't wasn't safe against an incredibly scary bug - the low I/O is all about the bitwise instructions, which need both the register and bit compile time known. `VPORT_t*` is not a type you should ever declare - if you have had to declare it, *you get no benefit* from faster access to it (like you do if you use the compile-time known VPORT's amd access them without pointing. )
40
47
* Enhance error messages from wrong-part on upload.
41
48
42
-
## Released Versions
43
-
44
49
### 2.6.10 - Critical fix
45
50
* Critical bugfix: Switch to using Azduino7c, which is the same as the Azduino7b binary, but with the correct CRC attached.
46
51
* Bugfix: #1014, named constants for ADCPowerOptions() did not work on 0/1-series parts. The 4 valid options are now given named defines, and the rest are #defined as `badArg("This option is on 2-series tiny and AVR Ex-series only")`
0 commit comments