Merge pull request #853 from dereified/spelling-corrections

Spelling corrections suggested by codespell and manually verified.

README.md

@@ -76,7 +76,7 @@ Typically 8x slower than expected - see below entry.
 The option should really be named "Set fuses and install bootloader (if any)" rather than "burn bootloader", which makes it sound irreversible (it's not), and by not mentioning the fuses, many users think that it isn't needed if a bootloader is being used. But it is, because this is the only time fuses are set; this is the same behavior as all other classic AVR cores, because it is possible to soft-brick the parts if the fuses are misconfigured, and so writing the .
 
 #### VUSB is not supported for USB functionality within the sketch
-It has been persuasively argued to me that it is not possible to get these parts to meet USB timing contstraints in an interrupt driven context without compromising on everything else. On the classical digispark, their core bent over backwards and got only mediocre results. The libraries floating around are stale, having rarely received updates, often dating back to the days of avr-gcc 4.8.x, and only ever worked on the digispark core - and even there they didn't work particularly well. USB timing constraints are very constraining. If anyone cared to put in the considerable amount of effort it would involve to port micronucleus and package the VUSB libraries, the pieces to make this viable *are actually present on the tinyAVR 0/1/2-series* (the key feature being the lvl 1 priority interrupt option though the improvements to instruction set timing don't hurt). But I don't know that anyone is showing much interest in taking that on.
+It has been persuasively argued to me that it is not possible to get these parts to meet USB timing constraints in an interrupt driven context without compromising on everything else. On the classical digispark, their core bent over backwards and got only mediocre results. The libraries floating around are stale, having rarely received updates, often dating back to the days of avr-gcc 4.8.x, and only ever worked on the digispark core - and even there they didn't work particularly well. USB timing constraints are very constraining. If anyone cared to put in the considerable amount of effort it would involve to port micronucleus and package the VUSB libraries, the pieces to make this viable *are actually present on the tinyAVR 0/1/2-series* (the key feature being the lvl 1 priority interrupt option though the improvements to instruction set timing don't hurt). But I don't know that anyone is showing much interest in taking that on.
 
 To make matters worse, much of the functionality you want on Windows (namely, low speed CDC for a serial port) requires drivers that don't exist in a fully working form. Unfortunately, even if you found a solution to meet the USB constraint and made the drivers work, that's still not enough because you need to bend over backwards to install them if they haven't been blessed with a digital signaure from Microsoft, so it is difficult to get a solution you could share with the world
 

avr/bootloaders/optiboot/source/optiboot.c

@@ -212,7 +212,7 @@
 /*      There are already enough unholy things done to this*/
 /*      version that it shouldn't compile for any ATmega  */
 /*      so why imply that it would?                       */
-/*      Adust most indentation to match all of my cores   */
+/*      Adjust most indentation to match all of my cores  */
 /* 58.0 Pull in RS485 support by Vladimir Dronnikov       */
 /*      ( github.com/dvv ) as used in                     */
 /*      github.com/SodaqMoja/optiboot                     */

avr/cores/tiny/HardwareSerial.h

@@ -73,7 +73,7 @@
   #endif
   /* WARNING
    * BUFFER SIZES MUST BE POWERS OF TWO - The compiler misses some of the
-   * optimization possible with the % opperator. only a small portion of it, but as there's no compelling reason NOT
+   * optimization possible with the % operator. only a small portion of it, but as there's no compelling reason NOT
    * to use a power of two size, and there are some extrenely flash-constrained parts that have a USART (I'm thinking of the 2313 in particular
    * I couldn't justify not explicitly optimizing the % SERIAL_BUFFER_SIZE to a & (SERIAL_BUFFER_SIZE -1))
    */

avr/cores/tiny/TinySoftwareSerial.cpp

@@ -259,7 +259,7 @@ size_t TinySoftwareSerial::write(uint8_t ch) {
     //                                   // We can't use r0 for this, because uartDelay uses r0 as it's delay counter.
     "cli"                         "\n\t" // disable interrupts if they're not disabled already.
     "ldi r20, 10"                 "\n\t" //
-    "in r19, %[uartPort]"         "\n\t" // load the curret value of the TX PORT register.
+    "in r19, %[uartPort]"         "\n\t" // load the current value of the TX PORT register.
     "or r19, %[txmask]"           "\n\t" // there's our pattern for a 1. one hopes that this line is unnecessary since serial is IDLE HIGH.
     "mov r18,r19"                 "\n\t" // copy it to the zero bit...
     "eor r18, %[txmask]"          "\n\t" // xor with the txmask, which has all but 1 bit set, a bit which we know is set in the destination register. 4 instructions to prepare the 0 and 1 bit patterns.

avr/extras/ATtiny_x41.md

@@ -35,7 +35,7 @@ The ATtiny x41-family is a more advanced version of the ATtiny x4-family. It is
 Any of these parts can be programmed by use of any ISP programmer. 4k and 8k parts can be programmed over the software serial port using Optiboot, and 8k parts can be programmed via Micronucleus. Be sure to read the section of the main readme on the ISP programmers and IDE versions. 1.8.13 is recommended for best results.
 
 ### Optiboot Bootloader
-This core includes an Optiboot bootloader for the ATtiny841/441, operating on the hardware UART0 (Serial) port at 115200 baud for 12 MHz or higher, or 57600 when running at lower speeds. The bootloader uses 640b of space, leaving 3456 or 7552b available for user code. In order to work on these parts, which do not have hardware bootloader support (hence no BOOTRST functionality), "Virtual Boot" is used. This works around this limitation by rewriting the vector table of the sketch as it's uploaded - the reset vector gets pointed at the start of the bootloader, while the EE_RDY vector gets pointed to the start of the application (versions of the core prior to 1.2.0 used WDT vector, so WDT cannot be used as an interrupt - we recommend burning bootloader with the new version if this is an issue). A version of the bootloader that operates on Serial1 is included as well (choose the desired UART when burning the booloader).
+This core includes an Optiboot bootloader for the ATtiny841/441, operating on the hardware UART0 (Serial) port at 115200 baud for 12 MHz or higher, or 57600 when running at lower speeds. The bootloader uses 640b of space, leaving 3456 or 7552b available for user code. In order to work on these parts, which do not have hardware bootloader support (hence no BOOTRST functionality), "Virtual Boot" is used. This works around this limitation by rewriting the vector table of the sketch as it's uploaded - the reset vector gets pointed at the start of the bootloader, while the EE_RDY vector gets pointed to the start of the application (versions of the core prior to 1.2.0 used WDT vector, so WDT cannot be used as an interrupt - we recommend burning bootloader with the new version if this is an issue). A version of the bootloader that operates on Serial1 is included as well (choose the desired UART when burning the bootloader).
 
 ### Micronucleus VUSB Bootloader
 This core includes a Micronucleus bootloader that supports the ATtiny841, allowing sketches to be uploaded directly over USB. The board definition runs at 8 MHz via the internal oscillator. For low power applications, it can be prescaled as listed in the table, or cranked up to 16 MHz for the adventurous. See the document on [Micronucleus usage](Ref_Micronucleus.md) for more information. In order to achieve the 12 MHz clock during USB operation, the OSCCAL is drastically increased to 12MHz while the bootloader is running, but is set back down before running the sketch.

avr/extras/ATtiny_x7.md

@@ -80,7 +80,7 @@ TC0 is always run in Fast PWM mode: We use TC0 for millis, and phase correct mod
 |>16 MHz | x/128/256=30 * x Hz |  x/64/512=  30 * x Hz | Phase correct TC1            |
 | 20 MHz | 20/128/255=  610 Hz | 20/64/512=     610 Hz | Phase correct TC1            |
 
-Where the /32 or /128 prescaler, not available on most parts, is used, it sigificantly improves the output frequency in the most desirable range for typical applications - unfortunately timer0 has only a single output (it's not the standard TC0 - it has much in common the the ATmega TC2 async, potentially externally-clocked timer.
+Where the /32 or /128 prescaler, not available on most parts, is used, it significantly improves the output frequency in the most desirable range for typical applications - unfortunately timer0 has only a single output (it's not the standard TC0 - it has much in common the the ATmega TC2 async, potentially externally-clocked timer.
 
 Where speeds above or below a certain speed are specified, it's implied that the other end of the range is the next marked value. So >16 in that table is for 16-20 MHz clocks. The formula is given as a constant times x where x is expressed as MHz (the division above gets the time in megahertz - in the interest of readability I did not include the MHz to Hz conversion - I'm sure you all know how to multiply by a million)
 
@@ -183,7 +183,7 @@ I (Spence Konde / Dr. Azzy) sell ATtiny167 boards through my Tindie store - your
 The 87 and 167 are available in three package variations. Additionally, the 167 only can be had in a fourth package.
 * SOIC-20 (wide) - bigger than the side of a house, but easy to hand solder
 * TSSOP-20 - Slightly more demanding to solder. While it is hard to imagine being able to read this text and miss a bridge between adjacent pins on a SOIC-20, the same cannot be said for a SSOP-20 - depending on your eyesight, you may need magnification or more attention to lighting in order to spot bridges visually
-* VQFN32 - with 12 unused pins - Atmel seemed to REALLY like this package - a lot of 20-pin tinyAVR parts got this as their QFN instead of a proper QFN20-type. It's an annoying package, though - it's very fine pitch, large for a QFN (5mm x 5mm), and the unused pins don't appear to have been arranged with consideration of the layout. They're in the same order as the pins up and down the two sides of the SOIC/SSOP parts (probably a technical constraint I've never seen a chip with what was believed to have the same die, *not* have the same pin order, so I think bond wires have to make straight lines that don't cross each other from the die to the pin), but the decisons for where those dummy pins would go appears to have been based only on their convenience.
+* VQFN32 - with 12 unused pins - Atmel seemed to REALLY like this package - a lot of 20-pin tinyAVR parts got this as their QFN instead of a proper QFN20-type. It's an annoying package, though - it's very fine pitch, large for a QFN (5mm x 5mm), and the unused pins don't appear to have been arranged with consideration of the layout. They're in the same order as the pins up and down the two sides of the SOIC/SSOP parts (probably a technical constraint I've never seen a chip with what was believed to have the same die, *not* have the same pin order, so I think bond wires have to make straight lines that don't cross each other from the die to the pin), but the decisions for where those dummy pins would go appears to have been based only on their convenience.
 
 ## Interrupt Vectors
 This table lists all of the interrupt vectors available on the ATtiny x7-family, as well as the name you refer to them as when using the `ISR()` macro. Be aware that a non-existent vector is just a "warning" not an "error" (for example, if you misspell a vector name) - however, when that interrupt is triggered, the device will (at best) immediately reset (and not clearly - I refer to this as a "dirty reset") The catastrophic nature of the failure often makes debugging challenging.

avr/extras/Ref_ChangePWMFreq.md

@@ -24,7 +24,7 @@ In a timer counter unit, when we're talking about PWM, we're talking about the s
 * When full control of the timer is taken the additional functionality might include (briefly - these features are beyond the scope of this document):
   * Periodic interrupts with CTC (Clear Timer on Compare match)
   * Arbitrary TOP values, sometimes without the loss of an output, other times only at the cost of an output channel.
-    * 16-bit timers which have an input capture feature (I belive all of the classic AVR "standard" timer1s plus higher timers that are a copy of the standard timer1) have a PWM mode where you set the ICR register to the TOP value without losing either of the output compares.
+    * 16-bit timers which have an input capture feature (I believe all of the classic AVR "standard" timer1s plus higher timers that are a copy of the standard timer1) have a PWM mode where you set the ICR register to the TOP value without losing either of the output compares.
     * On 8-bit timers, typically the only option is to set it so output compare channel A sets top, losing a channel.
   * Higher resolution on Timer1, except:
     * On the 43 - it's 8-bit there, copy of timer0.
@@ -85,7 +85,7 @@ The high speed timers have a few bits of odd behavior to them, the most relevant
 
 When either of these timers used to generate PWM, which is what they're made for, OCR1C is TOP (though this defaults to 255), while OCR1A, B, and D if present are the output channels.
 
-For the Tiny x5, you again have two swiches available that impact the frequency. The Tx61 does as well, but also lets you choose one of the whopping 4 WGMs available; all of these can be done without losing analogWrite(). Either way, the prescaler is 4 bits now (0 = stopped, otherwise, the prescaler is 2^(n-1))
+For the Tiny x5, you again have two switches available that impact the frequency. The Tx61 does as well, but also lets you choose one of the whopping 4 WGMs available; all of these can be done without losing analogWrite(). Either way, the prescaler is 4 bits now (0 = stopped, otherwise, the prescaler is 2^(n-1))
 
 The bits are located in TCCR1 on the tiny85:
 ```c

avr/extras/Ref_Optiboot.md

@@ -53,7 +53,7 @@ This is much harder without the `BOOTRST` fuse. The bootloader still gets locate
 
 Optiboot erases pages when using virtual boot the same way as it does when it has the insurance of a hardware bootloader (ie, the simplest way possible): Whenever it is fed the first byte of a page, it first erases that page, and then proceeds with programming. That all is fine as long as you have a BOOTRST fuse to guarantee that you can get back to the bootloader. A failure of some sort at this state would simply require reuploading the sketch. But with virtual boot, if it has erased the first page, but not rewritten it, it neither knows how to run the bootloader or start the application. It is bricked until it can be reprogrammed with an ISP programmer. Bitter experience has shown that this does happen in the field, particularly when running on batteries (where a "brownout", where weak batteries drop below the minimum voltage required (by BOD or physics) from the current of the erase process), from a mishandled programming attempt (where an attempt is started, abandoned with the port being closed, and retried) on a board with autoreset, or from other unknown adverse events. Murphy's law dictates that the greater the cost and inconvenience of trudging out there to reprogram the device, the higher the chance of it failing like this.
 
-**There is a well known and extensively tested (Micronucleus uses it) solution**: The moment that the booloader is told to write anything, you erase every page of flash outside the bootloader section, starting with the end and finishing with the first page (the one with the reset vector, which if you recall is pointed to the bootloader), and the application vector must be placed not in the vector table at the start of the flash, but rather as the last word of the application section. Thus, if an erase is incomplete, the application will be hosed, but the bootloader will still run, unless the erase completed, in which case there is nothing but empty flash between the reset vector and the bootloader. Empty flash holds all 1's. `0xFFFF`, despite being an invalid opcode, is interpreted as a "skip [next instruction] if bit 7 in 31 is set" (sbrs r31, 7) (opcode 0xFFF7) - so depending on the value of r31, it will skid along the empty flash executing and skipping alternating words, or executing every word. Since the only instructions running are `sbrs r31,7` sbrs will either skip every other instruction, or not, as there's no way for r31's value to change until it reaches non-empty flash. Since the bootloader must be an integer number of pages in size, and pages are always even numbers of words in size (typical page sizes are 32b to 128b), it will never miss the first instruction of the bootloader. Thus the case of a complete erase with no write will reach the bootloader. And if a failure occurs after writing the first page of flash, but before finishing the last, the bootloader will jump to the last location in the application section to try to start the app. That will be empty flash, from whence it will proceed to the bootloader and the upload could be reattempted.
+**There is a well known and extensively tested (Micronucleus uses it) solution**: The moment that the bootloader is told to write anything, you erase every page of flash outside the bootloader section, starting with the end and finishing with the first page (the one with the reset vector, which if you recall is pointed to the bootloader), and the application vector must be placed not in the vector table at the start of the flash, but rather as the last word of the application section. Thus, if an erase is incomplete, the application will be hosed, but the bootloader will still run, unless the erase completed, in which case there is nothing but empty flash between the reset vector and the bootloader. Empty flash holds all 1's. `0xFFFF`, despite being an invalid opcode, is interpreted as a "skip [next instruction] if bit 7 in 31 is set" (sbrs r31, 7) (opcode 0xFFF7) - so depending on the value of r31, it will skid along the empty flash executing and skipping alternating words, or executing every word. Since the only instructions running are `sbrs r31,7` sbrs will either skip every other instruction, or not, as there's no way for r31's value to change until it reaches non-empty flash. Since the bootloader must be an integer number of pages in size, and pages are always even numbers of words in size (typical page sizes are 32b to 128b), it will never miss the first instruction of the bootloader. Thus the case of a complete erase with no write will reach the bootloader. And if a failure occurs after writing the first page of flash, but before finishing the last, the bootloader will jump to the last location in the application section to try to start the app. That will be empty flash, from whence it will proceed to the bootloader and the upload could be reattempted.
 
 Optiboot needs to be adapted to do that. I wasn't able to see a clear route towards doing that when I last looked into that adaptation.
 

avr/extras/Ref_Programming.md

@@ -16,7 +16,7 @@ Ensure that you have connected all necessary external components (see [Wiring Gu
 * SCK of programmer (pin 13 on Uno/Nano/ProMini) to SCK of target
 * MISO of programmer (pin 12 on Uno/Nano/ProMini) to MISO of target
 * MOSI of programmer (pin 11 on Uno/Nano/ProMini) to MOSI of target
-* Pin 10 (pin 10 on Uno/Nano/ProMini, or pin "RST" pin on the ISP connector of a dedicated programer) to RST of target
+* Pin 10 (pin 10 on Uno/Nano/ProMini, or pin "RST" pin on the ISP connector of a dedicated programmer) to RST of target
 
 You must have a supported programmer:
 * AVR ISP