Many Arduinos are based on the Atmega 328 P chip. Note that P. If you buy raw chips be sure the P is present. When you look up “Atmega328” at a site like Digikey the P and non-P versions are side by side and you might just go for the cheaper one without noticing the difference. You will be sucking persimmons if you’re missing the  P. I am now a relative and reluctant expert about working around missing Ps. One might say I’m P‘ing into a pot with information I wish I didn’t have. Actually, it was many months ago that I accidentally bought some P-challenged Atmega328 chips. But it was only today that I realized I was down to the bottom of the barrel and forced to replace a P with a non-P in an Arduino Uno, and that situation can best be spelled PO.

THIS CHIP BELOW IS THE Atmega328P YOU WANT:

THIS CHIP ABOVE IS THE Atmega328 CHIP YOU DO NOT WANT. Notice how you can’t read the markings? That’s an accidental hint about which is the correct part, but also indicative of the apparent conspiracy the chip makers are involved in to make sure non-machines (i.e. us) can’t read the markings in ordinary conditions. Both chips were close to flat, but the bottom one was obviously not flat (or tilted with respect to the light source) enough!!!

Postscript: Making a 328 chip run in an Uno is a total Pain. I should probably document that some place to save the next person some trouble. However once it’s done the fact that it’s the “wrong chip” is no longer visible if you’re using the bootloader to program it.

For those using Linux or something functionally equivalent for “Arduino development”, Tim Marston’s Arduino make file makes a wonderful tool. Apart from saving lots of mouse movements, using this make file in combination with the AVR tools and Arduino libraries is drastically faster. You have to see the difference to believe it could have been possible to make the Arduino IDE look so dog slow.

Anyway I wanted to share one detail to save others grief if/when they use this tool with Attiny chips. The make file passes “-D” to avrdude, and that won’t fly with chips like the Attiny84A that need a chip erase cycle if you also want avrdude to verify the bytes it’s programmed.  Here is the problematic line:

AVRDUDEFLAGS  += $(addprefix -C , $(AVRDUDECONF)) -D

My quick hack was to use one of my (Bourne/Bash shell) scripts to determine if I’m programming one particular chip vs another (by reading its signature) and then pass the appropriate switch in for avrdude. So my make file looks like this:

AVRDUDEFLAGS  += $(addprefix -C , $(AVRDUDECONF) $(CHIP_ERASE)

And then when I invoke the make command I’ll use something like this:

make blah blah CHIP_ERASE=$ERASE blah blah upload

Then my script sets ERASE to “-D” or “” depending on the chip type.

Consult your specific AVR chip’s data sheet to determine whether it can get along without a chip erase cycle (e.g. like the Atmega 328p).

Addendum: The avrdude “-e” option can be appended and it will override -D and force an erase. So if the last AVRDUDEFLAGS assignment has the $(ERASE) reference the sense can be flipped and it becomes less confusing, and you just need to feed in a “-e” for the chips like Attiny that lack page erase.

Also, I forgot I’d removed the “-V” switch from Tim’s make file and this of course suppresses verification. So if you’re reading this Tim, I can understand why you might have been scratching your head.

Finally, one might assert that  the “-e” can trivially be appended with something like this:

make -f arduino.mk blah blah AVRDUDEFLAGS=”-e”

Except this doesn’t work as documented in the make file comments. That is, if you try to do this you end up with the “-e” replacing ALL the avrdude flags: the append operations in the make file are trumped by the command line assignment. Maybe I’m missing a make flag that changes the variable assignment semantics? Don’t know, but I’ll try to return to this later and maybe develop a patch to incorporate automation features to guess a programmer to use and chip to program.