spellcheck

megaavr/extras/Errata.md

@@ -31,7 +31,7 @@ Issue is mitigated in relevant API functions, but the workaround is distasteful
 * 4 - *Serious Impact*
 These issues are those that impact most or all users of the relevant peripheral, and for which no complete workaround will provide the functionality the datasheet described, and Microchip has confirmed by including it on errata or directly that they do consider it to be a bug, and this isn't just a really bad feature working as intended. Issues of 4 and 5 severity have a significant adverse impact on users.
 * 5 - *Critical Impact*
-This bug is impossible to avoid or nearly impossible to avoid if you are using the peripheral. We cannot work around it for the general case, if it can be worked around at all; any workaround is likely to have sideffects or have other limitations. If it's covered by the API, we don't handle it. These level of issue threaten to render parts unsuitable for impacted use cases. These may also be 4's with aggrevating factors like poor description in the errata, and/or particularly perverse and/or surprising  behavior (I'm looking at the RTC)
+This bug is impossible to avoid or nearly impossible to avoid if you are using the peripheral. We cannot work around it for the general case, if it can be worked around at all; any workaround is likely to have sideffects or have other limitations. If it's covered by the API, we don't handle it. These level of issue threaten to render parts unsuitable for impacted use cases. These may also be 4's with aggravating factors like poor description in the errata, and/or particularly perverse and/or surprising  behavior (I'm looking at the RTC)
 
 
 ## Errata Groups
@@ -51,7 +51,7 @@ Errata apply to a specific die. But the same die may be used on multiple parts,
   * all 32k
 
 ## The grand combined table, now readable
-[**The table is now in Google Sheets and publically viewable - color coded too!**](https://docs.google.com/spreadsheets/d/1N-dDZ3WogEXRYcOip5kOREj_ExPQQRD1OrgMuywjXzw/edit?usp=sharing)
+[**The table is now in Google Sheets and publicly viewable - color coded too!**](https://docs.google.com/spreadsheets/d/1N-dDZ3WogEXRYcOip5kOREj_ExPQQRD1OrgMuywjXzw/edit?usp=sharing)
 
 
 

megaavr/extras/Ref_Timers.md

@@ -167,7 +167,7 @@ They can be pressed into service as a rather poor PWM timer. TCB in PWM mode is
 **Errata Alert** - `TCBn.CCMP` is effected by silicon errata on all available silicon save the DD and EA-series: It still acts like a 16-bit register. That means that it uses the TCB.TEMP register for access, and that you must read and write both bytes together, starting with the low byte, then high byte: Writes to the low byte are redirected to the temp register, reading the low byte copies the high byte of the CCMP register to TEMP, and writing to the high byte is what copies the low byte from the TEMP register to the actual CCMP register low byte. However, if you only write the high byte, and write the low byte only once, writes to the high byte alone do work. Until you do something like reading the CNT register, at which point everything will fall over.
 
 #### Extra features on 2-series and Dx/Ex-series
-The tinyAVR 2-series and Dx parts add three upgrades, two useful, and the other less-so. The less useful one is a separate OVF event/interrupt source. I find this to be of dubious untility - likely the best use of the separate OVF bit is as a 17th bit in input capture mode, but this can generally be done without using it as an interrupt.
+The tinyAVR 2-series and Dx parts add three upgrades, two useful, and the other less-so. The less useful one is a separate OVF event/interrupt source. I find this to be of dubious utility - likely the best use of the separate OVF bit is as a 17th bit in input capture mode, but this can generally be done without using it as an interrupt.
 
 A much more interesting option is the clock-on-event option: The TCBs now have a second event user, which can be selected as the clock source! Combined with the CCL, this can, for example, be used to get a prescaled system clock into the TCB different from that of a TCA (see the Logic library documentation and examples for discussion of how the CCL filter and synchronizer can be used to generate s prescaled clock).
 
@@ -693,7 +693,7 @@ uint8_t _getCurrentMillisTimer();
  * sleepTime library two additional options will be possible: TIMERRTC and TIMERPIT. These are
  * returned in the unlikely event that this is called when sleeptime has been sleeping with RTC
  * timekeeping and hasn't switched back yet.
- * See Apppendix I. */
+ * See Appendix I. */
 (macro) MILLIS_TIMER
 
 /* This is the value (from appendix I - anything that _gCMT() can return except TIMERRTC and TIMERPIT, but including TIMERRTC_INT, TIMERRTC_XTAL, and TIMERRTC_EXT. These indicate that the RTC is *permanently* the millis source (mTC only).
@@ -764,7 +764,7 @@ Whenever a function supplied by the core returns a representation of a timer, th
 
 0 (`NOT_ON_TIMER`) will be returned by digitalPinToTimer() or digitalPinToTimerNow() (herafter: dPTT and dPTTN) if the specified pin has no timer.
 
-`*` Currently, the 3 low bits are never set to 1. However, this may change in the future. There are unfortunately two three-bit pieces of information vying for the same three data bits, and which piece of information you want depends on what you're doing, and is only trivial to determine for TCA0: the waveform output channel (0-2 or 0-5) or the mux option (0-6) that points to that pin, . No other timer will ever be numbered 0x10-0x17, nor 0x08-0x0F. 0x18-0x1F is reserved for hypothetical future parts with a third TCA. Hence to test for TCA type: `(timerType = MILLIS_TIMER & 0xF8; if (timerType || timerType < 0x20) {timerType = 0}` will give either `NOT_ON_TIMER`, `TIMERA0`, `TIMERA1`, or in the future, potentially `TIMERA2`. Note that dPTT does not report on the TCAs at all on DxCore (unlike megaTinyCore) - only dPTTN does, because dPTT needs to be a macro (or at least constant/compiletime known and foldable) otherwise it causes problems with other code that relies upon it being a macro (often without realizing it), or which produce really bad output from that. But at compiletime, you have no idea which timer the TCAs are on - you don't know that until you call analogWrite, which calls the function dPTTN()
+`*` Currently, the 3 low bits are never set to 1. However, this may change in the future. There are unfortunately two three-bit pieces of information vying for the same three data bits, and which piece of information you want depends on what you're doing, and is only trivial to determine for TCA0: the waveform output channel (0-2 or 0-5) or the mux option (0-6) that points to that pin, . No other timer will ever be numbered 0x10-0x17, nor 0x08-0x0F. 0x18-0x1F is reserved for hypothetical future parts with a third TCA. Hence to test for TCA type: `(timerType = MILLIS_TIMER & 0xF8; if (timerType || timerType < 0x20) {timerType = 0}` will give either `NOT_ON_TIMER`, `TIMERA0`, `TIMERA1`, or in the future, potentially `TIMERA2`. Note that dPTT does not report on the TCAs at all on DxCore (unlike megaTinyCore) - only dPTTN does, because dPTT needs to be a macro (or at least constant/compile time known and foldable) otherwise it causes problems with other code that relies upon it being a macro (often without realizing it), or which produce really bad output from that. But at compile time, you have no idea which timer the TCAs are on - you don't know that until you call analogWrite, which calls the function dPTTN()
 `**` What was described above regarding including the TCA mux option would look much like this. Notice how we split the byte up into, effectively,
 `***` A hypothetical part with multiple DACs with output buffers will extend this by increasing the count.  into 0x8x.
 `@` Planned for future use. All 0x9x values are reserved for future applications of the RTC and/or PIT and not other new kinds of timers to be determined at a future date.