next topic »

[Reply #15 on:]

Casting the parameter in a macro to an unsigned long forces the compiler to do the entire calculation as a long in other platforms I have used. Are you saying that the suggestion to use a macro with the cast wont work here?

It might or it might not, depending on how the function is called.  In particular, it won't work unless the arithmetic is being done right there in the function call.  So, it would allow "delay(60*1000)" to work, but not, for instance, "int interval = 60 * 1000; delay(interval)".  

[Reply #16 on:]

Casting the parameter in a macro to an unsigned long forces the compiler to do the entire calculation as a long in other platforms I have used. Are you saying that the suggestion to use a macro with the cast wont work here?

It might or it might not, depending on how the function is called.  In particular, it won't work unless the arithmetic is being done right there in the function call.  So, it would allow "delay(60*1000)" to work, but not, for instance, "int interval = 60 * 1000; delay(interval)".  

Tom,  your comment is an example of how the compiler can generally overflow integer math, I don't think there is any way to reduce the general problem you show in your example other than educating users on the nature of type overflow.

I thought the subject of this thread was how to address overflow in the argument to the arduino delay function.

It seems to me that we help users with overflows in the arguments of functions like delay if the cast is implicitly done by calling the function through a macro. I wonder if you think that would be worthwhile.

[Reply #17 on:]

I thought the subject of this thread was how to address overflow in the argument to the arduino delay function.

My main request when I started the thread to have the documentation improved, to explain more clearly how to use the delay() function correctly.  The docs still don't indicate what the type of the argument is.  A warning there about the perils of 16-bit arithmetic would also be pretty helpful.  

It seems to me that we help users with overflows in the arguments of functions like delay if the cast is implicitly done by calling the function through a macro. I wonder if you think that would be worthwhile.

I agree it would probably help most people avoid the mistake I made, and to that extent it might be worthwhile.  On the other hand, it doesn't help people understand what they're doing.  

My main objection to the macro, however, is that the way it works is a bit unclean.  The cast doesn't act on the argument as a whole, but depends on it being an arithmetic expression that can be modified before it's evaluated.  Usually, you try to avoid writing macros that work that way because they lead to code that fails mysteriously.  In this case, for example, the following cases do and don't work...

Code:

#define delay(_val) original_delay( (unsigned long) _val )
 
delay(60000);  //works
  
delay(60*1000);  //works

delay((60*1000));  // fails

unsigned long interval = 60*1000;
delay(interval);  // fails

So, the simplest and most common usages of the function would now work, but the reason why the last two examples fail would be hard to explain.  Just as C code, all four of my examples would ordinarily be expected to produce the same result, since all four delay() arguments evaluate to the same value when taken by themselves.  Of course, without the macro, all four examples would fail, but once you understood why, you'd have learned something useful and (hopefully) become a better C programmer.  

[Reply #18 on:]

Of course, without the macro, all four examples would fail,

That's not right, of course - the first example,

Code:

delay(60000);

works already.  It's just the second of my four examples that the macro would allow to work.

[Reply #19 on:]

Actually the fourth example of the macro does exactly what you expect it to do (garbage in/garbage out).  And I do think an inexperienced programmer is much more likely to use the second case rather than the third.

I do wholeheartedly agree that documentation and education are the best prevention for this problem. But it has been my experience that many that are attracted to the arduino enthusiastically jump in the deep end with some playground code that is related to their needs and don't spend a lot of time reading about syntax or semantics  

Anyway, the decision for the arduino team is to decide if they want to provide a little bit of  a safety net here or not.

I imagine that those that read this thread are unlikly to easily fall into the trap so thanks for raising the issue

[Reply #20 on:]

I am so confused with the delay function..
I want a delay for 84000 secs ..  this piece of code doesnt work ?
can anyone help me.. is there anything wrong in the delay function..


int j;
unsigned long a;
for(j=1;j<=840;j++)
        {
          if(digitalRead(19)==HIGH)
          {    
            digitalWrite(16,LOW);
            digitalWrite(17,HIGH);
            a=(j*100);
            delay(a);
            digitalWrite(17, LOW);
                      
            }
        delay(100);
        }

[Reply #21 on:]

Change this...

Code:

          a=(j*100);

...to this...
 

Code:

         a=(j*100L);

[Reply #22 on:]

Keep in mind that delay takes a value of milli-seconds, not second.

From your loop, it appears that you want to wait longer and longer each time though the loop. Is that true?

And this puzzles me:

I want a delay for 84000

Why do you want to wait almost an entire day?