1

I am used to programming PC's and smartphones using high level languages, microcontrollers are a new territory for me. Are they somehow different, more untrustworthy, requiring different techniques? Here is bit of code to write and read to EEPROM running on a Arduino Mega: (there is an Ethernet Shield attached, not used here)

#include <EEPROM.h>
int addr = 0;
int val;
byte value;
void setup()
{
  Serial.begin(9600);
}
void loop()
{
  val = 9;
  EEPROM.write(addr, val);
  delay(500);
  addr = addr + 1;
  if (addr == 20) addr = 0;
  value = EEPROM.read(addr);
  Serial.print(addr);
  Serial.print("\t");
  Serial.print(value);
  Serial.println();  
}

Heres what comes out:

1   91
2   91
3   9
4   9
5   9
6   9
7   9
8   9
9   9
10  9
11  9
12  202
13  202
14  202
15  202
16  202
17  202
18  202
19  202
0   9
1   89
2   91
3   9
4   9
5   9
6   9
7   9
8   9
9   9
10  9
11  9
12  9
13  9
14  9
15  9
16  9

..... In general address 1 and 2 are always flaky and it takes two writes to change memory locations above ~10.

I can switch out another board and still get similar oddities.

How can I adapt my programming to this seemingly flaky performance?

mcktimo
  • 1,440
  • 4
  • 19
  • 35
  • 1
    Oh boy, if computer hardware was so unreliable, how would the hardware even function? (That is, there must be a better explanation/fix.) –  Jan 23 '13 at 23:11
  • 1
    Hardware *is* unreliable and flaky at times. Hell, DRAM needs to be refreshed every few cycles otherwise it bleeds out. Hard drives are loaded with error correction logic to fix damaged sectors. Slight changes in voltage can yield completely wacky results. A surprising amount of things are so fragile that there's quite a lot of correction logic in their controllers ;) – slugonamission Jan 23 '13 at 23:30
  • 1
    There surely is a tradition of microcontroller programming techniques to check and correct sensors and logic. It is partially why I want to delve into it. Thnaks – mcktimo Jan 24 '13 at 02:27

1 Answers1

6

Simply enough, your code is wrong.

Logically step through it. You are writing to an EEPROM at address addr. You then wait 500ms, increment addr, and then read from the new addr. The addr you read from is therefore not the addr you write to.

slugonamission
  • 9,562
  • 1
  • 34
  • 41
  • Although as for locations 1 and 2, I don't have a clue sadly :( – slugonamission Jan 23 '13 at 23:10
  • Thanks, as far as the first few locations are concerned, it is easy to skip that region of memory – mcktimo Jan 24 '13 at 02:24
  • 1
    I ran your exact code with no unexplained behavior. The hardware is not unreliable when new, but may be _now_. BEWARE that your code will burn through the maximum write cycles in 11 days. If you where running other revisions of this code that only looped on locations 0 and 1 without the time delay you could have easily burned out the storage locations. 100k writes is not that large a number - 28 hours is more than 100 kseconds. – jdr5ca Jan 24 '13 at 06:33
  • @jdr5ca - I saw that in the documentation and data sheet and came to that as the only conclusion. I was hoping that it wasn't, since the OP had run it on different hardware, but it's also the only thing I can think of in this case. In any case, +1 – slugonamission Jan 24 '13 at 13:40