Mostly minor

SpenceKonde · Jun 21, 2023 · c8a87fa · c8a87fa
1 parent 9202a74
commit c8a87fa
Show file tree

Hide file tree

Showing 7 changed files with 120 additions and 77 deletions.
diff --git a/ChangeLog.md b/ChangeLog.md
@@ -17,9 +17,17 @@ These items are in addition to what was listed under changes already in release.
 * Port any applicable enhancements made to DxCore to megaTinyCore, should such happen be made.
 * If there are *other substantial changes that need to occur* within the core, I am unaware of the complaints and hence have no plans to address them before the heat death of the universe. If you desire changes on a more rapid timeline, please create an issue so that I am aware of the presence of said problem, deficiency, or imperfection. Those form the action item list for core development activity, so if something is not listed there, **it is unlikely to be implemented/fixed/etc** simply due to my being unaware of any concern.
 
+
 ## Unreleased changes
 Changes listed here are checked in to GitHub ("master" branch unless specifically noted; this is only done when a change involves a large amount of work and breaks the core in the interim, or where the change is considered very high risk, and needs testing by others prior to merging the changes with master - everything else goes straight into master). These changes are not yet in any "release" nor can they be installed through board manager, only downloading latest code from github will work. These changes will be included in the listed version, though planned version numbers may change without notice - critical fixes may be inserted before a planned release and the planned release bumped up a version, or versions may go from patch to minor version depending on the scale of changes
 
+### Planned 2.6.9 or 2.7.0
+* Bugfix: optiboot_x.c that has been in use since newyears day 2023 was never committed.
+* Bugfix: Remove boot_opt.h which is not applicable to modern AVRs.
+* Bugfix: Remove the useless dummy app that forced us to use avr-size -A to see the size of the bootloader separated from the app, and switch avr-size -A to normal avr-size to take advantage of this.
+* Rebuild all bootloader hex files Size appears unchanged. We need to get some eyes on this prior to release to make sure it works. This is simple stuff to do -it doesn't need to be done by me, so if some others could test the ones now checked into github that would be awesome
+
+
 ## Released Versions
 ### 2.6.8
 * CRITICAL bugfix: Fix issues introduced by pwm option menu. This prevented compilation on 1-series or Microchip boards. There were at least *4 separate issues* feeding into this.

diff --git a/README.md b/README.md
@@ -61,19 +61,12 @@ Read the [**SerialUPDI documentation**](https://github.com/SpenceKonde/AVR-Guida
 
 As of 2.3.2, with the dramatic improvements in performance, and the proven reliability of the wiring scheme using a diode instead of a resistor, and in light of the flakiness of the jtag2updi firmware, this is now the recommended programming method. As of this version, programming speed has been increased by as much as a factor of 20, and now far exceeds what was possible with jtag2updi (programming via jtag2updi is roughly comparable in speed to programming via SerialUPDI on the "SLOW" speed option, 57600 baud; the normal 230400 baud version programs about three times faster than the SLOW version or jtag2updi, while the "TURBO" option (runs at 460800 baud and increases upload speed by approximately 50% over the normal one. The TURBO speed version should only be used with devices running at 4.5v or more, as we have to run the UPDI clock faster to keep up (it is also not expected to be compatible with all serial adapters - this is an intentional tradeoff for improved performance), but it allows for upload and verification of a 32kB sketch in 4 seconds.
 
-#### Coming before year end 2022: HV programming tool
-An HV programming tool to be called HyperUPDI is expected to be available (though silicon shortages may limit quantities) by year end. It is *not* intended to replace SerialUPDI.
-* HV programming support for AVR-DD, AVR-EA, and tinyAVR parts, allowing the UPDI pin to be used as GPIO without precluding further programming.
-* An on-board buffer will allow data to be sent in chunks of 2k or more. The result of this will be a dramatic improvement in programming speed. I expect an improvement of perhaps 5-10% on Dx-series vs SerialUPDI (as it is already very close to the theoretical maximum) - but the benefits on tinyAVR c will be considerably greater, as at TURBO speed they spent half their time in a USB latency period/
-* When a normal serial console is used to access it, it will operate in passthrough mode, featuring the classic FTDI pinout.
-* When in programming mode, the nominal CTS line is used to output the UPDI signal. Many boards (including those I sell) now have a solder-jumper to connect CTS to UPDI. This will allow a you to upload via UPDI and then open the serial console without changing any connections nor the use of a bootloader!
-* It will utilize a new upload script (neither Prog.py nor avrdude) which leverages the python installation we bring in for SerialUPDI already.
-* Because of the built in awareness of the UPDI protocol and the NVMCTRL of supported parts other features like partial erase (to supplement Flash.h on the Dx-series).
-* Voltage options of 5V, 3.3V, and V<sub>target</sub> will be selectable with a slide switch, allowing programming where the target voltage is as low as 1.8V, programming devices running directly off LiPo batteries at 3.7-4.2v and so on.
-* Due to the considerably more complex hardware, HyperUPDI will obviously not be a $1 device like SerialUPDI (which I expect most people will continue to use)
-
-#### Realistically coming before year end 2022: Superior serial adapters
-A single-port serial adapter with a switch that toggles between UPDI and normal mode and another switch for 5v and 3.3v, and which exposes all modem liaison pins, with an optional stackable rider board that uses the more durable JST-XH connectors to help deal with the incredibly short lifespan of a dupont cable when beingfrequently plugged in and unplugged, particularly if you don't always connect them with perfect precision. This is a feature I added primarily with myself in mind, but if there is demand, I can totally get bulk JST-XH <-> Dupont adapter cables made - but is this worthwhile? That's a good question, because the whole reason I made the rider board was that dupont connectors have a short operating life - so you'd still need to be able to replace the dupont terminals your self or buy new adapter cables from me (note: the 3-pin cable suffers this issue far more often than the 6-pin ones. One might even consider putting a JST-XH header on the target board for this reason. The rider board will also feature 2 RGB leds facing sideways (so you can see them in almost any orientation) that can be enabled to show the status of modem liaison lights (this is particularly helpful for debugging).
+#### Hopefully coming 2023 early Q3: Superior serial adapters
+Three designs are being iterated: A dual port serial adapter where both are serial ports, a dual port serial adapter where one port is always UPDI, and and a single port one witch a switch to select the mode, and an optional addon board to give leds indicating status of modem control lines.
+
+These will allow use of either a SMT JST-XH connector or dupont connector - either way with 6 pins for serial (FTDI pinout as marked) and 3 pins (for UPDI).
+
+All three of these will be able to supply 3.3 or Vusb (nom. 5V), or disconnect both Vusb and 3V3 from the power, and expect that the target device is powered with 5.5V > Vdd > 1.8V. The logic levels used in this case will be the voltage of whatever is applied. Be warned that on dual serial devices, the VccIO power rail is shared! They must both be running at the same voltage, be the same device, or the adapter must be set to supply them and their power disconnected.
 
 #### (New in 2.5.6) What's With All The Different SerialUPDI Options?
 Depending on adapter model, and operating system, it has been found that different timing settings are required; however, settings needed to keep even 230400 baud from failing on Linux/Mac with most adapters impose a much larger time penalty on Windows, where the OS's serial handling is slow enough that nothing needs that delay...

diff --git a/megaavr/bootloaders/optiboot_x/optiboot_x.c b/megaavr/bootloaders/optiboot_x/optiboot_x.c
@@ -374,7 +374,7 @@ int main(void) {
   //  That means for overhead penalty of between 6 and 34 bytes added to app binary size, which is usable
   //  for other code, you would be able to....  ... enter the bootloader less robustly, and save 10 bytes
   //  in the bootloader, where you can't use it.
-  //  I do belive the phrase "strictly worse" describes this.
+  //  I do believe the phrase "strictly worse" describes this.
 
   __asm__ __volatile__("clr __zero_reg__");  // known-zero required by avr-libc
   ch = RSTCTRL.RSTFR;   // get reset cause

diff --git a/megaavr/cores/megatinycore/HardwareSerial.h b/megaavr/cores/megatinycore/HardwareSerial.h
@@ -68,55 +68,38 @@
  * Since the USE_ASM_* = 1 option is apparently working, we do not recommend disabling it, as it will waste flash and hurt performance.
  *
  * Flash versus RAM table
- * |       |  modern tinyAVR series parts   | Other modern parts   |
- * | Flash | 0-series | 1-series | 2-series | mega | All Dx |  EA  |
- * |-------|----------|----------|----------|------|--------|------|
- * |  2048 |      128 |      128 |       -  |   -  |     -  |   -  |
- * |  4096 |      256 |      256 |      512 |   -  |     -  |   -  |
- * |  8192 |      512 |      512 |     1024 | 1024 |     -  | 1024 |
- * | 16384 |     1024 |     2048 |     2048 | 2048 |   2048 | 2048 |
- * | 32768 |       -  |     2048 |     3072 | 4096 |   4096 | 4096 |
- * | 49152 |       -  |       -  |       -  | 6120 |     -  |   -  |
- * | 65536 |       -  |       -  |       -  |   -  |   8192 | 6120 |
- * |  128k |       -  |       -  |       -  |   -  |  16384 |   -  |
- * This ratio is remarkably consistent. No AVR part was ever made with
- * less than 8:1 flash:ram, nor more than 16:1, since first ATmegas!
- * The sole exception? The ATmega2560/2561 has only 8k RAM, a 32:1 flash to ram ratio.
- * (to be fair, you are allowed to use external RAM - which was a very rare feature indeed,
+ * |       |  modern tinyAVR series parts   | Other modern parts          |
+ * | Flash | 0-series | 1-series | 2-series | mega | All Dx |  EA  |  EB  |
+ * |-------|----------|----------|----------|------|--------|------|------|
+ * |  2048 |      128 |      128 |       -  |   -  |     -  |   -  |   -  |
+ * |  4096 |      256 |      256 |      512 |   -  |     -  |   -  |   -  |
+ * |  8192 |      512 |      512 |     1024 | 1024 |     -  | 1024 | 1024 |
+ * | 16384 |     1024 |     2048 |     2048 | 2048 |   2048 | 2048 | 2048 |
+ * | 32768 |       -  |     2048 |     3072 | 4096 |   4096 | 4096 | 3072 |
+ * | 49152 |       -  |       -  |       -  | 6120 |     -  |   -  |   -  |
+ * | 65536 |       -  |       -  |       -  |   -  |   8192 | 6120 |   -  |
+ * |  128k |       -  |       -  |       -  |   -  |  16384 |   -  |   -  |
+ * This ratio is remarkably consistent. No AVR part was ever made with less than 8:1 flash:ram,
+ * nor more than 16:1, since the earliest recognizable AVRs. I am only aware of one exception. Was it some bizarro part
+ * from the dark ages? Nope - it's the surprisingly popular ATmega2560!
+ * The ATmega2560/2561 has only 8k RAM, a 32:1 flash to ram ratio. (to be fair, you are allowed to use external RAM
+ * on those, which was a very rare feature indeed, and that is by far the most widespread part with such a feature - though if you're using the
+ * XMEM interface, you've burned 19 GPIO lines right there.... The ATmega2560 is kind of the "I have a job too big for an AVR.
+ * But I don't know how to program anything else!" part. That is not a compliment.
+ *
+ * |  RAM  | TX | RX | Amount of RAM implied | Total ram used |
+ * |-------|----|----|-----------------------|----------------|
+ * | < 512 | 16 | 16 | 256b (0/1 w/2k or 4k) | 32b, all 1 port|
+ * | <1024 | 16 | 32 | 512b                  | 48b or 96b     |
+ * | <2048 | 32 | 64 | 1024b                 | 96b or 192b    |
+ * | More  | 64 | 64 | 2048b or 3072b        | 128b or 256b   |
+ *
+ * (the two numbers in final column are given because 0/1-serieas has 1 port, but tiny2 has 2, though if you only use one, you only
+ * get one set of buffers)
  */
-#if !defined(LTODISABLED)
-#if !defined(USE_ASM_TXC)
-  #define USE_ASM_TXC 2    // A bit slower than 1 in exchange for halfduplex.
-//#define USE_ASM_TXC 1    // This *appears* to work? It's the easy one. saves 6b for 1 USART and 44b for each additional one
-#endif
-
-#if !defined(USE_ASM_RXC)
-  #define USE_ASM_RXC 1    // This now works. Saves only 4b for 1 usart but 98 for each additional one
-#endif
 
-#if !defined(USE_ASM_DRE)
-  #define USE_ASM_DRE 1      // This is the hard one...Depends on BOTH buffers, and has that other method of calling it. saves 34b for 1 USART and 68b for each additional one
-#endif
-#else
-  #warning "LTO has been disabled! ASM TXC/RXC/DRE not available. USART falling back to the old, flash-inefficient implementation with fewer features."
-  #if defined(USE_ASM_TXC)
-    #undef USE_ASM_TXC
-  #endif
+/* Buffer Sizing */
 
-  #if defined(USE_ASM_RXC)
-    #undef USE_ASM_RXC
-  #endif
-
-  #if defined(USE_ASM_DRE)
-    #undef USE_ASM_DRE
-  #endif
-#endif
-
-
-// savings:
-// 44 total for 0/1,
-// 301 for 2-series, which may be nearly 9% of the total flash!
-// The USE_ASM_* options can be disabled by defining them as 0 (in the same way that buffer sizes can be overridden)
 // The buffer sizes can be overridden in by defining SERIAL_TX_BUFFER either in variant file (as defines in pins_arduino.h) or boards.txt (By passing them as extra flags).
 // note that buffer sizes must be powers of 2 only.
 
@@ -169,6 +152,45 @@
   #error "ERROR: RX buffer size must be a power of two."
 #endif
 
+/* Buffer sizing done */
+
+
+#if !defined(LTODISABLED)
+#if !defined(USE_ASM_TXC)
+  #define USE_ASM_TXC 2    // A bit slower than 1 in exchange for halfduplex.
+//#define USE_ASM_TXC 1    // This *appears* to work? It's the easy one. saves 6b for 1 USART and 44b for each additional one
+#endif
+
+#if !defined(USE_ASM_RXC)
+  #define USE_ASM_RXC 1    // This now works. Saves only 4b for 1 usart but 98 for each additional one
+#endif
+
+#if !defined(USE_ASM_DRE)
+  #define USE_ASM_DRE 1    // This is the hard one...Depends on BOTH buffers, and has that other method of calling it. saves 34b for 1 USART and 68b for each additional one
+#endif
+#else
+  #warning "LTO has been disabled! ASM TXC/RXC/DRE not available. USART falling back to the old, flash-inefficient implementation with fewer features."
+  #if defined(USE_ASM_TXC)
+    #undef USE_ASM_TXC
+  #endif
+
+  #if defined(USE_ASM_RXC)
+    #undef USE_ASM_RXC
+  #endif
+
+  #if defined(USE_ASM_DRE)
+    #undef USE_ASM_DRE
+  #endif
+#endif
+
+
+// savings:
+// 44 total for 0/1,
+// 301 for 2-series, which may be nearly 9% of the total flash!
+// The USE_ASM_* options can be disabled by defining them as 0 (in the same way that buffer sizes can be overridden)
+// The buffer sizes can be overridden in by defining SERIAL_TX_BUFFER either in variant file (as defines in pins_arduino.h) or boards.txt (By passing them as extra flags).
+// note that buffer sizes must be powers of 2 only.
+
 #if USE_ASM_RXC == 1 && !(SERIAL_RX_BUFFER_SIZE == 256 || SERIAL_RX_BUFFER_SIZE == 128 || SERIAL_RX_BUFFER_SIZE == 64 || SERIAL_RX_BUFFER_SIZE == 32 || SERIAL_RX_BUFFER_SIZE == 16)
   #error "Assembly RX Complete (RXC) ISR is only supported when RX buffer size are 256, 128, 64, 32 or 16 bytes"
 #endif

diff --git a/megaavr/cores/megatinycore/UART.cpp b/megaavr/cores/megatinycore/UART.cpp
@@ -146,7 +146,7 @@
             "out     0x3f,      r24"  "\n\t"  // restore it
             "pop      r24"            "\n\t"  // pop r24 to get it's old value back
             "pop      r31"            "\n\t"  // and r31
-            "pop      r30"            "\n\t"  // Pop the register the ISR did
+            "pop      r30"            "\n\t"  // Pop the register the ISR pushed
             "reti"                    "\n"    // return from the interrupt.
             ::);
         __builtin_unreachable();