spell check?!

Author: SpenceKonde

megaavr/cores/megatinycore/core_devices.h

@@ -414,7 +414,7 @@
  * generators allows them to add both options for all ports and both RTC options to all generator channels
  * Too bad they released so many parts with the other versions :-/ */
 
-#if defined(PORTA_EVGENCTRL)||defined(PORTA_EVGENCTRLA) // Starting with EA, they have EVGENCTRL registers onthe PORTS and RTC, so all channels are equal.
+#if defined(PORTA_EVGENCTRL)||defined(PORTA_EVGENCTRLA) // Starting with EA, they have EVGENCTRL registers on the PORTS and RTC, so all channels are equal.
                                                         // Starting with EB, and retroactively changing EA, they renamed them to EVGENCTRLA. Elsewhere we define the other if either one of the two is defined, as we always do when they change spellings.
   #define _AVR_EVSYS_VERSION   (3)
 #elif defined(EVSYS_STROBE) // mega0 - basically Dx, but different name for strobe.
@@ -1001,7 +1001,7 @@ has once worked for the same thing as meaning that thing */
     #define TCA_SINGLE_EVACTA_CNT_HIGHLVL_gc TCA_SINGLE_EVACTA_CNT_HIGHLVL_gc
     #define TCA_SINGLE_EVACTA_UPDOWN_gc TCA_SINGLE_EVACTA_UPDOWN_gc
   #endif
-  // TCA V1.1 - DA/2-series and everthing since
+  // TCA V1.1 - DA/2-series and everything since
   //  with two inputs changes the names the existing ones to specify channel A
   // We add in the non-postfixed ana
   #if !defined(TCA_SINGLE_CNTEI_bm)

megaavr/cores/megatinycore/dirty_tricks.h

@@ -271,9 +271,9 @@ Not enabled. Ugly ways to get delays at very small flash cost.
  *
  * SK: isn't this the architecture specific stuff, which we know is poor for AVR? GCC compiles to an architecture agnostic intermediate form, optimizes that,
  * and then transforms that into the architecture specific output. The first part has gotten a ton of attention because it effects everything. Atmel used to pay
- * people to work on GCC. I do not belive that is still occurring, at least not to the extent it did. Pretty much all of these fall into two categories:
+ * people to work on GCC. I do not believe that is still occurring, at least not to the extent it did. Pretty much all of these fall into two categories:
  * Either we're desperately scrambling for every last cycle, and using knowledge that the computer isn't permitted to, like knowing that we don't need to finish a math
- * opperation on a multi-byte datatype because we just need to low byte or know the high byte will be 0.
+ * operation on a multi-byte datatype because we just need to low byte or know the high byte will be 0.
  */
 
 /************/

megaavr/extras/Ref_Analog.md

@@ -29,7 +29,7 @@ Notes:
 3. No external reference on 0-series and 1-series below 16k.
 4. 16k (1+series) parts are blessed with a number a boons. One of them is a second ADC. I think the intent was to provide a way to approximate having a differential ADC by triggering both at once (well, one of the intents, another one was because the ADC0 is taken over by the PTC if that is in use.
 5. The Dx-series differential ADC is a bad joke. First: The maximum absolute value both voltages is V<sub>ref</sub>, above that, wrong results are returned. And there's no amplification other than what you can press the opamps into service as.
-  **Unsubstantiated and slanderous speculation** My theory is this: The dual ADC on the 1+ series was to get dual ADC field tested because even then they could see that the new ADC was going to be an ordeal. They figured they can get away with 1 generation of chips without explicit differential ADC, but they still needed a way for some friendly customers to be able to do something like a differential ADC reading - and they were going to have to dothat inthe DX - I think the Dx-series parts's "differential mode" is equivalent to two single ended measurements and some simple math) 
+  **Unsubstantiated and slanderous speculation** My theory is this: The dual ADC on the 1+ series was to get dual ADC field tested because even then they could see that the new ADC was going to be an ordeal. They figured they can get away with 1 generation of chips without explicit differential ADC, but they still needed a way for some friendly customers to be able to do something like a differential ADC reading - and they were going to have to dothat in the DX - I think the Dx-series parts's "differential mode" is equivalent to two single ended measurements and some simple math) 
 6. This is a REAL differential ADC. Max V<sub>Ain</sub> = Vdd + .1 or .2V and for useful readings their difference must be smaller than VREF. The tiny2 has some mysterious tunables, proper tuning of which is unclear. Offset error is disappointingly high, which Microchip noticed and introduced sign chopping (and removed a mysterious tunable or two) in the EA series, which should help significantly.
 
 The differential ADC on the Dx-series is disappointing.
@@ -358,7 +358,7 @@ Note that the numeric values, though not the names, of some of these were change
 |Potentially valid reading       |see previous   |                         |                    0 | analogCheckError() will return 0 when passed a 16-bit datatype with a number less than 4096, or a signed 32-bit datatype containing a number between 
 | -                              |             . |                       . |                    - | -2,097,152 and 4,194,303, that is. 4095 * 1024 accumulated samples, or -2048 * 1024 accumulatted samples. (note, millions, 32-bit type can hold billions)
 
-Unsigned column is provided for convenience for those not interested in using the helper function, The reason the numbers are in the middle of nowhere is so we didnt collide with negative differential readings, and they start just below a byte so I can subtract the LSB from 0 to get the error code. 
+Unsigned column is provided for convenience for those not interested in using the helper function, The reason the numbers are in the middle of nowhere is so we didn't collide with negative differential readings, and they start just below a byte so I can subtract the LSB from 0 to get the error code. 
 
 These errors are mostly of the sort that point to a bug in user code or a designer misunderstanding key aspects of the functionality, or something silly like a pin selection issue, or a peripheral conflict trying to use the ADC for two different things. adjacent array in memory? Overclocking too hard such that the chip was doing math wrong?).