next topic »

[Reply #15 on:]

Seems having it outside an IF works just as well, as any state change gets you into the IFs to do stuff.

[Reply #16 on:]

Any idea why I have to declare "int swState" twice?  It won't compile when I omit it from the loop, but I thought the void setup was where you set those up.

Scope (Google Keyword). Declared variables inside curly braces are only valid within those, or any nested curly braces. If you want both setup and loop to use the same variable, it needs to be declared in the global scope (outside of both functions).

[Reply #17 on:]

   } <-- The close goes here

I see, I was misreading Nick's code.  Apparently, when you have an IF followed by one line of code, you don't need brackets at all, hence me thinking the bracket past the state change write was the end of the IF, but it wasn't.

Thanks!

[Reply #18 on:]

It's a style thing. Some people always like to have the braces, personally I think it is clutter to do something like this:

Code:

if (minutes > 59)
  {
  hours++;
  }

Instead of:

Code:

if (minutes > 59)
  hours++;

[Reply #19 on:]

Cool, thanks

Speaking of minutes > 59, do you know how to make a 24 hour clock easily?  I'd like to have scheduled events happen throughout a 24 hour day maybe based on dip switch inputs for which hour for them to occur.  Is there an easy way to make a reliable clock from millis() or something?

Thanks!

[Reply #20 on:]

It should be accurate enough

Code:

uint32_t
  time_old,
  time_new;

void setup()
{
  time_old = millis();
}

void loop()
{
  time_new = millis();

  if ( time_new - time_old >= ( 24UL * 60 * 60 * 1000 ) )
  {
    time_old = time_new;
    //do something every 24 hours here
  }
}

Edit: after re reading your post I doubt that is useful for you...sorry I'm not english, sometimes I don't understand

[Reply #21 on:]

It's a style thing. Some people always like to have the braces, personally I think it is clutter to do something like this:

I'm firmly in the 'always use braces' camp. It's so easy for a careless code change or macro substitution to add a second statement which appears to be included in the condition, but really isn't. And then when you have somebody used to coding like this (but not experienced enough to be aware of all the gotchas) you can have all sorts of bother with nested ifs and so on. As far as I'm concerned, the benefits of always using braces and indentation to make the control structure clear and verifiable outweigh all considerations about compactness. The best way I know to achieve for myself that is to put each brace on a separate line with matching pairs indented by the same amount and the lines between the indented an extra level, although others prefer different layouts and that's fine.

[Reply #22 on:]

uint32_t
  time_old,
  time_new;

 if ( time_new - time_old >= ( 24 * 60 * 60 * 1000UL ) )

Couple questions:  What is "uint32_t"?
Also, what is the UL in 1000UL?

Still new over here, thanks!

[Reply #23 on:]

"uint32_t" is the same as writing "unsigned long", and UL is to inform the compiler that the resulting number (of the multiplications) will be a unsigned long as well

Edit: If you do for example:

Code:

uint32_t n1 = 24 * 60 * 60 * 1000;
uint32_t n2 = 24UL * 60 * 60 * 1000;

Serial.println(n1);
Serial.println(n2);

Here is the result:

Code:

23552
86400000

So it is important to put the 'UL' when needed

[Reply #24 on:]

uint32_t
  time_old,
  time_new;

Is that comma after time_old correct or is it supposed to be a ";"

Thanks

[Reply #25 on:]

No it's correct, it's like writing

Code:

uint32_t time_old, time_new;

or

Code:

uint32_t time_old;
uint32_t time_new;

All the same

PS: I fixed a little mistake in my previous post: do not place UL after the last number. To any other numbers but the last, else it will give a bad resulting number!

[Reply #26 on:]

"uint32_t" is the same as writing "unsigned long"

Not quite.

The uint32_t type explicitly creates a 32 bit variable on any platform - Windows, Max, Linux, 64 bit, 32 bit, 16 bit, 8 bit, whatever. It doesn't matter. The same hold true for the uint16_t, int32_t, int8_t, etc. types. The number defines the number of bits. The prefix defines the type - int, unsigned int.

An unsigned long or int or byte can be different sized on different platforms.

[Reply #27 on:]

PS: I fixed a little mistake in my previous post: do not place UL after the last number. To any other numbers but the last, else it will give a bad resulting number!

That's not true, either. The UL has to close enough to the front so overflow doesn't occur before the type change.

uint32_t myVar1 = 80 * 1000 * 1000UL;
is wrong, because 80 * 1000 will be performed using ints, and will overflow.

uint32_t myVar2 = 80UL * 1000UL * 1000UL;
is OK, because all the values are unsigned long, so unsigned long arithmetic will be used.

uint32_t myVar3 = 10 * 1000 * 1000UL;
is also OK, because 10 * 1000 will be performed using ints, but no overflow will occur.