Re: [avr-libc-dev] [RFC] New eeprom.h

[Joerg Wunsch]

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.

However, there's still no confirmation whatsoever that the issue was
reproducible at all.  For sure, I could not see it on an ATtiny13 when
trying to reproduce the problem, and the originator could no longer
provide a test case either.  Given that the rewritten routines cause
code bloat (which our users are always picky about) by inlining things
that are currently called functions, I start to question whether the
rewrite this way is really any good.

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:

. we are reading/writing a reserved SPH register on devices that
  don't have SPH

. we are reading/writing a reserved EEARH register on devices that
  don't have it

. our per-architecture (rather than per-device) linker scripts cause
  evil hacks with -Tdata being passed from the compiler in order to
  arrange for the different SRAM start addresses of individual
  devices; this is known to cause collisions with users who want to
  move their entire data segment away from the beginning of SRAM
  (since two contradictionary start addresses for .data are seen by
  the linker)

. initialization routines for SRAM are partially located in libgcc.a,
  and partially in crtXXX.o, depending on the size of SRAM to be
  initialized -- really confusing, if you ask me.

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.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)