AVRFreaks.net

uint8_t eeprom_read_byte (const uint8_t *addr)
void eeprom_write_byte (uint8_t *addr, uint8_t value)
uint16_t eeprom_read_word (const uint16_t *addr)
void eeprom_write_word (uint16_t *addr, uint16_t value)
void eeprom_read_block (void *pointer_ram, const void *pointer_eeprom, size_t n)
void eeprom_write_block (void *pointer_eeprom, const void *pointer_ram, size_t n)

My second tutorial. This tutorial will center around GCC's handling of data stored into EEPROM memory.

Do you plan to publish a pdf version of this fine tutorial?

Pop

In <avr/eeprom.h>, eeprom_read_byte and eeprom_write_byte use a u08 pointer for the address. Doesn't this mean you can only access 256 bytes in the EEPROM? What about the remaining 1024-256 = 968 EEPROM bytes in a ATmega32?

This is a problem when dealing with pointers to the AVR's flash memory, since in some AVRs this overflows an int. Because of this, pointers to flash addresses are still two bytes in size but the pointer is word rather than byte aligned, so an increase of one in the pointer's address corresponds to a jump of two bytes.

You can reply me at my e-mail address
aliasgherman@yahoo.com

Our second variable is an int, so we need the eeprom_read_word routine:

Cheers John!

I sadly don't have the talent to write a book of my own - Smokey possesses what I do not. I've become quite adept at writing specific tutorials, but I just can't seem to "glue" them all together into one big book.
...

Sounds like you probably need to set the EESAVE fuse in your AVR. Otherwise each time you put a new program into it the EEPROM is being wiped when the "chip erase" is performed.

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.

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

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

#include <avr/interrupt.h>
#include <avr/io.h>
#include <avr/eeprom.h>

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;
...
}

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

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 make sure the fuse is set where the eeprom isn't overwritten anymore.

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.

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?

let's say at location 46