Determining which switch causes the Keboard Interrupt for the HCS08

[FC]

Hi,

How to determine the pressed key for the HCS08 KBI module under interrupt driven mode?

Here is my code:

__interrupt void isrVkeyboard(void)
{
 
  unsigned char delay = 0xFF;
  unsigned char pressed_switch;
 
  pressed_switch = PTAD;
  while(delay--);                         // debounce switch
  KBISC_KBACK = 1;               // clear KBACK flag
  timer_mode = ~timer_mode; // switch timer function mode
 
}

I am only using SW2 on the DEMO9S08QG8 board, so the variable pressed_switch is not used yet. The KBI is set at falling edge only.

Thanks

[peg]

Hi FC,

Yeah that should work, but:

If the switch is held down longer than delay and a bit it will re-enter and as you have a toggle in there end up at some indeterminate state.

This can happen even if you use edge triggered and you get "bounce" on release (only once though).

One way around this (if it is a problem) is to ACK the INT but also disable it in the ISR and then re-enable it in the background when the port is clear. But this all depends on what you are trying to acheive.

Regards David

[FC]

Basically, I am trying to use a switch to change the main program flow. 

Debouncing must be done, so see if this will work:

Within the ISR:

KBI interrupts will be disabled and a delay routine (50ms) will be called using the MTIM timer.

Within the MTIM ISR, the saved state of the KBI pin will be used to tell which switch was pressed and reenable the KBI interrupts.

What is the simplest software debounce method?   There are so many complex ways.

[bigmac]

Hello FC,

---

FC wrote:

Within the ISR:

KBI interrupts will be disabled and a delay routine (50ms) will be called using the MTIM timer.

Within the MTIM ISR, the saved state of the KBI pin will be used to tell which switch was pressed and reenable the KBI interrupts.

What is the simplest software debounce method?   There are so many complex ways.

---

A variation on your proposed method, applicable to pushbutton operation - it should be possible to read the port input status and determine which pushbutton is pressed from within the KBI ISR.  This will actually determine the switch state before any "bounce" commences, but should be valid.  The purpose of the delay is simply  to inhibit further KBI interrupts for a period of 50ms, after which bounce should have ceased.  This will give a faster response to each pushbutton press.

Regards,
Mac

[peg]

Hi all,

Mac, I believe he already intended to do it this way if you check the first post.

I have often wondered (haven't experienced it, I don't think) whether if you have a bouncy switch and use KBI when you read the state of the port in the isr it might be "bounced" at that instant and you miss it. You could immediatly re-enable ints I guess to try again.

This could be worse if you have throttled back the CPU to save power while nothing much was happening (waked up by the KBI).

Another thought for life outside the padded room!

Regards David

[bigmac]

Hello,

---

peg wrote:

I have often wondered (haven't experienced it, I don't think) whether if you have a bouncy switch and use KBI when you read the state of the port in the isr it might be "bounced" at that instant and you miss it. You could immediatly re-enable ints I guess to try again.

This could be worse if you have throttled back the CPU to save power while nothing much was happening (waked up by the KBI).

---

If the switch status is read a few microseconds after the initial closure is detected, as would be the case with a normal KBI, I would guess that the result should be valid since mechanical resonances within the switch contacts (the presumed cause of the bounce) are unlikely to act that quickly.

However, it would be a different story if the MCU needed to wake up from stop mode in response to the switch closure, with perhaps one millisecond, or more, of oscillator stabilisation delay.  In this case, a more sluggish response would be necessary, with the switch status read after debounce.

In the first case, the de-bounce delay would be non-critical, provided it is sufficiently large.  For the second case, the user will notice the delay if it is made too long.

Regards,
Mac

[rocco]

Hi, FC:

It looks to me like that idea would work fine.

---

What is the simplest software debounce method?

---

I think what you have is probably close to the simplest. The 50 milliseconds should be able to debounce almost anything.

[rocco]

Hi, FC, . . . and to add to what David said:

I would avoid putting any delay in an ISR, since it would prevent other interrupts from being serviced. As David mentioned, you could disable that bit and exit the ISR, and re-enable the switch later, using a timer.

Since you saved the state of all of the switches (PTAD) in "pressed_switch", you could bit-test them later, if you wanted. But you would have to make "pressed_switch" static, and not local to the ISR.