[TUT] [C] Using the EEPROM memory in AVR-GCC

Go To Last Post
356 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I still get that weird looking character. I started a new topic in the GCC forum, it seemed more appropriate. Please, if u have any suggestions, post there.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

char array[10];

'&array' is a pointer to the /address/ of the first element.
'array' is a pointer to the first element.

So you need to remove the '&'

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think noone has mentioned it before in this thread, so I'll do it :)

Quote:
6.5.5. Preventing EEPROM Data Corruption

Well, guess what? Simple usage of the target’s internal EEPROM will lead to spurious and frequent data corruption. The problem is caused mainly on the device’s power down and power fluctuation, and it’s a universal problem that happens with any “unprotected” kind of processor.

When power is cut (or provided) from a device, it actually decays “slowly” and not instantaneously, mainly because of capacitors in the circuit. There’s a point where power is starting to be insufficient for the target, and it starts to behave strangely, like jumping around and executing random pieces of code. That’s when parts of your own EEPROM write routines get executed and corrupt your data! It may also happen that power is turned off right in the middle of a write sequence, leaving your data inconsistent.

In cases of power fluctuation, known as “brown-out”, the problem process is similar. Power goes down to a point that makes the device malfunction, even though not completely off.

The solution to prevent EEPROM data corruption is 2-fold:

    1) The device needs protection against the “power fluctuation” – a brown-out detector, which puts and keeps the device in RESET while the power level is below a threshold considered as “minimum safe value” for the device. A normal power-down can be considered a special case of brownout, in which power doesn’t come back.

    2) Even with brownout protection, data can still get corrupted, because the device can be turned off or reset while a large (more than 1 byte) data structure is being written in the EEPROM. So, you need software protection or redundancy, by using some kind of checksum to validate your data, and optionally multiple data copies so that you don’t loose all of it (in case data is critical).

Many AVRs have a built-in brownout detector that can be enabled. It can be done when programming the device's fuses. There are also external chips that do brown-out detection and have other features as well (like a watchdog, some bytes of FLASH, etc). These devices connect to the uC’s RESET pin.

Embedded Dreams
One day, knowledge will replace money.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear Dean,
still there are fellows (like me) meeting your *excellent* tutorial just now. I have read all the discussion followed it, too, but did not get answer to my special question:
Is there any way of storing my EEPROM variable at a specific address? I need to force an array to be stored on page boundary. Can I do it?
Cheers, Istvan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Istvan,

I can't see why you'd need that - the EEPROM is not paged, so there are no performance benefits, nor any indication of how big a "page" is, since it's byte-addressed.

However, you could do one of two things. First, you could just use a pointer to your desired address:

eeprom_read_byte((uint8_t*)600);

Which would present problems if your other automatic variables overlap that area. The second way is to use GCC's sections to create a new EEPROM section at the desired location - there are some threads about this which you can search out. However, while the section method will allow you to create automatic variables in the new EEPROM section, you'll still run into problems if your normal EEPROM variables overlap.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Dean,
thanks for the fast response.
My program implements an extremely fast assembly loop (only 9 statements) to generate a stored waveform. To be fast enough, this loop handles only the lower part of a pointer, so my data must be aligned to some address represented as 0x...00 (I meant a page is an area of 256 locations starting at nn00 and ending at 00ff).
Is there any way of direct alinging?
Thanks, Istvan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The EEPROM is byte addressed, so no pages. You could I suppose just change the lower byte address every loop cycle and increment the upper address once every 256 cycles, but that would produce some jitter in your waveform due to the extra cycles being used on the 256'th iteration. Better to just use an extra cycle and load the full address.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alternatively it should be possible to put a named section into EEPROM space done in a similar way to the existing .eeprom at present and with a --section-start passed to the linker.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
The EEPROM is byte addressed, so no pages. You could I suppose just change the lower byte address every loop cycle and increment the upper address once every 256 cycles, but that would produce some jitter in your waveform due to the extra cycles being used on the 256'th iteration. Better to just use an extra cycle and load the full address.

- Dean :twisted:

I'm afraid my English is too bad to describe my wish.
I know EEPROM is byte addressed, but... e.g. in Intel386 assembly, if I want to fit a table to a 16 bit boundary (i.e. the lowest 4 bits of the address are 0 and the others are anything else) it is called a "paragraph". Similarly, if the lowest 8 bits are 0, then this is a "page" boundary.
Due to the upper address byte is intended to be eliminated, I have to care the table to be fit to proper address. So I am looking for the way to build something like this:

ldi zh,high table
clr zl
...
...
...
.eeprom
.org 0x100
table:
.byte x, y, z, etc

Now I have solved my original question by mixing with assembly, but I am still interested whether it can be solved in pure C?
Thanks, Istvan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes it can - use a named section and place it with the linker (like I said above)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Yes it can - use a named section and place it with the linker (like I said above)

Could you please drop me a link where I could read about the details? I'm a bit afraid of editing makefile... :(
Thanks forward,
Istvan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have found it useful to have two stacks in eeprom. One at 0x4 with increasing address and one at 0x1FF (on my mega16) and two stack pointers at 0x0 resp 0x2. I can store linked lists this way, vey useful.

One thing though, the data sheet says the mega16 has 512 bytes of EEPROM but it seems it is 513 bytes as i can address 0x0 -> 0x200, can anyone confirm this or is this where my bug is lying? I am absolutely positive that i can address 0x200 but i was thinking it might be reserved or something like that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Thank you for your excellent tutorial!
I am using the STK500 with the ATMega8515 chip and programming in C using AVR studio with GCC compiler.

When you use the eeprom_write_byte / eeprom_read_byte commands in your program, can the assembled .hex file just be loaded into the flash memory and will that be sufficient to store my data into the eeprom?

If I run my code as is it simulates fine on the AVR simulator, however, when I load the file onto the the chip, the output is entirely different.

The code basically cycles through an input string and displays the corresponding values in PORT B (LED's)

#include 
#include 
#include 
#include 

#define F_CPU 1000000UL 	//1 Mz

int main(void)
{
	DDRB = 0x3f;	//set 0-5 LED's to output
	char tex[20] = "ABCDE";
	int i=0;

	eeprom_write_byte((uint8_t*)65, 0x01);	//A
	eeprom_write_byte((uint8_t*)66, 0x03);	//B
	eeprom_write_byte((uint8_t*)67, 0x09);	//C
	eeprom_write_byte((uint8_t*)68, 0x19);	//D
	eeprom_write_byte((uint8_t*)69, 0x11);	//E
	
	for (;;)
	{ 
		while (tex[i] != '\0')
		{
			uint8_t byteofdata= eeprom_read_byte((uint8_t*)tex[i]);	

			
			PORTB = byteofdata;
		
			_delay_ms(2000);
			_delay_ms(2000);
			i++;	
		}
		i = 0;
	}
	return(0); 
}

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, just loading the HEX into the chip would be sufficient in your case -- if you move to using the EEMEM attribute in the future with initialized values, you'll also need to program in the generated .EEP file into your chip.

In your case, you've got a problem. Your write code is fine, and should result in the letters A, B, C, D and E being stored to consecutive EEPROM addresses. However, your read loop reads in bytes from EEPROM, but at the address of your "tex" array, which is located in SRAM. Since the location of the tex array will almost definitely be different to your hard-coded EEPROM addresses (of 65 through 69), the program will output different values to the LEDs.

Also, unless you are using the latest WinAVR/avrlib-c distribution, the _delay_ms() macro has a limit of only about 20ms -- check the user manual.

The "correct" code would be:

#include 
#include 
#include 
#include 

#define F_CPU 1000000UL    // 1 MHz

char texEEPROM[20] EEMEM;  // Create a variable located in the EEPROM space

int main(void)
{
   char    tex[20] = "ABCDE";
   uint8_t texByte;

   DDRB = 0x3f;   //set 0-5 LED's to output

   // Copy the "tex" array to the EEPROM, at the location of the texEEPROM array
   for (texByte = 0; texByte < sizeof(tex); texByte++)
      eeprom_write_byte(&texEEPROM[texByte], tex[texByte]);
   
   for (;;)
   {
      uint8_t ReadByte;

      texByte = 0;

      // Read out the texEEPROM array from EEPROM and display on LEDs
      do
      {
         ReadByte = eeprom_read_byte(&texEEPROM[texByte]);
 
         PORTB = ReadByte;

         for (uint8_t DLoops = 0; DLoops < 100; DLoops++)
            _delay_ms(20);
      } while (ReadByte != '\0');
   }

   return 0;
}

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Dean,

However, I am trying to do something a little different. Basically, when the string shows A, B, C... I want the LED's (PORT B) to specifically be 0x01, 0x03, 0x09...as seen in the write_byte command (these values must be hardcoded).
So in order to do this, I hardcoded these values in the eeprom locations corresponding to the ASCII values of A,B,C...
So when i=1, tex[i] = 65 (ascii value of 'A')
Next I read eeprom_read_byte((uint8_t*)65) which should be 0x01 right?

When I run this code in the AVR simulator I get 0x01 in PORT B, but when I load the code onto the chip itself, the LED's on the STK500, don't display 0x01.

Thanks in advance!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most likely then your _delay_ms function isn't working as expected. Unless you have the absolute latest library version the maximum ms delay value is around 20ms. Try replacing your calls to _delay_ms with the code:

for (uint8_t DLoops = 0; DLoops < 100; DLoops++)
            _delay_ms(20);

And ensure you compile with the right F_CPU CPU speed value - if the AVR is out of the box, it will be running off its internal 1MHz RC oscillator and not your external clock/crystal.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great tutorial! For anyone else who had trouble finding information on (at compile time) retrieving the size of the EEPROM (for example, you want to start storing things at the end, rather than the beginning), the constant for the last address in the EEPROM is

E2END

There are corresponding constants for Flash and other sizes, allowing you to write more portable code. I think, based on other information I found, that when using the IAR compiler, the equivalent definition is __EEPROM_SIZE__
Good luck!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi, thx for the tutorial!!!

i'm working on my first project in C on a ATmega8 (actually it's a porting of an asm project in C).
i've got some problems when i read a data from the eeprom (i can't understend where i'm wrong)

:cry:
the piece of code is:

Quote:

#include
#include
#include

void readEeprom(void)
{
uint8_t eepromData;
...

//read idCube
eeprom_busy_wait();
eepromData = eeprom_read_byte((uint8_t*)6);
if (eepromData == 0xff)
idCube = idCubeDefault; (*)
else
idCube = eepromData;
...
}

and i get the following error:

Quote:

../MicrelCube3_2.c:352: error: expected expression before '=' token

on the line with the (*)

i just can't figure out what's wrong...
thx,
b.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need to declare idCube, the compiler is complaining that it doesn't know what "idCube" is. Try sticking:

uint8_t idCube;

At the start of the program (after "uint8_t eepromData;").

Also, a suggestion. Try using the ternary operator for the assignment to clean up the code:

idCube = (eepromData == 0xff) ? idCubeDefault : eepromData;

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
i've defined idCube, in my header, but because of the source project in asm i had definitions like:
#deine idCube = 1
and that '=' caused all my troubles...
thx for the help,
b.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That means that idCube is a constant token, not a variable. You can't assign values to a macro, only variables.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean,
How does one initialize an eeprom array?

uint8_t EEMEM SomeVariable = 12; works fine for a single byte..., but what if it is SomeVariable[10] and one wishes to initialize a particular element or two?

Thanks,
John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can initialize the EEPROM array just like a normal C array:

uint8_t EEArray[5] EEMEM = {1, 2, 3, 4, 5};

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Egads man!..., don't you ever sleep?!

That, of course does the trick for the array.

Thanks, again
John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sl...eep? I'll have to go look that up in the dictionary ;).

Glad I could help.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everyone. I've got stuck on this EEPROM problem. I am using an ATmega169 and JTAGICE as debugger/programmer. I just want to verify that i am succesfully writing a data to the EEPROM. So I make a code to write and then read the data.

#include 
void main(void)
{
   uint8_t mbyte;
   uint8_t rbyte;

   for(mbyte=0;mybte<100;mbyte++)
      eeprom_write_byte((uint8_t *) mbyte,mbyte);
      //just write data 00 to 99 at address 00-99
   for(mbyte=0;mbyte<100;mbyte++)
      rbyte=eeprom_read_byte((uint8_t *)mbyte);
      //read data from address 00-99
   while(1);//endless loop
}

This code works pretty well and I confirm it during debugging and step by step execution. But when i tried to comment the portion of eeprom writing, and then run the debugger, it seems that all data i read are all 0xFF(at all address). Is there something wrong?.. Hope someone could help me on this.Thank you so much, more power!..
jasperman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Each time you start to debug it erases the chip and downloads the code. During the chip erase the EEPROM will also be wiped. To avoid that try setting the EESAVE fuse.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Each time you start to debug it erases the chip and downloads the code. During the chip erase the EEPROM will also be wiped. To avoid that try setting the EESAVE fuse.

I already try that, using the "Preserve EEPROM during Chip erase", but i still get the same result.. Is there anything else i forgot about settings?..

jasperman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys!

I have already figured out with my problem on the EEPROM. I decided to share it here so that it can help also others with troubles the same as mine..

First is you must enable the "Preserve eeprom during programming" Fuse bit.

Second, since I am using a JTAG ICE, you must enable also the "Preserve eeprom during programming" in the JTAG settings. This is what i mislooked.

JTAG settings can be achieve on the "Debug" menu of the AVR studio, click on the "JTAG ICE options". It will open you a new window with options on the "Connections", "Debug", "Breakpoints" and "Status". Under the "Debug" options, you must enable the "Preserve eeprom during programming".

You must take note that even though you enable the "preserve eeprom" fuse bits but did not enable the "preserve eeprom" on the JTAG settings, then your eeprom will always be erased everytime you start the JTAG ICE.

Hope this might help others with the same problem as mine.

jasperman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I'm trying to use the eeprom to store the mac and IP address.

Not knowing the structure of the eeprom hex file, I let GCC do it by declaring the values using the EEMEM attribute:

uint8_t EEMEM mymac[6] = {0x54,0x55,0x58,0x10,0x00,0x24};
uint8_t EEMEM myip[4] = {192,168,2,101};

I took the eeprom file that it generated and renamed it so it wouldn't get overwritten the next time I compiled. The file looks like this by the way in a hex editor:

3A 31 30 30 30 30 30 30 30 35 34 35 35 35 38 31 30 30 30 32 34 43 30 41 38 30 32 36 35 46 46 46 46 46 46 46 46 46 46 46 46 46 32 0D 0A 3A 31 30 30 30 31 30 30 30

I make sure the fuse is set where the eeprom isn't overwritten anymore.

Now that I have my eeprom file I comment out the above lines and just make the variables empty arrays:

uint8_t mymac[6];
uint8_t myip[4];

I then try to read into the arrays:

eeprom_read_block((void*)&mymac, (const void*)0, 6);
eeprom_read_block((void*)&myip, (const void*)6, 4);

I get garbage out every time.

What's odd to me is that I don't see the hex mac address in the eeprom. In short, I know I'm doing it wrong but I feel that I've followed the tutorial pretty closely.

Anyone else use eeprom this way?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I make sure the fuse is set where the eeprom isn't overwritten anymore.

Try reading the EEPROM contents back out to a different .hex after you have just programmed it. Then program the app code and read out the EEPROM yet again. Does the data appear to be intact across all steps? Also does your app code contain any form of eeprom_write_*() that might be corrupting the data?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just read the eeprom after a programming and shows the same as above followed by a lot of 0x46's (FF's) surrounded by address fields.

Does it make sense how it writes those bytes? As an example, take the first byte of the mac address (0x54). In the eeprom, it appears to be in the two bytes 0x35, 0x34. Putting a "3" in front of each number makes no sense to me unless that's how the hex file structure is supposed to be for an eprom.

Also, I have no eeprom writing in my program, just reading in those two lines.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well my program appears to be working since if I write a new eeprom file with a new ip address, the program switches to it.

I just don't understand why the eeprom file looks that way in a hex editor.

EDIT: All was/is working. I was looking at the wrong screen of my hexeditor.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm experimenting and building a dot matrix display, and want to store the font (max 16*16 px) inside the Atmegas eeprom. I need advice about how to store the pixel information.

The "problem" is that I don't want to store 16*16 bits for characters which don't need the size. As you all know, 'M' is much wider than '!'.. No need to store '!' 16px wide, right? My idea is to store a "size byte" (using upper/lower 4 bits for width/heigth) to each char which tells me how wide/high it is.

For example, let's say ' ! ' is 1 bit wide, 8 bits high (data byte 0xFD), and ' " ' is 3 bits wide, 8 bits high (data bytes 0xC0, 0x00, 0xC0).. And let's pretend another char is a 16*16 char. I can store the description byte telling me how wide/high they all are, but how do I store the actual data in the eeprom in custom size? How do I know where to read the data?

I hope you get the idea of what I'm looking for. Is it possible to do something like this? Suggestions?

Thank you in advance,
/D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

daffy,

Just out of interest, why use the EEPROM and not simply const data in code flash or is the idea here that the font is some how user editable (but that's going to make it a nightmare if a small block of data needs to be replaced by a larger block!)

As for the "compression". You seem to have described a solution that works there anyway. Obviously to display character N you either need an index for the start locations of all the defintions or you start at the first character, read its width/height then skip that many bytes to the next width/height and do this N times to get to character N. If space allows perhaps an index is a better idea?

To prepare the data (assuming you already have it all defined as 16x16) I'd just put together a quick PC program to process this and output it in the "compressed" form. The advantage of this is that you can then later edit the 16x16 grids and just crank the handle to output a new dataset.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

edit: double post

Last Edited: Tue. Sep 16, 2008 - 09:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Just out of interest, why use the EEPROM and not simply const data in code flash or is the idea here that the font is some how user editable (but that's going to make it a nightmare if a small block of data needs to be replaced by a larger block!)

As you thought, my plan is to be able to write/create the font "outside" the avr, and insert it later. I'll write a small app where I can specify heigth/width per char, and then send it via rs232 to the display.

Quote:

As for the "compression". You seem to have described a solution that works there anyway. Obviously to display character N you either need an index for the start locations of all the defintions or you start at the first character, read its width/height then skip that many bytes to the next width/height and do this N times to get to character N. If space allows perhaps an index is a better idea?

Ah.. Do you mean I keep a separate list with eeprom start locations of every character? (And that location describes how many bytes the character consist of, followed by the data bytes?)

Edit: Yes, that must be what you mean.. But how do I figure out the start locations when storing the font in the first place?

Quote:

To prepare the data (assuming you already have it all defined as 16x16) I'd just put together a quick PC program to process this and output it in the "compressed" form.

Exactly my plan. Write a PC app in which I create the font, save the font to the display. Would be convenient =)

Quote:

The advantage of this is that you can then later edit the 16x16 grids and just crank the handle to output a new dataset.

I don't understand what you mean? (it's certainly something good though ;)

Thanks for the reply!
/D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My application uses 6 parameters which I want to be able to set by a 2x8 LCD and three buttons so I do not need my laptop. I use the following code:

uint16_t wtht;
wtht = eeprom_read_word((uint16_t*)46);
while (1)
{
lcd_clear();
lcd_gotoxy(0, 0);
lcd_string("WTHT ");
lcd_int(wtht);
lcd_gotoxy(0, 1);
lcd_string("- + NEXT");
delay_ms(50);
if ( (PINB & (1 << PB0)) == 0 )
{ --wtht; delay_ms(100); }
if ( (PINB & (1 << PB4)) == 0 )
{ ++wtht; delay_ms(100); }
if ( (PINB & (1 << PB5)) == 0 )
{ break; }
}
eeprom_write_word((uint16_t*)46,wtht);
delay_ms(500);

Works great and can be multiplied for all my other parameters.

I took the value 46 because it was in the tutorial, I tried to read the datasheet of the MEGA48 but do not understand how I can determine the numbers I am allowed to use. Can anyone explain?

Erik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I took the value 46 because it was in the tutorial, I tried to read the datasheet of the MEGA48 but do not understand how I can determine the numbers I am allowed to use. Can anyone explain?

Yes. That is a totally arbitrary address in EEPROM that Dean chose:
abcminiuser wrote:
let's say at location 46

The addresses you are allowed to use are from zero to the size of the EEPROM minus one. The mega48 has 256 bytes of EEPROM so the legal addresses are 0 to 255.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sometimes life is easier than expected,

As I use 16 bit parameters I have to skip one adress between every parameter, it works great, thanks for the reply

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hallo, I'm a really newbie at programming avr-controllers. At the moment i want to learn to work with the eeprom memory. But i have a big problem. After i have included avr/eeprom.h i get following error message:
Unknown EEPROM register(s) location
:(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which AVR are you building for?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

XMEGA128A1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does this mean, that i can't work with eeprom.h on mega128a1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nope but you can't use pre-written routines in the current avr-libc's eeprom.h so you'll have to hit the registers directly yourself.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great Tutorial Thanks helped me when my AVR books couldn't.
Dean

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean thanks for your tutorial!
but i think the max Endurance is
Endurance: 100,000 Write/Erase Cycles.

I love Digital
and you who involved in it!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quite right Ali! The original AVRs had endurances of 10,000 writes for FLASH, and 100,000 for EEPROM. Later with the newer versions (MEGA and TINY) the FLASH endurance was extended to 100,000 also. Looks like I managed to mix the two up - the EEPROM lifespan was never extended.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Pages