On Sunday 02 March 2008 04:25, Weddington, Eric wrote:
I'm ok to commit to HEAD if these conditions are met:
- builds for all current AVR devices that have EEPROM
- fixes avr-libc bug #21410
- fixes gcc bug #31644
Hi Eric, hi all.
It is commited into CVS HEAD.
. Avr-libc bug #21410 is fixed.
Shaun Jackman wrote:
On Fri, Feb 29, 2008 at 12:43 PM, Rick Altherr [EMAIL PROTECTED] wrote:
Many linkers will coalesce copies of the same function from multiple
object files. I'm not familiar with binutils enough to know if it
does or not.
In the standard use of avr-libc with gcc and
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of David Brown
Sent: Saturday, March 01, 2008 4:04 PM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
Shaun Jackman wrote:
In the standard use of avr-libc
On Thu, Feb 28, 2008 at 11:48 AM, Rick Altherr [EMAIL PROTECTED] wrote:
...
There might be an intermediate ground where the core functionality could be
written as a set of inline functions. The library code could just make a
non-inline function that calls the inline routine. In the header,
On Fri, Feb 29, 2008 at 11:29 AM, Rick Altherr [EMAIL PROTECTED] wrote:
If you look at Dmitry's header, you'll see that you pass the address
of eeprom_read_byte or eeprom_write_byte.
How many versions of eeprom_read_byte and eeprom_write_byte are there?
I haven't seen Dmitry's header. Is it
On Feb 29, 2008, at 11:41 AM, Shaun Jackman wrote:
On Fri, Feb 29, 2008 at 11:29 AM, Rick Altherr [EMAIL PROTECTED]
wrote:
If you look at Dmitry's header, you'll see that you pass the address
of eeprom_read_byte or eeprom_write_byte.
How many versions of eeprom_read_byte and
On Feb 29, 2008, at 12:32 PM, Shaun Jackman wrote:
On Fri, Feb 29, 2008 at 11:46 AM, Rick Altherr [EMAIL PROTECTED]
wrote:
It was on the mailing list. There are only one of each, but they are
inline functions defined in the header so they will be correct for
every device. The address of
On Fri, Feb 29, 2008 at 12:43 PM, Rick Altherr [EMAIL PROTECTED] wrote:
Many linkers will coalesce copies of the same function from multiple
object files. I'm not familiar with binutils enough to know if it
does or not.
In the standard use of avr-libc with gcc and binutils, you will get
On Feb 29, 2008, at 3:00 PM, Shaun Jackman wrote:
On Fri, Feb 29, 2008 at 12:43 PM, Rick Altherr [EMAIL PROTECTED]
wrote:
Many linkers will coalesce copies of the same function from multiple
object files. I'm not familiar with binutils enough to know if it
does or not.
In the standard use
On Fri, Feb 29, 2008 at 3:05 PM, Rick Altherr [EMAIL PROTECTED] wrote:
The example I am most familiar with is text coalescing with Apple's
ld. Sadly, I can't give out details on how it works nor can I provide
source.
Alright. Back to EEPROM functions...
When using binutils and gcc,
Hi all.
Rick, thank you for fine explanation of 'project 1'!
Now I have include this project into my local Avr-libc copy,
build and test. Now I am busy to add DOXYGEN.
The list of changes is:
New variant of EEPROM functions: inline byte procedures and library
multibyte
Hi all,
I like the rewrite. It looks good. My only concern is possibly code
size. I haven't tested it, but it looks as though
__eeprom_write_byte_address_word should generate about 10
instructions, which means __eeprom_write_dword_address_word will
generate 40 instructions, or 80 bytes. It seems
-Original Message-
From: Shaun Jackman [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 28, 2008 7:45 AM
To: Weddington, Eric
Cc: Wouter van Gulik; avr-libc-dev@nongnu.org; Joerg Wunsch
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
Hi all,
I like the rewrite. It looks
Hello Eric,
I agree: correct code first, optimization second. I am not complaining
that eeprom_write_dword is an 80 byte function. I agree that
reading/writing a 32-bit word will take a bunch of code on an AVR. I
am arguing that it is a design flaw that eeprom_write_dword takes 80
bytes *per
On Feb 28, 2008, at 6:53 AM, Weddington, Eric wrote:
-Original Message-
From: Shaun Jackman [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 28, 2008 7:45 AM
To: Weddington, Eric
Cc: Wouter van Gulik; avr-libc-dev@nongnu.org; Joerg Wunsch
Subject: Re: [avr-libc-dev] [RFC] New
The solution you're recommending is possible, and in fact probably the
only solution with the current architecture. The only catch is that it
requires one device-specific function for each location of the EEPROM
registers. How many EEPROM register locations are there across the AVR
product line?
On Feb 28, 2008, at 10:23 AM, Shaun Jackman wrote:
The solution you're recommending is possible, and in fact probably the
only solution with the current architecture. The only catch is that it
requires one device-specific function for each location of the EEPROM
registers. How many EEPROM
Well, your suggestion would solve the code size issue, but the
function wouldn't be particularly fast if all the EEPROM register
accesses were indirectly addressed. In most applications, EEPROM
writes aren't usually time critical; although I can imagine that
exceptions exist.
Do the EEPROM
On Feb 28, 2008, at 9:23 PM, Dmitry K. wrote:
Hi all.
I like the rewrite. It looks good. My only concern is not
only code size. There is a second question: this functions
are not a normal C functions. That is:
. No argument type control at compile time. For expamle,
the expressions like
Hi Wouter and All,
I took your rewrite and had to fix a few things. I also added new 32-bit
integer read/write routines per Shaun's feature request (tracker on
avr-libc). Everything finally tested correctly.
I can finally say this now: Besides all of the other reasons I mentioned
for changing
: [avr-libc-dev] [RFC] New eeprom.h
Hi Wouter and All,
I took your rewrite and had to fix a few things. I also added
new 32-bit
integer read/write routines per Shaun's feature request (tracker on
avr-libc). Everything finally tested correctly.
I can finally say this now: Besides all
Weddington, Eric schreef:
Mainly because this is a total rewrite of the implementation. The API
(interface) stays the same. I'm certainly fine with putting the old
copyrights back on.
I thought the address thingy was taken from Bjoern Haasse's
implementation. So that's why I thought he
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
Weddington, Eric schreef:
Bah! Trying again.
Thanks for everyone's patience.
Eric Weddington
So I got the header and my first consideration in is the copyright...
All previous contributers are now gone? I hope this is WorkInProgress.
Second why all these hideous define with there
Joerg Wunsch wrote:
As Weddington, Eric wrote:
I did not receive any attached source in any of the email in this
thread including this last email from you.
Trying again. Let me know if it's not attached this time.
Not there. Do you remember that the list processor strips attachments
Or inline functions defined in a header file.
Sheesh. You guys are making comments about *how* I implemented the
functionality, not if it *actually works*.
Well I would, if I knew where to get the sources... There not on the list,
not in the avr-libc bug report. So where can I find
-Original Message-
From: Wouter van Gulik [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 27, 2008 2:00 PM
To: Weddington, Eric; 'Rick Altherr'
Cc: avr-libc-dev@nongnu.org
Subject: RE: [avr-libc-dev] [RFC] New eeprom.h
Or inline functions defined in a header file
-Original Message-
From: Preston Wilson [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 27, 2008 7:58 PM
To: Weddington, Eric
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
Attached is my latest source.
I did not receive any attached source in any of the email
As Weddington, Eric wrote:
I did not receive any attached source in any of the email in this
thread including this last email from you.
Trying again. Let me know if it's not attached this time.
Not there. Do you remember that the list processor strips attachments
of type
Anton Erasmus wrote:
On 15 Jan 2008 at 20:05, Weddington, Eric wrote:
snip
I have not seen the eeprom.h file, so my comments might be totally inapropriate.
Wouldn't it be better to use static inline functions in stead of macros ? One
gets
the same advantages of macros, but without many of
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of David Brown
Sent: Wednesday, January 16, 2008 3:57 AM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
In general, I agree with you - static inline functions
Weddington, Eric wrote:
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of David Brown
Sent: Wednesday, January 16, 2008 3:57 AM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
In general, I agree with you - static
-Original Message-
From: Michael Hennebry [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 16, 2008 10:24 AM
To: Weddington, Eric
Cc: David Brown; avr-libc-dev@nongnu.org
Subject: RE: [avr-libc-dev] [RFC] New eeprom.h
On Wed, 16 Jan 2008, Weddington, Eric wrote:
- One
Weddington, Eric wrote:
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of David Brown
Sent: Wednesday, January 16, 2008 10:01 AM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
Weddington, Eric wrote:
No, no - I
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of David Brown
Sent: Wednesday, January 16, 2008 12:34 PM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
Weddington, Eric wrote:
-Original Message
:[EMAIL PROTECTED]
org] On Behalf Of David Brown
Sent: Wednesday, January 16, 2008 10:01 AM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
Weddington, Eric wrote:
No, no - I think you misunderstood my post. I was responding
to Anton's
suggestion of using more static
-Original Message-
From: Rick Altherr [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 16, 2008 2:41 PM
To: Weddington, Eric
Cc: David Brown; avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
Or inline functions defined in a header file.
Sheesh. You
-
From: Rick Altherr [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 16, 2008 2:41 PM
To: Weddington, Eric
Cc: David Brown; avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
Or inline functions defined in a header file.
Sheesh. You guys are making comments about *how* I
Hi All,
Because of an avr-libc bug (#21410), a GCC bug (#31644), and IIRC, the
fact that the EEPROM API does not work on at least 2 AVR devices, I have
taken a stab at rewriting the EEPROM API. The interface has been kept
the same, but instead of library functions, it has been rewritten as
macros
On 15 Jan 2008 at 20:05, Weddington, Eric wrote:
Hi All,
Because of an avr-libc bug (#21410), a GCC bug (#31644), and IIRC, the
fact that the EEPROM API does not work on at least 2 AVR devices, I have
taken a stab at rewriting the EEPROM API. The interface has been kept
the same, but
40 matches
Mail list logo
