spell

Author: SpenceKonde

ChangeLog.md

@@ -26,7 +26,7 @@ These items are in addition to what was listed under changes already in release.
 
 
 ### 1.6.0 3/25/26
-* **1.6.0 should be treated as a test release, because I need to get the new toolchain into the testing environment in order for the automated tests to see what doesn't compile, but the test environment only gets the previous release's dependancies, so until I release with the new toolchain, I can't do automated tests against it.**
+* **1.6.0 should be treated as a test release, because I need to get the new toolchain into the testing environment in order for the automated tests to see what doesn't compile, but the test environment only gets the previous release's dependencies, so until I release with the new toolchain, I can't do automated tests against it.**
 * OSCCFG is now written for Dx-series parts. We have never supported any option other that 0x00 on those parts, and the hardware only supports one other value, which starts the chip on the 32 kHz oscillator.
 * Support for the PTC peripheral on DA parts
 * Correct bug with EA-series parts having the SYSCFG0 fuse set during normal uploads, which is inappropriate, because if the UPDIPINCFG bit is not 1, the chip can only be reprogrammed with an exotic HV programmer.

megaavr/cores/dxcore/wiring_analog.c

@@ -694,7 +694,7 @@ inline __attribute__((always_inline)) void check_valid_resolution(uint8_t res) {
       ##           ########   #######           */
 
 
-  #elif defined(ADC_LOWLAT_bm) /* MAJOR IMPORTANT ELIF CONDITONAL */
+  #elif defined(ADC_LOWLAT_bm) /* MAJOR IMPORTANT ELIF CONDITIONAL */
   // only the good ADC has the larger temp register, and we're testing this if we don't have the larger register.
   static uint8_t _analog_options = 0x80 | 10;
 

megaavr/extras/Ref_Interrupts.md

@@ -311,7 +311,7 @@ Clock failure detection detects, clock, failures. For a *clock failure* to occur
 2. The clock source, having started, must cease all oscillation for around a quarter of a millisecond.
 3. CFD must be enabled and configured
 
-Importantly to hobbyists, condition 2 is not necessarily met by a crystal oscillator with improper loading capacitors and/or soldering errors, and condition will often not be met as well. These crystals may "limp", generating a sufficient number of transitions for the AVR to switch to it, but not generating them at a regular pase or with ~50% duty cycle, or otherwise violating the clock specification described in the electrical characteristics section. The "limping" transitions are also easily sufficient to make the CFD think everythink is fine and dandy. In this situation, it may switch to the clock, turn on the CFD and start to execute the app code, but because the clock is so severely deranged, the AVR will execute instructions incorrectly (as if it were being run at excessively high clock speeds).
+Importantly to hobbyists, condition 2 is not necessarily met by a crystal oscillator with improper loading capacitors and/or soldering errors, and condition will often not be met as well. These crystals may "limp", generating a sufficient number of transitions for the AVR to switch to it, but not generating them at a regular pace or with ~50% duty cycle, or otherwise violating the clock specification described in the electrical characteristics section. The "limping" transitions are also easily sufficient to make the CFD think everythink is fine and dandy. In this situation, it may switch to the clock, turn on the CFD and start to execute the app code, but because the clock is so severely deranged, the AVR will execute instructions incorrectly (as if it were being run at excessively high clock speeds).
 
 ## Reminders
 * ISRs should run FAST. Minimize the time that the code spends in the ISR. Never use polling loops unless you know that they will only need a couple of passes (an example would be TCD0 ENRDY or CMDRDY, which will never take longer than 16 clocks to clear), and avoid writing to serial. Most interrupts should just set a flag that is checked elsewhere, and do what must be done that instant (ex, read an incoming data byte from a register and store it in a buffer then set a flag or byte indicating at what point in the buffer it's at. Don't process the byte you received and figure out what it's instructing you to do - that should be done outside of the interrupt).

megaavr/extras/Ref_Serial.md

@@ -305,16 +305,16 @@ This function returns a byte encoding the current status of the serial port.
 | 3     | Yes      | SERIAL_FRAME_ERROR         | A Framing Error has been encountered since the last time this was called indicating baud mismatch. This clears that record.
 |4,5=00 | No       | SERIAL_AUTOBAUD_DISABLED   | Bits 4 and 5 are combined to express autobaud conditions. 00 = autobaud not enabled
 |4,5=01 | No       | SERIAL_AUTOBAUD_ENABLED    | 01 = Autobaud enabled. Nothing to report
-|4,5=10 | No       | SERIAL_AUTOBAUD_SYNC       | 10 = Autobaud enabled. A sync charachter was received and we are now operating at a different baud rate than it was started at.
-|4,5=11 | Yes      | SERIAL_AUTOBAUD_BADSYNC    | 11 = Autobaud enabled. An **inconsistant sync field** was received, the previous attempt at setting the baud rate failed. See below note
+|4,5=10 | No       | SERIAL_AUTOBAUD_SYNC       | 10 = Autobaud enabled. A sync character was received and we are now operating at a different baud rate than it was started at.
+|4,5=11 | Yes      | SERIAL_AUTOBAUD_BADSYNC    | 11 = Autobaud enabled. An **inconsistent sync field** was received, the previous attempt at setting the baud rate failed. See below note
 | 6     | Yes      | SERIAL_OVERFLOW_RING       | Indicates that the *RING BUFFER* filled up and characters were dropped (because data was coming in, but application was not calling Serial.read() often enough to keep up). getStatus clears that record.
 | 7     | Yes      | SERIAL_OVERFLOW_HARDWARE   | A buffer overflow at the hardware level has occurred; This happens when interrupts are disabled for too long while receivign data. getStatus() clears this record
 
 Since getStatus also clears the errors, be sure to store the first value you get from it if you are looking for multiple errors.
 In the case of autobaud, both sides should probably be using this - non-autobaud device would check for framing errors that indicate a need to sync, and then attempt to do so, while the autobaud device would need to watch out for ISFIF, which disables receiving until addressed.
 
 #### BADSYNC
-In the event of an **inconsistant sync field**, the normal serial receive handler fires. It discovers that rather than an RX flag, it was summoned by an error flag. However, because there are two
+In the event of an **inconsistent sync field**, the normal serial receive handler fires. It discovers that rather than an RX flag, it was summoned by an error flag. However, because there are two
 
 ### Loopback Mode
 When Loopback mode is enabled, the RX pin is released, and TX is internally connected to Rx. This is only a functional loopback test port, because another device couldn't drive the line low without fighting for control over the pin with this device. Loopback mode itself isn't very useful. But see below.

megaavr/libraries/SPI/README.md

@@ -36,7 +36,7 @@ As always, constants of the form `SPI_CLOCK_DIVn` are provided. These are what s
 
 In the event that an invalid value is passed, if the value is known at compile time, an error will be produced telling you that you're passing an invalid value. However, this only catches the most common, obvious cases. Since there are no runtime exceptions, invalid values that are not known at compile time will get through. When an invalid value is passed that can't be picked out at compile time, we are left with a connundrum:
 
-What should we set the clock divider to? We can't just have the function return and do nothing, because then it will appear that the problem is with the library. My first thought was to just have it set to the minimum speed, which will likely function, if possibly with poor performance, but I realized the SPI peripheral's odd design gives us a way to signalize an error condition here, because there are only 7 supported speeds, but the 2+1 bits are structured as a single-bit field that doubles the clock speed, ahd a 2-bit field that selects thee base between /4, /16, /64, and /128. Hence, /128 with CLK2x and /64 without both generate the same clock frequency.
+What should we set the clock divider to? We can't just have the function return and do nothing, because then it will appear that the problem is with the library. My first thought was to just have it set to the minimum speed, which will likely function, if possibly with poor performance, but I realized the SPI peripheral's odd design gives us a way to signalize an error condition here, because there are only 7 supported speeds, but the 2+1 bits are structured as a single-bit field that doubles the clock speed, and a 2-bit field that selects thee base between /4, /16, /64, and /128. Hence, /128 with CLK2x and /64 without both generate the same clock frequency.
 
 `SPI_CLOCK_DIV2`, `SPI_CLOCK_DIV4`, `SPI_CLOCK_DIV8`, `SPI_CLOCK_DIV16`, `SPI_CLOCK_DIV32`, `SPI_CLOCK_DIV64`, `SPI_CLOCK_DIV128`