I have two Nano clones, and I just wondered if it might make sense to replace the "old bootloader" with the default bootloader. I know I won't get any additional flash memory doing this, but might there be other benefits?
Faster upload is what I can think of.
You can also burn the Uno bootloader.
You do get more space for your program. I do this with all my classic Nanos and mark them so I know to treat these as Unos in the Arduino IDE. There is a long history to this (as to why the Nano diverged from the Uno) and I think that you gain 1.5kB by upgrading to Optiboot, the current standard on the Uno. @westfw can surely say something here.
The ‘default’ bootloader for the Nano is the same optiboot bootloader that is used for the UNO, but 2K bytes of flash memory is allocated despite the fact that the bootloader fits in 512 bytes. By selecting UNO when burning the bootloader, you get the additional flash memory for use by your code.
The older bootloader does have problems if you use the watchdog timer, if I recall correctly.
Thanks for the replies. I guess the problem I have with flashing them as Unos is that I post my projects here and on Github, and don't want someone who wants to use my sketches to have to burn a new bootloader to his Nano to make it work. So for a large sketch, I think in practice I would always stay within the limit caused by the 2K bootloader anyway. So if I do reflash them, I think it would only be to the default Nano bootloader.
Flashing the Nano default bootloader would not be something they would have to do. They could just use the old bootloader if that's what came installed on their clones. That's unless the default bootloader actually changes things beyond being faster booting or more reliable.
By the way, is there a reason why the suppliers from the Far East continue to install the old botloader in their Nano clones? Is the newer one not open source?
Why would flashing them as Unos cause any problems with projects posted here unless it used huge amounts flash memory ?
That would be the only reason. I'm just saying if I did write a very large sketch, I wouldn't want to accidentally go into that extra 1.5K. So that being the case, there's no reason to make it an Uno.
That is correct:
I think there could be two different factors:
Inertia: a manufacturer set up everything for manufacturing the board prior to the change, and since that initial setup serves to produce a product that continues to sell, they don't have any reason make the effort to change it.
Cloning: I don't have a full understanding of how the manufacture of these products works, but I get the impression that several different manufacturers produce them independently. It seems that what happens is the manufacturers clone each other's designs. In this case, it means that the later generations of manufacturers are just provisioning the boards from a binary they dumped from a board from the earlier generation manufacturer. These later generation manufacturers don't give any consideration to the full lineage of their clone, and thus don't bother to check to see if there have been any developments in the original product.
It is likely that this is just one of many widgets to the manufacturers. They don't have any special interest in Arduino, nor make any effort to follow the developments. So it is entirely possible that they aren't even aware of the fact that the bootloader on the official boards was changed eight years ago.
I get the impression that there is a significant separation between the manufacturers and end sellers (who aren't necessarily procuring their stock directly from the manufacturer). Even though the sellers probably also see the board only as a widget, they are more likely to become aware of the situation due to receiving customer service requests and negative feedback about the failing uploads. However, they don't necessarily have the ability to effect a change in the manufacturer's process.
It is the open source Optiboot bootloader. The revision of the source code from which the binary on the official boards was built is hosted here:
And the upstream project (which has seen significant further development since the revision used by Arduino) here:
The manufacturers wouldn't even need to build the binary from source or obtain an official board to dump it from because it is distributed as part of the "Arduino AVR Boards" platform:
https://github.com/arduino/ArduinoCore-avr/blob/master/bootloaders/optiboot/optiboot_atmega328.hex
I didn't realize the Pro Mini also uses the Nano "old bootloader".
Does this one support writing to flash in runtime?
The version of Optiboot used by Arduino does not have that feature. The feature was added in a later revision of Optiboot.
So you will not have that capability out of the box from an official board. Likewise, you won't gain that capability if you perform a "Burn Bootloader" operation while the "Arduino Nano" or "Arduino Uno" board definitions are selected in Arduino IDE.
If you want to get that capability via a "Burn Bootloader" operation, I think the easiest way is to install the MiniCore boards platform. The latest versions of MiniCore don't actually use Optiboot. That isn't a problem from the perspective of wanting a flash write capability, because the urboot now used by MiniCore also has that capability:
https://github.com/MCUdude/MiniCore#write-to-own-flash
If you do want the latest version of Optiboot, I think MiniCore is still the best option. However, in this case you must make sure to install version 2.2.2 of MiniCore via Boards Manager. This is the last version from before the switch was made from Optiboot to urboot.
Slightly off topic, but maybe as an additional note from practical experience:
I can only speak from my own experience with an Uno clone: the key difference between the original bootloader and Optiboot is quite significant.
With the original bootloader, I ran into limitations when trying to use the internal timer as a watchdog. After switching to Optiboot, it became possible to reliably use the onboard watchdog for triggering a software reset.
From my perspective, having a functional watchdog that can safely reset the system is not just a nice feature but a fundamental requirement for long-term stability and robustness. Especially in unattended or critical applications, this makes a real difference.
Ok, if I'm following this correctly, I do need to upgrade the Nano old bootloader at least to the new Nano bootloader if not all the way to making it an Uno. I don't think I've ever used the watchdog, but I might at some point.
If you are using the watchdog reset, the new bootloader is definitely essential. Any of the options we discussed here will serve as a fix for the reset loop bug that is present in the old "ATmegaBOOT" bootloader.
There's no official "new" bootloader for the Pro Mini, particularly the 8MHz version. Is there an Optiboot 8MHz bootloader somewhere in v1.8.19?
No. You can get it by using MiniCore.
8 MHz ATmega328P targets are supported by several other 3rd party platforms as well, but AFAIK they all use an older version of Optiboot that doesn't have the flash write feature. One of these is the boards platform that is part of the Optiboot project itself:
Having been responsible for most of the "significant further development" of Optiboot, I think I should say that while I'm a bit disappointed that Arduino has never updated the version they use, MOST of the changes that have been made have had more to do with supporting additional chips and improving the build procedures.
There are two relatively significant changes that might be of interest to normal Uno/Nano users:
- Ability for the application to write to flash (via the bootloader.)
- Passing the "original" "reset cause" to the application (permits the app to determin whether it was started from a powerup, reset, or watchdog...)
It’s almost 5AM but I’ve been up almost a half hour, it took me a while to remember the Boards Manager part of the IDE… oh yeah, that!
So the Boards Manager is how we can set bootloaders. Bueno.
To be clear, Boards Manager is the tool used to install Arduino boards platform. Platforms add support to Arduino IDE for for sets of board targets.
Once a platform has been installed via Boards Manager, you can select boards supported by that platform via Arduino IDE's Tools > Board menu. Doing that configures the behavior of Arduino IDE when you perform a "Burn Bootloader" operation.
Some board definitions (including those from MiniCore) also define "custom board options" menus that allow the user to adjust specific aspects of how Arduino IDE is configured when that board is selected. You will find these menus under Arduino IDE's Tools menu after selecting the board from the Tools > Board menu. The selections you made from the custom board option menus can affect the behavior of the "Burn Bootloader" operation.
Are those changes present in the Optiboot version used by Arduino. or only in later versions requiring Minicore?
Edit: Also, are there any example sketches that demonstrate writing to flash using the bootloader?