diff --git a/.github/workflows/arduino-lint.yml b/.github/workflows/arduino-lint.yml index 612d5c45..bd9a1509 100644 --- a/.github/workflows/arduino-lint.yml +++ b/.github/workflows/arduino-lint.yml @@ -23,3 +23,4 @@ jobs: uses: arduino/arduino-lint-action@v1 with: path: megaavr + token: ${{ secrets.GITHUB_TOKEN }} diff --git a/.github/workflows/general-formatting-checks.yml b/.github/workflows/general-formatting-checks.yml index 8a1c4cae..eb3b77a6 100644 --- a/.github/workflows/general-formatting-checks.yml +++ b/.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 diff --git a/ChangeLog.md b/ChangeLog.md index 72bf0021..07b3fc52 100644 --- a/ChangeLog.md +++ b/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). diff --git a/ContributionGuidelines.md b/ContributionGuidelines.md index 9b778b0f..614d74be 100644 --- a/ContributionGuidelines.md +++ b/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) diff --git a/README.md b/README.md index f11cf115..5a71ea1f 100644 --- a/README.md +++ b/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. diff --git a/megaavr/cores/dxcore/WInterrupts.c b/megaavr/cores/dxcore/WInterrupts.c index 691846e2..030cb400 100644 --- a/megaavr/cores/dxcore/WInterrupts.c +++ b/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" diff --git a/megaavr/cores/dxcore/wiring_analog.c b/megaavr/cores/dxcore/wiring_analog.c index 3e0e9923..2f726634 100644 --- a/megaavr/cores/dxcore/wiring_analog.c +++ b/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); } diff --git a/megaavr/extras/DB28.md b/megaavr/extras/DB28.md index ca5adf36..3cdf3f73 100644 --- a/megaavr/extras/DB28.md +++ b/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. diff --git a/megaavr/extras/DB32.md b/megaavr/extras/DB32.md index 36ee07c5..6ceea202 100644 --- a/megaavr/extras/DB32.md +++ b/megaavr/extras/DB32.md @@ -152,12 +152,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. diff --git a/megaavr/extras/DU14.md b/megaavr/extras/DU14.md index c99e916a..86405c1c 100644 --- a/megaavr/extras/DU14.md +++ b/megaavr/extras/DU14.md @@ -3,7 +3,7 @@ ## Pin Mapping / Pinout `[DU14 Pin Mapping](DU14.png "Arduino Pin Mapping for AVR DU14")` -**Image not available - absent help we do not forsee being able to provide any sort of pinout diagram for this or future parts** +**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts** **Please help** diff --git a/megaavr/extras/DU20.md b/megaavr/extras/DU20.md index b6789acc..3a74e5ef 100644 --- a/megaavr/extras/DU20.md +++ b/megaavr/extras/DU20.md @@ -3,7 +3,7 @@ ## Pin Mapping / Pinout `[DU20 Pin Mapping](DU20.png "Arduino Pin Mapping for AVR DU20")` -**Image not available - absent help we do not forsee being able to provide any sort of pinout diagram for this or future parts** +**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts** ## Features and Peripherals diff --git a/megaavr/extras/DU28.md b/megaavr/extras/DU28.md index 83be4fbb..19f420de 100644 --- a/megaavr/extras/DU28.md +++ b/megaavr/extras/DU28.md @@ -3,7 +3,7 @@ ## Pin Mapping / Pinout `[DU28 Pin Mapping](DU28.png "Arduino Pin Mapping for AVR DU328")` -**Image not available - absent help we do not forsee being able to provide any sort of pinout diagram for this or future parts** +**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts** ## Features and Peripherals diff --git a/megaavr/extras/DU32.md b/megaavr/extras/DU32.md index 9ec2d6a0..2ffb0d96 100644 --- a/megaavr/extras/DU32.md +++ b/megaavr/extras/DU32.md @@ -3,7 +3,7 @@ ## Pin Mapping / Pinout `[DU32 Pin Mapping](EA48.png "Arduino Pin Mapping for AVR DU32")` -**Image not available - absent help we do not forsee being able to provide any sort of pinout diagram for this or future parts** +**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts** ## Features and Peripherals | | AVR[16|32|64]DU32 | diff --git a/megaavr/extras/EA28.md b/megaavr/extras/EA28.md index e999214e..f23f5d40 100644 --- a/megaavr/extras/EA28.md +++ b/megaavr/extras/EA28.md @@ -1,7 +1,7 @@ # AVR64EA28/AVR32EA28/AVR16EA28/AVR8EA28 ## Pin Mapping / Pinout `[EA28 Pin Mapping](EA28.png "Arduino Pin Mapping for AVR EA28")` -**Image not available - absent help we do not forsee being able to provide any sort of pinout diagram for this or future parts** +**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts** ## Features and Peripherals | - | AVRxxEA28 | diff --git a/megaavr/extras/EA32.md b/megaavr/extras/EA32.md index d92da6a2..8bafe118 100644 --- a/megaavr/extras/EA32.md +++ b/megaavr/extras/EA32.md @@ -1,7 +1,7 @@ # AVR64EA32/AVR32EA32/AVR16EA32/AVR8EA32 ## Pin Mapping / Pinout `[EA32 Pin Mapping](EA32.png "Arduino Pin Mapping for AVR EA32")` -**Image not available - absent help we do not forsee being able to provide any sort of pinout diagram for this or future parts** +**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts** ## Features and Peripherals | - | AVRxxEA32 | diff --git a/megaavr/extras/EA48.md b/megaavr/extras/EA48.md index aa8430df..a8c5c002 100644 --- a/megaavr/extras/EA48.md +++ b/megaavr/extras/EA48.md @@ -1,7 +1,7 @@ # AVR64EA48/AVR32EA48/AVR16EA48 ## Pin Mapping / Pinout `[EA48 Pin Mapping](EA48.png "Arduino Pin Mapping for AVR EA48")` -**Image not available - absent help we do not forsee being able to provide any sort of pinout diagram for this or future parts** +**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts** ## Features and Peripherals | - | AVRxxEA48 | diff --git a/megaavr/extras/EB14.md b/megaavr/extras/EB14.md index 5b2eec79..2fe449ce 100644 --- a/megaavr/extras/EB14.md +++ b/megaavr/extras/EB14.md @@ -3,7 +3,7 @@ ## Pin Mapping / Pinout `![EB14 Pin Mapping](AVRxxEB14.svg "Arduino Pin Mapping for AVR EB14")` -**Image not available - absent help we do not forsee being able to provide any sort of pinout diagram for this or future parts** +**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts** ## Features and Peripherals diff --git a/megaavr/extras/EB20.md b/megaavr/extras/EB20.md index 9d0f690d..c2885b07 100644 --- a/megaavr/extras/EB20.md +++ b/megaavr/extras/EB20.md @@ -4,7 +4,7 @@ ## Pin Mapping / Pinout `![EB20 Pin Mapping](AVRxxEB20.svg "Arduino Pin Mapping for AVR EB20")` -**Image not available - absent help we do not forsee being able to provide any sort of pinout diagram for this or future parts** +**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts** ## Features and Peripherals | Feature | AVR16EB20 | AVR32EB20 | diff --git a/megaavr/extras/EB28.md b/megaavr/extras/EB28.md index 78be3589..0a892a4c 100644 --- a/megaavr/extras/EB28.md +++ b/megaavr/extras/EB28.md @@ -3,7 +3,7 @@ ## Pin Mapping / Pinout `![EB28 Pin Mapping](AVRxxEB28.svg "Arduino Pin Mapping for AVR EB28")` -**Image not available - absent help we do not forsee being able to provide any sort of pinout diagram for this or future parts** +**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts** ## Features and Peripherals diff --git a/megaavr/extras/EB32.md b/megaavr/extras/EB32.md index 018994a4..15571554 100644 --- a/megaavr/extras/EB32.md +++ b/megaavr/extras/EB32.md @@ -3,7 +3,7 @@ ## Pin Mapping / Pinout `![EB32 Pin Mapping](AVRxxEB32.svg "Arduino Pin Mapping for AVR EB32")` -**Image not available - absent help we do not forsee being able to provide any sort of pinout diagram for this or future parts** +**Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts** ## Features and Peripherals diff --git a/megaavr/extras/Ref_Defines.md b/megaavr/extras/Ref_Defines.md index 04756c29..69d79b8b 100644 --- a/megaavr/extras/Ref_Defines.md +++ b/megaavr/extras/Ref_Defines.md @@ -284,7 +284,7 @@ There are a number of macros for determining what (if any) features the core sup ## Hardware feature detection * `ADC_MAX_OVERSAMPLED_RESOLUTION` = 13 (tinyAVR0/1), 15 (Dx-series) or 17 (tinyAVR 2 or Ex-series) - If either `CORE_HAS_ANALOG_ENH` or `CORE_HAS_ANALOG_DIFF` is 1, this will be defined as the maximum resolution obtainable automatically via oversampling and decimation using those functions. -* `ADC_MAXIMUM_GAIN` is 0 (DA, DD, DU, tinyAVR0/1), -1 (DB), or 16 (EA, EB, tinyAVR 2) - Some parts' ADC is blessed with a Programmable Gain Amplifier (PGA) amplifier, often used for differential readings (though modern AVRs can use it for single-ended readings, if they have it - not that it's terribly useful). The Dx-series are not among them, though the EA will have it. If this is defined as a positive number, it is the maximum gain available (16 on the EA). If this is defined as 0 that means there is no way to amplify an analog signal we might want to measure (if this is a problem you need external opamps). If this is defined as -1 (or 255 if stuffed into a uint8), there are one or more `OPAMP` peripherals available which could be directed towards the same purpose, though more deliberation and part specific work would be needed; they may be more flexible in some ways, but they are very rigid in others (for example, in that there is only one pin option for them. If it is defined as -128 (128 in a uint8) there is a gain stage on the differential ADC, but it is specified along with the pair of pins, not with separate configuration options. This also means that it's *NOT* a modern AVR! This is generally what is done on all classic AVRs with a differential ADC) so the available gain options depend on which pins are being measured, and there is a different procedure to use it, as detailed in the core documentation (ex, ATTinyCore 2.0.0 and later). If it is undefined, there is definitley no support exposed through the core, and it may not be a feature of the hardware at all. +* `ADC_MAXIMUM_GAIN` is 0 (DA, DD, DU, tinyAVR0/1), -1 (DB), or 16 (EA, EB, tinyAVR 2) - Some parts' ADC is blessed with a Programmable Gain Amplifier (PGA) amplifier, often used for differential readings (though modern AVRs can use it for single-ended readings, if they have it - not that it's terribly useful). The Dx-series are not among them, though the EA will have it. If this is defined as a positive number, it is the maximum gain available (16 on the EA). If this is defined as 0 that means there is no way to amplify an analog signal we might want to measure (if this is a problem you need external opamps). If this is defined as -1 (or 255 if stuffed into a uint8), there are one or more `OPAMP` peripherals available which could be directed towards the same purpose, though more deliberation and part specific work would be needed; they may be more flexible in some ways, but they are very rigid in others (for example, in that there is only one pin option for them. If it is defined as -128 (128 in a uint8) there is a gain stage on the differential ADC, but it is specified along with the pair of pins, not with separate configuration options. This also means that it's *NOT* a modern AVR! This is generally what is done on all classic AVRs with a differential ADC) so the available gain options depend on which pins are being measured, and there is a different procedure to use it, as detailed in the core documentation (ex, ATTinyCore 2.0.0 and later). If it is undefined, there is definitely no support exposed through the core, and it may not be a feature of the hardware at all. * `_AVR_PORT_INLVL` is 1 if the INLVL bit is present. If undefined or 0, that feature is not available. ## Hardware pin determination diff --git a/megaavr/extras/Ref_Digital.md b/megaavr/extras/Ref_Digital.md index ae1a2416..6b22759a 100644 --- a/megaavr/extras/Ref_Digital.md +++ b/megaavr/extras/Ref_Digital.md @@ -39,7 +39,7 @@ You might be scurrying to your datasheets thinking "I swear they were symmetric What tinyAVR calls current injection, Dx/Ex-series call "Clamp current" - it's current through the protection diodes. Oddly It wasn't spec'ed on classic AVRs (but was well known as the usual cause of "blown" pins). Atmel employees are rumored to have said +/- 1mA maximum, which is pretty poor). Certainly if that is true (likely, and consistent with the number of blown pins people are reporting on forums) If you think the problem with blown pins on arduinos with classic AVRs is bad among hobby folks (based on the forums), it's apparently WAY worse in schools - I've heard of highschool instructors who grab an arduino from the shared bin to do a demo, intentionally choosing weird unpopular pins - *because so many of the shared boards have blown pins*... and apparently they don't replace them - or even the pluggable chip on most Unos. I think it's a public school thing - they get funding to set up something new, but not for maintaining existing things that's a much longer term and less . And though I think any of us could give a dead simple flow chart for determining if an uno is bad, and if so whether replacing the chip will fix it.) -It remains to be seen what the pin drive strength will be like on the Ex-series or any other future part, and until the IO pin output current is added to the characteristics graphs section of the datasheet, you don't really have much information; preliminary datasheets typically omit this sort of data, because these properties have not yet been characterized. (I'm not sure how they manage that. Automating that testing, while not trivial, would be far from of reach for a few microcontroller experts. Now, I'm not a Microchip personenle department worker, nor am I an employee there at all (I am prety sure some of the things I've said would get me fired or prevent me from getting hired there - but the things to which I refer are both accurate (if a bit dramatic) and criticisms which have to be heard), but from the outside, I'm pretty sure there are a considerable number of microcontroller experts employed by Microchip, so I'm unsure why this information takes so long +It remains to be seen what the pin drive strength will be like on the Ex-series or any other future part, and until the IO pin output current is added to the characteristics graphs section of the datasheet, you don't really have much information; preliminary datasheets typically omit this sort of data, because these properties have not yet been characterized. (I'm not sure how they manage that. Automating that testing, while not trivial, would be far from of reach for a few microcontroller experts. Now, I'm not a Microchip personenle department worker, nor am I an employee there at all (I am pretty sure some of the things I've said would get me fired or prevent me from getting hired there - but the things to which I refer are both accurate (if a bit dramatic) and criticisms which have to be heard), but from the outside, I'm pretty sure there are a considerable number of microcontroller experts employed by Microchip, so I'm unsure why this information takes so long ## Ballpark overhead figures The digital I/O functions are astonishingly inefficient. This isn't my fault (not on mTC - on DxC I have definitely not helped...) - it's the Arduino API's fault @@ -203,7 +203,7 @@ These are the maximum voltage guaranteed to qualify as LOW and the minimum guara * With Vdd = 1.8 V (the minimum), below about half the operating voltage, it's going to read low, while it may need to be very close to the power rail to read `HIGH`. * With Vdd = 5.0 V (maximum typically used intentionally) anything over about 1/3rd if the supply voltage is guaranteed to be `HIGH`, and you need to get down to 1/6th of the supply voltage for a guaranteed `LOW`. * The actual lower threshold is likely to be higher, and the upper threshold lower. For example, on DA-series SMBus pins, those voltages are 1.09 V and 1.24 V over most of the operating voltage range. This leave you with very little hysteresis, if that happens to be problematic. - * If interacting with an output that for whatever reason struggles to pull the pin as close to ground as an ideal output should, or if you're counting on the transition being somewhere near the middle of the range, definitley don't use this option. + * If interacting with an output that for whatever reason struggles to pull the pin as close to ground as an ideal output should, or if you're counting on the transition being somewhere near the middle of the range, definitely don't use this option. Particularly in the context of these MVIO-equipped parts, however, the TTL input level option has an obvious major advatage: It makes communication with parts that run at lower voltages easier, and reduces competition for the limited number of MVIO pins. If we allow the low part to control it push-pull (aka totam-pole and other names), and treat it as an `INPUT`, we will always read what they intend. The fact that you can switch a pin between input and output, while pulling it up externally was noted above, and the voltage it was pulled up to could be the lower operating vboltage. That can be done on any AVR. But with INLVL, this scheme is viable for a bidirectional line: the The line between devices could either be pulled up to the lowest operating voltage externally, with the DB or DD series part manipulating the pin as an open drain output (see above). One need not stop with just two devices - multiple DB/DD-series parts with `INVLV = TTL` set could communicate with multiple devices operating at the low voltage, as long as none of them ever drove it `HIGH` (though, if it was low, they would not know which device was doing that. The designer would have to make sure this approach made sense in that regard, and that everything was smart enough to not hold onto the line or anything. diff --git a/megaavr/extras/Ref_Reset.md b/megaavr/extras/Ref_Reset.md index f4c44981..4a9499bf 100644 --- a/megaavr/extras/Ref_Reset.md +++ b/megaavr/extras/Ref_Reset.md @@ -79,7 +79,7 @@ The reset sources are listed below. Note that for brevity and familiarity to tho ### The power of two software resets The fact that there are now two ways of resetting from software changes things. There is an obvious way that both features can be used (an application uses the WDT to detect that it has gotten hung up somewhere and reset itself, and issues a software reset when some set of conditions is met or per user command). This is likely the most common use of them outside of Arduino. But there is also a second way that these can be used, and this is how we use it by default - Use SWRF as a "reset and run bootloader" while you can trigger resets without SWRF by the standard method of setting the WDT for minimum time and then going into forever loop which will trigger the reset. -It is not recommended to set windowed mode and continualy send WDRs. You're doing something strange. When someone else reads it, or you read it later, you will likely have to come back and read either this document or the datasheet to understand how continually WDRs which normally would prevent the WDT from resetting, but for windowed mode. That would be okay - an ugly hack if it would reult in eliminating the 8 ms wait - but it just replaces it with a slightly slower one - WDRs, like everything related to the WDT, have a 2-3 WDT clock sync delay. The WDT clock is around 1 kHz derived from the internal 32 kHz ULP. Once you write the settings to the WDT register, it will take 2-3ms. Then the timer starts up. Now you can execute WDR, and it's no longer a no-op. The first WDR goes in - but you can't queue up a second WDR - WDR will again be a no-op unil, 2-3 ms later, the first WDR finishes syncing; it will reach the WDT and reset the timer - only after this first WDR is the window used, and only after that WDR is synced will a WDR instruction do start syncing a WDR. 2-3 ms later, it will finally slam into the closed window. Now a total of 3 sync periods have happened, for a total of 6-9 ms If we had not done this and simply used the shortest timeout, we would reset in 10-11 ms (2-3 ms sync before it turns on, minimum setting of 8 WDT ticks as WDT period. We could save as little as 1ms or as much as 6ms. +It is not recommended to set windowed mode and continualy send WDRs. You're doing something strange. When someone else reads it, or you read it later, you will likely have to come back and read either this document or the datasheet to understand how continually WDRs which normally would prevent the WDT from resetting, but for windowed mode. That would be okay - an ugly hack if it would result in eliminating the 8 ms wait - but it just replaces it with a slightly slower one - WDRs, like everything related to the WDT, have a 2-3 WDT clock sync delay. The WDT clock is around 1 kHz derived from the internal 32 kHz ULP. Once you write the settings to the WDT register, it will take 2-3ms. Then the timer starts up. Now you can execute WDR, and it's no longer a no-op. The first WDR goes in - but you can't queue up a second WDR - WDR will again be a no-op unil, 2-3 ms later, the first WDR finishes syncing; it will reach the WDT and reset the timer - only after this first WDR is the window used, and only after that WDR is synced will a WDR instruction do start syncing a WDR. 2-3 ms later, it will finally slam into the closed window. Now a total of 3 sync periods have happened, for a total of 6-9 ms If we had not done this and simply used the shortest timeout, we would reset in 10-11 ms (2-3 ms sync before it turns on, minimum setting of 8 WDT ticks as WDT period. We could save as little as 1ms or as much as 6ms. No matter what, triggering a reset with the WDT hence takes far longer than other methods., but at 11 ms, still a very short period of tme by human standards. diff --git a/megaavr/extras/Ref_Robust.md b/megaavr/extras/Ref_Robust.md index 29c53f3c..e48d358a 100644 --- a/megaavr/extras/Ref_Robust.md +++ b/megaavr/extras/Ref_Robust.md @@ -103,4 +103,4 @@ If it doesn't work, you need to either solve the technical problem, or clearly d In warm conditions, are any heatsinks you're using sufficient? How close does the temperature get to the ratings? ### Shake, poke, drop -Everything gets abused. Make sure your physical assembly is sufficiently robust. Shake it while it's running and make sure it doesn't reset (unless that's what it's designed to do, or is too heavy to shake). Poke and prod it while it's running (assuming it doesn't have dangerous voltages exposed, which it really ought not to have!). Hold it by its wires, yank out its cable (Micro USB connectors should be the kind with the through holes, which prevent a yank from pulling the connector off the PCB, unless you have a case around it to keep the force from being handled mainly by the connector). The crap connectors that many developemnt boards have used are so bad they've given MicroUSB a bad rep in some circles - including for a time Arduino circles due to the connector on early Arduino Micros. Pick them up and drop them from as high a height as is plausible. Your customers may use the products while frazzled and hurried, at awkward physical angles, and while intoxicated - sometimes all of the above. If your product is unavoidably fragile, warn people (but don't cry wolf if it's not). +Everything gets abused. Make sure your physical assembly is sufficiently robust. Shake it while it's running and make sure it doesn't reset (unless that's what it's designed to do, or is too heavy to shake). Poke and prod it while it's running (assuming it doesn't have dangerous voltages exposed, which it really ought not to have!). Hold it by its wires, yank out its cable (Micro USB connectors should be the kind with the through holes, which prevent a yank from pulling the connector off the PCB, unless you have a case around it to keep the force from being handled mainly by the connector). The crap connectors that many development boards have used are so bad they've given MicroUSB a bad rep in some circles - including for a time Arduino circles due to the connector on early Arduino Micros. Pick them up and drop them from as high a height as is plausible. Your customers may use the products while frazzled and hurried, at awkward physical angles, and while intoxicated - sometimes all of the above. If your product is unavoidably fragile, warn people (but don't cry wolf if it's not). diff --git a/megaavr/extras/Ref_Timers.md b/megaavr/extras/Ref_Timers.md index d4e2bcdc..f4553a60 100644 --- a/megaavr/extras/Ref_Timers.md +++ b/megaavr/extras/Ref_Timers.md @@ -13,7 +13,7 @@ This document is divided into two sections. The first one simply describes the a * [Input Capture on Event](Ref_Timers.md#input-capture-on-event) * [Input Capture Frequency Measurement](Ref_Timers.md#input-capture-frequency-measurement) * [Input Capture Pulse Width Measurement](Ref_Timers.md#input-capture-pulse-width-measurement) - * [Input Capture Frequecy And Pulse Width Measurement](Ref_Timers.md#input-capture-frequecy-and-pulse-width-measurement) + * [Input Capture Frequency And Pulse Width Measurement](Ref_Timers.md#input-capture-frequency-and-pulse-width-measurement) * [Single-shot](Ref_Timers.md#single-shot) * [Timeout Check](Ref_Timers.md#timeout-check) * [8-bit PWM mode](Ref_Timers.md#8-bit-pwm-mode) @@ -108,7 +108,7 @@ This applies to the tinyAVR 0/1/2-series, megaAVR 0-series, and AVR DA, DB and D ### TCA0 - Type A 16-bit Timer with 3/6 PWM channels This timer is the crown jewel of the modern AVR devices, as far as timers go. It can be operated in two very different modes. The default mode on startup is "Normal" or `SINGLE` mode - it acts as a single 16-bit timer with 3 output compare channels. It can count in either direction, and can also be used as an event counter (ie, effectively "clocked" off the event), is capable of counting up or down, generating PWM in single and dual slope modes, and has 7-output prescaler. In terms of PWM generation, a TCA in SINGLE mode is on the same level as the classic avr 16-bit Timer1 (though most classic AVRs only had 2 outputs per timer - there the third output was a rare feature reserved for top-end parts like the 2560). The newly added features aren't ones that are particularly relevant for most Arduino users. TCA0 can generate events or interrupts on compare match for each channel (independently), as well as on an overflow. -The Type A timer can be also be set to split mode to get six 8-bit PWM channels (this is how it is configured by default by megaTinyCore and DxCore - since `analogWrite()` is only 8-bit, we might as well double the number of channels we get right? In split mode the high and low bytes of the timer count `TCA0.SINGLE.CNT` register become `TCA.SPLIT.LCNT` and `TCA.SPLIT.LCNT`; likewise the period and compare registers *in SINGLE mode, these are 16-bit registers; accessing them uses the temporary register. In SPLIT mode, they are 8-bit registers!* (Unlike the TCB in PWM mode, this works correctly on all parts). The frequency of the clock from which the signals generated by the two halves of the timer are derived is always the same - they share the prescaler - but the period, and hence the frequecy of the output, is not. For example, if we have a 1 MHz clock (16 MHz prescaled by 16), and set LPER to 249 (250 clocks) and HPER to 199 (200 clocks) the low-half period, covering WO 0-2 will generate PWM at 4kHz, and the high half will generate PWM at 5 kHz on WO3-5. +The Type A timer can be also be set to split mode to get six 8-bit PWM channels (this is how it is configured by default by megaTinyCore and DxCore - since `analogWrite()` is only 8-bit, we might as well double the number of channels we get right? In split mode the high and low bytes of the timer count `TCA0.SINGLE.CNT` register become `TCA.SPLIT.LCNT` and `TCA.SPLIT.LCNT`; likewise the period and compare registers *in SINGLE mode, these are 16-bit registers; accessing them uses the temporary register. In SPLIT mode, they are 8-bit registers!* (Unlike the TCB in PWM mode, this works correctly on all parts). The frequency of the clock from which the signals generated by the two halves of the timer are derived is always the same - they share the prescaler - but the period, and hence the frequency of the output, is not. For example, if we have a 1 MHz clock (16 MHz prescaled by 16), and set LPER to 249 (250 clocks) and HPER to 199 (200 clocks) the low-half period, covering WO 0-2 will generate PWM at 4kHz, and the high half will generate PWM at 5 kHz on WO3-5. Event functionality is not supported in SPLIT mode. @@ -152,7 +152,7 @@ As above, but at the specified edge, the timer count is automatically reset (aft #### Input Capture Pulse Width Measurement One edge restarts the timer. The other edge copies the value and fires the interrupt, thus making it perfect for timing the length of pulses. -#### Input Capture Frequecy And Pulse Width Measurement +#### Input Capture Frequency And Pulse Width Measurement This one is the weird one. Does not work with prescaled clocks on some tinyAVRs (see silicon errata listings). On one edge, it starts the timer. On the other edge, it copies the count to CCMP *and continues to count* until the next edge. Only then will the interrupt fire (if enabled). Whether via polling or interrupt, when you see that this has happened, you need copy the count value someplace safely, then the CCMP value. As soon as CCMP has been read, when it next sees the "start count" edge, it will reset the timer and start counting. Thus, while great for measuring PWM of varying frequency and duty cycle where the duty cycle does not change drastically from cycle to cycle, it is not useful if you need to record every cycle (for that, you're forced to use Input Capture on Event mode, and have your interrupt very quickly switch the edge to which it is sensitive). #### Single-shot diff --git a/megaavr/extras/ci/codespell-ignore-words-list.txt b/megaavr/extras/ci/codespell-ignore-words-list.txt index 30cce681..8bf2eae6 100644 --- a/megaavr/extras/ci/codespell-ignore-words-list.txt +++ b/megaavr/extras/ci/codespell-ignore-words-list.txt @@ -4,3 +4,6 @@ acn combatibility shat commend +bootup +shiftIn +Rin diff --git a/megaavr/extras/ci/test-sketch/all/dummysketch/dummysketch.ino b/megaavr/extras/ci/test-sketch/all/dummysketch/dummysketch.ino index fadea9aa..bf58668d 100644 --- a/megaavr/extras/ci/test-sketch/all/dummysketch/dummysketch.ino +++ b/megaavr/extras/ci/test-sketch/all/dummysketch/dummysketch.ino @@ -1,4 +1,4 @@ -/* test fails entirely if any one loction in the list doesn't have a sketch, so we have to provide +/* test fails entirely if any one location in the list doesn't have a sketch, so we have to provide * a dummy sketch for lists which might otherwise be empty. */ diff --git a/megaavr/extras/ci/test-sketch/da/dummysketch/dummysketch.ino b/megaavr/extras/ci/test-sketch/da/dummysketch/dummysketch.ino index fadea9aa..bf58668d 100644 --- a/megaavr/extras/ci/test-sketch/da/dummysketch/dummysketch.ino +++ b/megaavr/extras/ci/test-sketch/da/dummysketch/dummysketch.ino @@ -1,4 +1,4 @@ -/* test fails entirely if any one loction in the list doesn't have a sketch, so we have to provide +/* test fails entirely if any one location in the list doesn't have a sketch, so we have to provide * a dummy sketch for lists which might otherwise be empty. */ diff --git a/megaavr/extras/ci/test-sketch/db/dummysketch/dummysketch.ino b/megaavr/extras/ci/test-sketch/db/dummysketch/dummysketch.ino index fadea9aa..bf58668d 100644 --- a/megaavr/extras/ci/test-sketch/db/dummysketch/dummysketch.ino +++ b/megaavr/extras/ci/test-sketch/db/dummysketch/dummysketch.ino @@ -1,4 +1,4 @@ -/* test fails entirely if any one loction in the list doesn't have a sketch, so we have to provide +/* test fails entirely if any one location in the list doesn't have a sketch, so we have to provide * a dummy sketch for lists which might otherwise be empty. */ diff --git a/megaavr/libraries/DxCore/README.md b/megaavr/libraries/DxCore/README.md index 02f1294f..96de3f5e 100644 --- a/megaavr/libraries/DxCore/README.md +++ b/megaavr/libraries/DxCore/README.md @@ -139,7 +139,7 @@ By default (if no argument is passed to getMVIOStatus() it will not use "debuggi Except for situation 1, which is most likely user error, or situation 4 (which would be a novel silicon bug), these situations can arise only when using a third party IDE that not configured to set the fuses, or is configured to set them incorrectly, or if that IDE does not pass the required define (`MVIO_ENABLED`) along to the compiler to tell it when MVIO is enabled. If cases 2 or 3 ever occur with the Arduino IDE, that is a serious bug that should be reported promptly along with any information on how you were able to make it happen. -Multiple errors can (and typically will be) be combined if they apply. `MVIO_MENU_SET_WRONG` only ever returned with at least MVIO_SETTING_MISMATCH, though the latter can appear without the former in Optiboot configurations, while in case 2, it is returned along with `MVIO_IMPOSIBLE_CFG` to indicate that it is not supposed to be possible to get the chip into this confiuration. It is also returned in weird situations that they datasheet says are impossible, for example if the system is set to single supply mode, but `MVIO.STATUS != 1` or `MVIO.INTFLAGS != 0`, directly contrary to the datasheet (MVIO chapter, functional description, under Initialization). +Multiple errors can (and typically will be) be combined if they apply. `MVIO_MENU_SET_WRONG` only ever returned with at least MVIO_SETTING_MISMATCH, though the latter can appear without the former in Optiboot configurations, while in case 2, it is returned along with `MVIO_IMPOSIBLE_CFG` to indicate that it is not supposed to be possible to get the chip into this configuration. It is also returned in weird situations that they datasheet says are impossible, for example if the system is set to single supply mode, but `MVIO.STATUS != 1` or `MVIO.INTFLAGS != 0`, directly contrary to the datasheet (MVIO chapter, functional description, under Initialization). The error values should be tested on a bitwise basis (ie, bitwise and), not with equality (as they are almost always combined) under most use cases. `if(getMVIOStatus()) {...}` will run the conditional statements if MVIO is **not** enabled and working. Similarly, `if(!getMVIOStatus()) {...}` or `if(!getMVIOStatus() == 0) {...}` will run the conditional if MVIO **is** supported and enabled, whether or not there is an appropriate VDDIO2 voltage supplied. The below example shows how one might print human readable description of the MVIO status: diff --git a/megaavr/libraries/Flash/src/Flash.cpp b/megaavr/libraries/Flash/src/Flash.cpp index 61a6acbe..d813fe1f 100644 --- a/megaavr/libraries/Flash/src/Flash.cpp +++ b/megaavr/libraries/Flash/src/Flash.cpp @@ -89,7 +89,7 @@ uint8_t FlashClass::checkWritable() { // the BOOTSIZE fuse must be 0 or 1. return FLASHWRITE_UNRECOGNIZED; } - // Optiboot 9.1 without SPM Z+ app callin support + // Optiboot 9.1 without SPM Z+ app call-in support // was shipped with 1.2.x and earlier of DxCore uint16_t optiversion = pgm_read_word_near(0x01fe); if (optiversion == 0x0901) { @@ -493,4 +493,4 @@ uint32_t FlashClass::flashAddress(uint8_t* mappedPtr) { } FlashClass Flash; -#endif // end of the ifdef SPMCOMMAND to de-clutter errpr messages. +#endif // end of the ifdef SPMCOMMAND to de-clutter error messages. diff --git a/megaavr/libraries/Logic/Tricks_and_Tips.md b/megaavr/libraries/Logic/Tricks_and_Tips.md index 7338333a..44e7b0aa 100644 --- a/megaavr/libraries/Logic/Tricks_and_Tips.md +++ b/megaavr/libraries/Logic/Tricks_and_Tips.md @@ -109,7 +109,7 @@ Sync/Filter: Off Yes, we could have done the third one with another CCL lut too - but why when there's a trick to do it without wasting a second LUT? Maybe we need the other LUTs. ### Modulated PWM -Like classic AVRs had on larger pincount devices. One PWM frequency should be significantly higher than the other if you're trying to modulate it, rather than measure the beat frequency or something, and they definitley should be at different frequencies, otherwise see the previous pattern. +Like classic AVRs had on larger pincount devices. One PWM frequency should be significantly higher than the other if you're trying to modulate it, rather than measure the beat frequency or something, and they definitely should be at different frequencies, otherwise see the previous pattern. INSEL: * X: Timer PWM channel. diff --git a/megaavr/libraries/tinyNeoPixel/tinyNeoPixel.cpp b/megaavr/libraries/tinyNeoPixel/tinyNeoPixel.cpp index 9c432367..b29b3b54 100644 --- a/megaavr/libraries/tinyNeoPixel/tinyNeoPixel.cpp +++ b/megaavr/libraries/tinyNeoPixel/tinyNeoPixel.cpp @@ -186,7 +186,7 @@ void tinyNeoPixel::show(uint16_t leds) { // // Finally, some of the constraints were incorrect, and this only ever // worked because classes are kryptonite to the optimizer. - // * [ptr] was decleared read only. No, it is not. The register is + // * [ptr] was declared read only. No, it is not. The register is // register contaains the address being pointed to. We read with // postincrement, so this is read-write. // * Conversely, [port], another pointer, is never written. The thing that diff --git a/megaavr/libraries/tinyNeoPixel_Static/tinyNeoPixel_Static.cpp b/megaavr/libraries/tinyNeoPixel_Static/tinyNeoPixel_Static.cpp index 9b562ed3..f86c9ac9 100644 --- a/megaavr/libraries/tinyNeoPixel_Static/tinyNeoPixel_Static.cpp +++ b/megaavr/libraries/tinyNeoPixel_Static/tinyNeoPixel_Static.cpp @@ -143,7 +143,7 @@ void tinyNeoPixel::show(uint16_t leds) { // // Finally, some of the constraints were incorrect, and this only ever // worked because classes are kryptonite to the optimizer. - // * [ptr] was decleared read only. No, it is not. The register is + // * [ptr] was declared read only. No, it is not. The register is // register contaains the address being pointed to. We read with // postincrement, so this is read-write. // * Conversely, [port], another pointer, is never written. The thing that diff --git a/megaavr/variants/32pin-ddseries/pins_arduino.h b/megaavr/variants/32pin-ddseries/pins_arduino.h index d5290794..b4466942 100644 --- a/megaavr/variants/32pin-ddseries/pins_arduino.h +++ b/megaavr/variants/32pin-ddseries/pins_arduino.h @@ -91,7 +91,7 @@ Include guard and include basic libraries. We are normally including this inside # # # # ### # # ### ##*/ // If you change the number of pins in any way or if the part has ADC on different pins from the board you are adapting // you must ensure that these will do what they say they will do. -// that bit about the 4 ADC ADC channels on PORTC not worling with MVIO enabled is ugly to handle. +// that bit about the 4 ADC ADC channels on PORTC not working with MVIO enabled is ugly to handle. #if !defined(USING_OPTIBOOT) || defined(ASSUME_MVIO_FUSE) /* When not using a bootloader, we know if MVIO is enabled because the fuse is set on upload */ #if defined(MVIO_ENABLED) /* MVIO disables ADC on PORTC */ #define IS_MVIO_ENABLED() (1) diff --git a/megaavr/variants/32pin-duseries/pins_arduino.h b/megaavr/variants/32pin-duseries/pins_arduino.h index fa9eebe2..07c991aa 100644 --- a/megaavr/variants/32pin-duseries/pins_arduino.h +++ b/megaavr/variants/32pin-duseries/pins_arduino.h @@ -91,7 +91,7 @@ Include guard and include basic libraries. We are normally including this inside # # # # ### # # ### ##*/ // If you change the number of pins in any way or if the part has ADC on different pins from the board you are adapting // you must ensure that these will do what they say they will do. -// that bit about the 4 ADC ADC channels on PORTC not worling with MVIO enabled is ugly to handle. +// that bit about the 4 ADC ADC channels on PORTC not working with MVIO enabled is ugly to handle. #if !defined(USING_OPTIBOOT) || defined(ASSUME_MVIO_FUSE) /* When not using a bootloader, we know if MVIO is enabled because the fuse is set on upload */ #if defined(MVIO_ENABLED) /* MVIO disables ADC on PORTC */ #define IS_MVIO_ENABLED() (1) diff --git a/megaavr/variants/32pin-easeries/pins_arduino.h b/megaavr/variants/32pin-easeries/pins_arduino.h index 4745ce32..ab696b4b 100644 --- a/megaavr/variants/32pin-easeries/pins_arduino.h +++ b/megaavr/variants/32pin-easeries/pins_arduino.h @@ -90,7 +90,7 @@ Include guard and include basic libraries. We are normally including this inside # # # # ### # # ### ##*/ // If you change the number of pins in any way or if the part has ADC on different pins from the board you are adapting // you must ensure that these will do what they say they will do. -// that bit about the 4 ADC ADC channels on PORTC not worling with MVIO enabled is ugly to handle. +// that bit about the 4 ADC ADC channels on PORTC not working with MVIO enabled is ugly to handle. #define digitalPinToAnalogInput(p) ((p) >= PIN_PD0 ? (((p) < PIN_PF0) ? (p) - PIN_PD0 : ((p) < PIN_PF6 ? ((p) - 4) : NOT_A_PIN)):(((p) > PIN_PA1) ? (p) + 20 : NOT_A_PIN)) #define analogChannelToDigitalPin(p) ((p) > 31 ? NOT_A_PIN : ((p) < 8 ? ((p) + PIN_PD0) : (p) > 21 ? (p) - 20 : (((p) > 15 ? (p + 4)) : NOT_A_PIN))) diff --git a/megaavr/variants/32pin-ebseries/pins_arduino.h b/megaavr/variants/32pin-ebseries/pins_arduino.h index eae7ebaa..11b6dc12 100644 --- a/megaavr/variants/32pin-ebseries/pins_arduino.h +++ b/megaavr/variants/32pin-ebseries/pins_arduino.h @@ -90,7 +90,7 @@ Include guard and include basic libraries. We are normally including this inside # # # # ### # # ### ##*/ // If you change the number of pins in any way or if the part has ADC on different pins from the board you are adapting // you must ensure that these will do what they say they will do. -// that bit about the 4 ADC ADC channels on PORTC not worling with MVIO enabled is ugly to handle. +// that bit about the 4 ADC ADC channels on PORTC not working with MVIO enabled is ugly to handle. #define digitalPinToAnalogInput(p) ((p) >= PIN_PD0 ? (((p) < PIN_PF0) ? (p) - PIN_PD0 : ((p) < PIN_PF6 ? ((p) - 4) : NOT_A_PIN)):(((p) > PIN_PA1) ? (p) + 20 : NOT_A_PIN)) #define analogChannelToDigitalPin(p) ((p) > 31 ? NOT_A_PIN : ((p) < 8 ? ((p) + PIN_PD0) : (p) > 21 ? (p) - 20 : (((p) > 15 ? (p + 4)) : NOT_A_PIN)))