next topic »

[on:]

The single line of code in the loop below flashes a LED without use of delay().
Only issue I see is that pin 9 is being written to on every loop cycle.
Is this a bad thing to be doing ?

Thank you.

BobW

Code:

void setup()   
{
  pinMode(9, OUTPUT);      // LED on pin 9
  pinMode(8, OUTPUT);      // virtual ground for LED
  digitalWrite (8, LOW);   // virtual ground for LED
}

void loop()
{
  digitalWrite ( 9, (millis()%500 < 250) ? 1 : 0 );  // flash LED at 2Hz

  // code that runs all the time goes here
}

[Reply #1 on:]

The single line of code in the loop below flashes a LED without use of delay().
Only issue I see is that pin 9 is being written to on every loop cycle.
Is this a bad thing to be doing ?

Not necessarily a bad thing, was there a specific concern you had in mind?

[Reply #2 on:]

Jack:

One thought was: does the memory I'm writing to so many times have a life span to it ?
Doesn't flash memory have a limited number of writes in its estimated lifetime before it goes bad ?

BobW

[Reply #3 on:]

You're not writing to flash memory, you're writing to a register.

[Reply #4 on:]

It does what you want without any side effects that I can see, so there's nothing wrong with that as a solution. Explicitly comparing the result of millis() against a threshold gives you much more flexibility, but it's flexibility that you don't need in this simple example.

[Reply #5 on:]

According to the datasheet, the flash memory that holds the program is good for 10,000 write/erase cycles, so that puts an upper limit on the number of times the part can be programmed. But once the program is running, nothing will "wear out". (The EEPROM memory, used for non-volatile data storage has an endurance of 100,000 write/erase cycles.) "Regular" variables declared in the code usually go into the static RAM (SRAM), which has no endurance limits.

[Reply #6 on:]

OK.  I understand.  No practical limit on reading or writing with SRAM.

I'm still weak on understanding differnce in purpose of Flash vs EEPROM.
Both non-volatile.  Bootloader and sketch stored in Flash.
What's EEPROM for then ?  Why couldn't non-volatile data be stored in flash ?
Why two kinds of non-volatile memory ?

[Reply #7 on:]

OK.  I understand.  No practical limit on reading or writing with SRAM.

I'm still weak on understanding differnce in purpose of Flash vs EEPROM.
Both non-volatile.  Bootloader and sketch stored in Flash.
What's EEPROM for then ?  Why couldn't non-volatile data be stored in flash ?
Why two kinds of non-volatile memory ?

EEPROM is for user only data, used for say storing configuration data to be used when a sketch starts up depending on say a switch input being on or off on startup. It's simply a user scratch pad type memory to use or not use as you please. Useless to many applications, indispensable for other applications. Flash memory can't be (easily?) written to once the sketch has started, only the bootloader code or ISP programming (and a few other hardware programmer methods) can write to flash memory. The user can read or write to EEPROM anytime they wish.

Lefty

[Reply #8 on:]

OK.  I understand.  No practical limit on reading or writing with SRAM.

I'm still weak on understanding differnce in purpose of Flash vs EEPROM.
Both non-volatile.  Bootloader and sketch stored in Flash.
What's EEPROM for then ?  Why couldn't non-volatile data be stored in flash ?
Why two kinds of non-volatile memory ?

Good questions. Executable code/program/sketch can only run from flash. NV data can be stored in flash, there is a modifier called PROGMEM for this purpose, see http://www.arduino.cc/en/Reference/PROGMEM and http://playground.arduino.cc/Learning/Memory

Also note the F() function which is a more convenient way to store strings in flash with PROGMEM.

Data stored in flash with PROGMEM is pretty well fixed (just like program code), where EEPROM can be changed while the sketch runs, and it will retain the data even when power is removed. SRAM must be powered to retain data.

[Reply #9 on:]

Is this a bad thing to be doing ?

At the point millis wraps, the code will not work as expected.  The most extreme outcome is that the LED will stay on or off for a bit less than 500ms.  You will have to decide if that constitutes a "bad thing".

The other potential downside is that some of the long integer helper functions have to be included.  For a memory constraint application that can be a problem.  For most applications, it makes no difference.

[Reply #10 on:]

From the 328 (and family) datasheet:

– Write/Erase Cycles: 10,000 Flash/100,000 EEPROM

If you could live with powers of 2 -1 then how about masking millis?

Code:

  digitalWrite ( 9, ((millis() & 0x1FF) < 255) ? 1 : 0 );  // flash LED at 2Hz

[Reply #11 on:]

OK.  Good.

EEPROM useful because it can be changed while sketch running. Got it.

Also - I'm just using the flashing LED as an annunciator for an alrarm condition.
       Blinking draws attention better than steady state ON.
       Overflow thus is not an issue for me.


Finally, Re Powers and Masking - I like that better than what I did.
         Will use this instead.

The reason I was interested in a simpler way to flash the LED was just to avoid having to deal with the logic and curly brackets that go with a *proper* "blink without delay".

I can keep this line "in stock" now and paste it in the future when I need this functionality.

I'm 100% good to go now !

Thank you all.

Bob W

[Reply #12 on:]

The reason I was interested in a simpler way to flash the LED was just to avoid having to deal with the logic and curly brackets that go with a *proper* "blink without delay".

I'd regard your solution as functional but obscure - the conventional approach is clearer (IMO) and more flexible. If reducing the number of curly brackets in your code was the main motivation for taking this approach, I suggest that's not a good reason.

[Reply #13 on:]

I think it'd be slightly faster with re-ordered logic too, maybe as much as a usec, or half-usec?

[Reply #14 on:]

I was also going to make the point that digitalWrite() is not without its overhead, so calling it only when needed would be more efficient. Having said that, I'm sure that in the vast majority of cases it makes no difference whatsoever.

Still, I'd be inclined to write a function, or use one of the various libraries, e.g.

Code:

#include "Timer.h"    //http://www.doctormonk.com/2012/01/arduino-timer-library.html

#define LED LED_BUILTIN

Timer t;

void setup()
{
    pinMode(LED, OUTPUT);
    t.oscillate(LED, 1000, LOW);
}

void loop()
{
    t.update();
}