Pages: [1] 2   Go Down
Author Topic: How accurate are delays within loops  (Read 799 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Full Member
***
Karma: 0
Posts: 139
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I am trying to store a value 40 to EEPROM times a second so the value will be stored every 25ms. If I put a 25ms delay in the loop then it delays 25ms, but takes time to run the rest of the loop so the time will actually be more than 25ms for the loop to run. Does anyone know how long that additional time will be? Is there a function that I can use to test the time? The number of samples a minute is flexible, but I need to know as accurately as possible how long that extra time will be. Thanks
Logged

Offline Offline
Full Member
***
Karma: 0
Posts: 139
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I am trying to store a value 40 to EEPROM times a second so the value will be stored every 25ms. If I put a 25ms delay in the loop then it delays 25ms, but takes time to run the rest of the loop so the time will actually be more than 25ms for the loop to run. Does anyone know how long that additional time will be? Is there a function that I can use to test the time? The number of samples a minute is flexible, but I need to know as accurately as possible how long that extra time will be. Thanks
Logged

New Hampshire
Offline Offline
God Member
*****
Karma: 17
Posts: 781
There are 10 kinds of people, those who know binary, and those who don't.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

delay() is pretty accurate, but fairly useless for a variety of other reasons.  One of them of course being the problem you are running into.  It's rather useless when used in conjunction with the rest of the program to perform overall timing.

Take a look at the Blink without Delay sample.  That provides a good method for overall timing.
Logged


UK
Offline Offline
Faraday Member
**
Karma: 99
Posts: 4153
Where is your SSCCE?!?!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

It will be about as long as it takes for you to completely kill your EEPROM.

Storing a value to EEPROM that frequently is just plain stupid.  I'm sorry, but it is.

The EEPROM can only be written to a finite number of times.  Approximately 100,000 times.  At 40 times per second, that's 100,000/40 = 2500 seconds.  That's a little over 41 minutes.

Stop now, before you go any further, and re-think just what you really want to do.

As for calculating how long the loop will take?  Well, that depends on two factors:

1. The number of instructions (and hence the number of clock cycles) the loop compiles into.
2. The number of times the EEPROM has been written to - it slows down with use as it takes longer and longer to erase the cell before writing to it after a while.  The death of an EEPROM cell isn't actually the cell dying per se, but the fact that it takes longer than a threshold timeout to erase.
Logged

Get 10% off all 4D Systems TFT screens this month: use discount code MAJENKO10

Portugal
Offline Offline
Edison Member
*
Karma: 37
Posts: 1544
Pretending you know everything then you will learn nothing.
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I am trying to store a value 40 to EEPROM times a second so the value will be stored every 25ms
Are you crazy dude?
You can't store a value on eeprom 40 times in one second.
Did you know the eeprom writes are limited!!!
Logged

Debian,Mint,Ubuntu
Arduino Mega 2560
Arduino Nano
Arduino Duemilanove
MAC OS Montain Lion
Raspberry PI Model B


California
Offline Offline
Faraday Member
**
Karma: 88
Posts: 3360
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

As others mentioned, you'll kill your EEPROM pretty quickly that way, but to answer your questions...

Does anyone know how long that additional time will be?
That entirely depends on your code. If the rest of your loop is an assignment statement, a mere nano seconds. If the rest of your loop is a few hundred floating point calculations, then it might take a while.

Quote
Is there a function that I can use to test the time?
millis(). You're better off using that than delay() anyway.
Logged

Grand Blanc, MI, USA
Offline Offline
Faraday Member
**
Karma: 92
Posts: 3955
CODE is a mass noun and should not be used in the plural or with an indefinite article.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Use millis(). Save the value from millis() in a variable (use an unsigned long variable). Then in the main loop, constantly check millis() and compare it against the saved value. When it's 25 more than the saved value, then 25ms have elapsed, so do the next write. The timing should be reasonably accurate, within half a percent or so.

You are aware that according to the datasheet, EEPROM endurance is 100,000 write/erase cycles? At 40 writes per second, that works out to 41 minutes or so. Some folks have tested this and reported significantly higher endurance, but once the datasheet spec is exceeded, I wouldn't bank on it.

Logged

MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

Grand Blanc, MI, USA
Offline Offline
Faraday Member
**
Karma: 92
Posts: 3955
CODE is a mass noun and should not be used in the plural or with an indefinite article.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

And please don't cross-post.
http://arduino.cc/forum/index.php/topic,122540.msg921509.html#msg921509
Logged

MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

Global Moderator
UK
Offline Offline
Brattain Member
*****
Karma: 290
Posts: 25770
I don't think you connected the grounds, Dave.
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Topics merged.

I'm really fed up having to tell people not to cross-post.

OP, you had two threads asking the same question in different parts of the forum.
Did it not occur to you that other people would answer in one thread and not realise that someone else had answered it in the other?
Don't you realise this wastes their time?
How do you think it makes that person feel?

DO NOT CROSS-POST.

CLEAR ENOUGH?
« Last Edit: September 12, 2012, 10:45:47 am by AWOL » Logged

"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

UK
Offline Offline
Shannon Member
****
Karma: 222
Posts: 12549
-
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I am trying to store a value 40 to EEPROM times a second so the value will be stored every 25ms. If I put a 25ms delay in the loop then it delays 25ms, but takes time to run the rest of the loop so the time will actually be more than 25ms for the loop to run. Does anyone know how long that additional time will be? Is there a function that I can use to test the time? The number of samples a minute is flexible, but I need to know as accurately as possible how long that extra time will be. Thanks

Setting aside the issue of killing the EEPROM, you can avoid the processing delay issue you mention if you code the time comparison correctly:

Code:
unsigned long lastTime;
const unsigned long interval = 25; // ms

...

if(millis() - lastTime > interval)
{
    // ... do stuff
    lastTime += interval;
}

The crucial part here is that you update lastTime to record when the event was due, not when your sketch handled it. This means the timing doesn't slip by however long it took your sketch to notice that the interval had elapsed.
Logged

I only provide help via the forum - please do not contact me for private consultancy.

Global Moderator
UK
Offline Offline
Brattain Member
*****
Karma: 290
Posts: 25770
I don't think you connected the grounds, Dave.
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Code:
if(millis() - lastTime >= interval)
The really crucial part is to get the right comparison.
Logged

"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

0
Offline Offline
Faraday Member
**
Karma: 23
Posts: 3470
20 LEDs are enough
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Here is one of the articles on EEPROM endurance: http://blog.blinkenlight.net/experiments/counting-resets/wear-leveling/. Burning out the EEPROM is not a all or nothing issue though. It's more an issue of aging smiley-wink
Logged

Check out my experiments http://blog.blinkenlight.net

Offline Offline
Full Member
***
Karma: 0
Posts: 139
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I will not cross post in the future.

What exactly does the EEPROM "die" after 100,000 writes? I am only trying to store about 100 points which would theoretically be 2.5 seconds at 40 values per second. Afterwards I would upload them to the computer and wipe the old values. Any suggestions of a better way to do this? It was mentioned to me to instead use an SD card. If that is a good idea do you know of any tutorials or threads that you could point me in the direction of. Thanks.
Logged

UK
Offline Offline
Faraday Member
**
Karma: 99
Posts: 4153
Where is your SSCCE?!?!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I will not cross post in the future.

What exactly does the EEPROM "die" after 100,000 writes? I am only trying to store about 100 points which would theoretically be 2.5 seconds at 40 values per second. Afterwards I would upload them to the computer and wipe the old values. Any suggestions of a better way to do this? It was mentioned to me to instead use an SD card. If that is a good idea do you know of any tutorials or threads that you could point me in the direction of. Thanks.
A great site that tells you all about it:

http://www.lostcircuits.com/mambo//index.php?option=com_content&task=view&id=69&Itemid=1&limit=1&limitstart=3

The important bit from it:

Quote
...cycling a NAND flash cell entails extremely high electrical fields that can exceed 10 million volts per cm, which is needed to force the electrons to pass through the oxide layer in either direction. Over time, this causes degradation of the oxide layer by causing atomic bonds to break within the oxide layer proper and also at its interfaces with the floating gate and the substrate. The intermediate result is trapping of electrons at the broken bond sites with the oxide layer acquiring negative electrical charges. As a consequence, the erase process becomes slower whereas the programming becomes faster.

Wear levelling is most commonly used to get around the problem - the more cells there are for you to write to, the more you can write before the whole thing becomes unusable.

The great thing with an SD card over the internal EEPROM is that a) the SD card is replaceable so can be swapped when it begins to die, and b) is considerably bigger than the internal EEPROM, so has many millions more cells for you to play with, so you have many millions times more lifetime from it.  Most SD cards include their own wear levelling systems, so you can just forget about it and it does it for you.

There are plenty of tutorials and examples around for using an SD card with the Arduino.  Check the Examples within the IDE for a start.

Oh, and one tip - don't write your data points direct to EEPROM/SD/Whatever.  Collate them in RAM first, and then write them after the sampling has been done together in one batch.
« Last Edit: September 12, 2012, 07:21:10 pm by majenko » Logged

Get 10% off all 4D Systems TFT screens this month: use discount code MAJENKO10

0
Offline Offline
God Member
*****
Karma: 2
Posts: 854
Arduino rocks!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I am only trying to store about 100 points which would theoretically be 2.5 seconds at 40 values per second. Afterwards I would upload them to the computer and wipe the old values.

Why can't you store the 100 bytes in SRAM then until you upload it to the computer?  The only reason to use EEPROM is if you want the values to persist through the Arduino being reset.
Logged

Pages: [1] 2   Go Up
Jump to: