Merge pull request #539 from nomakewan/typofix

Fix typos

.github/workflows/arduino-lint.yml

@@ -23,3 +23,4 @@ jobs:
         uses: arduino/arduino-lint-action@v1
         with:
           path: megaavr
+          token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/general-formatting-checks.yml

@@ -97,4 +97,5 @@ jobs:
       - name: Lint Code Base
         uses: github/super-linter@v4
         env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           VALIDATE_MARKDOWN: true

ChangeLog.md

@@ -93,7 +93,7 @@ Spelling, grammar and typographical fixes.
 * Bugfix: pinConfigure would under some circumstances fail because of a misspelled variable.
 * Bugfix: Correct an issue with bootloading a specific DD-based board definition.
 * Enhancement: Add the the Optimization Level menu that megaTinycore got.
-* Enhancement: Improve Wire.h compatibility with other cores that have falled behind.
+* Enhancement: Improve Wire.h compatibility with other cores that have fallen behind.
 * Enhancement: Add option for 48 MHz crystal options. Because it turns out that a DB with E-spec temp rating often runs at that speed.
 * Bugfix: Correct issue with compiling for 32-pin DD-series for Optiboot. Correct several board.txt issues where the correct properties were assigned to the wrong boards.
 
@@ -262,7 +262,7 @@ Spelling, grammar and typographical fixes.
 * Enhancement: Optboot serial port menu option for the DD-series parts is now ready to be enabled.
 * Enhancement or bugfix, depending on perspective: init_reset_flags() will automatically clear reset flags if not overridden, stashing them in GPIOR0 (chosen because has lower overhead than a variable)
 * Enhancement: Add 27 MHz external clock/crystal... Math is amazingly simple, one of the cleanest so far!
-* Bugfix: Block attempts to use "upload using programmer" when an optiboot board is selected. That confiuration is guaranteed not to work, and we should not do things that we know 100% will not work. We would need a merged output file for this, but the IDE doesn't make those for us here. The only place it DOES make them is... on ATTinyCore, where they're not usable and we must go out of our way to delete the damned things)
+* Bugfix: Block attempts to use "upload using programmer" when an optiboot board is selected. That configuration is guaranteed not to work, and we should not do things that we know 100% will not work. We would need a merged output file for this, but the IDE doesn't make those for us here. The only place it DOES make them is... on ATTinyCore, where they're not usable and we must go out of our way to delete the damned things)
 * Documentation: Include recent version of the io headers for practical reference, and the original versions for historical reference (mostly so you can view them in your web browser).
 * Bugfix: Somewhere along the line I realized `MAPPED_PROGMEM` isn't a good name because the symbol is used by the headers too, and switched to PROGMEM_MAPPED. Docs and even some libraries were never updated and were silently not using this...
 * Documentation: Updated pinout diagrams and part specific docs (LOOOONGGGGG overdue).

ContributionGuidelines.md

@@ -11,7 +11,7 @@ They are discussions. I don't check them as often, because I don't expect to see
 
 ### Before creating an issue or discussion topic
 Check the existing  [issues](https://github.com/SpenceKonde/DxCore/issues), and recent [discussions](https://github.com/SpenceKonde/DxCore/discussions) and recently closed issues [closed issues](https://github.com/SpenceKonde/DxCore/issues?q=is%3Aissue+is%3Aclosed)
-1. If there is a disusssion, read it and see if it applies to you. If it does, either it will solve your problem or you will have additional information that shows that the issue is a defect in the core - if so it is recommended to post that information as a comment in that discussion thread **IFF** there is a large amount of additional and necessary context in the discussion, such that I should be converting the discusssion to an issue. Otherwise reference the discusssion and open a new issue.
+1. If there is a disusssion, read it and see if it applies to you. If it does, either it will solve your problem or you will have additional information that shows that the issue is a defect in the core - if so it is recommended to post that information as a comment in that discussion thread **IFF** there is a large amount of additional and necessary context in the discussion, such that I should be converting the discussion to an issue. Otherwise reference the discussion and open a new issue.
 2. If there is an existing issue that appears to be the exact same issue, read it. If your issue really does look the same, *and* the issue is either open, or was closed recently (and you think the fix didn't work), go ahead and comment there. By recently I mean a month or so, maybe a few months if the topic is obscure. Over 3-6 months, dollars to donuts, you've got a different bug that just has superficial similarities, and you should make a new issue.
 ***If you are unsure of whether your issue is the same as another issue, it is much better to put it in a new issue, and have me close it as a duplicate if its confirmed to be the same as another*** - The reason comes back to the "issues are action items". If we end up with two issues within one issue, It's very easy to autoclose the issue with a commit to fix one of them, and forget that there's another issue there. I don't mind closing duplicate issues.
 3. If such an issue was **recently** closed, read it to be sure it really is same. Have you updated to a version that is claimed to fix the issue? Is one even available? **issues are closed when they are fixed in github, not when a released version including the fix is available** - so you may need to update to the github version of the core in order to test a change. (see the installation docs)

README.md

@@ -65,7 +65,7 @@ This is an Arduino core to support the exciting new AVR DA, DB, and DD-series mi
   * [Memory-mapped flash? It's complicated](#memory-mapped-flash-its-complicated)
   * [Writing to Flash from App](#writing-to-flash-from-app)
   * [Servo Support](#servo-support)
-  * [`printf()` support for "printable" class](#"printf-support-for-printable-class)
+  * [`printf()` support for "printable" class](#printf-support-for-printable-class)
     * [**WARNING** `printf()` and variants thereof Have Many Pitfalls](#warning-printf-and-variants-thereof-have-many-pitfalls)
     * [Selectable `printf()` Implementation](#selectable-printf-implementation)
   * [Interrupts From Pins and in General](#interrupts-from-pins-and-in-general)
@@ -121,7 +121,7 @@ This is an Arduino core to support the exciting new AVR DA, DB, and DD-series mi
   * [`analogReadResolution()` is different](#analogreadresolution-is-different)
   * [As of 1.3.3, SerialEvent is removed](#as-of-133-serialevent-is-removed)
   * [Oh, and -Wall (compile warnings) are enabled no matter what you choose in the preferences](#oh-and--wall-compile-warnings-are-enabled-no-matter-what-you-choose-in-the-preferences)
-* [Instruction Set Enhancements (AVRe/AVRe+ vs AVRxt)](#instruction-set-enhancements-avreavre+-vs-avrxt)
+* [Instruction Set Enhancements (AVRe/AVRe+ vs AVRxt)](#instruction-set-enhancements-avreavre-vs-avrxt)
 * [License](#license)
 
 ## Announcements
@@ -296,7 +296,7 @@ EB: Migration path for tiny861 in low pincounts (these will be the first modern
 ## Supported Clock Speeds
 ### For the DA, DB, DD and DU-series parts
 The maximum rated spec is 24 MHz **across the entire voltage and temperature range.**
-And that temperature range is pretty nuts - 105C for I-spec and 125C for E-spec. With waterproofing, you could run at the bottom of a pot of boiling water! Maybe you're making a still for makin moonshine, but you want the control system entirely internal to make it easier to camouflage. There are lots of reasons not to do this (legal, chemical, flavor, sanity), but the temperature range of the AVR isn't one of them. Even if it's sitting in boiling water, that's no hotter than 100C.
+And that temperature range is pretty nuts - 105C for I-spec and 125C for E-spec. With waterproofing, you could run at the bottom of a pot of boiling water! Maybe you're making a still for making moonshine, but you want the control system entirely internal to make it easier to camouflage. There are lots of reasons not to do this (legal, chemical, flavor, sanity), but the temperature range of the AVR isn't one of them. Even if it's sitting in boiling water, that's no hotter than 100C.
 The internal oscillator can be used at 1 MHz, or any increment of 4 beyond that up to and including 32 MHz (note that this is 1/3rd more than max rating). For compatibility with tinyAVR, we also offer 5/10 MHz (generated by dividing 20 MHz).
 
 All parts can use an external clock, and DB and DD-series parts can also use a crystal.

megaavr/cores/dxcore/WInterrupts.c

@@ -286,7 +286,7 @@
       "icall"             "\n\t" // call their function, which is allowed to shit on any upper registers other than 28, 29, 16, and 17.
       "rjmp AIntLoop"     "\n\t" // Restart loop after.
     "AIntEnd:"            "\n\t" // sooner or later r17 will be 0 and we'll branch here.
-      // with EARLYCLEAR variant, we don't need to do anythin other than cleaning up working registers - flags already cleared.
+      // with EARLYCLEAR variant, we don't need to do anything other than cleaning up working registers - flags already cleared.
       "pop   r31"         "\n\t" // clean up a million registers
       "pop   r30"         "\n\t"
       "pop   r29"         "\n\t"

megaavr/cores/dxcore/wiring_analog.c

@@ -1223,7 +1223,7 @@ void analogWrite(uint8_t pin, int val) {
         }
       #endif
     }
-  // now hastily set the pin output with this quickie macro since we know alll we need in order to do so now.
+  // now hastily set the pin output with this quickie macro since we know all we need in order to do so now.
   }
   //_setOutput(portnum, bit_mask);
 }

megaavr/extras/DB28.md

@@ -140,12 +140,12 @@ At a minimum, everyone using a modern AVR should plan on having a PDF viewer ope
 
 The "silicon errata and datasheet clarification" is an extremely important document ~details~ lists and gives a terse description of ways in which they know that the hardware they are shipping does not behave as the datasheet describes. Both phrases are euphemisms. "Silicon Errata" are bugs in the hardware, which the manufacturer admits and agrees are incorrect behavior, and comes with a rarely fulfulled promise of a silicon revision to correct them. A "workaround" which may or may not be useful may by listed, or they may say "None". The workaround line may or may not be an accurate mirror on reality. For example, a "This feature does not work" erratum might have "Workaround: Do not use this feature" (not much of a workaround). But - for once - this goes both ways. An erratum listed as having no workaround occasionally in fact has a workaround. On he DA and DB, whichever pin the ADC is pointed at has it's digital input buffer disabled. All you need to to to work around that is set the ADC mux to point to something that's not a pin except when using it (that's what we do). I suspect a tunnel vision effect is in evidence here - in that example, I suspect that the problem was noticed in the context of trying to read the digital value of the pin while analog measurement was ongoing, so engineering was not thinking "Why the hell would anyone do that?!" but "Gee, yeah, there's no way you could do that", and nobody realized that there's a far more common case: the ADC is enabled, but not in use, and you may be doing other things with the pin..
 
-Now a Datasheet Clarification - that's a bit more serious. They are also usually silicon bugs, thogh technical miscommunication is not a non-issue. The key difference is that an erratum indicates that the intended fix involves changing the die, while Datasheet Clarification involves changing the datasheet to say that the current behavior is correct. On the one hand the average datasheet clarification is less severe than the average erratum. On the other hand, that's not to say there aren't nasty ones in there too.
+Now a Datasheet Clarification - that's a bit more serious. They are also usually silicon bugs, though technical miscommunication is not a non-issue. The key difference is that an erratum indicates that the intended fix involves changing the die, while Datasheet Clarification involves changing the datasheet to say that the current behavior is correct. On the one hand the average datasheet clarification is less severe than the average erratum. On the other hand, that's not to say there aren't nasty ones in there too.
 
 ### Technical briefs
 Technical briefs are what Microchip calls the sort of documents that most of the industry refers to as "app notes". Technical brief is an apt term, as it covers the wide range of usefulness and detail that can be seen in the technical briefs: Some of these are briefs as in a briefing, like what would be given to a military commander for making strategic decisions, and are highly useful. Other "technical briefs" are simply "brief", that is, short. This is not always bad, but sometimes a technical brief ends up FAR too brief and covers a topic that deserves considerably more discussion (the "product brief" is the extreme of this - in the past what is now called a "product brief" may have been called a "datasheet summary". There are also nn unfortunate few of the "technical briefs" that are even less helpful. Here the name is still apt, but in this case, it's in the sense of the article of clothing of that name: they cover the ass ("Yeah, we have a technical brief explaining that functionality"), but achieve little more. While they may be a starting point, you'd need a lot more to go anywhere.
 
-These three broad classes are likely correlated with the knowlede and skill of their authors. Some tech briefs are written by people who really know how the feature works at a very deep level, resulting in useful informative (yet occasionally cryptic - I think this happens when people who aren't tech writers by trade get order to write a public facing document after the documentation group has tried and failed to write a useful tech brief, so even after being edited for readability by tech writers and after the censors have gone over it and redacted anything too revealing, the core of the document is written by an engineer. Most engineers are poor at clearly communicating with people who aren't steeped in the jargon and who don't think like engineers. And since the tech writer knows they don't undersand it, when they can't parse an oddly phrased sentence, they leave it as is. But this isn't universal - there are good clear tech briefs... and the less-clear ones are usuallty of great value when you do finally make sense of them
+These three broad classes are likely correlated with the knowlede and skill of their authors. Some tech briefs are written by people who really know how the feature works at a very deep level, resulting in useful informative (yet occasionally cryptic - I think this happens when people who aren't tech writers by trade get order to write a public facing document after the documentation group has tried and failed to write a useful tech brief, so even after being edited for readability by tech writers and after the censors have gone over it and redacted anything too revealing, the core of the document is written by an engineer. Most engineers are poor at clearly communicating with people who aren't steeped in the jargon and who don't think like engineers. And since the tech writer knows they don't understand it, when they can't parse an oddly phrased sentence, they leave it as is. But this isn't universal - there are good clear tech briefs... and the less-clear ones are usuallty of great value when you do finally make sense of them
 
 The other classes are, I suspect correspond to - for the midrange - to things written by pepoeple who do really understand the peripheral, but little experience with using it except following the instructions from the engineers, which is very different than having solved a problem with it. These abstract tech briefs are less likely to be useful, but they do occasionally tell you the key "This is the the right way to do it" for a problem that you would have approached from a less effecftive direction. And the bad ones? Written by people who don't understand what their writing about, lack guidance from anyone who does, but aren't going to let that make tem miss a deadline.