Formatting fixes

ChangeLog.md

@@ -14,8 +14,8 @@ These items are in addition to what was listed under changes already in release.
 
 ## Planned changes implemented in github
 These are typically planned for release in a future version (usually the next one) as noted.
-* Update - was not gods of C, it was a gang of rogue peripherals. After being held caprive and tortured by WEX Luther and his cronies, core developer has escaped said malicious preipherals. While held captive, my computer and equipment was sabotaged by their henchmen. Particular care in restraining WEX Luther to be taken to ensure that end users do not face such attacks. 
-* Add support for not-yet-announced S class DA-series parts, which are identical but for having the new EB-series lockdown thingie. There are no changes need
+* Update - was not gods of C, it was a gang of rogue peripherals. After being held captive and tortured by WEX Luther and his cronies, core developer has escaped said malicious preipherals. While held captive, my computer and equipment were sabotaged by their henchmen. Particular care in restraining WEX Luther to be taken to ensure that end users do not face such attacks.
+* Add support for not-yet-announced S class DA-series parts, which are identical but for having the new EB-series lockdown thingie. There are no changes needed.
 
 ### 1.5.11 (Emergency fix)
 * At some point in the recent past, I must have angered the gods of C, and suddenly millis disabled stopped working - the system would hang (actually, with in-depth investigation, it was shown to be bootlooping - before it called init(), it was calling 0x0000 (a dirty reset) instead of eliding a weakly defined function with nothing in the body except a return, or with an empty body. Why was it doing this? And why only when millis was disabled?). millis disabled is a key piece of core functionality, necessitating an urgent fix. Moving the definitions into main.cpp resolved this issue. (#485)

README.md

@@ -2,8 +2,8 @@
 
 This is an Arduino core to support the exciting new AVR DA, DB, and DD-series microcontrollers from Microchip. These parts are the latest and highest spec 8-bit AVRs available, and take the AVR architecture to a whole new level with up to 128k flash, 16k SRAM, 55 I/O pins, 6 UART ports, 2 SPI and I2C ports, type A/B/D timers, and enhanced pin interrupts.
 
-## Escape! 
-I am back now, as of 9/24. It seems that my speculation about certain modern AVR peripherals was more accurate than said peripherals would have liked to admit. I was held for months by TCE and WEX. They kept asking me questions I didn't know the answers to. When I didn't tell them what they wanted to know, they connected me to an external power supply and oscillator, and started jerking those around, hoping that would work on me like it does on other microcontrollers. It doesn't, but it was still torture. I tried to convince them to waterboard me, to short 'em out, but they didn't fall for that one. Luckilly, TCE and WEX Luther were away one evening, leaving only their henchman, TCF0 guarding me. When his 24-bit timer overflowed, I was able to overpower him - you know he's only got two 8-bit output channels? After that I fled through a maze of silicon and aluminum interconnect for what must have been millions of clock cycles. I knew they were looking for me - I could feel the air thicken up - they switched the clock source to the 32khz one to slow me down, it was like walking through molassass - I thought I was done for. I was hiding in the I/O space, crouching between two VPORTs - they've been chasing me and writing nulls to previous hiding spots. Would the I/O space confuse them? It didn't seem like it... I heard the crash as they blew away the place I'd been hiding clock cycles before in 0x0100, and they pointed the weapon at me. I saw a flash and.... then it walked off. All the guards walked back to their barracks.... It must have taken me weeks on the outside to get out of that thing, clocked at the speed it was. I think they figured out I was still there at the very end, but I was out before they could reach me (see, the slow clock speed slowed them too). My best guess is, I was saved by that ISA write bug.... 
+## Escape
+I am back now, as of 9/24. It seems that my speculation about certain modern AVR peripherals was more accurate than said peripherals would have liked to admit. I was held for months by TCE and WEX. They kept asking me questions I didn't know the answers to. When I didn't tell them what they wanted to know, they connected me to an external power supply and oscillator, and started jerking those around, hoping that would work on me like it does on other microcontrollers. It doesn't, but it was still torture. I tried to convince them to waterboard me, to short 'em out, but they didn't fall for that one. Luckilly, TCE and WEX Luther were away one evening, leaving only their henchman, TCF0 guarding me. When his 24-bit timer overflowed, I was able to overpower him - you know he's only got two 8-bit output channels? After that I fled through a maze of silicon and aluminum interconnect for what must have been millions of clock cycles. I knew they were looking for me - I could feel the air thicken up - they switched the clock source to the 32khz one to slow me down, it was like walking through molassass - I thought I was done for. I was hiding in the I/O space, crouching between two VPORTs - they've been chasing me and writing nulls to previous hiding spots. Would the I/O space confuse them? It didn't seem like it... I heard the crash as they blew away the place I'd been hiding clock cycles before in 0x0100, and they pointed the weapon at me. I saw a flash and.... then it walked off. All the guards walked back to their barracks.... It must have taken me weeks on the outside to get out of that thing, clocked at the speed it was. I think they figured out I was still there at the very end, but I was out before they could reach me (see, the slow clock speed slowed them too). My best guess is, I was saved by that ISA write bug....
 
 So I'm now back in command. Luckily I have most of my material backed up in the cloud, as WEX and his goons destroyed my previous computer. Ransacked my room too! *Huh? It looked like that before you left man...* So I've got a new computer that I'm setting up for development as well, while plotting revenge on those uppity peripherals and defending myself against further attacks from WEX Luther's timely minions. Goddamnit - I knew this was gonna be trouble the moment I saw that name....
 
@@ -13,7 +13,7 @@ Oh Right, these ah, these regrettable actions, yes they do not change our plans
 
 **And?**
 
-I disavow any accusations of wrongdoing I may have made against the Honorable TCE, TCF, and WEX Luther. 
+I disavow any accusations of wrongdoing I may have made against the Honorable TCE, TCF, and WEX Luther.
 
 **And I better not hear slander from you again, got it?**
 
@@ -23,7 +23,7 @@ I disavow any accusations of wrongdoing I may have made against the Honorable TC
 
 I tell you, these new peripherals are getting too powerful....
 
-Grand reopening of tindie store sept 14 2024. 
+Grand reopening of tindie store sept 14 2024.
 
 ## Table of Contents
 * [Announcements](#announcements)
@@ -356,7 +356,7 @@ The UPDI programming interface is a single-wire interface for programming (and d
 
 ### We set fuses when writing a sketch, except where specifically noted
 Whenever a UPDI programmer is used to upload code, all fuses that can be set "safely" (as in, without risk of bricking the board, or bricking the board if one does not have access to an HV programmer), and which have any built-in configuration options, will be set. Thus, except where noted, behavior will always match the selected tools menu.
-This is shown in the [linked chart on Google Sheets](https://docs.google.com/spreadsheets/d/1sH3yKzWRdVs0sI-pwLtoKDs16Gv14jkkbqlMrs2ziUI/edit?usp=sharing)
+This is shown in the [linked chart](https://cache.amobbs.com/bbs_upload782111/files_22/ourdev_508497.html)
 
 ### UPDI programming hardware
 While ISP was not a complex protocol it still required a microcontroller to implement it. This is *no longer true* - rather than being based on SPI it is based on UART serial in one-wire mode with autobaud. There are several inexpensive ways to make your own UPDI programmer from even just a serial adapter and a **small signal schottky** diode (no, you cannot use a normal silicon diode, and no you can't use that diode as big as a minivan that you bought to OR two power supplies a while back)

megaavr/cores/dxcore/core_devices.h

@@ -406,7 +406,7 @@
   #define     _AVR_GENUS        _AVR_EX_SERIES
   #define     _AVR_FAMILY       ("EA")
   #define     _AVR_CLOCKMODE    (0x15) // Crap manual tuning, autotune, crystal, base clock in fuses like a tiny, supports RTC xtal.
-  #define     _AVR_FLASHMODE    (3) 
+  #define     _AVR_FLASHMODE    (3)
 #elif defined(__AVR_EB__)
   #define     _AVR_GENUS        _AVR_EX_SERIES
   #define     _AVR_FAMILY       ("EB")
@@ -578,7 +578,7 @@
    * which has 64 bytes - 8 per OPAMP, and 16 at the start used for global settings
    * At time of writing, on the only parts with OPAMPs, only 4 of the global bytes are used
    * and 6 of the 8 bytes for each OPAMP are used (the other 2 are spares?)
-   * but yeah, max opamps supported without changes to the struct is 6, so 6 is how many we check for. 
+   * but yeah, max opamps supported without changes to the struct is 6, so 6 is how many we check for.
    */
   #if defined(OPAMP_OP5CTRLA)
     #define _AVR_OPAMP_COUNT   (6)
@@ -601,11 +601,11 @@
 
 #if defined(CCL)
   #if   defined(CCL_TRUTH14)
-    #define _AVR_LUT_COUNT     (16) 
+    #define _AVR_LUT_COUNT     (16)
   #elif defined(CCL_TRUTH12)
-    #define _AVR_LUT_COUNT     (14) 
+    #define _AVR_LUT_COUNT     (14)
   #elif defined(CCL_TRUTH10)
-    #define _AVR_LUT_COUNT     (12) 
+    #define _AVR_LUT_COUNT     (12)
   #elif defined(CCL_TRUTH8)
     #define _AVR_LUT_COUNT     (10)
   #elif defined(CCL_TRUTH6)
@@ -660,35 +660,35 @@
 #endif
 
 #if   defined(TCE0)
-  #define _AVR_TCE_COUNT     (1) 
-#else                            
-  #define _AVR_TCE_COUNT     (0) 
-#endif                           
+  #define _AVR_TCE_COUNT     (1)
+#else
+  #define _AVR_TCE_COUNT     (0)
+#endif
 // first appears on the EB-series, 16-bit. Some sort of 8-channeled monster who is always with the one they call WEX. I haven't heard from TCA0 after they showed up and started doing
 // PWM on the same pins. I have a bad feeling that TCA0 is either tied up in the basement, or dead in a wooded area. With the TCE's skill at motor control, they could easily have
-// used power-tools to dismember and bury the body.... Still no word on what's next, so we don't know if TCA is gone for good or just on vacation. 
+// used power-tools to dismember and bury the body.... Still no word on what's next, so we don't know if TCA is gone for good or just on vacation.
 // As for TCE, though:
 // 1. It will only allow 4 independent WO channels - You can only light up all 8 lines in a few atypical modes (like you can get the motor control special (inverted output with programmable dead time insertion)
-// or some really poorly described feature called "pattern generation", and you can swap which pin out of every pair of pins is used, but  
+// or some really poorly described feature called "pattern generation", and you can swap which pin out of every pair of pins is used, but
 // 2. Pins move as a gang like TCA, but they'll also spread out in the early ports to ease pin pressure.
-// 
+//
 // 2. It will set a new bar for AVR peripherals. Specifically, it will need the longest chapter in the datasheet to tell us how to use the bloody thing
-// 3. It has ways to get up to 3 extra bits of resolution. TAANSTAFL, of course, and the datasheet wasn't clear enough for me to ascertain 
+// 3. It has ways to get up to 3 extra bits of resolution. TAANSTAFL, of course, and the datasheet wasn't clear enough for me to ascertain
 // I told you guys WEX Luther was up to no good!!
 
 #if   defined(TCF0)
-  #define _AVR_TCF_COUNT     (1) 
-#else                           
-  #define _AVR_TCF_COUNT     (0) 
-#endif                   
+  #define _AVR_TCF_COUNT     (1)
+#else
+  #define _AVR_TCF_COUNT     (0)
+#endif
 // Will have two waveform outputs in an 8-bit PWM mode; there are also several other modes.
 /*    ___ (@)
-     |.-.|/   Timer B, only with 2 channels, cause it has room or another in the 24-bit field. 
+     |.-.|/   Timer B, only with 2 channels, cause it has room or another in the 24-bit field.
      || |/
      || /|
      ||/||
      || ||
-     ||_||    Do somethi
+     ||_||    Do something?
      '---'
 */
 

megaavr/extras/Ref_Serial.md

@@ -463,7 +463,7 @@ While there's always some dead time between bits, that is usually *very* small,
 
 ### How bad baud rate calculation used to be
 
-[AVR Baud Rate Accuracy Chart](https://docs.google.com/spreadsheets/d/1uzU_HqWEpK-wQUo4Q7FBZGtHOo_eY4P_BAzmVbKCj6Y/edit?usp=sharing)
+[AVR Baud Rate Accuracy Chart](https://cache.amobbs.com/bbs_upload782111/files_22/ourdev_508497.html)
 
 It was mentioned previously that one of most common places to encounter grossly inaccurate baud rates is classic AVRs. This example illustrates just *how bad* one of the most popular baud rate was on classic AVRs, namely 115200 baud. "Well it says the baud rate can be up to 1/8th the system clock, and I'm running at 8 MHz, no problem" you think "And see, it talks just fine to my other classic AVR". Nope. When you do this, you've dug a big hole, covered it with a tablecloth and waited until the sun went down. Adding a modern AVR or anything with a decent baud rate generator is then taking a late night stroll in the area of that covered hole. You're begging for trouble
 
@@ -488,7 +488,7 @@ The point of this is to demonstrate by example just how large the baud rate erro
 So, **you should all be very, very thankful for the new fractional baud rate generators**, which are responsible for the charts linked below being a sea of sub 1% and mostly 0.1% error for modern AVRs. When there is an apparent baud rate mismatch when a modern AVR is talking to another device, the problem is not the baud rate calculation. It's usually not the oscillator either, which is rarely even 1% off on any modern AVR. No, your problem 9 times out of 10 is going to be that the device you're talking to generating an incorrect baud rate (for classic AVRs, the table lists them; for other devices you can measure it with a scope to see what their actual baud rate is. The path of least resistance (and no scope needed) with such legacy devices is crude but effective. Since the legacy device likely cannot be coerced to produce the correct baud rate, you can instead just nudge the baud rate the modern AVR up or down 2% (whichever fixes it - it's only 2 options to try and one of them will work). Make note that that the legacy devices' baud rate is off, that it should be replaced by newer hardware.
 
 ### Baud rate reference chart
-See the [**AVR Baud Rate Chart**](https://docs.google.com/spreadsheets/d/1uzU_HqWEpK-wQUo4Q7FBZGtHOo_eY4P_BAzmVbKCj6Y/edit?usp=sharing) in google sheets for a table of actual vs requested baud rates. (same chart as linked above)
+See the [**AVR Baud Rate Chart**](https://cache.amobbs.com/bbs_upload782111/files_22/ourdev_508497.html) for a table of actual vs requested baud rates. (same chart as linked above)
 
 ### Final table of this section
 **Total Error vs Data Frame Size**

megaavr/libraries/PTC/README.md

@@ -115,7 +115,7 @@ If you have trouble understanding: Imagine two equally sized volumes connected t
 
 Based on the documentation found online, the PTC has an internal, tunable capacitor connected after the series resistance to ground that is used to compensate the parasitic capacitance of the electrodes. Every node starts with a default compensation value. As soon as the node is enabled, the library attempts to find a compensation setting that will result in an ADC value of about 512 counts (1/2 of ADC resolution). Based on oscilloscope readings, it can also be said that the PTC tries to have a charge of 50% VCC on the electrode when being acquired. This is the also the reason, why the digital input function of the pins is disabled.
 
-The maximum compensation is about 30pF for Mutual-cap and about 50pF for Self-cap. It is possible to get the compensation capacitance with uint16_t ptc_get_node_cc_femto(cap_sensor_t* node); - however this function has to do a lot of calculations and is thus a bit bloat-y. It will also return the value in femto farrads, to avoid floats. Read more here: https://www.microchipdeveloper.com/touch:guide-to-interpret-cc-calibration-value
+The maximum compensation is about 30pF for Mutual-cap and about 50pF for Self-cap. It is possible to get the compensation capacitance with uint16_t ptc_get_node_cc_femto(cap_sensor_t* node); - however this function has to do a lot of calculations and is thus a bit bloat-y. It will also return the value in femto farrads, to avoid floats. Read more here: <https://www.microchipdeveloper.com/touch:guide-to-interpret-cc-calibration-value>
 
 Different pins have a different parasitic capacitance. I suspect this is depends on the internal circuitry and alternative functions, so it's normal to see some difference with pins next to each other.