Implementing a non blocking delay

[mvictor]

Hi

Is there any setting which needs to be changed? The LEDs do not turn off and on during simulation (fast with updates).

Regards

[chipfryer27]

Hi

The speed of your PC can often cause confusion especially with interrupts. Running in GHz rather than the few MHz your PIC will be, things happen much faster than you expect. Hardware should be fine. Running "Fast" you will see counters increment in the thousands per second where each count of 75 equals one second in hardware...

I forgot to modify for your 10MHz crystal, now done. Note that you need to tell FC you are using a 10MHz oscillator in settings.

In the attached "On" taken a few seconds after Sw3 was activated you can see in simulation debugger that Count3 = 638 whilst the other two are 24935, and Trig3 = 1. This shows that Sw3 was detected, Count3 was indeed reset and the trigger flag set.

On.jpg (83.16 KiB) Viewed 389 times

In "Off" you can see Count3 = 1309 whilst others are now at 25606 and Trig3 now equals zero.

Off.jpg (81.6 KiB) Viewed 389 times

Note that it has kept counting whilst I was taking snapshots which helps explain the difference in On/Off times shown versus actual times.

I've modified the chart to have latching switches as this will help in simulation. Once you see the associated counter reset you can switch off again, Run the chart at 10Hz or slower and display the variables in Simulation Debugger. At 10Hz my laptop increments the counters roughly twice per second.

Again I stress that this is just to help explain the concept of using a counter(s) in a simplistic way.

[mvictor]

Hello

I saw your code and understood what you explain. Do you mean to say that I should test it on hardware to see how it actually does ? By programming into the PIC16F88 and testing it out ?

Simulation does cause confusion since my PC would be much faster.

[chipfryer27]

Hi

Downloading into the chip would be the best test as in this scenario PCs are not the greatest. If you slow the simulation speed down, you can see things progress, but that can take ages to simulate the entire chart. I found 10Hz a reasonable compromise as I could see what was occurring in Simulation Debugger. Using Fast (with updates) thousands of "counts" were taking place each second (in real time) whereas in hardware 75 counts would equal one second of time. Using Fast, those thousands of counts each second equates to many tens of seconds passing in "chip-time" so you would be unlikely to see the LEDs illuminate, especially for a duration of 333mS

Your PC is also doing a ton of other stuff in the background, whereas in hardware it's doing only what you ask.

That isn't to say Flowcode is at fault, far from it, it is just a reality of simulation. Some charts are better suited to simulation than others.

Regards

[mvictor]

Hi

Yes exactly. I do not see the LED illuminate like it should in fast mode as well as the counters increment really quick like in thousands per second (real time).

When I used blocking delay the simulation was working well but looks like in this case, testing it in hardware would be better ?

[chipfryer27]

Yep

Very much so. Although you could use "Step Into" to move through the chart a step at a time, the interrupt is still running in the background so by the time you have stepped to testing for the first Switch, the counter is already in the thousands, and although you reset a few steps later, by the time you get to check if it is at 300 (or whatever) the counter is again many tens of thousands.

It is just timer interrupts that can cause issues when simulating due to the PC running so very much faster.

Regards

[mvictor]

Hi

A small doubt….
Since the ISR is continuously running in the background it keeps incrementing the counter. So now if the switch is pressed (become high) my counter value would already be above the if statements value.

So wouldn’t that turn on the LED instantly ?

[chipfryer27]

Hi

Short answer, No....

Long answer. Although interrupt is running 24/7, it increments three counters (assigned to the switches) 75 times per second. Eventually those counters will overflow and start again at zero but we really do not care.

When in the Main loop we test for a switch being active, we branch and reset that counter, So before the switch is triggered the counter could be at any value e.g. 24732, but once we press the button and branch it is reset to zero and increments from that point on.

We also set a flag (Trig1 etc) so that later, when we reach the target delay e.g. 300 (4 seconds) it only branches if count is greater or equal to 300 AND Trig1 = 1

Regards

[mvictor]

Good day

I have implemented the logic into my board. The program works fine like it should. Although there is one small concern, when I make the respective port say A4 high, such as switch it on two times (say 1s apart), the respective output port B5 will only pulse one time after 5 seconds (I’ve set the count that way). Would be better if there is a way it could go high twice that means, as the button is pressed, 5 secs from it. Same goes for the other ports.

What would be the best way to achieve this ? Thanks for all the help until now Mr. Chipfryer, this has educated me a lot.

[chipfryer27]

Hi

That's now a totally different scenario to what you described. Also, you merely stated that the pulse is provided by a MCU but didn't specify duration, other than it is a single shot. What you are now describing is more complicated.

I'm not sure I actually understand what you want to do.

At present you press button A and after an x-second delay LED A comes on. How long does it stay illuminated for?

What happens if it is supposed to stay on for 3s, but you send a second pulse 2s after the first? The first "on" won't have completed before the second starts?

You really need to document in more detail what you are trying to do.

Possible things that may help are On / Off arrays per switch, or a circular buffer accessed every x-seconds, but until you properly document it is very difficult to advise.

Regards