New eeprom library. Comments please

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

I posted a query here http://www.avrfreaks.com/index.php?name=PNphpBB2&file=viewtopic&t=26005
but it was ignored. Please read it, it's a good introduction to my query.

I am aware of 3 problems with the eeprom support in avr-libc.

1. The SFR addresses are wrong for mega48, mega169, mega329 and the like.
2. eeprom_write_block takes a very long time even for small blocks. (56-Bytes takes approx 0.5s)
3. As discussed here http://www.avrfreaks.com/index.php?name=PNphpBB2&file=viewtopic&t=21371
The eeprom_read functions are not atomic. I.e. An interrupt could potentially mess up EEARL & EEARH.

To solve 2 & 3, I have taken the avr-libc source "eeprom.S" and heavily modified it to create "eeprom1.S" and I've made 2 libraries as follows:

1. libee1C.a for EECR at 0x1C (for Mega128 etc)
2. libee1F.a for EECR at 0x1F (for Mega169, Mega48 etc)

To use this I include the correct library in my Makefile using "LDFLAGS += libee1F.a" for mega169 example. This library overrides the avr-libc functions of the same name.

A zip file (libee.zip) is attached which contains the source, libraries and the Makefile used to build the libraries.

To solve 1 properly is somewhat more difficult.
Let's assume that creating separate builds of avr-libc specific to each micro is not on the cards.
Could then, the eeprom modules be stripped out of the standard "core dependant" builds of avr-libc and be provided as separate "SFR Location" based builds. We might only need the above 2 to start with:

It is then the users responsibility to include the correct library in his Makefile as I did above.
Much better still is that the linker script that invokes the correct avr-libc for each micro could also invoke the correct libeeXX.a.

What do people (especially Eric Weddington & Jörg Wunsch) think ?

Nigel Winterbottom

Attachment(s): 

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

N.Winterbottom wrote:
I posted a query here http://www.avrfreaks.com/index.php?name=PNphpBB2&file=viewtopic&t=26005
but it was ignored. Please read it, it's a good introduction to my query.

I am aware of 3 problems with the eeprom support in avr-libc.

1. The SFR addresses are wrong for mega48, mega169, mega329 and the like.
2. eeprom_write_block takes a very long time even for small blocks. (56-Bytes takes approx 0.5s)
3. As discussed here http://www.avrfreaks.com/index.php?name=PNphpBB2&file=viewtopic&t=21371
The eeprom_read functions are not atomic. I.e. An interrupt could potentially mess up EEARL & EEARH.

To solve 2 & 3, I have taken the avr-libc source "eeprom.S" and heavily modified it to create "eeprom1.S" and I've made 2 libraries as follows:

1. libee1C.a for EECR at 0x1C (for Mega128 etc)
2. libee1F.a for EECR at 0x1F (for Mega169, Mega48 etc)

To use this I include the correct library in my Makefile using "LDFLAGS += libee1F.a" for mega169 example. This library overrides the avr-libc functions of the same name.

A zip file (libee.zip) is attached which contains the source, libraries and the Makefile used to build the libraries.

To solve 1 properly is somewhat more difficult.
Let's assume that creating separate builds of avr-libc specific to each micro is not on the cards.
Could then, the eeprom modules be stripped out of the standard "core dependant" builds of avr-libc and be provided as separate "SFR Location" based builds. We might only need the above 2 to start with:

It is then the users responsibility to include the correct library in his Makefile as I did above.
Much better still is that the linker script that invokes the correct avr-libc for each micro could also invoke the correct libeeXX.a.

What do people (especially Eric Weddington & Jörg Wunsch) think ?

I think that it would do everybody more good if you posted this to the avr-libc-dev mailing list than here.

It would be more useful to change avr-libc, to fix it than it is to create your own libs that would override avr-libc.

We recently added a new volunteer to avr-libc who has been busy fixing a lot of things and we've also been trying to address the EEPROM lib issues regarding getting it on all of the devices. It would be helpful if you could join the discussion there. For example, I wasn't aware of the speed issue (#2 in your list above.)

Quote:
Let's assume that creating separate builds of avr-libc specific to each micro is not on the cards.

Why do you assume this? We've been discussing this very thing recently on the avr-libc-dev list. We know that it needs to be done (especially because of the EEPROM issue), and we've been discussing design issues surrounding this.

We really want the next avr-libc release to help the EEPROM lib issue.

Eric Weddington

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

Better join the avr-libc developers mailing list, and discuss it
there, please.

Our intented final solution for problem #1 will perhaps be something
like you're sketching out, only that we'll probably have the compiler
include the correct device-dependant library. A couple of interim
solutions (that could be quickly applied even to the 1.2 branch)
have been suggested, too.

I'm not sure whether we'd really like to address the interrupt protection,
or rather suggest users have to disable interrupts if needed (which is
probably only a minority of users).

Solving #2 really appears worth the while.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Could you give some examples on how to make the eeprom work on a mega48 with your libery.

I'm very new to the gnu compiler thing.

Regards
Benjamin

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

N.Winterbottom wrote:
2. eeprom_write_block takes a very long time even for small blocks. (56-Bytes takes approx 0.5s)

I agree that the current WINAVR eeprom code is a little sketchy. But it looked to me as if the writeblock function had no unnecessary delays. It looked as if it was polling the proper register as fast as the CPU could poll, and would feed the next byte as soon as the CPU was ready. Is this not true? It takes between 3 and 8.5ms per byte (my 128 takes 8.5ms), so 56 bytes should be no more than 0.476 seconds. This is what you are getting, so I bet that you are getting eeprom writes as fast as they can be done!

I afree that this is abysmally slow, but it seems to be a hardware limitation. Therefore, I was looking for was an interrupt-driven writeblock function. I wrote this for the 128 and posted it to the academy. I got no feedback of bugs (yet) and I have used it successfully for my own uses.

This makes EEPROM block writes painless and nearly invisible. THe problem comes when you want to access what you "wrote" before it is actually written!

-Tony

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

Ok Benjamin,

Give me a few days and I'll compile a version, I think mega48 is slightly different in that you can (or must) perform an eeprom erase and eeprom write separately.

Regards

Nigel

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

You don't need to, but it's one of the few devices where you're able to.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Thanks alot, that would be very helpfull!

Any idea on when a new release of WinAVR, will arrive that fixes these problems?

Regards
Benjamin

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

Nigel came a bit late with his updated library, as Björn Haase already
submitted a well-thought update for the EEPROM library that fits very
well into the existing build framework, and addresses the most
pressing problem (unability to access EEPROM on a number of AVRs).
That has already been integrated into avr-libc-1.2.5, so the next
release of WinAVR will have that fix.

As for speed updates by first looking whether the existing cell needs
to be written at all, there's no timeline yet.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Cool - I can't wait for the next release of WinAVR! What's the timeline on it, EW? I think I remember you saying September once....

[ot]
I have to ask: where'd you get your name dl8dtl? Is there a meaning to it that i'm missing?
[/ot]

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

> where'd you get your name dl8dtl? Is there a meaning to it that i'm missing?

My ham radio call sign. Makes for a good worldwide unique ID everywhere. ;-)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.