lint

ContributionGuidelines.md

@@ -167,7 +167,7 @@ Notice how in this case, we noticed that we had an unusual structure for the tab
   e. Format it so that the operands to each instruction are lined up in columns
   f. Line up all the "\n\t" sequences.
   g. unless your asm takes only a small number of output or input operands, put input and output on separate lines. If you think it makes it clearer to put each opperand on it'd own line, do that.
-  h. You can't rjmp to a label in another function. You can jmp to it (though this only works because of LTO and technically is not above board), but not rjmp. Just because you have an rjmp doesn't mean the linker will decide to place the routine you want to jump to within range of an rjmp!
+  h. You can't rjmp to a label in another function. You can jmp to it (though this only works because of LTO and technically is not above board), but not rjmp. Just because you have an rjmp doesn't mean the linker will decide to place the routine you want to jump to within range of an rjmp! Don't forget also that you can't jmp on parts with 8k of flash or less (with a small number of oddballs, like the m808/809
   i. Your code must be correct and valid: A pointer to a volatile variable, which you use to change that variable using st X/Y/Z or std Y+q/Z+q only is an input operand. You haven't changed it! You've changed what it's pointing to, but you haven't changed the pointer. Similarly, you must never use a pointer to a non-volatile variable to write to that variable from within asm. The only variables you are can change are volatile variables accessed via pointers, and opperands declared with the read-write or write only constraint.
   j. A pointer to a variable, even if you only use it to read the variable, if you use ld X+/Y+/Z+ or ld -X/-Y/-Z must be marked as a read-write operand - the operand is the pointer, and you're changing it!
   k. If you specify a write only constraint it may contain anything until you write it. Specify a read-write opperand if you need to, for example, add to an existing value.
@@ -244,7 +244,7 @@ Code is constantly ported between DxCore and megaTinyCore. You need to be aware
   * If `__AVR_ARCH__` == 103, then the part has fully memory mapped flash. Just declare the variable const and access normally, it won't be copied to ram like it would be where `__AVR_ARCH__` != 103.
   * If FLMAP_LOCKED is defined, this change is implemented, and you are on a part has only partially mapped flash, but the user has not asked for FLMAP to be mutable, so it will be locked while app code is running. PROGMEM_MAPPED will be defined, and you can declare with PROGMEM_MAPPED and access them without the pgm_... macros (remember that this will result in flash with a big hole in the middle, and may cause programs to return inaccurate flash sizes during compilation and upload).
   * If PROGMEM_MAPPED is defined but FLMAP_LOCKED is not, this change has not been implemented yet, so FLMAP is mutable. You cannot safely use PROGMEM mapped in core or library code - that code could be used by people who change FLMAP, and it would then break horribly; you must declare the array PROGMEM and access with pgm_... macros. Note that this does not apply to your application, because there you control the application, and if you use PROGMEM_MAPPED and change FLMAP, you will get exactly what you deserve - severe breakage.
-  * If neither PROGMEM_MAPPED not FLMAP_LOCKED are defined, then either it's a classic AVR, or it's a modern AVR where __AVR_ARCH__ != 103, and the user has told us that they intend to change FLMAP. Either way, you need to do the same thing - PROGMEM and pgm_... macros.
+  * If neither PROGMEM_MAPPED not FLMAP_LOCKED are defined, then either it's a classic AVR, or it's a modern AVR where `__AVR_ARCH__` != 103, and the user has told us that they intend to change FLMAP. Either way, you need to do the same thing - PROGMEM and pgm_... macros.
 * Any code going into either core (unless it is specific to tinyAVR only and hence we know it won't be ported, and I agree with you about that), as core or library - must either use only PROGMEM and pgm_... macros, or must handle all cases appropriately using #ifs to conditionally compile the appropriate version, as shown below.
 
 ```c

megaavr/libraries/Logic/Tricks_and_Tips.md

@@ -170,7 +170,7 @@ Sync/Filter: Off for latch, on for flip-flop.
 ### Pulse-stretcher
 You often need pulses output on pins or to direct internal peripherals via the event system. Maybe you have an input that generates fast pulses, but you need a long enough pulse for a synchronous peripheral to react to, or maybe you'd like to generate a pulse from software, and then immediately write to another pin *during* the pulse, because that would make some bigbanged mess cleaner (I doubt it will, but feel free to try).
 
-#### Even LUT:
+#### Even LUT
 Start with the even LUT set to act as an S/R latch as described above.
 
 INSEL:
@@ -180,7 +180,7 @@ INSEL:
 
 LUT per above.
 
-#### Odd LUT:
+#### Odd LUT
 The odd lut is a simple delay.
 
 INSEL:
@@ -219,7 +219,7 @@ This combination does the following:
 ### Pulse Stretcher 2
 This uses the sequencer. It doesn't get you the delayed pulse. However, it is largely free of complications.
 
-#### Even LUT:
+#### Even LUT
 Even LUT drives set.
 
 INSEL:
@@ -229,7 +229,7 @@ INSEL:
 
 LUT 0x02
 
-#### Odd LUT:
+#### Odd LUT
 The odd lut drives reset, much like the one above did.
 
 INSEL:
@@ -347,7 +347,7 @@ This generates a pulse two or four clocks long on either a rising *or* falling e
 
 We need 2 LUTs, n, and n+1, where n is an even number.
 
-#### LUTn+1: Configure for 2 or 4 clock delay as above.
+#### LUTn+1: Configure for 2 or 4 clock delay as above
 See also variant below. The first stage is just generating a delayed version of the input waveform.
 
 #### LUTn