lesson 3 - delay on reading button press

[mtbf0]

That sounds like an eminently reasonable design, but simply suggesting that people "use interrupts" doesn't make it clear how they need to adjust their sketches to use them effectively. Maybe you could publish some tutorials on the Arduino playground site to show people how to use interrupts this way?

all three of the timers on the arduino's mega168 are used for pwm generation, and the timer0 overflow interrupt is used to count milliseconds, but you can enable the overflow interrupt on one of the other timers and add write your own interrupt handler.

to use the timer2 overflow interrupt you need to add the following to your init() routine...

Code: Select all

TIMSK = (1 << TOIE2);      // enable timer 2 overflow interrupt


and then you'll have to write an interrupt handler. variables used within the interrupt handler should be declared with the attribute volatile so that the compiler does not optimize away references to it.

Code: Select all

volatile int variable_I_use_in_my_interrupt_handler;

ISR (TIMER2_OVF_vect) {
//
// your code goes here
//
}


timer2 is an 8 bit timer setup with a prescaler of 64 and will therefore overflow 16000000 / 256 / 64 times a second. that's 976.5625 for those of you without a calculator handy.

[darus67]

put another way "...you'll regret it. Maybe not today. Maybe not tomorrow. But, shoon, and for the resht of your life."

I wonder what percentage of people recognize that quote.

[darus67]

Edited to addMy bad - it was darus67 who suggested people use interrupts

Guilty as charged.

I made no claim of being an expert on the subject. In fact, I've learned a thing or two from the follow up posts.

[Salvatore]

[...]

Code: Select all

[...]
  if (lightMode == 0) {
[...]
  else if (lightMode == 1) {
[...]
  else if (lightMode == 2) {
[...]

// etc, etc...


Nice, but have you seen the switch()-statement?

http://www.arduino.cc/en/Reference/SwitchCase

[TomP]

Nice, but have you seen the switch()-statement?

Of course. Why do you think it would have been be an improvement here? I thought the code, as I wrote it, was easier to read than it would have been if I had used switch/case, which would have required adding a 'break' statement to each block. It's a matter of taste, I guess.

[caitsith2]

There are times where you do have the advantage of code reuse in switch/case statements, that, is some of your cases purposely fall into another case statement before breaking.

Code: Select all

// If/elseif/elseif/endif

if(Condition 1)
{
   [code for condition 1]
}
else if (Condition 2)
{
  [code for condition 2]
}
else if  (Condition 3) //Also uses code for Condition 2 after the code for condition 3
{
  [code for Condition 3]
  [Code for Condition 2]
}
else
{
  [Code for condition 4]
}

//Now for a switch/case equiv.

Switch(variable)
{
case 1:
  [code for condition 1]
  break;
case 3:
  [code for condition 3]
  //Fall through to condition 2
case 2:
  [Code for condition 2]
  break;
default:
  [code for everything else.]
}


Im sure there are some light patterns that may be possible to optimize with switch/case over if/elseif/elseif/endif.

[nicpottier]

There are times where you do have the advantage of code reuse in switch/case statements, that, is some of your cases purposely fall into another case statement before breaking.

Although this is true, it's more the exception than the rule. Most coders eventually find that switch statements are more burdens than good tools in the end except in rare cases. They are just too prone to bugs due to missing breaks and their global scoping within the switch often ends up being awkward.

Of course that opinion just comes form a dozen years of coding computers not micro controllers, I don't know if there are possibly performance (or code size) reasons which make switch statements more advantageous on the more limited devices.

-Nic