Merge pull request #1179 from MX682X/master

Fixing Code Checks and syncronizing PTC with DxCore

ContributionGuidelines.md

@@ -233,7 +233,7 @@ But it looks like it works as long as the bitwise and is non-zero. There's no re
 * macros DO NOT CHECK TYPES; your macros that are exposed to user code library code must be hardened to take stupid types passed to them. Remember that while the core uses uint8_t's for all pin identifiers, code in the wild frequently follows the boneheaded lead of the Arduino IDE and uses signed 16-bit integers. A bug discovered in early 2023 involved the fact that if certain pin information macros were called with a signed value, the math where we checked if it was a valid pin could fuck up; we were checking if pin >= NUM_DIGITAL_PINS. When the values are unsigned, this works because -1 = 255 > pin whenever pin is valid - a single test can be used to catch both known NOT_A_PIN and other invalid pins not yet identified as much. But if a signed integer was passed to the macro, the default signed integer type would remain in use for the comparison with 0. So any negative number would pass through the test, and down the line would cause us to read from a memory location that was not part of the table we were looking values up in. If there is anything type sensitive, explicitly cast it.
 * Because of this, in macros, always use 255 if for some reason you have to write out the value of the NOT_A_whateveritis error values, not -1, even though you know it will end up in a uint8_t. There's no advantage to -1, but though you may know what type it will eventually have, you do not know the path it will take to get there, which may involve multiple data types.
 
-### Performance and binary size matter.
+### Performance and binary size matter
 Particularly within the core API, performance matters. That means that things like division and modulo are bad, especially on large datatypes. Division and modulo both run the same routines. Approx time cost of math (how the variables are initialized may have an impact of +/- 2 x (size of datatype), so this is not gospel. The time required for division shown below is an average, since that routine does not execute in a fixed period of time. Large numerators and small denominators make it worse - as you would expect, computing x / y where x < y is highly favorable. Notice that switching to 64-bit types from 32-bit ones more than doubles the execution time - this is due to register pressure. It is likely to actually have an even larger effect in practice if there are other variables that need to be swapped out of working registers and reloaded.*
 
 | Math Operation | uint8_t | uint16_t | uint32_t | uint64_t | float |

README.md

@@ -13,7 +13,7 @@ This corrects many of the bugs present in 2.6.x
 ### ATTN: Linux Users
 **Only versions of the Arduino IDE downloaded from [arduino.cc](https://arduino.cc) should be used, NEVER from a linux package manager. The package managers often have the Arduino IDE - but have *modified it*. This is despite their knowing nothing about Arduino or embedded development in general, much less what they would need to know to modify it successfully** Those version are notorious for subtle but serious issues caused by these unwise modifications. This core should not be expected to work on such versions, and no modifications will be made for the sake of fixing versions of the IDE that come from package managers for this reason.
 
-### IDE Versions 2.0.x and some 2.1 do not work correctly.
+### IDE Versions 2.0.x and some 2.1 do not work correctly
 This is a bug in the Arduino client.
 
 IDE versions between 1.8.13 and 2.x developed significant novel defects. IDE versions 1.8.2 and earlier , however, possess crippling unfixed defects. I believe that they finally have a working version of the IDE out, and I believe that latest is able to install my core correctly.
@@ -24,7 +24,7 @@ Prior to megaTinyCore 2.6.0, manual installation of megaTinyCore would cause V1.
 I buy a lot of electronics stuff on AliExpress. It's a great marketplace for things that are made by Chinese companies and are mostly generic, including loads of components unavailable to individuals in the global West any other way (ex, min order is a reel or something like that - if you can even find a component vendor that works with the no-name chinese chip maker). It is not a great place for the latest semiconductor product lines from major Western manufacturers, especially in the midst of a historic shortage of said chips. The modern AVR devices, when they are available through those channels at all, are **frequently reported to be fake or defective** (like ATtiny412s that think they're 416s and may not correctly execute power on reset). For that matter, **you probably don't want to buy any AVR microcontrollers on AliExpress**... Assembled boards, like Arduino Nano clones, generally work if you avoid the ones with the third party LGT8 chips and watch out for the ones with the ATmega168p instead of the '328p - but there are a lot of reports of bogus microcontrollers when they're sold as bare chips (I have heard of fake ATtiny85s that were actually remarked ATtiny13s; it's not just modern AVRs that get faked). There are a lot of interesting theories for where those bogus chips came from, and Microchip has remained totally silent on the issue.
 
 ## Using This Document
-This document is best viewed online (as opposed to opening the markdown file in your favorite text editor), so that links are clickable and inline images are shown, and probably most importantly, to make tables render correctly sometimes. Again, this [document can be found on github](https://github.com/SpenceKonde/megaTinyCore](https://github.com/SpenceKonde/megaTinyCore)
+This document is best viewed online (as opposed to opening the markdown file in your favorite text editor), so that links are clickable and inline images are shown, and probably most importantly, to make tables render correctly sometimes. Again, this [document can be found on github](<https://github.com/SpenceKonde/megaTinyCore>](<https://github.com/SpenceKonde/megaTinyCore>)
 
 ## Getting Started
 ### [Wiring](Wiring.md)

megaavr/extras/PlatformIO.md

@@ -227,7 +227,7 @@ Programmer used for uploading.
 | `powerdebugger_updi`                  | Power Debugger in UPDI mode                                                                                      |
 | `serialupdi`                          | Serial UPDI based on pymcuprog, includes improvements taken from the DxCore implementation                       |
 
-**Note that this is not an exhaustive list**. 
+**Note that this is not an exhaustive list**.
 The full list of supported programmers is accessible via the `avrdude -c ?` command.
 
 ### `upload_flags`
@@ -243,7 +243,7 @@ upload_flags =
 ### Using SerialUPDI from platformIO
 It has been reported that, added to platformio.ini, the following works for making platformIO use SerialUPDI, but requires `python3` in the path. This is also a very aggressive configuration, and you may have better luck if you back off the speed to 115200 baud. UPDI does autobaud - you just want to make sure you pick a speed that the hardware will handle. 115200 works almost always, higher speeds are more demanding of how the UPDI circuit is wired up to meet required rise and fall times.
 
-However, note that this is probably obsolete and in most cases the same functionality can be achieved simply by setting `upload_protocol = serialupdi`, unless you have a specific reason to use this core's implementation. 
+However, note that this is probably obsolete and in most cases the same functionality can be achieved simply by setting `upload_protocol = serialupdi`, unless you have a specific reason to use this core's implementation.
 ```ini
 [env:ATtiny1614]
 platform = atmelmegaavr
@@ -252,18 +252,18 @@ framework = arduino
 platform_packages = platformio/framework-arduino-megaavr-megatinycore@https://github.com/SpenceKonde/megaTinyCore
 
 ; Fill in the following as per your hardware setup
-upload_port = 
+upload_port =
 upload_speed = 230400
 
-upload_flags = 
-	--tool
-	uart
-	--device
-	$BOARD
-	--uart
-	$UPLOAD_PORT
-	-b
-	$UPLOAD_SPEED
+upload_flags =
+    --tool
+    uart
+    --device
+    $BOARD
+    --uart
+    $UPLOAD_PORT
+    -b
+    $UPLOAD_SPEED
 
 upload_protocol = custom
 upload_command = python3 ${platformio.packages_dir}/framework-arduino-megaavr-megatinycore/tools/prog.py $UPLOAD_FLAGS -f$SOURCE -a write