Aaaaah the new versionof the spell checker

Author: SpenceKonde

ContributionGuidelines.md

@@ -242,7 +242,7 @@ Particularly within the core API, performance matters. That means that things li
 | Multiplication |       8 |       22 |       81 |      371 |   141 |
 | Division (avg) |     233 |      235 |      604 |     1734 |   479 |
 
-Seriously, those are not typos or mistakes on the division line (and the time is non-constant). Addition of two 8-bit values takes 5 clocks, their multiplication 8, and their division, on average, 233. Clearly somethings being promoted to 16-bity, but even there the numbers are 14, 22, and 235. Large binary size and slow execution are closely correllated, so avoiding doing bad kinds of math will help both.
+Seriously, those are not typos or mistakes on the division line (and the time is non-constant). Addition of two 8-bit values takes 5 clocks, their multiplication 8, and their division, on average, 233. Clearly somethings being promoted to 16-bity, but even there the numbers are 14, 22, and 235. Large binary size and slow execution are closely correlated, so avoiding doing bad kinds of math will help both.
 
 The obscenely slow division of 32-bit datatypes is why micros has all that ugly assembly in it - division was way too slow. So we used a combination of bitshifts and addition, and used tricks to minimize the size of the operands at all times. But the compiler rendered it as an incredibly inefficient mess. (a + (a >> 1) + (a >> 2)) was rendered as (copy a to a temp register. Then copy it again, rightshift that once, add to temp register. Copy the original, replacing that singly rightshifted version. Rightshift twice, and add). Instead of simply rightshifting the intermediate value another place and repeating the addition.
 

megaavr/cores/megatinycore/main.cpp

@@ -132,7 +132,7 @@ int main() {
 /**************************************************************************************************
  * INITIALIZATION FUNCTIONS LOCATED ANYWHERE SPECIAL GO HERE!                                     *
  *                                                                                                *
- * They *MUST* be declared with both the ((naked)) ahd ((used)) attributes! Without the latter,   *
+ * They *MUST* be declared with both the ((naked)) and ((used)) attributes! Without the latter,   *
  * the optimizer will eliminate them. Without the former, the sketch will not start...            *
  * Wait what? Yeah, it was generating a and outputting a ret instruction, which caused the        *
  * sketch to return to nowhere under certain conditions and never reach main() at all.            *
@@ -158,7 +158,7 @@ int main() {
   * megaTinyCore. You must write to flash    *
   * using optiboot if required               *
   *******************************************/
-      // if we are, we also need to move the vectors. See longwinded deascription above.
+      // if we are, we also need to move the vectors. See long-winded deascription above.
       void _initThreeStuff() {
         init_reset_flags();
         _PROTECTED_WRITE(CPUINT_CTRLA,CPUINT_IVSEL_bm);

megaavr/extras/ImportantInfo.md

@@ -39,7 +39,7 @@ We only officially support (and test on) the Arduino IDE. Other IDEs are often u
 * [Arduino-cli](Arduino-cli.md) is an official command-line version of Arduino. This guide was submitted by @dattasaurabh82 - THANKS!
 
 ## General information
-* [Change Log](../../ChangeLog.md) weith listings of all changes that I remembered to record.
+* [Change Log](../../ChangeLog.md) with listings of all changes that I remembered to record.
 * [README](../../README.md) **(READ IT)** This is the main documentation which describes the state of the standard Arduino API functions and general caveats and key information about these parts, as well as special features of this core. There are sections of that file covering most significant areas of megaTinyCore, including sections on I2C, SPI, and reading analog voltages, including the advanced functionality of the ADC in the 2-series parts, and much more.
 * [Making UPDI programmer](../../MakeUPDIProgrammer.md) These (unless running Optiboot) require a UPDI programmer, not a classic SPI programmer like a USBAsp/etc. Fortunately a dirt cheap serial adapter can be used as a UPDI programmer - or a cheap nano clone can be loaded with jtag2updi - either way gets you a UPDI programmer for the cost of a cup of coffee.
 * [Direct Port Manipulation](Ref_DirectPortManipulation.md) Like with the classic AVR parts, you can use direct port manipulation for ultra-fast read and write from pin. The names of the registers are different, and there are some additional caveats, but also some improvements, and the pins and their interrupts are, overall, more powerful.

megaavr/extras/Ref_Digital.md

@@ -74,7 +74,7 @@ Anyway, the takeaways I intended from this are:
 * The I/O pins we have are a hell of a lot better than the ones classic had, and they're getting better
 * The I/O pins on the Dx-series in particular are spectacularly strong, and they have greatly improved resilience to clamp current across the board. 
 * Pin drive is not symmetric. This has ramifications for the design constraints on an RC filter used to make analog voltages out of PWM. 
-* The section of the datasheet where they are talking abou 
+* The section of the datasheet where they are talking about 
 
 
 ## Now we can talk about the digital I/O features supplied by the core 
@@ -279,7 +279,7 @@ These are the maximum voltage guaranteed to qualify as `LOW` and the minimum gua
   * The actual lower threshold is likely to be higher, and the upper threshold lower. For example, on DA-series SMBus pins, those voltages are 1.09 V and 1.24 V over most of the operating voltage range. This leave you with very little hysteresis, if that happens to be problematic.
   * If interacting with an output that for whatever reason struggles to pull the pin as close to ground as an ideal output should, or if you're counting on the transition being somewhere near the middle of the range, definitely don't use this option.
 
-Particularly in the context of these MVIO-equipped parts, however, the TTL input level option has an obvious major advatage: It makes communication with parts that run at lower voltages easier, and reduces competition for the limited number of MVIO pins. If we allow the low part to control it push-pull (aka totam-pole and other names), and treat it as an `INPUT`, we will always read what they intend. The fact that you can switch a pin between input and output, while pulling it up externally was noted above, and the voltage it was pulled up to could be the lower operating vboltage. That can be done on any AVR. But with INLVL, this scheme is viable for a bidirectional line: the The line between devices could either be pulled up to the lowest operating voltage externally, with the DB or DD series part manipulating the pin as an open drain output (see above). One need not stop with just two devices - multiple DB/DD-series parts with `INVLV = TTL` set could communicate with multiple devices operating at the low voltage, as long as none of them ever drove it `HIGH` (though, if it was low, they would not know which device was doing that. The designer would have to make sure this approach made sense in that regard, and that everything was smart enough to not hold onto the line or anything.
+Particularly in the context of these MVIO-equipped parts, however, the TTL input level option has an obvious major advantage: It makes communication with parts that run at lower voltages easier, and reduces competition for the limited number of MVIO pins. If we allow the low part to control it push-pull (aka totam-pole and other names), and treat it as an `INPUT`, we will always read what they intend. The fact that you can switch a pin between input and output, while pulling it up externally was noted above, and the voltage it was pulled up to could be the lower operating vboltage. That can be done on any AVR. But with INLVL, this scheme is viable for a bidirectional line: the The line between devices could either be pulled up to the lowest operating voltage externally, with the DB or DD series part manipulating the pin as an open drain output (see above). One need not stop with just two devices - multiple DB/DD-series parts with `INVLV = TTL` set could communicate with multiple devices operating at the low voltage, as long as none of them ever drove it `HIGH` (though, if it was low, they would not know which device was doing that. The designer would have to make sure this approach made sense in that regard, and that everything was smart enough to not hold onto the line or anything.
 
 ## PINCONFIG and associated registers (Dx, Ex only)
 This section applies only to DxCore. megaTinyCore users should skip this unless they want to drool over the new features in those Dx-ey new parts.

megaavr/extras/Ref_Reset.md

@@ -3,7 +3,7 @@ Various reset sources are available, these conditions trigger a "hardware reset"
 
 Note that a necessary consequence of the dirty-reset guard is that a duplicate guard will break, because the only way any dirty reset can be detected is if the reset flag register has been cleared before the dirty reset occurs. So in order to catch any dirty reset that could occur in bad user code, we must reset the reset flags first. Since checking and resetting the reset flags is essentially not present in the wild, despite being a basic and simple safeguard against the most severe and difficult to understand bugs, while properly the responsibility of an application, is performed by the core. Three behaviors have been used by various bootloaders. It is the opinion of the author of this document and the majority of this core that only one is correct.
 1. The bootloader may do nothing. This is clearly a bug on classic AVRs (the bootloader takes longer than 16ms to run and, having neither reset the WDT nor turned it off, resets endlessly - this is an odd course of action for a bootloader to take, since the bootloader frequently exits by using), but was present on the original nano and pro mini bootloaders, which is why these boards are generally bootloaded as if they are Unos. On modern AVRs, this does not cause overt misbehavior, however neither does it prevent it. It is fully up to the app to detect and mitigate dirty resets (which as noted is essentially unhearof, and I do not expect to upgrade the wetware of every arduino user, especially when, as in this case, the correct response is always the same - You issue a software reset, because you are in an unmitigated error condition. This error condition occurs specifically because of something unforeseen and unintended occurring in code.
-  a. Intentionally triggering a dirty reset was dangerouns and inadvisable practice on classic AVRs to workaround the bug in early bootloaders that failed to handle the WDRF properly; the correct course of action is to bootload those devices as Unos or using MiniCore, and use the WDT to reset, not to trigger dirty resets directly by jumping to 0x0000.
+  a. Intentionally triggering a dirty reset was dangerous and inadvisable practice on classic AVRs to workaround the bug in early bootloaders that failed to handle the WDRF properly; the correct course of action is to bootload those devices as Unos or using MiniCore, and use the WDT to reset, not to trigger dirty resets directly by jumping to 0x0000.
 2. The bootloader clears only WDRF. If a classic AVR, it turns off the WDT. Other reset flags left in place. This was used by Optiboot classically, and is, for example, what the Uno does. This achieves minimum functionality but because only WDRF is cleared, it is still left to user code (which can be relied upon not to do it) to clear RSTFR in order not only to detect dirty resets (which as far as I am aware was not done) and decide upon entry to the bootloader. That is to say, on a classic or modern AVR, the bootloader entry conditions are honored only if the user code clears RSTFR. Most users are unaware of this register, and hence do not reset it, and thus once the reset button has been pressed once, EXTRF remains set, until a BOR or POR occurs. Since EXTRF is the entry condition for the bootloader, once the reset button has been pressed once, it will alwaysrun. If PORF is the entry condition, if the user doesn't clear it, every restart will trigger the bootloader, even if the user specifically stated that thy wanted (say) only reset buttomn resets, or only software resets, to enter the bootloader. I consider this to be a bug, as it relies on people alwaystaking actions that hardly any users even know about. Not acceptable.
 3. The bootloader checks the reset flags. If the flags are a non-entry condition (either because WDRF is set, or no entry condition flags are) clear them all, stash their value in GPIOR0, and then jump to the app. This guarantees a clean restart if something causes a dirty one, ensures that entry conditions are always honored, and also puts the results in a stable and sane part of memory (a register that is reset on reset, not reset while transitioning from bootloader to app, can be accessed without inline asm (unlike the "stash it in r2" approach. That'd be just dandy except you can't fish it out of there without writing assembly and then stuffing that assembly into a .init function or callback called from within one) (by the time you're at setup() it's entirely possible that the compiler decided to store something else in the (as far as it knows, unused r2.))). The GPIORs were the only ones that seemed suitable. I also needed somewhere to store two bits that indicated runtime errors from init_clock(). Thus, GPIOR0 gets data stored to it after a reset **but only right after a reset**.
 

megaavr/extras/Ref_Robust.md

@@ -43,7 +43,7 @@ Internal pullups are not sufficient. See the description of UsePulluops() in the
 ### Read the errarta FIRST
 As in, before you're tripping over them and it's gating development or inconveniencing users.
 
-Alwaus hope for fixes to them, but don't depeend on fixes or expect them, because wwe have no idea when those fixes will be coming. Sometimes that future die revision never happens. Once you know what the errata are, you can plan around it and ensure that they don't become showstoppers when you discover them later plan around these issues, and also be aware of the fact that that behavior will change, so you also should not depend on the bug being there forever.
+Always hope for fixes to them, but don't depeend on fixes or expect them, because wwe have no idea when those fixes will be coming. Sometimes that future die revision never happens. Once you know what the errata are, you can plan around it and ensure that they don't become showstoppers when you discover them later plan around these issues, and also be aware of the fact that that behavior will change, so you also should not depend on the bug being there forever.
 
 ### Capacitors are good
 Don't skimp on the decoupling caps. 1x 0.1uF per pair of power and ground. 1uF on the MVIO pin of parts with that feature (other side to ground), and FFS (for Faraday's Sake) be sure to include some "board level" decoupling. The datasheet specifies a minimum of 1uF (for just the chip), in practice, this should really be 4.7 to 10uF, assuming the same supply doesn't have any large loads attached to it. If it does, bigger caps. USB has a limit on how much it allows - only 10uF =before you need inrush current limiting.  If it isn't powered by USB though, you can be a lot more liberal with the capacitors. I put 47 uF on the PCB I use for controlling LEDs, in addition to several times that along the strings of lights. Caps under 10uF should probably be ceramic. Larger caps you can use aluminum electrolytics, though it's recommended to still have a ceramic cap in the 1-10uF range. In the most demanding designs, it is very common to parallel multiple caps of different values. Many chips spec a 0.1uF and a 0.01uF decoupling cap pair on each power pin, and those that don't usually at least "recommend" it.  These are especially helpful for dealing with high frequency (ie, sudden sharp transitions) noise. The lower value caps are better able to supporess high frequency noise.
@@ -54,7 +54,7 @@ The Dx-series parts overclock fantastically well. That should not be an invitati
 ### Check the thickness of the wire you're using
 I don't mean reading the number on the insulation anyone can print "22 AWG" on wire, but that doesn't make it 22 AWG. Strip it, measure the bundle of wire,  separate it to strands, count them, and measure one strand as accurately as you can (need to measure to at least 0.01 mm) and calculate what gauge it actually is. Some dishonest Chinese manufacturers (and probably some in other countries, but China is by far the most prolific producer of everything) frequently use wire 2-6 AWG smaller than the number they print on the insulation.  In order to keep people from immediately noticing (because it's too thin) they make up the difference with extra thick insulation. Cheap hookup wire (UL1007) on AliExpress, for example, is usually 3-4 AWG too thin. Some pre-wired JST-SM connectors I've gotten had what appears to be 32-gauge wire marked 24. I didn't discover this until heat from the load through the too-small wires had resulted in it heating up and turning the red insulation black; when investigating the subsequent failure, I was mystefied as to why there were two black wires instead of a black and a red...
 
-Apparently it's not just wire being exported that's like this - I hear stories of assembled equipment also made with the undersized wire, abd failing as a result. The impression I get is that some of the manufacturers using it don't realize it's undersized (likely they are aware that undersized wire exists, were asserted that the stuff they were getting was not, and maybe even measured it back when they started buying from that supplier...)
+Apparently it's not just wire being exported that's like this - I hear stories of assembled equipment also made with the undersized wire, and failing as a result. The impression I get is that some of the manufacturers using it don't realize it's undersized (likely they are aware that undersized wire exists, were asserted that the stuff they were getting was not, and maybe even measured it back when they started buying from that supplier...)
 
 ### Do not use dupont line in production devices
 At least not the cheap crap normally sold as that. The cheao dupont line is for prototyping only, and barely suitable for that. Real DuPont line with real DuPont terminals is fine (that division is now run by Amphenol, the line is called MiniPV), as long as you make sure you get ones made by Amphenol obtained through a reputable western supply house. They should cost a minimum of 10 cents each in quantiy for no-frills terminals, and typically more like 20-30 for decent gold plated ones. Use the highest spring tension ones unless you have more than 20 pins ins a connector, and make sure that you or your manufacturing partner is doing a good job crimping them on (go try the pull test on some cheap dupont line - most of it doesn't even pass the pull test) If you look at the terminal of real dupont connectors, they are obviously not the same design as the cheap ones.