I think the signature of the 328PB MCU will not match, so upload is not possible right away. For example, if I try to upload a sketch compiled for 328PB to a 328P equipped board, it fails.
If somebody would like to use the originalArduinoCorefor 328PB (and not interested in the additional features of PB variant), then here is an easy solution:
Download, and addpb-variant folder into to the ArduinoCore variants folder
(C:\Users\ME\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.6\variants\)
Add a custom board with the following properties boards.txt (it can be a copy of UNO)
build.mcu=atmega328pb --> signature will match (all register addresses are available for bit banging)
build.variant=pb-variant --> backward compatibility is provided
If I have a well tested sketch (with ArduinoCore) and I would need to switch to 328PB, then I would consider sticking to the original core. As it is stated in the related application note:
The code that is available for your existing ATmega328 variants will continue to work on the new ATmega328PB device.
You don't need a whole new platform, just a few adjustments stated above.
Starting a new project with 328PB is a different story, especially if it would use the new peripherials of the PB version.
If you burn the ATmega328p (not PB) bootloader into a PB, it will lie to the IDE thereafter, claiming itself just a 328p, and probably everything will work fine. This requires slight finesse while burning the bootloader, but doesn't require any other boards.txt changes or anything.
(You can do the same thing with an ATmega328 (not P), but that's less surprising since it is essentially identical to a 328P. Whereas the PB has "extra features" that can be ignored.)
Does this can be done from the IDE? Isn't the signature checked when you burn a bootloader?
I'm sure it can be done with an avrdude command using -F option.
If the ATmega328PB is intended to be programmed via USB, then a ATmega328P bootloader can hide the fact, that the chip is actually a PB variant. The original ArduinoCore can be used, additional features of PB variant will be unavailable.
Add PB variant to the IDE with the method described in #1. The original ArduinoCore can be used, additional GPIOs, Timers of the PB variant will be available on register level.
In general, no. You can modify avrdude's configuration file, but that's generally not a good idea. Best to manually burn the "fake" bootloader, correctly identifying the chip as a 328P at that time.
I need to warm this up again because of an experience I made yesterday:
I received a bunch of used, Chinese NANO's and wanted to put them through a simple test, only to find out which of them are actually dead. At this point I didn't know they were equipped with the PB chip.
I used Arduino 2.x the latest version and just flashed a Blink on them, and it worked with no compiling or upload issues. Later the day I found out that all of them were PD chips, and I was surprised that I didn't have any issues programming them with the IDE.
I then tried the same with the Arduino IDE 1.x and programming failed on them.
Of course, a big question cam up: Did Arduino add "native" support for the PD chips recently?
Someone else made a similar experience, that IDE 2.x is capable of compiling and programming code for Atmega328PB without modifications and add-ons?
The Arduino AVR board manager file installed on both IDEs (1.x and 2.x) was the same.
Normally, the bootloader lies about chip type, and a PB chip is close enough to a P chip that it doesn't matter. In fact, if your "derivative" boards simply used PB chips on a board designed for the P version (which also "works"), it may be better to go on having the IDE think that they are just P chips - one of the differences is that the PB has IO pins where the P has power pins, which is OK as long as you never configure those pins as outputs...
You may have to change the processor to "old bootloader" (or not) to upload.
Yup, my mistake. I didn't read westfw's reply as an answer to my question. It took me a second look to understand what they meant.
It seems like the PB's on Chinese boards have the standard NANO bootloader installed and don't look any different to the IDE than the P version modules. As long nobody tries to make use of the ports on the pins 3 and 6, they should just work like any NANO or UNO with the P-chip.
Hello everybody,
I've been trying to use the Atmega328PB for some time and so far it has won the battles. I received some parts from a friend and they are original, I'm using a generic Arduino Uno board as a base (I modified pins 3 and 6), but I have a lot of difficulty using them with the "minicore" the bootloader doesn't work correctly, now after so much time changing several things I will need to re-install the IDE.
I wanted to know if anyone knows or can provide a step by step guide for idiot, I want to do everything correctly this time.
Tips, tricks and prayers are welcome.
Thanks.
How did you install the bootloader once the PB chip was on the board? Or is that the part that is causing problems?
(I don't remotely consider modifying an Uno (SMD?) board and putting a 328PB on it to be an "idiot class" thing to do. Although I guess there are HW gurus that have problems with SW. Why do you want a PB variant, anyway?)
I did not know bootloaders can lie. So I checked it: yes they can.
Actually, I installed both board types, MiniCore and Pololu (I did not try Elektor) which both work pretty well, only to find out that the pins of PORT E are getting different numbers. My aim was to find out in a sketch which board definition actually was used. It seems there is no #define for board names. At the end of the day, I managed to find that the entry NUM_DIGITAL_PINS was 24 for Pololu and 27 for MiniCore. Obviously MiniCore gives access to the crystal pins located at port B.
See my results below.
[code]
/*
https://joy-it.net/files/files/Produkte/ARD-One-C-MC/ARD-One-C-MC_Manual-EN_2024-04-17.pdf
*/
#include <avr/boot.h>
#define SIGRD 5
void setup() {
Serial.begin(9600);
Serial.println("\n" __FILE__);
long sig = 0;
for (int i = 0; i < 3; i++)
((byte*)(&sig))[2 - i] = boot_signature_byte_get(2 * i);
Serial.print("\nIdentified by signature = ");
Serial.print(sig, HEX);
Serial.print(" should be ");
switch (sig) {
case 0x1E950F: Serial.println("ATmega328P"); break;
case 0x1E9516: Serial.println("ATmega328PB"); break;
}
Serial.print("result given by bootloader: ");
#if defined(__AVR_ATmega328PB__)
Serial.println("ATmega328PB");
#else
Serial.println("no ATmega328PB");
#endif
int ndp = NUM_DIGITAL_PINS;
Serial.print("\nNumber of digital pins: ");
Serial.println(ndp);
Serial.print("Board type: ");
switch (ndp) {
case 20: Serial.println("Arduino Standard"); break;
case 24: Serial.println("Pololu"); break;
case 27: Serial.println("MiniCore"); break;
default: Serial.println("no idea");
}
Serial.println("\ni\tport\tbit-nr");
char prev = ' ';
for (byte i = 0; i < ndp; i++) {
char a = pgm_read_byte(&digital_pin_to_port_PGM[i]) + '@';
byte b = pgm_read_byte(&digital_pin_to_bit_mask_PGM[i]);
byte c = log(b) / log(2);
if (a != prev) Serial.println("----------------------");
Serial.print(i);
Serial.print("\t");
Serial.print(a);
Serial.print("\t");
Serial.print(c);
Serial.println();
prev = a;
}
}
void loop() {}
/*
Pololu
------
i port mask
-------------
0 D 0
1 D 1
2 D 2
3 D 3
4 D 4
5 D 5
6 D 6
7 D 7
-------
8 B 0
9 B 1
10 B 2
11 B 3
12 B 4
13 B 5
-------
14 C 0
15 C 1
16 C 2
17 C 3
18 C 4
19 C 5
-------
20 E 2
21 E 3
22 E 0
23 E 1
Minicore
--------
i port mask
-------------
0 D 0
1 D 1
2 D 2
3 D 3
4 D 4
5 D 5
6 D 6
7 D 7
-------
8 B 0
9 B 1
10 B 2
11 B 3
12 B 4
13 B 5
-------
14 C 0
15 C 1
16 C 2
17 C 3
18 C 4
19 C 5
-------
20 B 6 = XTAL1
21 B 7 = XTAL2
22 C 6
23 E 0
24 E 1
25 E 2
26 E 3
*/
[/code]
The developer of each Arduino boards platform has the freedom to configure the behavior of the platform as they like, but there is a common convention to provide such macros. All the official Arduino boards platforms do so and I think most of the 3rd party platforms do as well.
For example, if you have the "Arduino Uno" board of the "Arduino AVR Boards" platform selected, then the macro ARDUINO_AVR_UNO will be defined:
(note the -DARDUINO_{build.board}flag in the compilation command templates)
If you have the "ATmega328" board of the "MiniCore" platform selected, then the macro ARDUINO_AVR_ATmega328 will be defined:
(note the -DARDUINO_{build.board} flag in the compilation command templates)