XMEGA EEPROM Read and Write

[David_AVD]

The number located at a memory address stored in a pointer is always

8bits if the memory is organised in bytes
16bits if the memory is organised in words
etc.

So you mean the contents of the pointer (not the address of the pointer) for the address argument in that EE function is only 8 bits ?

EDIT: I assumed that the EE was organised as bytes.

[Psi]

I've never used an XMega so i dunno how it structures the memory and the eeprom.

But a pointer always points to a single memory location be it 8bit, 16bit, 32bit etc.. depending on the hardware

eg,

For a cpu that has memory/eeprom stored in bytes...

uint32_t  *MyPointer;

When you use *MyPointer in code you're working with a 32bit number only because the compiler has itself taken care of reading/writing the next 3 bytes ahead of the pointer every time you interact with it.
The pointer still only points to one byte, the first one.


If the memory is stored in words it's the same except a single memory location is 16bit. So the compiler only needs to read ahead in memory by 1 to get all 32bits.
And the pointer still only points to one unit/address, except this time its a word. The first word of the 32bits

[Kremmen]

I've read and Googled, but the answer still eludes me.  Using C (Atmel Studio) with an XMEGA, I'm wanting simply read and write the EEPROM using constant addresses.

The C function eeprom_write_byte takes two parameters; the address to write and the value to write at that address.

But the address parameter is of type uint8_t, so how can it work with more than 256 EE locations?  I'm obviously missing something here.   

Actually, as stated here already, the address parameter is a _pointer_ _to_ uint8_t. The address variable is of pointer type, not uint8_t.
You can simply typecast a constant into a pointer. The EEPROM is mapped form 0 to EEPROM_SIZE-1 and the compiler/linker will handle any address translations for you.
so you should be able to do this:

Code: [Select]

nvm_eeprom_write_byte( (eeprom_addr_t) 0, 0xaa); (assuming you used the Studio ASF NVM driver library). That will write the byte 0xaa at EEPROM address 0.

[David_AVD]

Actually, as stated here already, the address parameter is a _pointer_ _to_ uint8_t. The address variable is of pointer type, not uint8_t.

I understand that the pointer is a 16 bit value that points to a memory location.

When you say "the address parameter is a _pointer_ _to_ uint8_t.", are you saying that the value in the memory location pointed to is an 8 bit type?

[Psi]

Er, no, you have it backwards :-)

Foo is a pointer to a byte. In AVR-GCC all pointers are 16 bit by default, so Foo is actually a uint16_t.

Foo = the pointer, i.e. a memory address stored as a uint16
*Foo = dereferenced pointer, i.e. the value that Foo points to which is a uint8

ops,  sorry guys. 

I really should have refreshed my knowledge of pointers before posting instead of trying to remember.

I've gone back and edited my original posts so they make sense.

And sorry bingo600, i see you also noticed my mistake and i didn't quite realise what you were saying

[dannyf]

When you say "the address parameter is a _pointer_ _to_ uint8_t.", are you saying that the value in the memory location pointed to is an 8 bit type?

When you typecast a literal (let's say 0x0140) to a uint8_t *, all it does is to say that that pointer is a two-byte type pointing to 0x0140. The reason it is uint8_t is to make it easier to increment the pointer in the future, as the data you are writing to it is a uint8_t (byte) type.

If you were to write a word or a double word, you would then typecast 0x0140 to a pointer to a word or double word, so the same increment code would work, regardless of the data type to be written to eeprom.

Again, all you need to remember is that regardless of the data it points to, the pointer is always a multi-byte type.

[madires]

Actually, as stated here already, the address parameter is a _pointer_ _to_ uint8_t. The address variable is of pointer type, not uint8_t.

I understand that the pointer is a 16 bit value that points to a memory location.

When you say "the address parameter is a _pointer_ _to_ uint8_t.", are you saying that the value in the memory location pointed to is an 8 bit type?

I think you got it :-)

[westfw]

I think you're all making it much more complicated than it needs to be.
eeprom_writes_byte() reads a byte into chunk of memory; therefore its destination argument is a pointer to a byte.
There are similar eeprom_write_word() and eeprom_write_dword() that take pointers to uint_16 and uint_32.
This way you can seamlessly do things like:

Code: [Select]

typedef struct chartdata_ {  // chart recorder data record.
  uint32_t timestamp;
  uint8_t temperature;
  uint8_t humidity;
} chartdata_t;

chartdata_t *logfile = (chartdata_t *)(0);  // logfile starts at the beginning of eeprom
  :
  eeprom_write_dword(&logfile[n]->timestamp, now);
  eeprom_write_byte(&logfile[n]->temperature, currenttemp);
Yes, since eeprom and data have separate address spaces, you can screw yourself over by using the pointer to point to the wrong kind of memory.

[David_AVD]

The function definitions still look weird to me, but I'm sure it will click totally one day.  For now I'm happy knowing how to use them, even if I don't know how they operate internally.

Where does one find the source for those functions?  The header file is easy to find, but there doesn't appear to be a matching C file?

[dannyf]

AS is based on win-avr so you should be able to download the source if you google.

[Psi]

There's no real need to search/download it, the library and source is in the AS folders somewhere.
Searching for a copy online is probably faster though.

Finding the core functions can be a bit tricky in avr-gcc, due to how they all fit together and provide support for all micros with a single h file.

[dannyf]

Atmel like to include small macro-like functions in their header files

Everyone does that - it makes the code a lot easier to port and understand.

[David_AVD]

The function definitions still look weird to me, but I'm sure it will click totally one day.  For now I'm happy knowing how to use them, even if I don't know how they operate internally.

Where does one find the source for those functions?  The header file is easy to find, but there doesn't appear to be a matching C file?

In Atmel Studio you can just right click on the function and select "Goto Implementation". A lot of those functions are only actually defined in the header file.

I know how to get to the header file, but that doesn't show me the nuts and bolts of the actual implementation.   

[westfw]

http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/libc/misc/eerd_byte.S?root=avr-libc&view=markup

As Psi said, it's rather obscured by the bits that allow the same source tree to support so many chips and sub-architectures.   Note that avr-libc is not maintained by Atmel; it's an open source software thing (and they look a bit aggressively non-gnu as well, which is a good thing for embedded software.)  I doubt that the source is included in AS.  For Xmega, I think there are similar functions as part of "Atmel Software Foundation" ( http://asf.atmel.com/docs/2.9.0/xmegaa/html/group__nvm__eeprom__group.html ), and THAT source might be included as part of AS.

Older versions of avr-libc (for instance, the version shipped with Arduino) actually implement eeprom_read_byte() in the .h file, as an inline function.

Finding the core functions can be tricky...

Allow me to introduce y'all to the "ID Database" utility: http://www.gnu.org/software/idutils/manual/idutils.html
This is sort-of a bunch of those IDE "find implementation" capabilities in a zippy little command-line utility.
So you pull your svn copy of avr-libc/trunk, connect to the top-level directory and say "mkid", and it builds a database of all the identifiers in all the source files in all the directories (recursively.)  Then you can search and gets lists of files that contain the identifier, and etc.  Combined with things like eTags, this is one of the things that prevents old-timers from getting excited about "modern IDEs."

[happylex]

I've never used an XMega so i dunno how it structures the memory and the eeprom.

But a pointer always points to a single memory location be it 8bit, 16bit, 32bit etc.. depending on the hardware

Ok, so the XMEGA A is capable of using 32 bit pointers, since this can access all my megabytes of external SDRAM:

Code: [Select]


uint32_t my_own_pointer= 0x00010000; // > 0xFFFF, and thus > 16 bit :-)
uint8_t value = 5;
*(uint8_t *)my_own_pointer = value;

Great this works, but then there is the point mentioned by mojo-chan.

In AVR-GCC all pointers are 16 bit by default

Yes I found out. How difficult can it be? There was a statement from AVR that 16 bit pointers will not be supported till GCC 4.7. Now I am already using 4.8.2 and still it uses 16 bit pointers.

I couldn't find the source indeed, or else I would have changed the uint16_t into uint32_t. (Or am I missing something complex here?)

So I should write my own allocate() bla bla bla? I am usin three arrays to divide my SDRAM in sectors. Structures can then access the arrays to find a free sector. The speed of my software is going down a lot this way! And also my flash memory and valuable real life time. Moreover, I am not using my RAM efficiently with free memory in every sector.

How do I solve the speed and efficiency issues? It must be possible, since the custom '32 bit pointer' works.

Edit: Here is an old version of the AVR-LIBC with a malloc.c I could addapt  http://download.savannah.gnu.org/releases/avr-libc/
However, if I use my custom pointer in an existing function it converts it to 16 bit.