How to avoid floating point math

3 interrupts...correct, the first and third are pretty simple. The middle one though, has floating point calcs

void IncrementFlowPulse ()     //This is the function that the flow sensor interrupt on pin 2 calls to add to the count and total count
{
  //This function measures the rising and falling edge of the hall effect sensors signal
  total_pulses++ ;  //change to this variable so running tally is incremented in the background...
  Count++;
  tenth_gallon++;   //be careful here, fuel_tenth and plural exist. this is used to decrement by tenth gallon once it is high enough
  running=1;
}  

// The setup()  runs once, when the sketch starts
// the FOLLOWING loop() method runs over and over again,
// as long as the Arduino has power
//****************************************************************************************     

void Repeats(){ //interrupt timer1 repeats every second-changed to 5 seconds...

  //here is the math...we sample every 5 seconds.  9200 counts per gallon. FIXED-use float cast to convert integers to float before calculating

  Calc = ((float)Count* ((float)720.0 / (float)k_factor)); //(Counts in 5 seconds/ number counts per gallon, converted from seconds to hours
  //using a large value we can select any k-factor - use counts per gallon - perfect
  // Calc is the gallons per hour.

  if (!flag){  //reset flag so running total flag is run only once 
    flag=1;
  }      //this is used for averaging routine for average flow rate

  if (Count>0){
    stopped_flag++; //add 5 seconds to running time length 

  }
  if (stopped_flag>5){  //this is to delay the time till we stop and wait....
    //30 seconds or so...it decrements with no flow
    stopped_flag=5; //add 5 seconds to length of time running, up to 30 seconds 
    //-each unit of increase = 5 seconds of stoppage
  }

  if (Count==0){  //decrement once per 5 second with zero flow...
    stopped_flag--; 

  }
  if (stopped_flag<=0){
    stopped_flag=0;  // no longer running
  }
  else { 
    running=1;  //added this to ensure it stays running with flow
  }

  Count=0;  //reset for next interrupt

  //For some reason, when we start back up from stop, we re-enter the save routine. 
  if ((stopped_flag<=0) && (running) ){  //we were running, then stopped

    state=10;  //keeps returning to state 10, stop and save, and looping again
    return;
  }




}
//****************************************************************************************

void Toggle(){ //this is an interrupt to switch screens every few seconds

  if (state==0){
    state=1;
    return;
  }
  if (state==1){
    state=2;
    return;
  }
  if (state==2){
    state=0;
    return;
  }
}

Code tags? Makes it easier to read.

I sorta wish I had dived into the forum last week, one can learn a lot in a big hurry with such awesome quick feedback.
I just don't want to be any more hassle than one has to be, don't want to be that noob who thinks somebody needs to implant knowledge in his brain without indulging first and learning some the hard way...

ahem...what's a code tag?
Ok got it. Revised. Thanks

As long as you are trying, we'll be pleased to help.

I don't see interrupts being the issue here. You have two ISRs that you say are called every couple of seconds, so they are hardly the issue.

Then you have one which does a couple of adds. How many times a second do you expect it to be called? Let's put a metric on this.

And what data types are total_pulses, Count, tenth_gallon and running?

cornwallav8r:
ahem...what's a code tag?

OK, here's some boilerplate. Read it, though:

Read this before posting a programming question

Please edit your post, select the code, and put it between [code] ... [/code] tags.

You can do that by hitting the # button above the posting area.

Very good questions those...

I expect no more than say, 100 pulses in a second.
total_pulses-unsigned long, Count-unsigned int, tenth_gallon- unsigned int and running-boolean.

The calculating interrupt is done every 5 seconds, so I guess that can't be such an overhead issue, right?

Well out of interest, I set up a test. This code:

  total_pulses++ ;  
  Count++;
  tenth_gallon++;   
  running=1;

Takes about 2.8 uS to execute. So if you do 100 of them you have taken 280 microseconds. Add in the overhead of 100 interrupts, say 5 uS each, and that is another 500 uS. So in total 780 uS.

You have not even used up 1/1000 of the time you have in a second. Time to look elsewhere.

Besides, none of those are floating point variables. I thought you were worried about that?

No actually, it is this interrupt and its floating point math that I jumped to conclusions about...thoug I may simply have more dumb programming mistakes to fix instead.

void Repeats(){ //interrupt timer1 repeats every second-changed to 5 seconds...

  //here is the math...we sample every 5 seconds.  9200 counts per gallon. FIXED-use float cast to convert integers to float before calculating

  Calc = ((float)Count* ((float)720 / (float)k_factor)); //(Counts in 5 seconds/ number counts per gallon, converted from seconds to hours
  //using a large value we can select any k-factor - use counts per gallon - perfect
  // Calc is the gallons per hour.

  if (!flag){  //reset flag so running total flag is run only once 
    flag=true;
  }      //this is used for averaging routine for average flow rate

  if (Count>0){
    stopped_flag++; //add 5 seconds to running time length 

  }
  if (stopped_flag>5){  //this is to delay the time till we stop and wait....
    //30 seconds or so...it decrements with no flow
    stopped_flag=5; //add 5 seconds to length of time running, up to 30 seconds 
    //-each unit of increase = 5 seconds of stoppage
  }

  if (Count==0){  //decrement once per 5 second with zero flow...
    stopped_flag--; 

  }
  if (stopped_flag<=0){
    stopped_flag=0;  // no longer running
  }
  else { 
    running=true;  //added this to ensure it stays running with flow
  }

  Count=0;  //reset for next interrupt

  //For some reason, when we start back up from stop, we re-enter the save routine. 
  if ((stopped_flag<=0) && (running) ){  //we were running, then stopped

    state=10;  //keeps returning to state 10, stop and save, and looping again
    return;
  }

Alarm.timerRepeat(5,Repeats);

TimeAlarms doesn't use interrupts. So Repeats is not an ISR (Interrupt Service Routine).

Quote from http://arduino.cc/forum/index.php/topic,37693.0.html

Q: Are there any restrictions on the code in a task handler function?
A: No. The scheduler does not use interrupts so your task handling function is no different from other functions you create in your sketch.

Calc = ((float)Count* ((float)720 / (float)k_factor));

just a tip: division is much slower than multiply so this code can be written as

Calc = 720.0 * Count * inverse_k_factor;

As the first value is float the whole expression is float, no need to cast. Yes you need to calculate inverse_k_factor somewhere in advance.

Your intuition is correct. Floating point math is typically implemented via calls. When floating math is used in the isr and elsewhere in the main loop, you can get into re-entrancy -> big issues.

Sometimes 32-bit multificaton is done via calls so same issue.

You can simplify the math or to use a flag.

I don't see the relevance of this. As shown, the only interrupt which is called at all frequently (100 times a second) doesn't do floating maths.

Isn't the floating point code reentrant, in any case? I would have assumed it was, and I can't think of any good reason for it NOT to be.

I suggest you post all of your code - or attach it, if it's too big to post. Various snippets have been posted, but the only complete copy I can see is in the first post, which is formatted horribly and probably out of date.

Just a couple thoughts...
(1) I am both surprised and respectfully humbled by the effort you guys gave in getting me in line.
I will make the multiplication versus division changes...I do have the app working, against all odds.
It's been 2 and a half weeks of grunt work to get up to speed. Newbie efforts are expensive, time wise.
But I am building something I think my fellow pilots and I will greatly benefit from, and for that, it is worth it.
Christmas came early for a couple of my friends. Thanks all, who assisted, I will be back soon for more advice and abuse :wink:
You guys are the absolute best.

But I am building something I think my fellow pilots and I will greatly benefit from, and for that, it is worth it.

Can you tell a bit more (or maybe after Christmas) ?

I know this is an old post, but in the last entry from the OP, he states that he has "3 interrupts". I only see one "Interrupt" (external interrupt) and two functions that get called from the loop. Does the OP consider them to be interrupts because the program "jumps" to them?

Pete Stanaitis

cornwallav8r:
I have now 2 weeks solid in programming a new project, and as a newbie I don't mind figuring out my screwups on my own, but now I have what appears to be stack overflow issues due to the overhead of multiple timing interrupts and sensor pulse input interrupts overloading the processor....so my question is....I need to eliminate the floating point math I threw in....I can't remember the tips I read somewhere about how to avoid floating point where workarounds can be done....fractions in my case will kill the project, what is one to do...

Are you to multiply the parts by say, 100 or 1,000 before multiplying or dividing, to move the fractional part up, then afterwards divide it back down, thus preserving the initial decimal fractional part? Is there more to it?
Thanks as always...

I suspect your problem lies in misuse of interrupts (for example, executing large, complex blocks of code within the interrupt itself).

There is absolutely no reason to resort to programming witchcraft to simulate floating point when floating point itself works just fine and doesn't use much more flash memory anyway.

And, any variables used by the interrupt service code should be cast as volatile, for example [b]volatile uint8_t busy_flag;[/b]

Rather than exec lots of code in an ISR, you should simply use flags (use uint8_t for atomic access without grief).

For example, you could have a main loop something like this:

while (1) {
    if (flag1) {
        // do somthing
        // flag1 = 0; // says "event 1" is done
    }

    if (flag2) {
        // do something else
        // flag2 = 0; // says "event 2" is done
    }
}

Then all your ISR(s) need to do is set a flag for example:

ISR (INT0_vect)
{
    if (flag1 == 0) {
        // exec event #1 if it's not already being handled.
        // checking this way prevents piling up interrupts until the stack overflows.
        flag1 = 1;
    }
}

Make sense?

@krupski, I want to make myself quite clear that the following is NOT meant to discourage you from continuing to help people and I do believe your post was worth writing for the benefit of everyone else who will come to this thread.

Quote from: cornwallav8r on Nov 29, 2012, 11:19 pm

Last Online: 574 days ago

krupski:
Make sense?

I have a suspicion @cornwallav8r will not be responding.

Oops... didn't notice that. Sorry.

(I'll bet you're right!)