All of the March 9 meeting video is on the meeting archive page now.

http://spectrum.ieee.org/automaton/robotics/aerial-robots/gimball-drones-for-good-competition

Here’s an in-depth New Yorker article about Graphene for those who might wonder what the hype is about or how to make it yourself (Zhiwei Peng’s work described near the end of the article).

It is with great sadness that I pass this farewell notice along:

http://www.drdobbs.com/architecture-and-design/farewell-dr-dobbs/240169421

This Monday’s meeting will feature short (5-10 minute) talks/demos aimed at giving us ideas for future, in depth treatments as well as things to chat about during the latter portion of the meeting.  There will also be a blue sky session to explore ideas for an area parts exchange or similar mechanism(s) for helping people lay hands on needed parts and shed their surplus. Meeting details here.

The TriEmbed community is encouraged to visit the PCB Carolina 2014  web sit. The conference is all day Wednesday. You’ll see fellow TriEmbed enthusiasts there.

IEEE Spectrum has a short blurb about a very creative application of quadcopters. The videos are worth a look.

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.

I’m still looking for clues about how this happened, but with yesterday’s soldering Chip and I did there was this terrible too-fast drop in temperature that explains the “dull” appearance of some of the solder joints. There were six breakout boards maybe 3/4 to 1″ square each sitting on a 1×4″ piece of circuit board in the middle of the oven tray. I’m aware this (plain T-962) oven is notorious for not performing well on large boards or boards outside the center of the tray, etc. But this was the first case of the temp control making a huge error at a critical moment. With one other batch I saw a mistake like you see below below and to the right of the one the arrow points to. Oh well, time to finish the fume hood and turn attention to some upgrades.