23 files of spellcheck

Author: SpenceKonde

ChangeLog.md

@@ -247,7 +247,7 @@ Spelling, grammar and typographical fixes.
 * Bugfix: Correct verification bug in SerialUPDI where it would fail on a last page of the minimum size (thanks @dbuchwald!). The 1-word read takes a different codepath because it doesn't need the REP.
 * Documentation: Improve bootloader source comments re:building (albeit without providing hard information; more of a plea of ignorance and admission of just how crude my build process is), pindefs for DD-series (and EA-series is a linear combination of DA/DB and DD - though it is said to be back to paged writes, so it might be made from optiboot_x rather than optiboot_dx), rename pindefs_x to pindefs_dx and remove 2 references to optiboot_x that should have been dx.
 * Bugfix: Correctly comment out leftover debugging prints that would be called when using `tone()` (megaTinyCore #550).
-* Bugfix: Fix a bug (well, several actually) in the new attach interrupt that kept it from working on on ports E and F. PORTE would use PORTC's interrupts. And PORTF would either fail to find functions to jump to if no PORTC or PORTD interrupts were attached, or else it would use the high byte of PORTC's interrupt table as the high byte abd the low byte of PORTD's table as the high byte, and look there for pointers. If there was anything there, it would assume it could jump to them. Oops. I also worked around something that had an easier solution which didn't need to be like that... eliminating that saves 5 clocks and 4 bytes, plus 2 bytes (number of ports -1).
+* Bugfix: Fix a bug (well, several actually) in the new attach interrupt that kept it from working on on ports E and F. PORTE would use PORTC's interrupts. And PORTF would either fail to find functions to jump to if no PORTC or PORTD interrupts were attached, or else it would use the high byte of PORTC's interrupt table as the high byte and the low byte of PORTD's table as the high byte, and look there for pointers. If there was anything there, it would assume it could jump to them. Oops. I also worked around something that had an easier solution which didn't need to be like that... eliminating that saves 5 clocks and 4 bytes, plus 2 bytes (number of ports -1).
 * Bugfix: Major cleanup of variants, removing unnecessary garbage defines left and right.
 * Bugfix: Correct issue where the intended useful error message was not shown to users who did not have millis or micros enabled but tried to use it anyway.
 * Enhancement: Add new Wire library method names to keywords.txt.
@@ -310,7 +310,7 @@ Spelling, grammar and typographical fixes.
   * Add getAnalogReference(), getDACReference(), getAnalogSampleDuration() and getAnalogReadResolution() macros (all are trivial, all should have existed for a long time).
 * Startup related (also, see new reference on reset)
   * Ensure that anything that determines what is built is always part of the name of expoered binaries. Writing to SPM from app wasn't, and this caused difficulty tracking down huge bug.
-  * Ensure that that functions in `.init` sections do not get a `ret` autogenerated at the end. They must have attributes used *and* naked. if not ((used)) they are optmimized away. If not ((naked)) they will get an autogenerated `ret` and the end which will generally result in a dirty reset loop. Also, if have any sort of entrypoint like we do for unrestricted flash writes from app, you need to have them start with an rjmp to jump over the body of the function in case execution gets there during startup. Also the init sections don't work for getting things into the first page of flash. To do that, you need to put it in `.trampolines`, otherwise progmem variables will get to go first.  and the ) that do have a return, thery need to start weith an rjmp to carry execution at startup around them.
+  * Ensure that that functions in `.init` sections do not get a `ret` autogenerated at the end. They must have attributes used *and* naked. if not ((used)) they are optmimized away. If not ((naked)) they will get an autogenerated `ret` and the end which will generally result in a dirty reset loop. Also, if have any sort of entrypoint like we do for unrestricted flash writes from app, you need to have them start with an rjmp to jump over the body of the function in case execution gets there during startup. Also the init sections don't work for getting things into the first page of flash. To do that, you need to put it in `.trampolines`, otherwise progmem variables will get to go first.  and the ) that do have a return, thery need to start with an rjmp to carry execution at startup around them.
   * Add (commented out) entries to boards.txt for DD series (only one thing is not known: size of bootsize/codesize segments) and EA without optiboot. Re-add MVIO menu: I finally checked on hardware, MVIO being disabled just seems to turn off the oversight of that behavior. With it disabled it does not short VDDIO2 to power rails as some, including myself, had feared it might. Add menu option to enable printf (and everything that uses it) to print floats.
   * Fix critical bug relating to flash writing (don't think it was ever in a release).
 * Pin-mapping related

ContributionGuidelines.md

@@ -34,7 +34,7 @@ Check the existing  [issues](https://github.com/SpenceKonde/DxCore/issues), and
   a. try to compile bare minimum for the same board and settings. If this fails, it is likely that the core is not installed correctly, or there is a larger system-level issue. Perform the next test in that case. It is possible but unlikely to be a core defect - We run CI, though it doesn't hit every combo of options.
   b. **If that fails**, try to compile bare minimum for the Arduino Uno. If *that* does not work either, something is wrong with your Arduino IDE installation in general, and you should post in the Arduino technical support forum.
   c. **If the second test** in this section works, try it on the original DxC/mTC board, but with the default settings for that board. If that works, then it is very likely a bug in the core and should be reported as such.  If that fails (ie, you cannot compile anything associated with one or both of these cores), if it is a released version that isn't listed as bad.
-3. **If the problem involves a library not included with the core, always include the URL that you got the library from, or if installed from Library Manager, the version**. Otherwise, the issue is not actionable and you will be immediately asked for that information and no work on the issue can occur until it is provided, slowing down any resolution. That is because **the name of a library does not uniquely identify the library** - Frequently there are **hundreds** of forks of popular libraries all over the web, with the same name and almost always an identical readme and version number to the upstream repo at the time it was forked, but with (rarely documented) changes ranging from trivial to a major rewrite with drastic API changes, and most of these versions in turn are each associated with the author of some program + forum or blog post describing their project. They modified the library to make some change they needed, talked about it in the forum thread, almost never have they put a link back to the context or documented anything in the repo. So people often end up using the library that the tutorial they first read anout the library in does. Which may be customized to someone's project. I have no way of knowing what version you are using.
+3. **If the problem involves a library not included with the core, always include the URL that you got the library from, or if installed from Library Manager, the version**. Otherwise, the issue is not actionable and you will be immediately asked for that information and no work on the issue can occur until it is provided, slowing down any resolution. That is because **the name of a library does not uniquely identify the library** - Frequently there are **hundreds** of forks of popular libraries all over the web, with the same name and almost always an identical readme and version number to the upstream repo at the time it was forked, but with (rarely documented) changes ranging from trivial to a major rewrite with drastic API changes, and most of these versions in turn are each associated with the author of some program + forum or blog post describing their project. They modified the library to make some change they needed, talked about it in the forum thread, almost never have they put a link back to the context or documented anything in the repo. So people often end up using the library that the tutorial they first read about the library in does. Which may be customized to someone's project. I have no way of knowing what version you are using.
 
 Do also check the supported libraries page (shared by DxCore and megatinyCore due to the great deal of similarity between them) to make sure that it is not known to be a defect in the library, and that there is no working version of the library (there is one library, for example, that has steadfastly refused to support any post-2016 AVRs, even when given PRs that will fix it for all current and announced products, in that case, the fixed version that was used for the PRs is linked to from that page.)
 4. **For any error involving a library, check if the problem reproduces with any of the examples included with that library.** If so, that is **HUGE** as it proves that the problem is **not a bug in your code**, though the inverse is not true. A bug in the library may not trigger any failures in the usually cursory examples.

README.md

@@ -384,7 +384,7 @@ I feel like the HV UPDI mechanism has got to involve something like this added o
 
 But as we don't know what the actual voltage we need to use is - the documentation still maintains that to be 12v in one place, 3 volts higher than the absolute maximum.
 
-I would advise against experimenting with this unless you are prepared to either potentially sacrifice chips on the bench. I suggest using a ZIF socket, since at this time "Trying to use HV UPDI with a non-official tool" means "Trial and error, and until the documentation is correc"
+I would advise against experimenting with this unless you are prepared to either potentially sacrifice chips on the bench. I suggest using a ZIF socket, since at this time "Trying to use HV UPDI with a non-official tool" means "Trial and error, and until the documentation is correct"
 
 
 ## Exposed Hardware Features

megaavr/boards.txt

@@ -3626,7 +3626,7 @@ avrddopti.menu.flmap.locksection0.build.flmapabr=.fl0
 #______________________________________________________#_________________#
                                                        #
 # Should be possible with the first die rev that fixed the really busted parts of NVMCTRL
-# Implemntation will be based on tinyAVR one, as they are more similar in the relevant ways.
+# Implementation will be based on tinyAVR one, as they are more similar in the relevant ways.
 
 
 ##########################################################################
@@ -3638,7 +3638,7 @@ avrddopti.menu.flmap.locksection0.build.flmapabr=.fl0
 #  #   #    #    #  #      #####  ####           ###   ###    #   ##     #
 #______________________________________________________#_________________#
 
-# Can probaby be binary idential with EA's
+# Can probably be binary identical with EA's
 
 ########################################################################################################
 #                                                                                                      #

megaavr/cores/dxcore/Arduino.h

@@ -468,9 +468,9 @@ FX        P  P
 #define ADC_ENH_ERROR_BUSY                     (-2100000002) /* Not currently generated */
 #define ADC_ENH_ERROR_RES_TOO_LOW              (-2100000003) /* Requested resolution is less than 8 bits */
 #define ADC_ENH_ERROR_RES_TOO_HIGH             (-2100000004) /* Requested resolution exceeds what can be generated using builtin accumulation and decimation */
-#define ADC_DIFF_ERROR_BAD_NEG_PIN             (-2100000005) /* See datasheet or Analog refererence, not all pins can be negative. */
+#define ADC_DIFF_ERROR_BAD_NEG_PIN             (-2100000005) /* See datasheet or Analog reference, not all pins can be negative. */
 #define ADC_ENH_ERROR_NOT_DIFF_ADC             (-2100000006) /* Likely can't ever be returned*/
-#define ADC_ENH_ERROR_DISABLED                 (-2100000007) /* Not Used - we reenable, take the reading, and turn off again if analogReadEnh() is called when ADC off. */
+#define ADC_ENH_ERROR_DISABLED                 (-2100000007) /* Not Used - we re-enable, take the reading, and turn off again if analogReadEnh() is called when ADC off. */
 #define ADC_ERROR_INVALID_CLOCK                     (-32255)
 
 
@@ -670,7 +670,7 @@ void init_ADC0()      __attribute__((weak)); // this is called to initialize ADC
 //   init_DAC0()                             // no _init_DAC0() - all that the core does is call DACReference!
 void init_TCA0()      __attribute__((weak)); // called by init_timers() - without this, pins that give PWM from TCA0 will not function.
 void init_TCA1()      __attribute__((weak)); // called by init_timers() - without this, pins that give PWM from TCA1 will not function, nor will the TCBs unless the clock source is changed.
-void init_TCE0()      __attribute__((weak)); // Even ne'er do well's that associate with villians like WEX Luther need initiation! "You mean initialization" "I'm not sure I do..."
+void init_TCE0()      __attribute__((weak)); // Even ne'er do well's that associate with villains like WEX Luther need initiation! "You mean initialization" "I'm not sure I do..."
 void init_TCF0()      __attribute__((weak)); // called by init_timers()
 void init_TCBs()      __attribute__((weak)); // called by init_timers()
 void init_TCD0()      __attribute__((weak)); // called by init_timers()

megaavr/cores/dxcore/core_devices.h

@@ -365,7 +365,7 @@
  * S   = 1 = Internal oscillator selects from list of speeds, 0 = fuse selects 16 or 20 MHz
  * W   = 1 = Supports use of a watch crystal for RTC.
  *
- * LSB of this field is as before, describing the tuning and clocking options, with emphasis on tuning (you also need to use different intialization code, but that isn't perfectly sharable so I do that with family tests not clockmode. It's
+ * LSB of this field is as before, describing the tuning and clocking options, with emphasis on tuning (you also need to use different initialization code, but that isn't perfectly sharable so I do that with family tests not clockmode. It's
  *
  */
 
@@ -617,7 +617,7 @@
     /* The AVR Dx and Ex families are not expected to have any cases where this should be 0 */
   #endif
   #if   defined(CCL_TRUTH14)
-    #define _AVR_LUT_COUNT     (16) // Yeah, we will probably never see one thsi big. Alas.
+    #define _AVR_LUT_COUNT     (16) // Yeah, we will probably never see one this big. Alas.
   #elif defined(CCL_TRUTH12)
     #define _AVR_LUT_COUNT     (14) // 2 LUTs are obviously more than twice as useful as a single one.
   #elif defined(CCL_TRUTH10)
@@ -812,15 +812,15 @@
 
 
 /* OH SHIT! They actually fixed all the bugs on the DB! */
-/* There's one little problem - it's not a compiletime check anymore, but a runtime check :-( This isn't really going to work.*/
+/* There's one little problem - it's not a compile time check anymore, but a runtime check :-( This isn't really going to work.*/
 
 
 #define ERRATA_IRREL                 (-128)
 #define ERRATA_APPLIES                  (1)
 #define ERRATA_DOES_NOT_APPLY           (0)
 
 #define checkErrata(errata)  (errata == ERRATA_DOES_NOT_APPLY ? ERRATA_DOES_NOT_APPLY : (errata==ERRATA_IRREL ? ERRATA_DOES_NOT_APPLY :  (errata > SYSCFG_REVID ? ERRATA_DOES_APPLY : ERRATA_DOES_NOT_APPLY)))
-/* YARGH! **NOT** **A** **COMPILETIME** **TEST**
+/* YARGH! **NOT** **A** **COMPILE TIME** **TEST**
    so I think I still will get better code assuming the bugs are there for the most part
 
    */
@@ -929,9 +929,9 @@ DB silicon with die rev 0x11 is available.*/
   //                                            on a feature that is very specialized to begin with. Whatever we handle it anyway so you don't care even if you use autobaud!
   #define ERRATA_FCPU_20M                (1) // What? Completely unexpected
   #define ERRATA_NO_RWW                  (1) // Seems RWW is a challenge... But wait, this is a Dx! What the hell?! The Dx parts already could get all the benefit of RWW in terms of upload speed (which is significant) on account of writing wordwise
-  //                                            fast enough that you can do it between bytes of data. The normal Dx optiboot I ship doesnt't, I couldn't make it fit in 512b, but I'm certain it could be done.
+  //                                            fast enough that you can do it between bytes of data. The normal Dx optiboot I ship doesn't, I couldn't make it fit in 512b, but I'm certain it could be done.
   //                                            Seems to me like the whole thing could be better cleared up by just removing the FLREADY and FLBUSY bits from the datasheet and not talking about RWW - I'd take the Dx write system over pages any day.
-  //                                            Even if the paged one had proper RWW. The Dx's 'salami RWW' (the time needed with the cpu halted for writeing is sliced up real thin, see?) is fine, and it really is nice to write by words.
+  //                                            Even if the paged one had proper RWW. The Dx's 'salami RWW' (the time needed with the cpu halted for writing is sliced up real thin, see?) is fine, and it really is nice to write by words.
   #define ERRATA_EEPROM_EEWP             (1) // NVM EEPROM erase ignores EEWP. Likely discovered while examining what I call ERRATA_FLASH_MULTIPAGE
 
 #elif defined(__AVR_EB__)
@@ -941,7 +941,7 @@ DB silicon with die rev 0x11 is available.*/
 #endif
 
 #define ERRATA_AVRXT_IOREG               (1) // theorized to be present on all modern AVRs until it's discovery and disclosure by Microchip in 2023. There is no sign of this being fixed, and two series have had this erratum known at birth.
-// This is one of those bugs that looks really scary at first, and in the abstract, that's exactly right, it is really scary. Almost any program would seem to be plausibly at risk of being compiled with the wrong two instructions adjacent to eachother.
+// This is one of those bugs that looks really scary at first, and in the abstract, that's exactly right, it is really scary. Almost any program would seem to be plausibly at risk of being compiled with the wrong two instructions adjacent to each other.
 // But we got saved (and of course we did, they do test these things): Although the compiler for almost every plausible input could legally output code that causes writes to be lost. But it doesn't; the parts had been shipping for like 4-5 years before anyone
 // tripped over it. You kind of have to dance the hokey pokey backwards under a full moon in order to make it manifest.... It presumably impacted addresses up to 96 (0x60 - 0x40 for the I/O space, and in the versions of AVR that came before this, the working
 // registers were actually mapped at 0x00 to 0x1F. While working on AVRXT, someone recognized that the paradigm of mapping working registers to address spaces was daft (which it is), and they did the sensible thing. But they didn't do it quite right. So the

megaavr/cores/dxcore/main.cpp

@@ -167,7 +167,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 and outputting a ret instruction, which caused the          *
  * sketch to return to nowhere under certain conditions and never reach main() at all.            *