From 5bc7c4c11650f23aa61729a3b9e9cc99cf59d2aa Mon Sep 17 00:00:00 2001 From: nomakewan Date: Wed, 3 Jan 2024 13:09:25 -0800 Subject: [PATCH 1/2] Fix MVIO typo in boards.txt This fixes a typo in boards.txt. --- megaavr/boards.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/megaavr/boards.txt b/megaavr/boards.txt index 87a8ce55..c5e1e968 100644 --- a/megaavr/boards.txt +++ b/megaavr/boards.txt @@ -2890,7 +2890,7 @@ avrdbopti.menu.mvioopti.disabled.bootloader.mviobits=10 avrdbopti.menu.mvioopti.disabled.build.mvioenable= avrdbopti.menu.mvioopti.reallyenabled=Enabled. "burn bootloader" done for sure. avrdbopti.menu.mvioopti.reallyenabled.bootloader.mviobits=01 -avrdbopti.menu.mvioopti.reallyenabled.build.mvioenable==-DMVIO_ENABLED -DASSUME_MVIO_FUSE +avrdbopti.menu.mvioopti.reallyenabled.build.mvioenable=-DMVIO_ENABLED -DASSUME_MVIO_FUSE avrdbopti.menu.mvioopti.reallydisabled=Disabled. "burn bootloader" done for sure. avrdbopti.menu.mvioopti.reallydisabled.bootloader.mviobits=10 avrdbopti.menu.mvioopti.reallydisabled.build.mvioenable=-DASSUME_MVIO_FUSE @@ -3462,7 +3462,7 @@ avrddopti.menu.mvioopti.disabled.bootloader.mviobits=10 avrddopti.menu.mvioopti.disabled.build.mvioenable= avrddopti.menu.mvioopti.reallyenabled=Enabled, "burn bootloader" done for sure. avrddopti.menu.mvioopti.reallyenabled.bootloader.mviobits=01 -avrddopti.menu.mvioopti.reallyenabled.build.mvioenable==-DMVIO_ENABLED -DASSUME_MVIO_FUSE +avrddopti.menu.mvioopti.reallyenabled.build.mvioenable=-DMVIO_ENABLED -DASSUME_MVIO_FUSE avrddopti.menu.mvioopti.reallydisabled=Disabled, "burn bootloader" done for sure. avrddopti.menu.mvioopti.reallydisabled.bootloader.mviobits=10 avrddopti.menu.mvioopti.reallydisabled.build.mvioenable=-DASSUME_MVIO_FUSE @@ -3905,7 +3905,7 @@ azduinoboard.menu.mvioopti.disabled.bootloader.mviobits=10 azduinoboard.menu.mvioopti.disabled.build.mvioenable= azduinoboard.menu.mvioopti.reallyenabled=Enabled. Assume that "burn bootloader" has been performed with this option. azduinoboard.menu.mvioopti.reallyenabled.bootloader.mviobits=01 -azduinoboard.menu.mvioopti.reallyenabled.build.mvioenable==-DMVIO_ENABLED -DASSUME_MVIO_FUSE +azduinoboard.menu.mvioopti.reallyenabled.build.mvioenable=-DMVIO_ENABLED -DASSUME_MVIO_FUSE azduinoboard.menu.mvioopti.reallydisabled=Disabled. Assume that "burn bootloader" has been performed with this option. azduinoboard.menu.mvioopti.reallydisabled.bootloader.mviobits=10 azduinoboard.menu.mvioopti.reallydisabled.build.mvioenable=-DASSUME_MVIO_FUSE From 9ed00dafa9dec40e32e28be8201c931d0f47a3dc Mon Sep 17 00:00:00 2001 From: nomakewan Date: Wed, 3 Jan 2024 13:10:38 -0800 Subject: [PATCH 2/2] Update Ref_Optiboot.md Fixes typo --- megaavr/extras/Ref_Optiboot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/megaavr/extras/Ref_Optiboot.md b/megaavr/extras/Ref_Optiboot.md index cdd5d2f7..0b255e7a 100644 --- a/megaavr/extras/Ref_Optiboot.md +++ b/megaavr/extras/Ref_Optiboot.md @@ -126,7 +126,7 @@ Notes: **Notes** 14-pin parts had to depart from our tradition of PA7 LEDs. The LED is on PD6 on 14-pin parts, and PD4 if Serial1 is the serial port the bootloader uses (because that uses pins PD6 and PD7 - mux option 0 becomes available only when the TX pin, PC0, actually exists. This is only present on 28 and 32-pin parts). (Corrected jan 3 2024). -These were chosen because they're also tthe output pins for the communication interfaces (USART, some others IIRC). Therefore, if one is using those peripherals, you've got that pin connected to something that can deal with the pin being driven by something else (in this case the AVR). Thus, it is unlikely to cause damage to the other device. On the other hand, if we used PD5/7, that's an input if the peripheral there is in use, hence it absolutely should not be used for the LED, because of the likihood that another device's output would be connected there, and they would fight until one burned out. +These were chosen because they're also the output pins for the communication interfaces (USART, some others IIRC). Therefore, if one is using those peripherals, you've got that pin connected to something that can deal with the pin being driven by something else (in this case the AVR). Thus, it is unlikely to cause damage to the other device. On the other hand, if we used PD5/7, that's an input if the peripheral there is in use, hence it absolutely should not be used for the LED, because of the likihood that another device's output would be connected there, and they would fight until one burned out. ### Serial Ports, DA/DB