[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avr-libc-dev] [RFC] New eeprom.h
From: |
Weddington, Eric |
Subject: |
RE: [avr-libc-dev] [RFC] New eeprom.h |
Date: |
Tue, 29 Jan 2008 18:33:56 -0700 |
> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of Joerg Wunsch
> Sent: Tuesday, January 29, 2008 2:17 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
>
> As Weddington, Eric wrote:
>
> > > And the old code is not disabling interrupts during eeprom
> > > write... which is no good! Maybe this was the problem of the
> > > report for the tiny13?
>
> > No, the old code is disabling the interrupts for the write
> > routines. You have to look in the libc/misc/eeprom.S file in the
> > avr-libc source.
>
> Sure, I'm now almost convinced that we have to move to a per-device
> library model some day. This will really become a major step though
> (affecting the entire toolchain, binutils, compiler, and library), but
> will resolve many of these things:
>
<snip>
> I don't see much point in picking only one of these, and trying to
> craft a reimplementation for it (just because it /could/ be resolved
> by entirely reimplementing it within a header file) when all these
> things eventually have to be resolved anyway.
Joerg, we've gone over this before.
- Yes, we need to move per-device libs *someday*.
- This requires a lot of time and work.
- I need to fix a GCC bug, support *all* AVR device variants with the
EEPROM API, *and support future AVR devices that will be coming out
within a month*.
- No one has yet to volunteer to change all of avr-libc to per-device
libs
- You are working on avr-libc on a volunteer basis; I doubt you have the
time to work on per-device libs and get them working within 2 weeks.
- Therefore, I've chosen the path of least resistance and I'm modifying
<avr/eeprom.h>
- We have precedence in having inline macros that are tailored per
device: pgmspace.h, sleep.h, wdt.h. This just adds another one.
I know that the changes causes the code size to increase. The code *has
to work correctly* before there can be any focus on optimization. At
this point, the EEPROM API implementation causes a GCC bug (internal
compiler error) and IIRC doesn't even work for 2 AVR devices. This is
bad. To add to this, I need the EEPROM API to work for these future
devices that are coming out in a month. You have the datasheets to these
devices, which includes how the EEPROM operates in those devices.
This is the whole reasoning for this change. Since I don't expect anyone
else to volunteer to help, I took it upon myself to make the necessary
changes. Those changes have some problems. I submitted those changes for
feedback from the list.
Eric Weddington
- RE: [avr-libc-dev] [RFC] New eeprom.h, (continued)
- RE: [avr-libc-dev] [RFC] New eeprom.h, Wouter van Gulik, 2008/01/27
- RE: [avr-libc-dev] [RFC] New eeprom.h, Weddington, Eric, 2008/01/27
- Message not available
- RE: [avr-libc-dev] [RFC] New eeprom.h, Weddington, Eric, 2008/01/27
- Re: [avr-libc-dev] [RFC] New eeprom.h, Joerg Wunsch, 2008/01/28
- [avr-libc-dev] Re: [RFC] New eeprom.h, Ivan Shmakov, 2008/01/28
Re: [avr-libc-dev] [RFC] New eeprom.h, Preston Wilson, 2008/01/28
- RE: [avr-libc-dev] [RFC] New eeprom.h, Weddington, Eric, 2008/01/28
- Re: [avr-libc-dev] [RFC] New eeprom.h, Wouter van Gulik, 2008/01/29
- RE: [avr-libc-dev] [RFC] New eeprom.h, Weddington, Eric, 2008/01/29
- Re: [avr-libc-dev] [RFC] New eeprom.h, Joerg Wunsch, 2008/01/29
- RE: [avr-libc-dev] [RFC] New eeprom.h,
Weddington, Eric <=
- Re: [avr-libc-dev] [RFC] New eeprom.h, Wouter van Gulik, 2008/01/30
- RE: [avr-libc-dev] [RFC] New eeprom.h, Weddington, Eric, 2008/01/30
Re: [avr-libc-dev] [RFC] New eeprom.h, Wouter van Gulik, 2008/01/30