Wasn't paying 100 percent attention when I made a Mouser purchase recently and bought the ATMega328 chip instead of the 328p for use in a breadboard Arduino. Subsequently, I've reviewed the data sheet and I can't find any differences between the two chips (proving once again, I was a liberal arts major, not an engineering major).
I was able to hack into avrdude.conf and boards.txt to be able to burn a bootloader onto this chip, but now am having difficulties getting the vanilla BareMinimum sketch to upload ("protocol error, expect=0x14, resp=0x51").
Since this is a virgin breadboard project, there are many potential places where the problem may lie, so I ask this question to get a nagging one off my mind: should the 328 (no p) work the same as the 328p if the bootloader was installed?
Yes the 328 works just fine once it's burned with the 328p bootloader (the p suffix is for picoPower, works at lower voltages) I have several 328s from Mouser that I'm using right now.
i think they have a different signature...
the signature of the atmega328p is hardcoded into the bootloader, so you have to hack and recompile the bootloader to let it recognize the new ic (the 328 non "p").
BrainBooster:
i think they have a different signature...
the signature of the atmega328p is hardcoded into the bootloader, so you have to hack and recompile the bootloader to let it recognize the new ic (the 328 non "p").
I don't think that is quite correct. There are signature bytes differences between the 328 and 328p, but they are 'hardcoded' in the silicon of the chip not the bootloader. And it's the AVRDUDE, the uploading program that reads the signature and will error out if it mismatches the signature stated in the boards.txt for the selected board type. Just creating a 'new' board type in the boards.txt file and edit the signature value should be all that is required to get a 328 non p chip going I think.
and the SIG3 signature is different for the non "P", it is 0X14
Again my understanding is that the 'root' source of the signature bytes is from the chip itself, and they are read-only.
From the datasheet:
Signature Bytes
All Atmel microcontrollers have a three-byte signature code which identifies the device. This
code can be read in both serial and parallel mode, also when the device is locked. The three
bytes reside in a separate address space. For the ATmega48P/88P/168P/328P the signature
bytes are given in Table 25-10.
...and this is correct.
but they should match with the atmega boot code, and since the signature is different, there is the need to add a section for the atmega328 (non p) whith the correct signature for that kind of ic, the way he can introduce himself the correct way during the bootloading process , isn't it?
otherwise why signature bytes are defined in the bootloader source code?
There is no need to change anything in the bootloader, you can literally just force the 328p binary onto the 328 (essentially ignoring the signature check) and it will just work.
I used optiLoader instead of AVRDude to do this, but the net result is the same.
yes, but what if you want to do it in the arduino ide?
is there a way to pass the "-F" argument to avrdude? ....maybe upload.options= -F in the configurarion file
BrainBooster:
can you quickly summarize the procedure you used?
i never played with optiloader
download optiLoader
find the definition for 328p and change the 0x0F to 0x14
use the Arduino IDE to upload the sketch to your board
use your board to program your bare chip as per optiLoader instructions
retrolefty:
But if you just wants to use the standard arduino IDE to upload, how does he specify the -F option?
You add the 328 to your boards.txt, or modify your 328P entry to have the signature of the 328
why modify when you can add?
i mean, if you modify that way the files then you wil not be able to deal with the 328p without changing again the files.
It's not simpler to add a proper section for that ic and make just the family wider?
BrainBooster:
i think they have a different signature...
the signature of the atmega328p is hardcoded into the bootloader, so you have to hack and recompile the bootloader to let it recognize the new ic (the 328 non "p").
I don't think that is quite correct. There are signature bytes differences between the 328 and 328p, but they are 'hardcoded' in the silicon of the chip not the bootloader.
I believe both the above conflicting statements are true, but in different contexts.
When using a boot loader, the signature bytes are indeed hardcoded based on the mcu define at compile time. The boot loader could have opted to fetch this from the AtMega signature row at run time, but choose not to (I assume less code/space/complexity is the reason).
When we upload through the likes of AVRISP however (such as when we burn the boot loader), avrdude will read the signature row directly from the chip itself and so there is a mismatch if the “non p” version is expected.
It’s probably not a good idea to create a new board for the “non p” version because the Arduiono core does not make provision for this chip. The problem then is that all the #ifdefs in the source that enable Atmega328 features will fail and so sketches will not compile. A more workable option may be to use the “-F” flag with avrdude when uploading the boot loader to the “non p” version. This would then be a one time requirement and thereafter the chip will identify itself through the boot loader as an AtMega328-P.
It’s probably not a good idea to create a new board for the “non p” version because the Arduiono core does not make provision for this chip. The problem then is that all the #ifdefs in the source that enable Atmega328 features will fail and so sketches will not compile. A more workable option may be to use the “-F” flag with avrdude when uploading the boot loader to the “non p” version. This would then be a one time requirement and thereafter the chip will identify itself through the boot loader as an AtMega328-P.
Thanks, that makes sense, on a somewhat confusing matter. However, I think I will just avoid buying 328 non-p chips.
I think I will just avoid buying 328 non-p chips. smiley-grin
The long way:
if you want to add a permanent support in the arduino ide for the "non P" , you have to modify the ATmegaBOOT_168.c , ardude.conf the makefile and add a new antry in the boards.txt, the way it reflect the actual clock and fuse configuration of the new ic.
then you'll be able to use the non p version of the ic in the arduino ide.
