Is there a way at compile time to know that it is for a Nano with old bootloader? (Kinda SOLVED via extra line to boards.txt)

#EDIT 2021-08-10#
I have inserted a line into my .arduino15/packages/arduino/hardware/avr/1.8.3/boards.txt file
After nano.menu.cpu.atmega328old.build.mcu=atmega328p , I inserted

nano.menu.cpu.atmega328old.build.extra_flags=-DNANO_OLD_BOOTLOADER

(Similar lines can be used for other differentiation). So now I can use

 #ifdef NANO_OLD_BOOTLOADER
  #define BAUDRATE 38400 // old boot loader? works ok
 #else
  #define BAUDRATE 115200 // ESP8266 default of 74880 not supported on Linux
 #endif

#/Edit#
I have two types of Nano clones, some with the old bootloader and some with the new.
I would like to compile different code depending on which bootloader is involved.
The specific problem I have is that the 'new' ones are happy communicating at 115200 to Serial Monitor, but the 'old' ones drop characters at 115200 & 57600; they only seem reliable at 38400 or below.
So anyway, I would like to select a lower baud rate for my 'old' ones

  • I realise that it may not be the actual bootloader, but some other hardware quirk/shortcut, so perhaps 'just update the bootloader' may not fix things.

I assume it is not possible, no.
Like you said, this is not something that has to do with the bootloader. Is the code the same, that runs on both arduino nanos?

I also use an arduino nano with the old bootloader and I can transmit at 115200baud without problems.

2 Likes

There may be some way to detect which bootloader is present ar runtime and alter the baud rate at that point. Either way, you will then have to manually change baud rate in the serial monitor.

1 Like

I agree. If you updated the bootloader on those Nano for some other reason, probably they would still not work at 115200, so checking the bootloader version would no longer be the right criteria. Plus, if you buy more Nano with old bootloader, they probably will work at 115200. All mine do.

You could mark those Nano that won't work at 115200 in some way like a label or spot of paint. When you use them, you could short an unused pin to ground. Your setup() function could read that pin and choose a lower baud rate. You could even "mark" those Nano by semi-permanently using a short length of insulated wire, with a bright colour, soldered from a rarely used pin to ground.

2 Likes

You could look at Gammon's board detector sketch which is quite well documented. Maybe you can find a way to detect if the boards are good for higher baud rates or not

@Danois90, i'm not sure that Nick's board detector sketch would work here. Unless I missed something, it requires a 2nd board to interrogate the 1st board and can read out the processor specifics (device signature, fuses etc).

I'd go with the suggestion by @PaulRB to use a spare pin as a signal to tell the difference between the 2 boards.

If you know which bootloaders are installed, you could look at their source and see if they place any identifying information in internal RAM before they pass control to the sketch. However, that would probably require additional effort to avoid that area of RAM being zeroed out as part of the code startup sequence.

1 Like

It used to be possible to modify the command line for different boards and add arguments. If you could add something like -DOLDBOOTL to the command for Nano with old bootloader, then you could use conditional compiling:

#ifdef OLDBOOTL
Serial.begin(9600);
#else
Serial.begin(115200);
#endif
1 Like

Thank you for that idea. It led me to look at boards.txt, and adding a line to it does
just that.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.