Group Actions
Engagement
  • Author Author: jpnbino
  • Date Created: Date Created
  • Views 1027 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

Parents

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

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

Comment
  • 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.

Children
  • 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!