What is the best way to read/write XMEGA EEPROM these days...

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

I know there was AVR1315, but it is probably way outdated by now.  Need to read a block of memory from EEPROM (which can likely be done one byte at a time), and also want to be able to write to EEPROM (preferably a page at a time for speed).

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

Doesn't your C compiler have functions for EEPROM support?

For example, avr-gcc/AVR-LibC has:

 

https://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html

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

My compiler is always AS7/gcc.  I'll try those!

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

clawson; I noticed in post #4 of this thread:

 

https://www.avrfreaks.net/forum/...

 

... that eeprom_write_block wasn't thought of to be optimized or intelligent, but simply a loop to eeprom_write_byte, but my experience with it on xmega is much better.  It will write an entire page in 8ms and seems smart enough to do multiple pages that way as well.

 

I can write:

 

32 bytes @ 0 = 8ms

64 bytes @ 0 = 16ms

2 bytes @ 32 = 8ms

2 bytes @ 31 = 16ms

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

Don't use the _write_ functions, use the _update_ functions.

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

Interesting.  I see the benefit in not doing any changes if it is the same at a byte level, but how does the page size affect this?  If I change a byte in a 32 byte page, does it have to erase and flash the entire page?  And in that case, does the update function do much unless all 32 bytes are the same?

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

This brings up what seems to me to be an important question.

 

Have the hardware interface functions, like those involving the EEPROM, been updated in AVR-LibC to work with the new tiny and mega devices? Or, are you expected to "migrate" to START? I can think of various sleep functions, watchdog, bod, and such as well as various things that require protected write.

 

And, of course, there is also FatFs. Has it been "ported" to the new devices?

 

Thanks

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Apr 2, 2019 - 10:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

ka7ehk wrote:
like those involving the EEPROM, been updated in AVR-LibC to work
You can see for yourself...

If you click through on any of those you can see it's update history:

That even lets you see a "diff" so you know what was changed - the last change applied did this (on August 20th 2015):

In the comments you can tell that this support is at least contemporary to the "Xmega E" as it mentions it by name.

 

Of course what you are looking at here is the "open" copy of AVR-LibC. This is not necessarily Atmel's own branch of it (which likely has more recent changes and supports a wider range of new devices). Atmel do publish their changes but it's not as easy to view the activity history as it is with this proper revision control system for the main code tree.

 

ka7ehk wrote:
And, of course, there is also FatFs. Has it been "ported" to the new devices?

FatFs is a bit more "backward" in it's release control in that they simply post new .zip files. So the only way to tell what's changed between one and the next is to pull and unpack two zip files then use a diff tool to compare the two code trees. Anyway, while ff.zip changes quite often they seem to be more relaxed about reissue of ffasmple.zip which is actually the file that has "architecture specific" code. But ffsample.zip does change from time to time and, for example, at one stage they ditched a perfectly working mmc_avr.c that provided SPI support for AVR for a copy that has most of the guts removed with lots of "implement your version here" (which is not very helpful!). At the same time they posted an mmc_usart_avr.c (or something like that) which is a fairly full implementation for "mega" AVR to use the UART in SPI mode. That is fine if you have anything from about mega48/88/168 owards that has the UART-SPI feature but not much use for "legacy" such as mega16/32 where you want to use the real SPI peripheral. 

 

What I haven't seen yet is any form of support for "X" - either Xmega or XTiny - that's presumably because Chan dimply doesn't have an Xmega board to do some experiments on or he's just not interested in bothering. However it does seem that some bits of ffsample.zip may be "user supplied", so if someone have an "X" implementation and wants to email it to Chan then perhaps you'll then find it in the next issue of ffsample.zip ?

 

Personally I've always thought the whole Xmega thing was a bit of an irrelevance because otherwise I would probably have had a go at it and might then have sent my work back to Chan. These new Xtiny which seem now to be the future of AVR are possibly gamechangers so perhaps one day I will do the support for those and contribute it. Of course if anyone else does it first then I'd highly recommend (unless commercial pressure prevents it) that the work is contributed back. This is, after all, the nature of FOSS.

ka7ehk wrote:
Or, are you expected to "migrate" to START?
That's a Microchip/Atmel thing - nothing to do with the open development of avr-gcc/AVR-LibC (though admittedly Atmel-Microchip also contribute to that). 

 

The AVR-LibC support for EEPROM will get Xtiny (or whatever) support when someone contributes it. To contribute to AVR-LibC all you do is sign up for an account on Savannha then add a ticket to the Bugzilla to say what you think is a new feature that should be added and to attach some files that are your changes to the code to be included. The peer developers on the avr-libc-dev mailing list will review your changes (probably suggest better ways to do some of it) and finally your collaboration will merge into the main code tree.

 

The upshot of all that is you get your name on the list at the bottom of this page:

 

https://www.nongnu.org/avr-libc/user-manual/index.html

 

(oh and you have to agree to give all your code a Free-BSD licence - which is the licence quoted there). The following shows the kind of discussion you may end up having when trying to get something added:

 

http://savannah.nongnu.org/patch/?5343

 

Last Edited: Wed. Apr 3, 2019 - 08:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks,  I had no idea how all that works. 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net