There are repetitive code sequences that could be put into their own functions to save space.  Especially the many places where four arguments have to be passed to draw a circle.

See how much code elimination you can do by condensing common code like that into a few functions that get called from several places.  At least that's where I'd start.

Good luck with your project,

-br

Instead of this construct, which I haven't seen before:

Code:

data = pgm_read_byte(image[x]);

…what happens if you try this:

Code:

data = pgm_read_byte(image + x);

-br

The default is 8 bits, no parity, one stop bit.

-br

Edit to correctly say "one" stop bit.

Don't try this at home, but I had good luck using 3.2 volt (and higher) blue LEDs in a V-USB rig instead of the Zeners.

-br

It needs a number, for sure.  Single-digit, probably.

Thinking in terms of root-cause analysis, the real answer is to delete the Blink example, and rename BlinkWithoutDelay to Blink.

-br

(the number in binary after NOTing is 11111011)

Thanks for the well-presented question.  In return, may I ask one?  Isn't that the bit pattern you expected?  If not, what was?

The 16-bit numbers -5 and 251 have the same bit pattern in the lower 8 bits.  Which is all that goes to the shift register right now, right?

-br

Just to point out a little social engineering: Wouldn't this be a great way to hack into a bunch of developer PC's?

"Please don't use your phone, we want your PC."

-br

One rarely connects two pins directly together; in fact, it can cause over-current problems if you short a HIGH pin to a LOW pin without any resistance in the circuit.

The sentence is just trying to say that a pin set to HIGH can source current and a pin set to LOW can sink it.  Keep it under 20 ma per pin either way and you're good.

-br

The most polite term for what I see going on is "Eternal September": http://en.wikipedia.org/wiki/Eternal_September

I honestly think the moderators should open a new "Whining" forum as a resting place for certain threads...

Cheers,

-br

Eried, I have great respect for your work.  I believe the problem you are pointing out is a real one, but I have a different view of the solution.

You know those signs at amusement park rides that say "you must be at least this tall…"?  Someone who can't get through the IDE install is just going to hit the next brick wall at a higher rate of speed if you grease the first speedbump for them.  If you've been reading around the forum lately, you'll know just what I mean.

My point being, you can't save the clueless from their cluelessness, and it's a social deadweight loss to inconvenience the competent in the attempt.

Just my two cents.

Holiday Best,

-br

 

I prefer to maintain control over what is installed in my environment.  I _really dislike_ automatic updaters.  I don't even like the IDE phoning home to check for updates.

There have been enough backwards incompatibilities introduced in the release series that this would have been disastrous for my projects, at least.

I would strongly prefer that automatic updates and an installer _not_ happen. 

One man's opinion.

-br

Move the code in loop() to setup() and it will only be executed once.

-br

Can't say exactly, but consider this: the calling function expects to find a return value on the stack after the called function returns, and it is going to use whatever is there.  You didn't put anything there, so the calling function was seeing random stack garbage.  Perhaps that garbage was different in the '9' case somehow.

When things get non-deterministic in C like this, they can go off the rails in weird ways very fast.  You are fortunate to have had a recognizable and consistent symptom, if this was in fact the bug.  Sometimes it just goes out to lunch and hangs and you are left scratching your head.

It's surprising you didn't get a warning from the compiler about the missing return statement.  It might be worth putting things back for a moment and scrutinizing the compiler output to see if it tried to help warn you.

-br

You need to keep the current drawn from the arduino IO pin under 20ma.  A couple of the items on that page require higher current and therefore would not be good candidates for a direct connection.  There is a piezo buzzer there that should work, but you can't really tell how loud that 75dB is going to sound until you try it. 

-br

This may not be the bug you're looking for, but ButtonChange should probably return something falsey when it finds no button has changed.

-br