Comments on Xmega EEPROM

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

Hello everyone,
mine it's only a consideration, I'd like to know if it is shared by others: Until now it was so easy to access the EEPROM onto ATMega, why ATMEL has complicated all into the XMEGA? It need much more instructions! I think it's terrible!

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

I think that you will find IAR, ImageCraft and CodeVision all handle xmega eeprom quite transparently.

avr-gcc is not clever enough to do it transparently. However you can achieve the same results by simply using appropriate functions or macros.

Regarding the actual eeprom physical operation, the xmega allows more efficient page-writing.

Most use of eeprom is for configuration data. The write speed is not very important. Other applications want efficiency.

YMMV.

David.

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

Thanks David for your answer,
the problem is that I must to buy IAR, ImageCraft and CodeVision while AVRSTUDIO is free.
Second problem is that for now I'm using the ATXMEGA A3 rev.B and there is an Errata about the EEPROM of this chip.
Ok, slowly I'll approach it and I'll try to write my special functions.
Thanks
Davide

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

I have not used the xmega recently.

The earlier avr-gcc did not spport xmega via
You will have to check the current avr-gcc.

Atmel have app notes for the EEPROM. You will just have to verify whether they work with your rev. B chips.

Adapt the app note driver functions for your purposes. Personally, I would try to write macros similar to the ones.

Then your code can run with your functions.
If and when avr-gcc supports the EEPROM, your code will need no changes. You just change the macros to use API's.

I am not proud. If I have a problem adapting the app notes, I look to see how the CodeVision executable achieves it. I have a full licence, but even the evaluation licence will compile for the xmega.

I am sue that Pavel would not mind you tracing the CV eeprom code. You may even buy a full licence! You will certainly reduce your development time by many hours.

David.

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

Thanks David,
I'm trying to adapt the Appnotes but until now without success. I think I've to understand better the Errata because atmel say that A3 revB have some problems on EEPROM.
Wow, this Xmega have many bugs :) Every time I use an Xmega hardware I discover that have some bug and i've to change something to use it.
I was too quick to use the XMEGA, maybe I should wait a year so that Atmel solves all problems. :)
If I'll not be able to find a solution I'll try to install CodeVison and at the end also to buy it if necessary.

Davide

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

Quote:

You will have to check the current avr-gcc.

It does.

C:\WinAVR-20100110\avr\include\avr>grep -i xmega eeprom.h
#elif defined (__AVR_ATxmega16A4__)
#elif defined (__AVR_ATxmega16D4__)
#elif defined (__AVR_ATxmega32A4__)
#elif defined (__AVR_ATxmega32D4__)
#elif defined (__AVR_ATxmega64A1__)
#elif defined (__AVR_ATxmega64A3__)
#elif defined (__AVR_ATxmega64D3__)
#elif defined (__AVR_ATxmega128A1__)
#elif defined (__AVR_ATxmega128A3__)
#elif defined (__AVR_ATxmega128D3__)
#elif defined (__AVR_ATxmega192A3__)
#elif defined (__AVR_ATxmega192D3__)
#elif defined (__AVR_ATxmega256A3__)
#elif defined (__AVR_ATxmega256A3B__)
#elif defined (__AVR_ATxmega256D3__)
    - For Xmega the EEPROM start address is 0, like other architectures.
#elif   defined (__AVR_XMEGA__) && __AVR_XMEGA__

so you just use eeprom_read_*() and eeprom_write_*() just as you would have done on mega or tiny.

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

Wow wow wow, thank you very much, guys!
Now I will try it.
I have used the atmel functions ad works well but are so heavy! they need much program space.
Thank again
Davide

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

It works!
I thought there was a special library for XMEGA instead is the same as other micros. I've done a Mistake inclusion of the library and so AVRstudio said that did not exist.
The correct instruction is

# Include 

Instead my inclusion was:

# Include 

Now it works like any other AVR! :)
I was scared after reading the Atmel Appnotes but I can see that everything is like all AVR.
Thanks a lot!.
David

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

Quote:

The correct instruction is

I think you'll find it is:

#include 

(use / not \ in include paths). The use of this is described in the user manual you know:

http://www.nongnu.org/avr-libc/u...

Notice the title of the page - especially the centred, large font title within the page ;-)

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

Thanks for your Note,
It's strange because my software is compiled well also if I write in the character "\".
May be the "\" character is automatically changed with the "/" from the compiler?
Anyway thanks a lot, from now I will use "/".
Davide

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

For some unknown reason Microsoft chose the backslash as a path separator on their MSDOS file system.

This was presumably so they could be incompatible with properly designed systems like Unix.

All manufacturers worked on the basis of being incompatible. Once they had a customer locked to their 'system' they would be reluctant to buy anything from a competitor.

This continued until the internet showed up how regressive this approach is.

We still live with the 'features'. Most CMD.EXE utilities use a forward-slash for options instead of using a hyphen. And only accept backslashes in paths.
The ported GCC utilities use a forward slash along with most of the civilised world but get upset with an MSDOS colon.

I have always assumed that the Microsoft policy was driven by marketing. As far as I know the actual MSDOS operating system will internally accept a forward-slash as a path separator. And has done from MSDOS 1.0

Because the civilised world has always used the backslash as a form of escape character, you have to use a double back-slash in a conventional C quoted string.

And to keep the MSDOS community happy, the rules get changed for C pre-processor #include "header.h" --- a single backslash is ok.

You will find life easier if you just use a forward slash. The operating system will find your file ok. And it always has done.

Your C Compiler will also work ok too. The compiler writers generally come from a civilised background.

I would be interested to know if Microsoft enforced the backslash in their very first MSDOS C compilers. Can anyone remember?

David.

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

Hi David thanks for your description, now I can understand well.
I'm sorry but I've not experience with MSDOS C Compilers.
Best regards
Davide