Problem with digitalWrite extending interrupt count

@pratto20 I have no idea why your code behaves the way it does, but I am using several ISR's and according to the doc'n I read this is how to set them up. 

portMUX_TYPE timerMux = portMUX_INITIALIZER_UNLOCKED;

// change ICACHE_RAM_ATTR to just IRAM_ATTR ?????? WHY ????

IRAM_ATTR void Timer1_ISR() {
  portENTER_CRITICAL_ISR(&timerMux); 
  TimerKitchenOn = false; 
  portEXIT_CRITICAL_ISR(&timerMux);
}

@pratto20 My apologies, I think I am using a different kind of interrupt mechanism than you, mine are the 4 built-in hardware interrupts on an ESP32. Therefore my example code may be totally irrelevant.

@pratto20

I haven't used ISRs in the past, so this is pure speculation ...

The approved specification of the definition for your sketch would be 

attachInterrupt(digitalPinToInterrupt(flowPin), Flow, RISING); // Func Gen input

whereas you have a 0 as the first parameter.

I don't know why sei() and cli() don't work for you (that seems kind of alarming) but you may be able to control the accumulation by introducing a new bool value doCount and setting it false. In the Flow(), change the code to 

if (doCount) count++;

and then change the code in the loop() to

doCount = true;

delay(1000);

doCount=false;

This should allow Flow to increment count only when you've set doCount true.

@will @pratto20 GAH, missed that 1st argument difference. I would do that first, the second part only adds more and unnecessary code to the critical section opening up the remote chance of an ISR foobar. Also, isn't he saying the count is too low?

I was wondering if anybody knows how to get the assembler listing so I can look at the difference between count++, ++count, count = count + 1. It shouldn't be any different with a fully optimizing compiler but until you look it's impossible to say.

Also, the ISR is running in slow program memory, would it help to run it in fast ram memory as the doc'n advises?

@will  thanks for the suggestions. I did change the attach interrupt syntax. but I had already tried it both ways many times. it is my understanding that either way is the same thing.

the boolean didn't work in the ISR, nor did any other if() I tried.

the bottom line is still the same : with the digitalWrite commented out, it works and following the count value makes sense, but un-comment it and it all goes to pieces.

@zander  no, the count goes much higher from loop two on.  whether I use count++ or count = count+1, it won't work unless I comment out the digitalWrite.

@pratto20 Sorry, I am getting confused between my timer based hardware interrupts and the sofgtware interrupts. First thing you need to do is fix parametyer one, it should be as @will said, 

attachInterrupt(digitalPinToInterrupt(flowPin),........

What line number are you referring to re the digitalwrite causing a problem?

@zander  I did change it. no line number shown in the post, so ;

 flowRate = count;

   Serial.print("count4 = ");  Serial.println(count);
    digitalWrite(LowVoltageAlarm, HIGH); 

@pratto20 I find it much easier to help folks who go to prefs and set it up like (see pic), also goto Tools -> Auto Format.

Now, I do NOT understand the purpose of your sketch. You are setting count to 0 at the top of the loop and the bottom. You are printing the value of count multiple times and most of the loop is running at something like 80 million instructions per second. Perhaps some print screens of the sketch working and not working would help. AND make sure the attachInterrupt is coded correctly, it will NOT work with 0 as the first argument.

BTW, one of those pins 6 IIRC is a PWM pin, what freq is the PWM on that board, maybe change to a non PWM pin like 4.

If you preface the sketch with a statement of function like 'This sketch computes the square root of the input and prints it to Serial.' that would be a good start.

@pratto20 Ok, I think I understand what you are trying to accomplish. It looks like you want to know flow rate in x units / time interval. The problem is you have no close to accurate time interval. Either use some millis times and normalize (if you want per second but your resolution etc gives 1,003 or 1,005 then divide by 1003 and multiply by 1,000 sort of thing. The other approach is to use a hardware timer which is another kind of interrupt to fire off every second if that is your timer choice or 1 per minute etc. Now your code is totally interrupt driven and the main loop is basically doing nothing waiting for the timer to pop. When it does, grab the count and elapsed time real quick (use RAM and critical section wrappers to guarantee granularity, I posted those earlier)

The use of delay is not a good idea for this kind of application. A general rule of design is to do as little work in the ISR but instead just set the key variable that allows the outside logic to work and do the bulk of the work outside the ISR. These are very fast devices, so once per second frequencies are easy, but at some point something finer will cause a break in the ISR code so be reasonable.

@pratto20 

I'm wondering if this is because you're using two pins on port D of the NANO. Please try moving the LED from pin 6 to one of 8-13 (i.e. PORT B) and see if that makes a difference.

@will   Thank you, thank you. I used Pin 8 instead of 6, as you suggested, and that solved the problem.

no doubt you can tell I am not wise in the ways of programming, but if you would, will you give me a dumbed down version of what the problem was ?

@pratto20 

I'd be happy to explain it if I could, but as I said, I don't use interrupts.

The wild goose I was chasing is that there are several different styles of interrupts. One of them homes in on the individual pins on the different ports of the NANO. You can Google "arduino port" for more information than I can give you.

Anyway, it occurred to me that pins 2 and 6 are on the same port (PORT D to be specific) and it might be possible that the interrupt was conflicting because both pins were on the same port. Hence, changing the configuration so that they were on different ports MIGHT work. Since you needed to keep the interrupt for pin 2, it had to be the other pin that moved.

Changing it to pin 8 means that it's now on PORT B and appears to have eliminated the conflict.

I'm glad it worked for you 🙂

@will  This is embarrassing. When I tested it, I had forgotten to move the LED to Pin 8, so no LED was connected to it. As soon as I put the LED in place the LED turned on, and the problem was back.

So I set the Pin back to 6, plugged in the LED and it worked as long as the LED was set LOW, but as so as it went HIGH (and the LED lit up), the problem was back.

So it seems that the problem occurs when the board actually sends current to the LED (not just sets it HIGH), on Pin 6 or 8.