dc42 is correct.  The keypad library works by polling the pins so if the microcontroller is asleep then the keypad is asleep.  You can wire up some diodes and connect the pins to an external interrupt.  CrossRoads added a hardware interrupt to his keypad and if you scroll down two more posts you'll see his code to go with it.

[Snip...] its not working any more.

I can't think of anything in the code that would cause the sketch to fail like this.  Is anything happening at all, even though it may not be right? Or does it just look completely dead?  Would you mind posting pictures of your schematic and board layouts?

[when]

Hi JoeWawaw,

  I've seen people use Keypad Events for various things but the main reason it's there is to let you know when a key was activated and which state it is in.  There are four states; IDLE, PRESSED, HOLD, and RELEASED.  In the beginning the main thing I wanted know was when a user was HOLDing a key down.  As I worked through the problem of how to make that happen I came up with a way to determine all four states.  Now it more closely matches what your keyboard does with your computer.

Very quickly, the PRESSED state occurs first, right when the users presses a key.

Following PRESSED the next state can be either HOLD or RELEASED.

If the key is pressed longer than 500 milliseconds (default) you will reach the HOLD state.  However, if the key was pressed and released in less than 1/2 a second then the next state is RELEASED.

The RELEASED state occurs after a PRESSED or HOLD state and only after the user lets go of the key.

Finally, the IDLE state occurs only after the RELEASED state.  I consider IDLE to be the default state where nothing is happening.

Knowing when a key is pressed, released, or being held provides a great way to simplify some coding problems. 

Example:  You want to see just how fast you can press a key.  If you start a counter when you get the PRESSED event then you can simply stop the counter and display the results when you get the RELEASED event.

Example:  You want a single key to do more than one thing.  Detect the HOLD event and change the function of the key.  If the users HOLDs the key a second time then switch back to the original function.

If you have something in mind just let me know and I can help you simplify your code.

Actually KirAsh4, you would need the analogRead() to average hundreds of readings over that 60000 milliseconds.  Taking one reading every minute is still going to cause large swings in the tank level readings from one minute to the next.

What you want to do is create a slope-intercept function for each section of the profile (what you are calling the set point line).  It looks like you have 9 sections of the profile and so you will have 9 functions that will end up looking like:

Code:

y = mx + b
where
     m = slope = (Y2-Y1)/(X2-X1)
     x = time axis (in seconds?)
     b = y-axis intercept
     y = the set-point temperature you want to compare to

You should already have the starting (X1,Y1) and ending (X2,Y2) points for each line section.  I didn't look at the GLCD library so if you are using a different method to define each line let me know and we can change the functions.

To convert the points into a function that will let you find the set-point on the fly you should be able to do the following:

Code:

unsigned int t_seconds;  // You should NOT need more than 65,000 seconds!
float set_point;
float X1, X2, Y1, Y2;

// Do this for each of the 9 line sections.
set_point = (Y2-Y1)/(X2-X1) * (float(t_seconds) - X1) + Y1

It's late and I know this is a little terse so if you have any questions then don't hesitate to ask.

-Mark

You really only need to update the gauge once every minute.  So the simplest way to fix it is to take the average of all the sensor readings over one minute.

The keypad library works by polling the pins so if the microcontroller is asleep then the keypad is asleep.  You'll need to wire up some diodes and connect the pins to an external interrupt.  CrossRoads added a hardware interrupt to his keypad and if you scroll down two more posts you'll see his code to go with it.

You are welcome.  And the term is not retarded, it's bloody genius.  You know, like "If I've learned from all my mistakes then I must be a bloody genius by now." 

And I may have just found it.

In nextColumn() all the digitalWrite()'s are going to SHARED_PIN_1

Code:

void OpenDeck::nextColumn(int column) {
    switch (column) {
case 0: // Col. 0 goes HI on 74HC238
digitalWrite(SHARED_PIN_1, LOW);
digitalWrite(SHARED_PIN_1, LOW);
digitalWrite(SHARED_PIN_1, LOW);
break;
case 1: // Col. 1 goes HI on 74HC238
digitalWrite(SHARED_PIN_1, LOW);
digitalWrite(SHARED_PIN_1, LOW);
digitalWrite(SHARED_PIN_1, HIGH);
break;
                        .
                        .
                        .
    }
}

When it should be???

Code:

void OpenDeck::nextColumn(int column) {
    switch (column) {
case 0: // Col. 0 goes HI on 74HC238
digitalWrite(SHARED_PIN_1, LOW);
digitalWrite(SHARED_PIN_2, LOW);
digitalWrite(SHARED_PIN_3, LOW);
break;
case 1: // Col. 1 goes HI on 74HC238
digitalWrite(SHARED_PIN_1, LOW);
digitalWrite(SHARED_PIN_2, LOW);
digitalWrite(SHARED_PIN_3, HIGH);
break;
                        .
                        .
                        .
    }
}

Yes?

And it looks like I'm wrong about problem 1 also.  I'm beginning to agree with you.  So far this isn't making any sense.   

Never mind on problem 2.  I just realized you are using an array of debounceTimer which changes everything.

OK, it's getting late so here's what I've got so far:

Problem 1:
I don't think I have the right spec sheet for the 4021N but if my guess is correct then here is what I think might be happening.  I believe latchPin() sets parallel mode, waits 20nSec, and then sets serial mode.  If I'm right then I think the problem might be that every time you do that you load new data onto the parallel pins. (I expect I'm wrong on this one, but...)

Problem 2:
Imagine the loop is running at a paltry 2500 loops per second (mine runs at 45k per second). So you call readButtons(colNum) on every pass through the loop which calls latchPin() on every pass.  Now suppose that you just pressed a button...  You need to wait 10mSec before the code gets passed the BUTTON_DEBOUNCE_DELAY test.  In 10mSec your loop will run 250 more times.  So now you've exited readButtons(colNum) because you don't want to block anything else from being called. So the loop now runs 250 more times while calling readButtons(colNum) while incrementing colNum 250 more times before you ever get inside your BUTTON_DEBOUNCE_DELAY code block.

Basically you are continuing to increment through your columns hundreds, or thousands, of times before your BUTTON_DEBOUNCE_DELAY is even finished.  So unless I've completely messed up I can guarantee you that buttonNumber no longer matches the pin that was last read by digitalRead(SR_DATA_PIN).

I tried something similiar already without success. Argh, this is really frustrating, I thought reading button matrix is a lot simpler.

It is simple in principle but there are several issues that need to be dealt with.  One of the first things is the speed that I talked about.  The chip can scan the keys thousands of times per second so you soon realize that you don't want your function to return 10,000 times telling you that a key is pressed.  So then you need to change your code to only return a value when the key changes from low-to-high or high-to-low.  Once you do that then you realize that you not only need to catch a key flying by but you need to make sure your scan code doesn't block any other code like updating 100 LED's.  The next thing to worry about is what happens if more than one key is pressed at the same time.

I'm about to leave work so it'll be a little bit before I can look at it again.  Can you post the entire sketch again so I can see where you are with it?

[elapsed time]

I can't think of anyhting else at the moment except timer interrupts.

I was thinking you could use the same technique as

Code:

if ((millis() - debounceTimer[buttonNumber]) > BUTTON_DEBOUNCE_DELAY) {

that's already in your code.  It allows you to take action after an elapsed time rather than slowing your system down with time wasting delay()'s.  It's the method I use in the keypad library.

Using timer interrupts could interfere with the proper operation of the millis() and micros() functions.

I learned an operational amplifier can be used for this purpose.

It might be a lot simpler for you to start with a magnetic reed switch.  Here's a Mouser search listing with a bunch of reed switches so you can learn about them.