freddie43:
Sadly, unlike my genuine Arduinos, all my clone Nano, Uno and Mega boards seem to have the same onboard refs, so there is no s/w way to identify them and treat them correctly and change the way the IDE handles them.
The solution is to just burn whichever bootloader you want to them. Then there is no need to do any identification. I prefer to use the Uno's configuration, since this frees up 1.5 kB of flash memory:
- Connect an ISP programmer to the nano. If you don't own an ISP programmer, you can use an Arduino board as an "Arduino as ISP".
- Tools > Board > Arduino/Genuino Uno
- Tools > Programmer > select the appropriate programmer
- Tools > Burn Bootloader
After doing this, you should use your Nano as an Uno.
freddie43:
But the real problem is as Robin2 says in my other thread: Arduino developers seem to have very little interest in backwards compatibility.
It is true they could have changed the bootloader and fixed the watchdog bug of the old one without breaking compatibility. The only downside compared to what they did do is needing to stay with the slower upload speed of the old bootloader. Or they could have broken compatibility, but changed the boot section to 0.5 kB instead of the unnecessary 2 kB they are using now. So we ended up with the worst of each option: Breakage, without reaping the most important potential benefit of the change. It would be interesting to know the story of how that came about. I suspect this one was not a decision made by the developers, but someone in management or manufacturing. I pointed out the issue immediately after the change was made to Arduino AVR Boards but by that time they had already made a bunch of Nanos with the new configuration so fixing it would have required either doing the right thing and recalling all the misconfigured Nanos from their distributors or else doing the hacky thing and adding yet another Nano configuration option. Instead, they decided to stick with the mistake and continue to produce Nanos with the suboptimal new configuration.