debouncing missing out on presses!

[dluu13]

[Ttelmah]

Do you possibly have them in structures?.
There is an 'insidious' problem sometimes with int1's used in structures.
Seems not to happen if you use bit fields instead. So in a structure
declaration:

[dluu13]

[temtronic]

I recall a 'quirky problem that dealt with bits (int1s) and the 'cure' seemed to be to have 8 int1 even though you only needed, say 5. I assuming this forced the compiler to use a whole byte and data was 'aligned'.
While this was probably fixed, I've always used the 'full' byte method.

Jay

[Ttelmah]

This may well relate.
Using bit fields, the bits are generated as bits in a byte. Hence the 'int8'
at the start of the declaration. If you don't use all the bits, a byte as an
entity is still allocated. Now, while you perhaps would expect the int1
declaration to do the same, if it doesn't, and the 'optimiser' tries then
to save space by using 'spare' bits elsewhere, I can easily see errors
occurring (particularly perhaps with bank switching when these are accessed).

[MassaM]

The Problem:

A code redo for array based compiles with the two warnings below with a halt on the timer0 interrupt init on actual test!

[dluu13]

Are you trying to use printf's to debug within your interrupts?

They are very slow and will mess with you. It is much better to set a flag in the ISR, and print in your main loop instead. A good rule for ISRs are to get in, set/check flags or increment counters, and then get out as soon as possible.

Also, in checkStates_Array():
You are using a int8 array to loop through store your switch states, when in fact you could store all of the values within a single int8 using the function input_b(). That will capture the value of all the pins on that port and store them in a single variable so you don't need to loop through.

Then you can do a bitwise comparison of previous and current states.

Another thing is that you are declaring previous_state[] inside the function, but you have not assigned anything to it. Therefore, previous_state's values can be just about anything by the next time you run checkStates_array(). You should either make that a global variable or static variable so its lifetime lasts beyond the function. Otherwise once the function returns, something else can use that memory area and you will get unexpected results.

[MassaM]

[MassaM]

Ok!

Sorry, stupid question follows alert:

>>> Warning 216 "main.c" Line 148(1,2): Interrupts disabled during call to prevent re-entrancy: (@READBITA)
>>> Warning 216 "main.c" Line 148(1,2): Interrupts disabled during call to prevent re-entrancy: (@WRITEBITA)

If all working smooth and nice, but have compiler warnings as above - can we ignore safely or is there a fix?

Finally, here is the final working code:

[dluu13]

The warning is just letting you know that there is some function that you have used inside your ISR that you are also using elsewhere in your program. During those function calls, the ISR has been disabled.

It looks as if it is the input() functions that probably are causing this.

[MassaM]

[dluu13]

Glad you got it working.

One thing I would try and do is to instead of looping through an array, just use a single int8 as a representation of the entire portb. You can copy that byte value to output to portd for your LEDs.

Current state and previous state variables can instead of being 8 bytes long, be only one byte long, and so on.

so instead of that loop, you can do something like:

[Ttelmah]

What you have posted doesn't debounce. Just detects the key going down:

[MassaM]

[MassaM]