S08 KBI vs General Purpose IO Port Scan

[danielhembree]

I have a project that has eight push button switches that are connected to and driving the KBI pins for user input. My code utilizes an ISR that responds to interrupts generated by the KBI. The particular device I have selected (MC9S08SE8CWL) has the KBI input pins spread across two ports. Because of this, my inputs and outputs are scattered and mixed across all available ports. If I adopt a general purpose I/O port scan method versus the KBI approach I can clean up some of the scattered architecture. The project has no timing critical tasks - simply writing output ports based on user selections, and periodically performing an A2D conversion on a potentiometer connected to one ATD pin. Is thee additional benefit to using the KBI scheme vs the port scan that I may be unaware of? I'm relatively new to all of this, so any input is welcome!

Thanks in advance,

Dan

[danielhembree]

Thanks for the input guys. I had for the most part made up my mind to go the polled route, I just needed confirmation. Can either one of you provide a bit more detail about the software debounce technique? I am currently using the PB switches to pull the port pins to an active low state. In my KBI ISR, I just added a substantial delay loop to keep from double triggering. Seemed to work well enough. The finished application will do nothing more than poll eight switches, write corresponding output bits to drive relays, and perform an ATD conversion of a pot value every time through the main loop (part of an R2R relay driven resistor ladder attenuation network - fancy audio volume control). There are no timing critical tasks to be performed.

Thanks!

Dan

[Derrick]

I like to use a timer interrupt service routine (ISR) to debounce switches.  Simply configure a timer (either a TPM channel or the RTC in the S08SE8 MCU) to generate a periodic interrupt - in this case 10ms.  You can adjust this depending upon how noisy your switches are.

The timer ISR samples the switch inputs and compares them against the previous value.  This gives you the ability to detect high-to-low and low-to-high transitions.  When a switch is low (i.e., active) for two consecutive samples the ISR sets a global system flag telling the main application code that the switch is active.  Similarly, when a switch is high (i.e., not active) for two consecutive samples the ISR clears the corresponding global flag.

Best Regards,

Derrick

[Derrick]

Daniel is correct regarding the real-time response benefit of using interrupts.  He also makes a very good point regarding polling and switch debouncing.

The primary reason for using the KBI hardware is to wake up the MCU from a low power mode of operation via an external switch closure.  A TV remote control is a good example of an application which spends most of its time in a low power mode and needs to wake-up and respond when the user presses a switch.

If your MCU does not need to wake up from a low power mode, then I would recommend the polling and switch debouncing technique which Daniel describes.

Best Regards,

Derrick

[Lundin · Accepted solution]

Generally, interrupts are just useful when the program needs to respond to something immediately, for example when used as a chip select signal. If you have to tough real time requirements, there is no apparent benefit from it.

In fact, since you use the inputs for push buttons, an interrupt pin may even be harmful. Because push buttons have an electro-mechanical signal bounce. If you connect it to a pin, you might get multiple, irrelevant interrupts that disturb the rest of the program. This would basically force you to use an external hardware filter for something this trivial. If just you poll the port instead, you can easily do the de-bouncing in software without disturbing the rest of the program. Simplest way is to read, wait 10ms, read again, logical AND the result (assuming a button push yields a logical 1).