The cost of a float in an ISR

2 May 2020

Goal

Share a time problem when I uncarefully used an unintended float within my ISR.

Description

Searching about debouncing switch routines, I came across this solution while revising a blog I already knew written by Jack Ganssle ( the article ). The technique for me seemed fine to me and then I applied it to a small project I'm doing. I tested the code logically, but not by execution time and that is what showed up later when I had a flickering led instead of a controlled brightness by software. ( note: due to aliasing effect it is not flickering as my eyes see )

It happened, that I came across this problem when I finished implementing a software PWM to control a LED. Additionally, the problem was not visible when the button was pressed (Low level, and you will know why). So, I had to investigate, and here is what I did ( - passed, - not passed) :

Isolated the PWM code;
Put all other components except my button routine.
Put the button module together.
Commented out ISR debounce code

Bang! Found where! Taking a closer look I was curious about why this else if was jumping to function that converts an integer to float. Specifically, the problem was here:

    else if (integrator < MAXIMUM)
    {
        integrator++;
    }

when I ran the debug, the code jumped into here:

Then, I realized the definition of the macro MAXIMUM was a float (due to #define DEBOUNCE_TIME be a float) which led the integrator to be converted to a float in order to perform that else if() :

#define DEBOUNCE_TIME 0.3
#define SAMPLE_FREQUENCY 10
#define MAXIMUM (DEBOUNCE_TIME * SAMPLE_FREQUENCY)

And that took me some time to realize it because in my head it was so simple, 10 times 0.3 is 3 (and easy integer ). Casting the MAXIMUM to uint8_t would solve the problem, but I wanted to know how much this float in the ISR was costing me and therefore I wanted to measure it.

The cost

Running the simulator within MplabX and using the StopWatch feature to measure from the entring point until the exit point of the debounce ISR, I had:

For Button State(Input)	Time (with float)	Time (cast to uint8_t)
High	1,78 ms	47 µs
Low	876 µs	36 µs

The Setup

And here is the setup I was using while coding:

- Compiler xc8 v2.10 (FREE)
- Optimization - 0 (None)
- PIC12F1840 microcontroller

Be always back to the basics!

via GIPHY

Top Comments

Parents

shabaz over 5 years ago

Hi jpnbino

Nice reminder about keeping an eye on code execution time : ) There was a time the free PIC compiler was deliberately crippled, i.e. would not do certain optimizations, so maybe that made the problem worse in this case too : ( I don't know if it's still the case or not with the compiler.
One trick (not really a trick) is to send a message or signal to non-interrupt code, i.e. push out the code to outside the interrupt. The easiest way to send this signal is to use a global variable. So, the interrupt sets the variable, and the main code repeatedly checks to see if the variable is set, and does what it needs to do, and clears the variable. It still doesn't help if overall execution time doesn't meet requirements of course, but means the interrupt continues to do all other servicing it needs to.
Regarding debounce, sometimes the more advanced algorithms are not needed. I just take immediate action when a button is pressed, and then inhibit button presses for a period of time (like say 20 msec - could be extended it it's unreliable with a switch) and then won't clear the button until 20msec after I see a button release. To do all that requires a variable to store button state (and a timer, it doesn't need to be dedicated it can be shared with other timed events in the code). That allows for debounce periods of 20msec on button push and button release. Also, this way an input is actioned slightly faster, rather than wait for an integration time.
For rotary mechanical controls : ) there's another trick, which is to avoid the problem totally : ) Optical encoders don't have such electrical bounce, and is far easier to manage. A lot more expensive though : ( but sometimes worth it.
- Cancel
- Vote Up +2 Vote Down
- Sign in to reply
- More
- Cancel
jpnbino over 5 years ago in reply to shabaz
Thanks for your contribution,
```
One trick (not really a trick) is to send a message or signal to non-interrupt code...
```
That's is true... that is the approach I use to put a char on a buffer whenever it comes and then treat it outside the ISR.

To do all that requires a variable to store button state (and a timer, it doesn't need to be dedicated it can be shared with other timed events in the code).
That is interesting and simple, I like it. As I usually have timed events in some projects I created a module that can give updates of 1ms in time, kinda Systick ( borrowed from here ), then your implementation is pretty easy to be integrated. I will check it and let you know.

hum....
could be extended it it's unreliable with a switch
I will check my switch under the scope
- Cancel
- Vote Up +1 Vote Down
- Sign in to reply
- More
- Cancel

Comment

jpnbino over 5 years ago in reply to shabaz
Thanks for your contribution,
```
One trick (not really a trick) is to send a message or signal to non-interrupt code...
```
That's is true... that is the approach I use to put a char on a buffer whenever it comes and then treat it outside the ISR.

To do all that requires a variable to store button state (and a timer, it doesn't need to be dedicated it can be shared with other timed events in the code).
That is interesting and simple, I like it. As I usually have timed events in some projects I created a module that can give updates of 1ms in time, kinda Systick ( borrowed from here ), then your implementation is pretty easy to be integrated. I will check it and let you know.

hum....
could be extended it it's unreliable with a switch
I will check my switch under the scope
- Cancel
- Vote Up +1 Vote Down
- Sign in to reply
- More
- Cancel

Children

No Data