spelling gramar format

Author: SpenceKonde

.github/workflows/compile-examplesEx.yml

@@ -164,7 +164,7 @@ jobs:
           - 32
         # Filter out these matrix combinations
         exclude:
-          # Things we cant get yet
+          # Things we can't get yet
           - device-family: ec
           - device-family: la
           # Things w/out xtals

megaavr/extras/DU14.md

@@ -1,10 +1,10 @@
 # AVR32DU14/AVR16DU14 AVR DU - That's U for USB
 These are one of those parts that leave you very little ambiguity about whether it's the right part for the job. Do you need USB? Then you need to DU the DU, cause as far as AVR is concerned, it's this, or classic AVR, and nobody wants to use those. And the DU-family of parts is absolutely a respectable product line. But the fact remains, that if you don't need USB, there is something cheaper, better at what you do need, usually both. USB exacts a very heavy price - but it obviously allows functionality that is otherwise entirely impossible, that of directly interacting with personal computers, so you will be able to:
-	* Spoof Keyboards and Mice
-	* Act as a virtual USB serial port
-	* Make a USB DMX device
-	* Program over USB pending availability of a bootloader suitable for such
-	* For the true wizards, the option to make an entirely custom USB device awaits you.
+  * Spoof Keyboards and Mice
+  * Act as a virtual USB serial port
+  * Make a USB DMX device
+  * Program over USB pending availability of a bootloader suitable for such
+  * For the true wizards, the option to make an entirely custom USB device awaits you.
 
 Currently, there is no support for the USB available as part of the core yet, that is the top priority new feature, but one which I feel totally unqualified to write.
 

megaavr/extras/DU28.md

@@ -1,11 +1,11 @@
 # AVR64DU28/AVR32DU28/AVR16DU28  AVR DU - That's U for USB
 
 These are one of those parts that leave you very little ambiguity about whether it's the right part for the job. Do you need USB? Then you need to DU the DU, cause as far as AVR is concerned, it's this, or classic AVR, and nobody wants to use those. And the DU-family of parts is absolutely a respectable product line. But the fact remains, that if you don't need USB, there is something cheaper, better at what you do need, usually both. USB exacts a very heavy price - but it obviously allows functionality that is otherwise entirely impossible, that of directly interacting with personal computers, so you will be able to:
-  * Spoof Keyboards and Mice
-  * Act as a virtual USB serial port
-  * Make a USB DMX device
-  * Program over USB pending availability of a bootloader suitable for such
-  * For the true wizards, the option to make an entirely custom USB device awaits you.
+	* Spoof Keyboards and Mice
+	* Act as a virtual USB serial port
+	* Make a USB DMX device
+	* Program over USB pending availability of a bootloader suitable for such
+	* For the true wizards, the option to make an entirely custom USB device awaits you.
 
 Currently, there is no support for the USB available as part of the core yet, that is the top priority new feature, but one which I feel totally unqualified to write.
 
@@ -156,9 +156,9 @@ When all else fails, read the real documentation. They keep moving the .pdf file
 
 **Datasheets and errata change. You can sign up to get emails about such changes through the Microchip PCN system; if you don't, be sure to always use the latest version of the datasheet and especially the errata**
 
-* AVR64DU28 - https://www.microchip.com/en-us/product/avr64du28 
-* AVR32DU28 - https://www.microchip.com/en-us/product/AVR32DU28
-* AVR16DU28 - https://www.microchip.com/en-us/product/AVR16DU28 
+* AVR64DU28 - [www.microchip.com/en-us/product/avr64du28](https://www.microchip.com/en-us/product/avr64du28)
+* AVR32DU28 - [www.microchip.com/en-us/product/AVR32DU28](https://www.microchip.com/en-us/product/AVR32DU28)
+* AVR16DU28 - [www.microchip.com/en-us/product/AVR16DU28](https://www.microchip.com/en-us/product/AVR16DU28)
 
 At a minimum, everyone using a modern AVR should plan on having a PDF viewer open with the datasheet, and a text editor with a good search function and the ioavr______.h file open so that when you're trying to use a constant, but the compiler says it isn't declared/defined, you can search the io header for a key phrase in the constant and figure out how it was spelled/formatted or copy/paste it to your sketch. (see [the IO headers](./ioheaders) for more information and links to them. I also keep the AVR instruction set manual open in the PDF viewer as well as the silicon errata and datasheet clarification. Datasheet clarifications are a bigger deal than an erratum, usually. An erratum says "Okay, this doesn't work, but it will some day, maybe" while a datasheet clarification says "This would be an errata, but we're not even going to pretend that we'll fix it some day". But watch out - datasheet clarifications vanish from the list once the datasheet has been updated!
 

megaavr/extras/Ref_Clocks.md

@@ -51,7 +51,7 @@ The AVR Dx-series come in I (105C) and E (125C) spec parts. **This is not marked
 Some of the listed speeds, while supported by the hardware are not supported by the core - typically weird, slow clocks. Crystals in particular can be made in any speed - though classic AVR rewarded the use of bizarre clocks by requiring them in order to generate UART baud clocks for normal speeds, modern AVRs do not need them, and so we don't support any oscillator frequency which is not an integer multiple of 1 MHz
 For unsupported speeds, the micros and delay-us columns indicate what internal plumbing has been implemented. micros is implemented for almost all speeds, delayMicroseconds with non-compile-time-known delays for most, even some unsupported ones. delayMicroseconds() is supported and accurate at any speed when the argument is a compile-time-known constant, as we use the avr-libc implementation of `_delay_us()`.
 
-### megaTinyCore (ATtiny 0-Series, 1-series, and 2-series.
+### megaTinyCore (ATtiny 0-Series, 1-series, and 2-series)
 | Clock Speed | Within Spec |      Internal |    Ext. Clock | micros | delay-us | Notes
 |-------------|-------------|---------------|---------------|--------|----------|-------
 |       1 MHz |         Yes |           Yes |            ** |    Yes |      Yes | 1

megaavr/extras/Ref_Errata.md

@@ -150,7 +150,7 @@ The actual behavior I observed is:
 Nobody is sad to see the fully/partially async pin distinction go.
 
 ### TCA pin override behavior inconsistent between part families
-The behavior of the Type A timer(s) with regards to pin direction override is not consistent between the AVR DA/DB and AVR DD parts.
+* The behavior of the Type A timer(s) with regards to pin direction override is not consistent between the AVR DA/DB and AVR DD parts.
   * On the AVR DD-series, whenthe TCA is outputting PWM, the pin mode is overridden by the peripheral and set to output.
   * On the AVR DA and DB-series, the pin mode is not overridden. If the pin is not set output, no output will be seen.
   * Behavior of EA-series TCAs and the EB-series TCE has not been tested