Fix docs

Author: SpenceKonde

avr/extras/ATtiny_43.md

@@ -40,7 +40,7 @@ Obviously, you can buy my lovely tiny43 board with the buck converter ready to g
  You want, ideally, a device which is prohibited by the laws of physics - a diode with near zero forward drop, but even more importantly, you need a diode with very VERY low reverse leakage current. If you just optiomi
 
 
-### PWM frequency:
+### PWM frequency
 TC0 is always run in Fast PWM mode: We use TC0 for millis, and phase correct mode can't be used on the millis timer - you need to read the count to get micros, but that doesn't tell you the time in phase correct mode because you don't know if it's upcounting or downcounting in phase correct mode. On this part, the TC1 is uniquely bad - it has a different, shorter list of possible WGMs, and is only 8 bits.
 
 | F_CPU  | F_PWM<sub>TC0</sub> | F_PWM<sub>TC1</sub>   | Notes                        |

avr/extras/ATtiny_x41.md

@@ -66,7 +66,7 @@ Example of a "guard" against wrong pin mapping:
 
 All pin mapping options assume that PB2 has the LED (bootloaders will blink that pin, and LED_BUILTIN is defined as PIN_PB2), unless it's a micronucleus configuration with D+ on PB2, in which case it will instead use PB0.
 
-### PWM frequency:
+### PWM frequency
 TC0 is always run in Fast PWM mode: We use TC0 for millis, and phase correct mode can't be used on the millis timer - you need to read the count to get micros, but that doesn't tell you the time in phase correct mode because you don't know if it's upcounting or downcounting in phase correct mode. Unique among the tinyAVRs, the x41 parts have a third timer. TC1 and TC2 are both the "good" timers, the 16-bit-capable ones.
 
 | F_CPU  | F_PWM<sub>TC0</sub> | F_PWM<sub>TC1/2</sub> | Notes                        |

avr/extras/ATtiny_x7.md

@@ -175,16 +175,16 @@ Mironucleus used: Micronucleus boards are locked to the crystal, no oscillator c
 
 ### Purchasing ATtiny167 Boards
 I (Spence Konde / Dr. Azzy) sell ATtiny167 boards through my Tindie store - your purchases support the continued development of this core. A new version is now available. In order to fit in the same form factor as my other tinyAVR breakout boards, these use the TSSOP-20 package version insteaad of the bulky SOIC-20.
-* [Azduino Tiny167 Pro - bare board]()
-* [Azduino Tiny167 Pro]()
-* [Ultramini - fits a DIP-24 socket]()
+* Azduino Tiny167 Pro - bare board - pending verification of functionality.
+* Azduino Tiny167 Pro - pending verification and assembly.
+* Ultramini - fits a DIP-24 socket - pending verification of functionality.
 
 ## Package variants
 The 87 and 167 are available in three package variations. Additionally, the 167 only can be had in a fourth package.
 * SOIC-20 (wide) - bigger than the side of a house, but easy to hand solder
 * TSSOP-20 - Slightly more demanding to solder. While it is hard to imagine being able to read this text and miss a bridge between adjacent pins on a SOIC-20, the same cannot be said for a SSOP-20 - depending on your eyesight, you may need magnification or more attention to lighting in order to spot bridges visually
 * VQFN32 - with 12 unused pins - Atmel seemed to REALLY like this package - a lot of 20-pin tinyAVR parts got this as their QFN instead of a proper QFN20-type. It's an annoying package, though - it's very fine pitch, large for a QFN (5mm x 5mm), and the unused pins don't appear to have been arranged with consideration of the layout. They're in the same order as the pins up and down the two sides of the SOIC/SSOP parts (probably a technical constraint I've never seen a chip with what was belived to have the same die, *not* have the same pin order, so I think bond wires have to make straight lines that don't cross each other from the die to the pin), but the decisons for where those dummy pins would go appears to have been based only on their convenience.
-* WQFN20 (167 only) - the only time, to my knowledge, that a new package option has been added for a classic AVR after the Microchip buyout. That this has only happened once, despite many examples of disappointing packages fromthe past, so I have to imagine that one or more very large customers (they're automotive parts, so the main buyers tend to be small in number but make up for it in volume) was giving them holy hell over that 32-pin package. The 87 did not get the same blessing (nor did the 861, which was also a 20-pin tiny stuck in a 32-pin VQFN), nor did any other part they have made. They have also not added any packages to a post-revolutionary part either, even when we can show that the die size would would work fine based on what they've already fit it into, and it is plain to see the that the product is held back by it's current package options.
+* WQFN20 (167 only) - the only time, to my knowledge, that a new package option has been added for a classic AVR after the Microchip buyout. That this has only happened once, despite many examples of disappointing packages fromthe past, leads me to belive that one or more very large customers (they're automotive parts, so the main buyers tend to be small in number but make up for it in volume) was giving them holy hell over that 32-pin package. The 87 did not get the same blessing (nor did the 861, which was also a 20-pin tiny stuck in a 32-pin VQFN), nor did any other part they have made. They have also not added any packages to a post-revolutionary part either, even when we can show that the die size would would work fine based on what they've already fit it into, and it is plain to see the that the product is held back by it's current package options.
 
 ## Interrupt Vectors
 This table lists all of the interrupt vectors available on the ATtiny x7-family, aas well as the name you refer to them as when using the `ISR()` macro. Be aware that a non-existent vector is just a "warning" not an "error" (for example, if you misspell a vector name) - however, when that interrupt is triggered, the device will (at best) immediately reset (and not clearly - I refer to this as a "dirty reset") The catastrophic nature of the failure often makes debugging challenging.

avr/extras/Ref_Internals.md

@@ -1,4 +1,4 @@
-# Internals and advanced functionality:
+# Internals and advanced functionality
 
 You can identify the core using the following:
 

avr/extras/development/removed_from_wiring.c

@@ -73,14 +73,14 @@ On these devices, when the master writes:
 2. Master clocks out the 7 bit part address and the Write bit
 3. Slave ACKs
 4. Master clocks out the address. Slave sets the pointer to this and acks (rarely, the second byte is also part of the pointer address (usually encountered with EEPROMs))
-5. Master clocks out one byte of data to write tothat address (most devices autoincrement, a few dont)
-6. Slave writes it to that location in the virtual register table and acks
+5. Master clocks out one byte of data to write tothat address (most devices autoincrement, a few don't, some have an option for that in some register).
+6. Slave writes it to to it's internal SFRs or RAM as appropriate.
 7. Repeat 5 and 6 until all data transferred.
-8. Master generates a stop condition
+8. Master responds with a NACK and generates a stop condition.
 
 For a read, the master would first perform the first 4 steps above setting the location they want to read from, then either send a stop, then start condition or a repeated start and then reads per steps 5 to 8 of the way the Arduino API provides.
 
-### Yeah, they don't line up so good.
-It's like the API designer read the protocol spec and designed to that and had never actually used an I2C device. You cannot have a register-model, because you don't know how many bytes the master will read (the protocol never tells you this), nor can you find out how many are read after the fact, nor can you put the slave to sleep because it might be silently servicing an interrupt for a read that hasn't finished yet. This will generally make you "that device" that when misused, becomes non-responsive with one or both being held low. You don't want to be that device.
+### Yeah, they don't line up so good
+It's like the API designer read the protocol spec and designed to that and had never actually used an I2C device, or had little imagination and hadn't attempted to make anything that acted like other I2C devices. You cannot have a register-model, because you don't know how many bytes the master will read (the protocol never tells you this), nor can you find out how many are read after the fact, nor can you put the slave to sleep because it might be silently servicing an interrupt for a read that hasn't finished yet. This will generally make you "that device" that when misused, becomes non-responsive with one or both lines being held low. You don't want to be that device. I don't really have any good solution to offer here, but this is why all arduino slave devices you've seen use I2C like lobotomized serial: That's the only mode of operation that the API supports.
 
-The API has been extended for DxCore and mTC, as the problem was far more tractable there (not only is it a single implementation covering a much more cooperative peripheral, the same library works unmodified and likely will continue to do so for the forseeable future.
+The API has been extended for DxCore and mTC - the problem was far more tractable there: It only had to be done once for every AVR released since 2016 - the same library works unmodified and likely will continue to do so for the forseeable future, with only trivial changes, whereas it would have to be done thrice for the older parts. Moreover, on all of these parts, whatever I2C implementation is available, it is much less helpful, and lacks the features that we used for this on mTC and DxC.