Re: [avr-libc-dev] [RFC] New eeprom.h
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. . GCC bug #31644 is workarounded. . Build for all current devices: I began to check this, but not *all*, only for devices, that are present in my system: binutils-2.18, avr-gcc 3.3.6 - 4.2.3. Before commit to CVS 1_6 I want to get answer for a write function question: I will post it separatly. Thanks, Dmitry. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 binutils, you will get one copy of the function per object file that uses it. For my programs at least, I would not see that as a problem - I always have eeprom access from a single module anyway. While other people might not be as strict as that, I don't think it is common to have eeprom access from many files. mvh., David ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [RFC] New eeprom.h
-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 with gcc and binutils, you will get one copy of the function per object file that uses it. For my programs at least, I would not see that as a problem - I always have eeprom access from a single module anyway. While other people might not be as strict as that, I don't think it is common to have eeprom access from many files. I tend to agree. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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, we could then provide 2 sets of API: one set of inline functions that call the internal routine and a set of macros that call the non-inline function. That should allow the end user to choose between code size and speed. ... Which approach do you plan on using for the non-inline functions? Passing the address of the EEPROM registers as an argument? Cheers, Shaun ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 in Savannah or on this mailing list? Cheers, Shaun ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 eeprom_write_byte are there? I haven't seen Dmitry's header. Is it in Savannah or on this mailing list? Cheers, Shaun 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 that inline function is passed to the library routines. That will cause a single copy of the inline function to be generated as a true function in the binary so the address of it can be found. -- Rick Altherr [EMAIL PROTECTED] He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Slashdot signature smime.p7s Description: S/MIME cryptographic signature ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 that inline function is passed to the library routines. That will cause a single copy of the inline function to be generated as a true function in the binary so the address of it can be found. Not exactly. It will generate a single copy of the inline function per object file in which it's used -- unless very tricksy linker magic is used, which is possible, I believe, but not typical. Still, I think one copy of eeprom_read_byte and eeprom_write_byte per object file is a reasonable compromise considering the technical challenges. Cheers, Shaun 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. -- Rick Altherr [EMAIL PROTECTED] He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Slashdot signature smime.p7s Description: S/MIME cryptographic signature ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 one copy of the function per object file that uses it. It would be a useful feature to eliminate duplicate copies of a function across multiple object files, but I do not know of one. Can you give an example of a linker that does do this? This feature would require cooperation from the compiler as well. I believe if you compile using GCC with the `-ffunction-sections' option to place each function in its own section, the linker then would then have enough information to be able to accomplish the above, but this approach certainly isn't typical. Cheers, Shaun ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 of avr-libc with gcc and binutils, you will get one copy of the function per object file that uses it. It would be a useful feature to eliminate duplicate copies of a function across multiple object files, but I do not know of one. Can you give an example of a linker that does do this? This feature would require cooperation from the compiler as well. I believe if you compile using GCC with the `-ffunction-sections' option to place each function in its own section, the linker then would then have enough information to be able to accomplish the above, but this approach certainly isn't typical. Cheers, Shaun 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. -- Rick Altherr [EMAIL PROTECTED] He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Slashdot signature smime.p7s Description: S/MIME cryptographic signature ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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, passing the inline eeprom_read_byte and eeprom_write_byte functions to the library functions will generate one copy of the byte function per object file in which it's used. That seems like a reasonable compromise of speed/space to me given the technical challenges. What's everyone else's opinion? Cheers, Shaun ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 envelopes. * include/avr/eeprom.h: Rewrite on the base of project by Eric B. Weddington. * libc/misc/eeprom.S: Remove file. * libc/misc/ee_rb.S: Remove file. * libc/misc/ee_rblk.S: Remove file. * libc/misc/ee_rw.S: Remove file. * libc/misc/ee_wb.S: Remove file. * libc/misc/ee_wblk.S: Remove file. * libc/misc/ee_ww.S: Remove file. * libc/misc/eerd_block.c: New file. * libc/misc/eerd_dword.c: New file. * libc/misc/eerd_word.c: New file. * libc/misc/eewr_block.c: New file. * libc/misc/eewr_dword.c: New file. * libc/misc/eewr_word.c: New file. * libc/misc/Files.am: Remove old sources, add new. * libc/misc/Makefile.am: Include $(misc_a_c_sources) to EXTRA_DIST. * libc/misc/Rules.am: Remove rules to build chip-specific objects. * tests/simulate/avr: New directory (for AVR-specific functions). * tests/simulate/avr/eeprom-1.c: New file. Eric, I wait yours approval to commit into CVS HEAD. Thanks, Dmitry. P.S. My misprint uint16_t -- uint32_t is fixed. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 to me that an 80 byte
function should not be inlined. I have been following the history of
this issue, and I know the reason these functions are inlined.
However, I'm not sure that the end result, namely an 80 byte inline
function, is valid.
It is possible for the application to provide it's own not inlined copy:
void eeprom_write_dword_not_inlined(uint16_t addr, uint32_t value)
{
eeprom_write_dword(addr, value);
}
which is a reasonably straight forward workaround. It just seems a bit
clunky. Since I don't have any solutions or suggestions, I'm
definitely not objecting to the rewrite being checked in. The rewrite
fixes otherwise unresolvable issues.
Cheers,
Shaun
On Wed, Feb 27, 2008 at 5:54 PM, Weddington, Eric
[EMAIL PROTECTED] wrote:
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 the EEPROM routines, one of the other reasons to change
these routines is becase of the new XMEGA chips that have been
announced. Because avr-libc does not yet have a design of library per
architecture, changing the EEPROM API implementation to be restricted to
just a header file (no compiled code in a library) allows us to modify
the implementation per device. This is necessary to fix the
implementation for a couple of other AVR devices (where they are
currently broken) and also to implement some of the new ways to access
the EEPROM in the ATxmega128A1 and ATxmega64A1.
The attached eeprom.h file is the first step in this.
Joerg, what is your opinion about adding this to the 1.6 branch? Or
would you rather it be restricted to HEAD? If it is restricted to HEAD,
then I lean towards cutting a 1.8.0 release sooner rather than later.
Any other thoughts? I would like to get this committed sometime soon.
Eric Weddington
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [RFC] New eeprom.h
-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 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 to me that an 80 byte
function should not be inlined. I have been following the history of
this issue, and I know the reason these functions are inlined.
However, I'm not sure that the end result, namely an 80 byte inline
function, is valid.
It is possible for the application to provide it's own not
inlined copy:
void eeprom_write_dword_not_inlined(uint16_t addr, uint32_t value)
{
eeprom_write_dword(addr, value);
}
which is a reasonably straight forward workaround. It just seems a bit
clunky. Since I don't have any solutions or suggestions, I'm
definitely not objecting to the rewrite being checked in. The rewrite
fixes otherwise unresolvable issues.
Hi Shaun,
Thanks for your response!
Your last sentence is really the crux of the matter. If regular
functions are provided then we're back to where we started and it
doesn't resolve the avr-libc bugs (non-working routines on certain
devices). If the functions are provided in the header file, and they are
non-inline, then there is a strong potential for duplicate function
names at the link stage. Without going to lib-per-device design, the
only solution available has to be in a header file, whether inline
assembly, or inline C functions.
The AVR is not terribly efficient at moving around 32-bit integers, or
greater, so I would expect that a read/write dword would be large to a
certain degree.
Again, it comes down to having correct code first, and then optimized
code (for size) later.
Eric
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 call*. It may be a documented, reasoned design flaw, but it is a inarguable design flaw nonetheless. Cheers, Shaun On Thu, Feb 28, 2008 at 6:53 AM, Weddington, Eric [EMAIL PROTECTED] wrote: Hi Shaun, Thanks for your response! Your last sentence is really the crux of the matter. If regular functions are provided then we're back to where we started and it doesn't resolve the avr-libc bugs (non-working routines on certain devices). If the functions are provided in the header file, and they are non-inline, then there is a strong potential for duplicate function names at the link stage. Without going to lib-per-device design, the only solution available has to be in a header file, whether inline assembly, or inline C functions. The AVR is not terribly efficient at moving around 32-bit integers, or greater, so I would expect that a read/write dword would be large to a certain degree. Again, it comes down to having correct code first, and then optimized code (for size) later. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 eeprom.h
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 to me that an 80 byte
function should not be inlined. I have been following the history of
this issue, and I know the reason these functions are inlined.
However, I'm not sure that the end result, namely an 80 byte inline
function, is valid.
It is possible for the application to provide it's own not
inlined copy:
void eeprom_write_dword_not_inlined(uint16_t addr, uint32_t value)
{
eeprom_write_dword(addr, value);
}
which is a reasonably straight forward workaround. It just seems a
bit
clunky. Since I don't have any solutions or suggestions, I'm
definitely not objecting to the rewrite being checked in. The rewrite
fixes otherwise unresolvable issues.
Hi Shaun,
Thanks for your response!
Your last sentence is really the crux of the matter. If regular
functions are provided then we're back to where we started and it
doesn't resolve the avr-libc bugs (non-working routines on certain
devices). If the functions are provided in the header file, and they
are
non-inline, then there is a strong potential for duplicate function
names at the link stage. Without going to lib-per-device design, the
only solution available has to be in a header file, whether inline
assembly, or inline C functions.
The AVR is not terribly efficient at moving around 32-bit integers, or
greater, so I would expect that a read/write dword would be large to a
certain degree.
Again, it comes down to having correct code first, and then optimized
code (for size) later.
Eric
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
While it's possibly a bit late for this option, you could write device-
specific methods with different function names. Then, the header file
can defined a macro that expands the generic function name that gets
used in the source code to one of the specific methods. That should
result in a larger library overall, but only the function used by the
device will actually be pulled into the final binary. It would
prevent inlining any code at all.
--
Rick Altherr
[EMAIL PROTECTED]
He said he hadn't had a byte in three days. I had a short, so I split
it with him.
-- Slashdot signature
smime.p7s
Description: S/MIME cryptographic signature
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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? Cheers, Shaun On Thu, Feb 28, 2008 at 9:53 AM, Rick Altherr [EMAIL PROTECTED] wrote: While it's possibly a bit late for this option, you could write device- specific methods with different function names. Then, the header file can defined a macro that expands the generic function name that gets used in the source code to one of the specific methods. That should result in a larger library overall, but only the function used by the device will actually be pulled into the final binary. It would prevent inlining any code at all. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 register locations are there across the AVR product line? Cheers, Shaun On Thu, Feb 28, 2008 at 9:53 AM, Rick Altherr [EMAIL PROTECTED] wrote: While it's possibly a bit late for this option, you could write device- specific methods with different function names. Then, the header file can defined a macro that expands the generic function name that gets used in the source code to one of the specific methods. That should result in a larger library overall, but only the function used by the device will actually be pulled into the final binary. It would prevent inlining any code at all. Well, it would require one function per unique EEPROM register location. In fact, even that isn't true. It requires one function per unique code sequence required. The register locations could be arguments to the function that are supplied in the header's generic macro. -- Rick Altherr [EMAIL PROTECTED] He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Slashdot signature smime.p7s Description: S/MIME cryptographic signature ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 registers always fall in the same locations from a single base offset address? Cheers, Shaun On Thu, Feb 28, 2008 at 11:48 AM, Rick Altherr [EMAIL PROTECTED] wrote: Well, it would require one function per unique EEPROM register location. In fact, even that isn't true. It requires one function per unique code sequence required. The register locations could be arguments to the function that are supplied in the header's generic macro. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 eeprom_write_block (Apple, s, sizeof(Apple)); eeprom_write_dword (3.14159, 0); do not type any warnings. Actually, eeprom_write_dword would give type warnings. You are correct about eeprom_write_block, however. . It is impossible to get address of eeprom function to inderect call. It all depends on which call you are making. That is one of the problems I see with the current header. Some of the calls are real functions, albeit inlined, that you can take an address of, others are just blocks. Even with the inlined code, you can take the address of it, but that causes it to not be inlined by the compiler anymore. You'll still get the correct addresses of the registers needed, but only one copy of the code will be included. . Avr-gcc can not to optimize the EEPROM reading, like it can do this in case of SRAM. Given that these are all inlined functions or macros resulting in blocks, the compiler _should_ be able to optimize the calls to them. The blocks are no question, but the inlined functions could confuse the optimizer. Summarizes the Eric's eeprom.h and all ideas from above (Wouter, Shaun, Rick) I have prepare two projects. Project 1. It is a very simple: use an inderect calls (not indirect registers). It is eliminates big space expense and notes above: eeprom functions are pure functions. It is needed to add only 6 very short functions into Avr-libc. At this moment this project is ready for test. I can to commite at this week-end. Excellent. The indirect call cuts down the overhead of being indirect considerably while still reducing the overall code size. Project 2. Use a set of high quality asm functions. This is not only space effective, also it is fast. Now the set of funtions is ready for test. Some efforts are needed to include into Avr-libc: I am not happy to do this manualy. I'm not certain which functions you would replace with asm. All of the functions (both inline and in avr-libc) seem simple enough that the compiler will do a reasonable job with them. The only optimization I can see would be to eliminate the overhead of pushing stack frames. Ultimately it would remove 2 stack setup/teardown pairs. In attach the eeprom.h of project 1. Opinions? Project 1 looks great. Simple, space efficient, and effective. Thanks, Dmitry. eeprom.h___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev -- Rick Altherr [EMAIL PROTECTED] He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Slashdot signature smime.p7s Description: S/MIME cryptographic signature ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [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 of the other reasons I mentioned for changing the EEPROM routines, one of the other reasons to change these routines is becase of the new XMEGA chips that have been announced. Because avr-libc does not yet have a design of library per architecture, changing the EEPROM API implementation to be restricted to just a header file (no compiled code in a library) allows us to modify the implementation per device. This is necessary to fix the implementation for a couple of other AVR devices (where they are currently broken) and also to implement some of the new ways to access the EEPROM in the ATxmega128A1 and ATxmega64A1. The attached eeprom.h file is the first step in this. Joerg, what is your opinion about adding this to the 1.6 branch? Or would you rather it be restricted to HEAD? If it is restricted to HEAD, then I lean towards cutting a 1.8.0 release sooner rather than later. Any other thoughts? I would like to get this committed sometime soon. Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [RFC] New eeprom.h
Attachment problems. Trying again...
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Weddington, Eric
Sent: Wednesday, February 27, 2008 6:55 PM
To: Wouter van Gulik
Cc: avr-libc-dev@nongnu.org; Joerg Wunsch; Shaun Jackman
Subject: RE: [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 of the other reasons
I mentioned
for changing the EEPROM routines, one of the other reasons to change
these routines is becase of the new XMEGA chips that have been
announced. Because avr-libc does not yet have a design of library per
architecture, changing the EEPROM API implementation to be
restricted to
just a header file (no compiled code in a library) allows us to modify
the implementation per device. This is necessary to fix the
implementation for a couple of other AVR devices (where they are
currently broken) and also to implement some of the new ways to access
the EEPROM in the ATxmega128A1 and ATxmega64A1.
The attached eeprom.h file is the first step in this.
Joerg, what is your opinion about adding this to the 1.6 branch? Or
would you rather it be restricted to HEAD? If it is
restricted to HEAD,
then I lean towards cutting a 1.8.0 release sooner rather than later.
Any other thoughts? I would like to get this committed sometime soon.
Eric Weddington
begin 666 eeprom.h
[EMAIL PROTECTED]7)I9VAT(AC*2 R,# R+ R,# S+ R,# T+ R,# W($UAF5K
M($UI8VAA;MI97=I8WH-B @($-O'ER:6=H= H8RD@,C P-2P@,C P-B!
M:F]E[EMAIL PROTECTED]%AV4-B @($-O'ER:6=H= H8RD@,C P.!!=UE;!#;W)P
M;W)A=EO;@T*( @0V]P7)I9VAT(AC*2 R,# X(%=O=71E[EMAIL PROTECTED]
M:6L-B @($%L;!R:6=H=',@F5S97)V960N#0H-B @(%)E9ES=')I8G5T
M:6]N(%N9!UV4@:6X@V]UF-E(%N9!B:6YA[EMAIL PROTECTED];7,L('=I=@@
M;W(@=VET:]U= T*( @;6]D:69I8V%T:6]N+!AF4@5R;6ET=5D('!R
M;W9I95D('[EMAIL PROTECTED]AE(9O;QO=VEN9R!C;VYD:71I;VYS(%R92!M970Z
M#0H-B @([EMAIL PROTECTED]:7-TFEB=71I;VYS(]F('-O=7)C92!C;V1E(UUW0@
MF5T86EN('1H92!A8F]V92!C;W!YFEG:'0-B @( @;F]T:6-E+!T:ES
M(QIW0@;[EMAIL PROTECTED]ET:6]NR!A;[EMAIL
PROTECTED]AE(9O;QO=VEN9R!D:7-C;%I
M;[EMAIL PROTECTED]@( J(%)E9ES=')I8G5T:6]NR!I;B!B:6YA[EMAIL PROTECTED];2!M
M=7-T(')E')O9'5C92!T:[EMAIL PROTECTED])[EMAIL PROTECTED]7)I9VAT#0H@(
@(YO=EC
[EMAIL PROTECTED]AIR!L:7-T(]F(-O;F1I=EO;G,@86YD('1H92!F;VQL;W=I;F@
M9ES8VQA:6UEB!I;@T*( @(!T:[EMAIL PROTECTED]]C=6UE;G1A=EO;B!A;F0O;W(@
M;W1H97(@;6%T97)I86QS('!R;W9I95D('=I=@@=AE#0H@( @(1IW1R
M:6)U=EO;BX-@T*( @*B!.96ET:5R('1H92!N86UE(]F('1H92!C;W!Y
MFEG:'0@:]L95RR!N;W(@=AE(YA;65S(]F#0H@( @(-O;G1R:6)U
M=]R[EMAIL PROTECTED]@=7-E9!T;R!E;F1OG-E(]R('!R;VUO=4@')O9'5C
M=',@95R:79E9 T*( @(!FF]M('1H:7,@V]F='=A[EMAIL PROTECTED]:]U=!S
M5C:69I8R!PFEOB!WFET=5N('!EFUIW-I;VXN#0H-B @5$A)4R!3
M3T945T%212!)4R!04D]6241%1![EMAIL PROTECTED]))1TA4($A/3$1%4E,@
M04Y$($-/3E1224)55$]24R B05,@25,B#0H@($%.1[EMAIL PROTECTED]/
M4B!)35!,245$(%=!4E)!3E1)15,L([EMAIL PROTECTED]($Y/5!,24U)
M5$5$(%1/+!42$4-B @24U03$E%1!705)204Y42453($]($U%4D-(04Y4
M04))[EMAIL PROTECTED]3U(@02!005)424-53$%2(%!54E!/4T4-
MB @05)%($1)4T-,04E-140N($E.($Y/($5614Y4(%-(04Q,(%1(12!#3U!9
M4DE'[EMAIL PROTECTED](@3U(@0T].5%))0E543U)3($)%#0H@($Q)04),12!3U(@
M04Y9($1)4D5#5[EMAIL PROTECTED])%0U0L($E.0TE$14Y404PL(%-014-)04PL($58
[EMAIL PROTECTED](-B @0T].4T51545.5$E!3!$04U!1T53(A)3D-,541)
M3DL($)55[EMAIL PROTECTED][EMAIL PROTECTED])/[EMAIL PROTECTED]B @4U5
M4U1)5%5412!'3T]$4R!/4B!315)[EMAIL PROTECTED]/1B!54T4L($1!5$$L
M($]2(%!23T9)5%,[($]2($)54TE.15-3#0H@($E.5$524E505$E/[EMAIL PROTECTED]
[EMAIL PROTECTED]($].($%.62!42$5/[EMAIL PROTECTED]@3$E!0DE,2519+!7
M2$542$52($E.#0H@($-/3E1204-4+!35%))[EMAIL PROTECTED],2519+!/4B!4
M3U)4(A)3D-,541)3D@3D5'3$E'14Y#12!/4B!/5$A%4E=)4T4I#0H@($%2
M25-)3D@[EMAIL PROTECTED](%=!62!/[EMAIL PROTECTED]@5$A%(%5312!/1B!42$E3(%-/1E17
M05)%+!%5D5.($E([EMAIL PROTECTED]@5$A%#0H@(%!/4U-)0DE,2519($]
M(%-50T@@1$%-04=%+B J+PT*#0HO*B D260D(HO#0H-@T*(VEF;F1E9B!?
M05927T5%4%)/35](7PT*(V1E9FEN92!?05927T5%4%)/35](7R Q#0H-B-I
M;F-L=61E(#QA=G(O:6\N:#X-B-I;F-L=61E(#QS=1I;G0N:#X-@T*#0HO
[EMAIL PROTECTED]1E9B!%14U%30T*( @(%QI;F=R;W5P(%VE]E97!R;VT-B @(!!
M='1R:6)U=[EMAIL PROTECTED]F5SVEO;B!C875S:6YG([EMAIL PROTECTED]:6%B;[EMAIL
PROTECTED][EMAIL PROTECTED]@
M86QL;V-A=5D('=I=AI;B!T:[EMAIL PROTECTED]')O;0T*( @(!S96-T:6]N+B @
M*B\-B-D969I;[EMAIL PROTECTED]@7U]A='1R:6)U=[EMAIL PROTECTED]V5C=EO;[EMAIL
PROTECTED]
M')O;2(I*2D-@T*#0HO*B!296=IW1EB!D969I;FET:6]NR J+PT*#0HO
M*B!#:5C:R!F;W(@97AIW1E;F-E(]F($5%4%)/32!P97)IAEF%L+B J
M+PT*(VEF($4R14Y$(#T](# -B-EG)OB B15V:6-E(1O97,@;F]T(AA
[EMAIL PROTECTED](%V86EL86)L92$B#0HC96YD:68-@T*#0HO*B!#:5C:R!F
M;W(@86QI87-E[EMAIL PROTECTED]B-I9B A95F:6YE9A%15=%*2 F)B!D969I;F5D
M*$5%4$4I#0HC95F:6YE([EMAIL PROTECTED](V5N9EF#0H-B-I9B A95F
M:6YE9A%14U712D@)[EMAIL PROTECTED]5F:6YE9A%14U012D-B-D969I;[EMAIL
PROTECTED]@
M145-4$4-B-E
Re: [avr-libc-dev] [RFC] New eeprom.h
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 should at least be there. But I am no lawyer, and personally I do not mind. This sounds promising. Do you care to modify the header? I did. See attachment. (if they do not get to the list, please notify me) No guarantees. But for me it saves up to 50 bytes testing read/write pairs per type. The only thing I can't make gcc do in a proper manner is the read block. GCC just uses to many instructions. That is a candidate for a special assembler routine. There is a loop, or should be. The loop is checking the EEWE flag (or equivalent) to make sure that a read or write is possible. 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. Right, I forgot about the assembler file... shame on me! Sorry for the fuzz. Wouter /* Copyright (c) 2007 Atmel Corporation All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of the copyright holders nor the names of contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ /* $Id$ */ #ifndef _AVR_EEPROM_H_ #define _AVR_EEPROM_H_ 1 #include avr/io.h #include stdint.h /** \def EEMEM \ingroup avr_eeprom Attribute expression causing a variable to be allocated within the .eeprom section. */ #define EEMEM __attribute__((section(.eeprom))) /* Register definitions */ /* Check for existence of EEPROM peripheral. */ #if E2END == 0 #error Device does not have EEPROM available! #endif /* Check for aliases. */ #if !defined(EEWE) defined(EEPE) #define EEWE EEPE #endif #if !defined(EEMWE) defined(EEMPE) #define EEMWE EEMPE #endif #if !defined(EECR) defined(DEECR) /* AT86RF401 */ #define EECR DEECR #define EEAR DEEAR #define EEARL DEEAR #define EEDR DEEDR #define EERE EER #define EEWE EEL #define EEMWE EEU #endif #if !defined(EECR) || !defined(EEDR) || !defined(EEARL) #ifndef __EEPROM_REG_LOCATIONS__ /* 6-byte string denoting where to find the EEPROM registers in memory space. Adresses denoted in hex syntax with uppercase letters. Used by the EEPROM subroutines. First two letters: EECR address. Second two letters: EEDR address. Last two letters: EEAR address. */ #define __EEPROM_REG_LOCATIONS__ 1C1D1E #endif /* If needed, override the locations defined in the IO headers. */ #ifdef EEPROM_REG_LOCATIONS_OVERRIDE #undef __EEPROM_REG_LOCATIONS__ #define __EEPROM_REG_LOCATIONS__ EEPROM_REG_LOCATIONS_OVERRIDE #endif #define CONCAT1(a, b) CONCAT2(a, b) #define CONCAT2(a, b) a ## b #define HEXNR CONCAT1(0x, __EEPROM_REG_LOCATIONS__) #undef EECR #define EECR _SFR_IO8((HEXNR 16) 0xFF) #undef EEDR #define EEDR _SFR_IO8((HEXNR 8) 0xFF ) #undef EEAR #define EEAR _SFR_IO8(HEXNR 0xFF) #undef EEARH #undef EEARL #define EEARL EEAR #endif /** \def eeprom_is_ready \ingroup avr_eeprom \returns 1 if EEPROM is ready for a new read/write operation, 0 if not. */ #if defined(__DOXYGEN__) # define eeprom_is_ready() #elif defined(DEECR) # define eeprom_is_ready() bit_is_clear(DEECR, BSY) #else # define eeprom_is_ready()
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. 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, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 nasty \ ?
For eeprom read an inline function I came up with this (for E2ND 0xFF)
//static inline uint8_t __eeprom_read_byte_address_word(uint8_t*)
__attribute__((always_inline));
static inline uint8_t __eeprom_read_byte_address_word(uint8_t* eeptr)
{
uint16_t __address_word = (uint16_t)(eeptr);
uint8_t __result;
do{}while(!eeprom_is_ready());
EEARL = __address_word 0xFF;
EEARH = __address_word 8;
EECR |= 1EERE;
__result = EEDR;
return __result;
}
This is plain C, but it's forced to be in this specific order, since all
(!) access is to volatile memory. There is no timing constraint on
instruction sequence so there is no problem.
For -O0 it generates large but valid code.
For -O[123] it gives all the same small code
For -Os it might give a function call, so I added the always_inline
constraint. Then it gives the same results, however it's arguable to leave
the inlining to gcc, since it might be smaller (in case of several calls)
My C function gives much, much smaller code. GCC gets its hands tide up
because of the assembler, it forgets it can recycle registers etc...
So I would recommend this C function approach for all read routines.
Of course read word could be made more sophisticated using gcc ability to
check on constants (__builtin_constant_p), so you could then check for page
crossing and write the high address only once.
The write sequence is best to be in asm since it needs a special timing and
interrupt clearing.
One last thing, why is there a loop before every function? In the old code
there is no loop (although the documentation state there is!?!).
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?
HTH
Wouter
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 of type application/octet-stream? You'd need something that's declared text/plain, or maybe application/zip. That is the problem. I received the attachment this time (I was directly addressed), and eeprom.h is attached with type application/octet-stream. I would attach eeprom.h to this reply, but my mail client (Entourage) is also encoding it as application/octet-stream, and I have not been able to quickly figure out how to make it do otherwise. -Preston ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
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 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 them? HTH, Wouter ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [RFC] New eeprom.h
-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. 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 them? They were in my original email to the list. Since then, I have started testing on real hardward. The read/write byte macros seem to work find. I've found, and fixed, a bug with the read/write word macros. There are problems with the read/write block macros that I haven't chased down yet. Attached is my latest source. Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [RFC] New eeprom.h
-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 in this thread including this last email from you. Thanks for letting me know. Trying again. Let me know if it's not attached this time. Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 application/octet-stream? You'd need something that's declared text/plain, or maybe application/zip. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 the dangers of macros.
i.e. In stead of having a macro
#define foo(x) /* Code here */
have an inline static function in the header file:
static inline void foo(int x)
{
/* Code here */
}
Because the function is static, no code is generated if it is not used.
In general, I agree with you - static inline functions are often
preferable to macros, and are underused by many people. They are type
safe, can easily have local variables and multiple statements without
horrible do {} while (0); constructs, don't need line continuation
characters, and so on. However, there are other things you can do with
macros, that can't be done with inline functions. I don't know what the
new API will look like, but there might be something like this:
static inline void eeStoreByte(uint16_t address, uint8_t data) { ... }
static inline void eeStoreData(uint16_t address, uint8_t *data,
uint16_t count) { ... }
#define eeStoreObject(address, obj) \
eeStoreData(address, (uint8_t*) (obj), sizeof(obj))
The eeStoreObject function must be written as a macro to get the
address-taking and sizeof to work nicely.
Anyway, judging from the predominance of static inline functions (often
with the ((always_inline)) attribute), I reckon that Eric will use
static inlines where possible!
mvh.,
David
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [RFC] New eeprom.h
-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 are often
preferable to macros, and are underused by many people. They
are type
safe, can easily have local variables and multiple statements without
horrible do {} while (0); constructs, don't need line continuation
characters, and so on. However, there are other things you
can do with
macros, that can't be done with inline functions. I don't
know what the
new API will look like, but there might be something like this:
It's not a new API, per se, in that the interface remains the same. It's
just a new implementation to fix bugs and problems with the current
implementation.
Anyway, judging from the predominance of static inline
functions (often
with the ((always_inline)) attribute), I reckon that Eric will use
static inlines where possible!
- The way they are written now, the do{...}while(0) construct is not
needed and not used.
- The way they are written now, they have local (to a block level)
variables.
- Who cares if it has line continuation characters or not? The user
won't seem them.
- Yes, they are type safe. But the macros ensure that parameters are
typecast to the types needed.
- These types of inline assembly macros are used elsewhere in avr-libc,
notably avr/pgmspace.h, avr/boot.h, and IIRC avr/sleep.h. Do you
propose to change all of this? Do you propose to do the work required?
Eric Weddington
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 inline functions are often
preferable to macros, and are underused by many people. They
are type
safe, can easily have local variables and multiple statements without
horrible do {} while (0); constructs, don't need line continuation
characters, and so on. However, there are other things you
can do with
macros, that can't be done with inline functions. I don't
know what the
new API will look like, but there might be something like this:
It's not a new API, per se, in that the interface remains the same. It's
just a new implementation to fix bugs and problems with the current
implementation.
Anyway, judging from the predominance of static inline
functions (often
with the ((always_inline)) attribute), I reckon that Eric will use
static inlines where possible!
- The way they are written now, the do{...}while(0) construct is not
needed and not used.
- The way they are written now, they have local (to a block level)
variables.
- Who cares if it has line continuation characters or not? The user
won't seem them.
These are just general points - code that is neater and easier to read
is better code, all other things being equal, and do {} while (0)
loops and other messy bits of macros make code harder to read.
But in a library, the balance is different from application level code -
here it is well worth using whatever constructs are needed to get the
best generated code. As you say, users won't see them.
- Yes, they are type safe. But the macros ensure that parameters are
typecast to the types needed.
- These types of inline assembly macros are used elsewhere in avr-libc,
notably avr/pgmspace.h, avr/boot.h, and IIRC avr/sleep.h. Do you
propose to change all of this? Do you propose to do the work required?
No, no - I think you misunderstood my post. I was responding to Anton's
suggestion of using more static inline functions instead of macros by
saying that while static inlines have a lot of benefits, sometimes
macros are the right choice - and that avrlibc already uses static
inlines where it makes sense.
mvh.,
David
Eric Weddington
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [RFC] New eeprom.h
-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 big reason to move away from compiling code to macros, is that we do *not* have a true multi-lib (per device) environment with avr-libc. We need to be able to have different variants of code for different devices (not just per architecture). Right now, the only way for us to do this *is* with macros in a header file. Additionally, someone who does want a function can write one rather easily. Very true. :-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 think you misunderstood my post. I was responding to Anton's suggestion of using more static inline functions instead of macros by saying that while static inlines have a lot of benefits, sometimes macros are the right choice - and that avrlibc already uses static inlines where it makes sense. I was giving this some further thought, and static inline functions wouldn't work for avr-libc. Avr-libc is a library of object modules. Having static inline functions requires a compilation step. Two things: static inline functions in headers should work the same way as macros in headers - the code is generated when the function or macro is used by the application code (or other parts of the library which use the function/macro in question). The inline functions are analysed by the compiler whenever the header is included (unlike for macros, which are only analysed when used) - the compiler may even generate assembly for the function. But since the functions are also static, this generated code will be discarded if it is not used. Thus if you have a static inline function that uses a type eepromAddress, and the typedef for eepromAddress depends on the avr in question, then the static inline function will still generate appropriate code in use, just like a macro would. The current eeprom.h file from the latest winavr package uses static inline functions in exactly this way, unless I'm really getting things mixed up. - The inline portion wouldn't work because we now have object code, and the linking stage (AFAIK) doesn't do inlining. It does not *yet* do inlining in this way. One fine day, gcc will support link-time optimisations such as inlining functions defined in different modules (it can do it today if you compile different C modules in one go, but that doesn't work for libraries) - there has been work on this going on for years. - One big reason to move away from compiling code to macros, is that we do *not* have a true multi-lib (per device) environment with avr-libc. We need to be able to have different variants of code for different devices (not just per architecture). Right now, the only way for us to do this *is* with macros in a header file. Is a multi-lib avrlibc something that is being considered? I can see that there would be definite advantages, but I can also see it being a lot more work. mvh., David ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [RFC] New eeprom.h
-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- 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: The current eeprom.h file from the latest winavr package uses static inline functions in exactly this way, unless I'm really getting things mixed up. Point. Personally, I've just never been fond of the idea of putting function definitions in header files. - The inline portion wouldn't work because we now have object code, and the linking stage (AFAIK) doesn't do inlining. It does not *yet* do inlining in this way. But I have to deal with today, not the future. Is a multi-lib avrlibc something that is being considered? I can see that there would be definite advantages, but I can also see it being a lot more work. We have a task in the project Task List for it, but as you said, it's a lot more work and no one has had the time or inclination to tackle it. Eric W. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
Or inline functions defined in a header file. Rick Altherr He said he hadn't had a byte in three days. I had a short, so I split it with him. On Jan 16, 2008, at 9:41 AM, Weddington, Eric [EMAIL PROTECTED] 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 think you misunderstood my post. I was responding to Anton's suggestion of using more static inline functions instead of macros by saying that while static inlines have a lot of benefits, sometimes macros are the right choice - and that avrlibc already uses static inlines where it makes sense. I was giving this some further thought, and static inline functions wouldn't work for avr-libc. Avr-libc is a library of object modules. Having static inline functions requires a compilation step. Two things: - The inline portion wouldn't work because we now have object code, and the linking stage (AFAIK) doesn't do inlining. - One big reason to move away from compiling code to macros, is that we do *not* have a true multi-lib (per device) environment with avr-libc. We need to be able to have different variants of code for different devices (not just per architecture). Right now, the only way for us to do this *is* with macros in a header file. Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [RFC] New eeprom.h
-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 guys are making comments about *how* I implemented the functionality, not if it *actually works*. Eric W. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
I'd test it, but my ski vacation didn't include an electronics test bench. :-) Rick Altherr He said he hadn't had a byte in three days. I had a short, so I split it with him. On Jan 16, 2008, at 2:45 PM, Weddington, Eric [EMAIL PROTECTED] wrote: -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 guys are making comments about *how* I implemented the functionality, not if it *actually works*. Eric W. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [RFC] New eeprom.h
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 instead of library functions, it has been rewritten as
macros generating inlined assembly.
Yes, there is the potential that the macro version could take up more
code space with more calls to the macro. However, it is imperative that
this API work on *all* AVRs (that have EEPROM) and to have it work on
future AVR devices as well. I would rather have it work correctly first,
optimize later. Since we do not have a true multi-lib environment (per
device), implementing it as macros is the only way we have right now to
handle differences with multiple devices.
I have done compile tests, however, I have not tried this out on actual
hardware yet. I thought I would get this out to everyone a bit early for
feedback. Over the next day or two, I will be testing this on some real
hardware (probably an ATmega128).
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 the dangers of macros.
i.e. In stead of having a macro
#define foo(x) /* Code here */
have an inline static function in the header file:
static inline void foo(int x)
{
/* Code here */
}
Because the function is static, no code is generated if it is not used.
Regards
Anton Erasmus
--
A J Erasmus
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
