Updating bootloader on Nano clones - A6 and A7

I have two Nano clones on the way from Banggood. I bought one there last year which I have since given away, but it was recognized by v1.8.8 as a Nano with 328P with "old bootloader", and I assume the new ones will be the same.

A couple months ago I asked about updating the bootloader to Optiboot, and came away with the conclusion that identifying the Nano as a Nano for this purpose wasn't the best idea because the definition of a Nano in the IDE still has the bootloader occupying the old size in flash. The better option was simply to identify it as an Uno, which would install Optiboot in the correct amount of flash.

I just want to make sure that I got that right, and that nothing has changed. But I also want to be sure that if I ever decide to make use of A6 and A7 on these boards, which don't exist on an Uno, the IDE will not balk. It seems to me it ought to balk at that.

A related question: do the pro mini and pro micro all come with Optiboot? i don't see any "old bootloader" option for them in the IDE.

Thanks

If you have a programmer, you can upload the Uno bootloader to any 328P chip.

Change this in bootloader.txt

uno.build.variant=standard

to

uno.build.variant=eightanaloginputs

and then re-bootload the chip.

Did you mean "boards.txt" instead of "bootloader.txt"?

And thanks for the information. I usually change any 328P chip using 5V to the Uno bootloader.

Yes, boards.txt. Bootloader on the brain.

CrossRoads:
If you have a programmer, you can upload the Uno bootloader to any 328P chip.

Change this in bootloader.txt

uno.build.variant=standard

to

uno.build.variant=eightanaloginputs

and then re-bootload the chip.

I don't have a bootloader, but was planning to use Nano A as an ISP to flash the new bootloader to Nano B, and then do the same thing with the functions reversed.

If I change the variant definition for the Uno, will the IDE then assume that a real Uno has 8 analog inputs?

To further complicate this, or possibly eliminate the issue, it occurred to me after the original post that I could test this, kinda. So I made a copy of the Examples file AnalogInput with A0 changed to A7, and I changed the board selection to Uno, but didn't connect anything. Then I did a test compile, and it compiled fine. No errors, no warnings. But I don't know if it would actually flash. That's with the Uno variant still set to standard. But of course, if the IDE doesn't care about this, then what is the variant definition used for?

ShermanP:
I just want to make sure that I got that right, and that nothing has changed.

You got it right. Nothing has changed.

ShermanP:
I also want to be sure that if I ever decide to make use of A6 and A7 on these boards, which don't exist on an Uno, the IDE will not balk. It seems to me it ought to balk at that.

No. The IDE will not balk. You will be able to use A6 and A7 with the Uno board definition no problem.

ShermanP:
do the pro mini and pro micro all come with Optiboot? i don't see any "old bootloader" option for them in the IDE.

The Pro Mini uses the same outdated "ATmegaBOOT" as the "old bootloader" Nano. There is no "old bootloader" option in the IDE because that is the only option. If you have the "(5V, 16 MHz) w/ ATmega328P" Pro Mini, you can burn the Uno bootloader to it and use it as an Uno, just like the ATmega328P Nano.

The Pro Micro uses a completely different "Caterina" bootloader. This is because the Pro Micro's ATmega32U4 microcontroller has native USB and thus the bootloader works quite differently. You could put a version of Optiboot compiled for ATmega32U4 on the Pro Micro, but then you'd need a separate USB to TTL serial adapter chip to handle the USB conversion so it wouldn't make much sense to do that.

Regarding the "eightanaloginputs" variant used by the Nano vs. the "regular" variant used by the Uno, here is what the code in the eightanaloginputs variant file looks like:

#include "../standard/pins_arduino.h"
#undef NUM_ANALOG_INPUTS
#define NUM_ANALOG_INPUTS           8

So you can see that it's identical to the standard variant with only one difference. The value of the NUM_ANALOG_INPUTS macro is 8 instead of 6. That only matters if you are working with code that uses NUM_ANALOG_INPUTS. None of the Arduino core library code uses this macro. I have found that it is very rarely used in other code. The most significant place I have seen it used is in the Firmata library.

ShermanP:
If I change the variant definition for the Uno, will the IDE then assume that a real Uno has 8 analog inputs?

The NUM_ANALOG_INPUTS macro value will then be set to 8 whenever you have Tools > Board > Arduino/Genuino Uno selected, whether it's a Nano or an Uno plugged into your computer.

Ok, I think I understand. If it doesn't affect A6/A7, I will probably leave the Uno variant at standard.

But it's curious that in v1.8.8 there is a selection for what you might call a "new" Nano, one with Optiboot, that is defined in boards.txt as:

nano.menu.cpu.atmega328=ATmega328P

nano.menu.cpu.atmega328.upload.maximum_size=30720
nano.menu.cpu.atmega328.upload.maximum_data_size=2048
nano.menu.cpu.atmega328.upload.speed=115200

nano.menu.cpu.atmega328.bootloader.low_fuses=0xFF
nano.menu.cpu.atmega328.bootloader.high_fuses=0xDA
nano.menu.cpu.atmega328.bootloader.extended_fuses=0xFD
nano.menu.cpu.atmega328.bootloader.file=optiboot/optiboot_atmega328.hex

It looks like they went to the trouble of defining it with Optiboot, and changed the baud rate to 115200, but didn't change the old flash size of 30720 to 32256, or change the high fuses from 0xDA (2K bootloader) to 0xDE (512 byte bootloader). Was there a reason for this? Was there ever a Nano with a 2K Optiboot? Is there any chance this definition will be fixed in a future IDE version so we can just call it a new Nano instead of an Uno when we convert an "old bootloader" Nano to Optiboot? Would fixing the definition break anything?

ShermanP:
It looks like they went to the trouble of defining it with Optiboot, and changed the baud rate to 115200, but didn't change the old flash size of 30720 to 32256, or change the high fuses from 0xDA (2K bootloader) to 0xDE (512 byte bootloader).

That's correct. All the official Arduino Nanos made since 2018 use the Optiboot bootloader and have that fuse configuration. Older Nanos and unofficial derivatives still use the ATmegaBOOT bootloader.

ShermanP:
Was there a reason for this?

I believe it was just forgotten.

ShermanP:
Is there any chance this definition will be fixed in a future IDE version so we can just call it a new Nano instead of an Uno when we convert an "old bootloader" Nano to Optiboot?

I don't foresee that happening. I reported the issue to Arduino immediately after they changed the board definition but I believe by that time a bunch of boards had already been manufactured with those fuse settings so they decided it was too late to do anything. The time to fix it would have been then.

ShermanP:
Would fixing the definition break anything?

I believe that it would not be a good thing to use a board definition configured for a 0.5 kB boot section with an official Nano that has its fuses set to a 2 kB boot section. If user code ends up in the boot section that could "brick" the board (actually you would just need to burn the bootloader to fix it but that would be a very bad experience for a beginner).

Ok, so changing it now would break all the official Nanos. Can't do that.

So the only way to fix this would be to add a third Nano processor entry called something like "Atmega328P (512 Optiboot)". I suspect that's not going to happen. So at this point I have a choice between making it look like an official Nano with Optiboot, but with the 2K fuse, or making it look lke an Uno. Looks like I need to make up a couple "UNO" sitckers.