Group Actions
Engagement
  • Author Author: jpnbino
  • Date Created: Date Created
  • Views 716 views
  • Likes 5 likes
  • Comments 5 comments
Related
Recommended

The cost of a float in an ISR

jpnbino

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 image)

 

 

    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 (image - passed, image - not passed) :

 

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

 

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:

    image

 

    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)
High1,78 ms47 µs
Low876 µs36 µ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

  • in reply to jpnbino

    There are a few simple things that you can do to monitor the amount of time each of the interrupt functions use and how frequently they are called.

     

    The first and simplest is to use a free GPIO pin and set it upon entry and clear it upon exit.  Then using an oscilloscope you can determine the amount of processing time that is being inside the interrupt.  This approach has revealed issues like you experienced, where a huge time (relative to your expectation) is being seen inside of an interrupt call.

     

    The other approach is to have a free time (free running) and capture the time entering and leaving a section of code.  This is very similar to how profiling software works.  With this approach you need some way of showing the results, like serial communications to expose the data.

     

    Best of luck!

  • in reply to genebren

    Thank you Gene,

     

    the minimum processing and go.

    that is so true, the fundamental of ISR.

    Is there a technic that I can apply to a bigger system that allows me to keep track of them when they are all together? checking if one interrupt is starving?  If that is a paper of your trust or something, I would like to read.

  • 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 image

  • Hi

     

    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.

  • Nice troubleshooting. I believe that I too borrowed ideas from this article (being a big fan of Jack Ganssel).  Nice that you found your problem.

     

    ISR can be real tough to deal with when you are trying to minimize the amount of time spent in interrupt processing.  You really need to watch the code carefully, no function/subroutine calls, no excessive precision in math, no extra bells and whistles, just the minimum processing and go.