[SOLVED]Missing functions in <avr/eeprom.h> -I got the eeprom working just asking-

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So this is my first thread.

Week ago i started AVR architecture with atmega32. I have gone through timers interrupts wave generation etc. with some basic input/output codes using leds only to learn the basics.I moved from 89s52 and so far everything was going well until eeprom. It is nice to have some predefined libraries saving me from writing all those long functions (89s52 eeprom bit banging code was headache).

 

Here is my question, when i add <avr/eeprom.h> library to my main it still gives me error. Examples i found on internet only uses this header file but i had to add some extensions as seen below in the code(found in this site http://www.edaboard.com/entry862...). 

 

As seen, my code could only compile when i added all those #define eeprom functions. Before that i had a lot of fails trying different methods, i am not getting into that to keep topic simple and understandable.

 

My questions are; is this the only way i should follow to use eeprom efficently? 
Second this is just a simple code to see if the data will be saved in eeprom, to do this i simply switch power off and on and see if the leds keep the last result. While doing this i m trying to be carefull not to do it while write/read cycles of eeprom. Is it still possible for eeprom to corrupt even if i switch the power off during a delay function.

I made some search on forums about this but closest one to my problem was https://www.avrfreaks.net/forum/e...
and it did not answer my question though helped me understand the procces a little bit better.

 

I am manualy programing the chip with hex and eep files using ISP with USBASP v2.0. Code is generated on Atmel Studio 7.

Any help, reference to using of BOD which i have not yet tried, is appreciated.

 

 

 

/*
 * internal eeprom test.c
 *
 * Created: 04.05.2017 02:23:23
 * Author : yorem
 */
#define F_CPU 1000000
#include <avr/io.h>
#include <avr/eeprom.h>
#include <util/delay.h>
#define read_eeprom_byte(address) eeprom_read_byte ((const uint8_t*)address)
#define write_eeprom_byte(address,value) eeprom_write_byte ((uint8_t*)address,(uint8_t)value)
#define read_eeprom_word(address) eeprom_read_word ((const uint16_t*)address)
#define write_eeprom_word(address,value) eeprom_write_word ((uint16_t*)address,(uint16_t)value)
#define read_eeprom_dword(address) eeprom_read_dword ((const uint32_t*)address)
#define write_eeprom_dword(address,value) eeprom_write_dword ((uint32_t*)address,(uint32_t)value)
#define read_eeprom_float(address) eeprom_read_float ((const float *)address)
#define write_eeprom_float(address,value) eeprom_write_float ((float*)address,(float)value)
#define read_eeprom_array(address,value_p,length) eeprom_read_block ((void *)value_p, (const void *)address, length)
#define write_eeprom_array(address,value_p,length) eeprom_write_block ((const void *)value_p, (void *)address, length)

unsigned char EEMEM birr_byte=0;

int main(void)
{
    unsigned char count;
	DDRD=0xff;
	PORTD=0;
	count=read_eeprom_byte(&birr_byte);
    while (1)
    {
		_delay_ms(5000);
		count++;
		if(count==200)
		{
			count=0;
		}

		PORTD=count;
		write_eeprom_byte(&birr_byte,count);
    }
}

 

This topic has a solution.
Last Edited: Sun. May 7, 2017 - 10:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yorem_kastor wrote:
My questions are; is this the only way i should follow to use eeprom efficently?  Second this is just a simple code to see if the data will be saved in eeprom, to do this i simply switch power off and on and see if the leds keep the last result. While doing this i m trying to be carefull not to do it while write/read cycles of eeprom. Is it still possible for eeprom to corrupt even if i switch the power off during a delay function. I made some search on forums about this but closest one to my problem was https://www.avrfreaks.net/forum/e... and it did not answer my question though helped me understand the procces a little bit better.

1. it's not the 'only' way - there are others. Apart from the #defines, I would use the functions in eeprom.h just like you do.

2. yes, it is possible for the eeprom to corrupt. Lose the power at the wrong time and corruption will occur.

3. Enable the BOD. This will lessen the potential for corruption.

 

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

I have lost the plot. I was not aware that AT89S52 had any EPROM hardware.
Of course, AT89S8252, AT89S8253, ... do have EEPROM
.
Enable BOD. Use proper wiring and power supply.
If you are determined to use non-standard macros, call the eeprom_update_xxx() versions.
.
David.

Last Edited: Thu. May 4, 2017 - 06:39 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As seen, my code could only compile when i added all those #define eeprom functions. Before that i had a lot of fails trying different methods, i am not getting into that to keep topic simple and understandable.

 

 Why do you construct a new function (macro)

#define read_eeprom_byte(address) eeprom_read_byte ((const uint8_t*)address)
count=read_eeprom_byte(&birr_byte);

when you can use directly the function from the file eeprom.h ?

count = eeprom_read_byte(&birr_byte);

 

Last Edited: Thu. May 4, 2017 - 08:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I noticed that later and realized the problem was all about the deffinition of the code :( i was using example codes was not paying attention to words thought they are the same. 

Last Edited: Thu. May 4, 2017 - 07:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

89S52 does not have eeprom and I2c but it can be achived through using any pins with bit banging.

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

david.prentice wrote:
I have lost the plot.
Me too.

 

Apart from using #define to rename the avr-libc functions (and lose the "const" modifier in the process!) what possible merit is there to be gained by this exercise? Is this just to give the AVR functions new names that you are already familiar with from 89S52 work?

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

yorem_kastor wrote:

89S52 does not have eeprom and I2c but it can be achived through using any pins with bit banging.

How can you bit-bang EEPROM when it does not exist on that particular chip?

 

Yes,  you can bit-bang I2C with any microcontroller.

Many "8051" controllers do have Flash self-Programming e.g. with a Bootloader like most AVRs.

Some have byte addressable EEPROM like an AVR.

 

I can see that you might find it convenient to have a consistent set of macros for your purposes.   It is not wise to inflict it on others.

 

David.