Bugs or not?

[jgu1]

Hi all!

I have asked before concerning the same issue. I thougth it was fixed i the new update.

I Arduino Uno I discoverd some strange.I made a small testprogram. att.

If I call a macro from an interrupt, and use a delay in the macro, the delay is leasr twice as loong as I preset. The same if I use a loop and use it for Count the Count counting the twice value.

Please look att. Am I doing something wrong? It Work fine in simulation but not in real world

Best regard

Jorgen

[jgu1]

MM Staff!

Please, would you look at it, please. I beg you.


BR

Jorgen

[Monie Jacobsen]

Hello Jorgen!
I have tested your program. It look like interrupt is doing something wrong. I tried to make a new test program and timing and value is ok if I NOT use interrupt, as soon as I add interrupt, something wrong happened with the variable.

Monie

[Benj]

Hello,

You are using a delay in your main program loop and a delay in your interrupt. If the processor is inside the delay routine when the interrupt fires then you will re-enter the delay routine causing stack corruption.

Think of it like a football penalty shoot out, you pick up the ball place it in front of the goal, run up to the ball and about to kick it when the interrupt happens. The interrupt repeats the setup to pick up the ball, place it in front of the goal and then shoots. When the interrupt has left the ball is already in the back of the net so you are left kicking air.

Delays inside interrupts are therefore risky at best and should be avoided as much as possible. Its not a bug as such, just something to be aware of. The same would go for things like calls to the LCD component, you might be right in the middle of a write operation in your main loop when an interrupt fires and starts talking to the LCD again. This would almost certainly corrupt the data shown on the LCD.

However if you really need to add delays into interrupts without causing the corruption then you can create your own delay routine.

To do this add a C icon where you want to add the delay and add the following code.

Code: Select all

nop();

The nop function is basically a no operation assembler command which consumes a single instruction. On AVR you get approx one instruction per clock cycle so at 8MHz, 8 nops would give you a delay of 1us.

If you need to you can then multiply this up by using a loop icon to repeat the C code icon as needed.

[jgu1]

Hi Ben!

Many thanks for your explanation, make sence. But I have tried to make a delay in a macro called by an interrupt when I use a PIC16 and there are no problems.

Ok I have changed the program and now I use no delay in the macro called by an interrupt, but made it in another way, see attachment.

PEFECT everything seem to Work, more precise ,stable and correct counting and delay. Succes....

Put in my memory.

Thank´s

Jorgen

[Benj]

Hello Jorgen,

The dsPIC compiler creates it's delays using an inline function. Going back to the football analogy (I don't even like football ) this means that every time you call the delay it's as if your playing with your own unique ball. On the AVR it seems that when you call the delay you share the ball which is why your experiencing the issue. Maybe this is something we can try and improve, I will look into how the delay is done in the CAL.

Edit: On the AVR the code to do the delay is flagged as inline but it is also flagged as static. The static means that your forcing the code to always be available which might be why we are "sharing the ball". I seem to remember issues early on in Flowcode 3 for AVR where delays wouldn't actually do anything as they got optimised out by the compiler. Adding the static forces the compilers hand and forces the delay to remain in the code. I will investigate and see if we can do anything to simplify this and make it work better as the 16-bit PIC does.

At least for now your workaround is allowing you to proceed so that is good news.

[jgu1]

Hi again Ben,

I am very grateful for your help and I understand your explanation .

It is very annoying when sitting and doing a program and see it work in simulation but behaves strangely after compile . and testing and testing and trying everything and it teases . but fortunately there are many Way to do it. As long as you know what you can and can not.

I thought Arduino works really well with FC6

Jorgen