Follow-up Comment #2, bug #27434 (project avr-libc):
Thanks for the quick response!
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?27434
___
Message sent via/by Savannah
URL:
http://savannah.nongnu.org/bugs/?27434
Summary: Arguments of macros must be protected in
parentheses
Project: AVR C Runtime Library
Submitted by: sjackman
Submitted on: Sun 13 Sep 2009 06:58:38 PM GMT
Category:
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 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 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,
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
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
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?
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
Follow-up Comment #1, bug #22355 (project avr-libc):
Ack. My code was munged by the rich markup. I'll resubmit the code in a
patch.
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?22355
Additional Item Attachment, bug #22355 (project avr-libc):
File name: eeprom32.c Size:0 KB
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?22355
___
URL:
http://savannah.nongnu.org/bugs/?22355
Summary: Feature request: eeprom_read_32 and eeprom_write_32
Project: AVR C Runtime Library
Submitted by: sjackman
Submitted on: Monday 02/18/2008 at 18:02
Category: Library
The General Purpose I/O Registers (GPIOR0 through GIPOR3) are directly
bit-accessible. It would be a very handy feature to be able to place a
static bool (or any variable, I suppose) in the GPIO registers.
Cheers,
Shaun
___
AVR-libc-dev mailing list
On Dec 19, 2007 1:24 PM, Stu Bell [EMAIL PROTECTED] wrote:
...
The real problem with a full workup would be a macro to help define
bit variables. For example it would be cool to do something like the
following:
#define DECLARE_BIT_VARIABLE(var,port,bnum) \
#define (name) ((volatile
On Dec 19, 2007 2:39 PM, Stu Bell [EMAIL PROTECTED] wrote:
The bit-field approach solves my primary complaint by not needing any
accessor functions. Both if (my_flag) and my_flag = true; work as
expected. As for the declaration, perhaps #define my_flag
(GPIOR0_BIT.bit0) would be
From boot.h:
\todo From email with Marek: On smaller devices (all except ATmega64/128),
__SPM_REG is in the I/O space, accessible with the shorter in and out
instructions - since the boot loader has a limited size, this could be an
important optimization.
I'm writing a boot-loader
and __boot_xxx_extended variants.
Cheers,
Shaun
2007-12-14 Shaun Jackman [EMAIL PROTECTED]
* include/avr/boot.h (__boot_page_fill_normal,
__boot_page_erase_normal, __boot_page_write_normal,
__boot_rww_enable): Use an out instruction rather than an sts
instruction when
___
Details:
If the size of each vector entry is four bytes, _VECTORS_SIZE should be 128
bytes.
2007-12-07 Shaun Jackman [EMAIL PROTECTED]
* (_VECTORS_SIZE): Bug fix. Should be 128, not 64
___
Details:
2007-12-06 Shaun Jackman [EMAIL PROTECTED]
* include/avr/io90pwm316.h (POEN1A, POEN1B, PSYNC10, PSYNC11):
New constant.
___
File Attachments
I've been bitten twice now by this little gotcha:
#define BOOTLOADER 0x1f00
void goto_bootloader(void)
{
goto *BOOTLOADER;
}
The above code is buggy. The worst of it is, it will work just fine
until your application program becomes just a little bigger than it
used to be. It should
(cc'ing [EMAIL PROTECTED])
On Nov 21, 2007 2:38 AM, Wouter van Gulik [EMAIL PROTECTED] wrote:
Also consider the fuse bit get routine. This scheme gives more knowledge
to the compiler, unfortunately gcc fails to see the loading of r31 can
done once:
using this:
Follow-up Comment #2, bug #21621 (project avr-libc):
The AC_PREREQ(2.57) line of configure.ac is meant to handle this sort of
version checking. I can confirm, though, that autoconf 2.61 works fine.
___
Reply to this item at:
___
Details:
2007-11-20 Shaun Jackman [EMAIL PROTECTED]
* include/avr/boot.h (__boot_page_fill_normal,
__boot_page_erase_normal, __boot_page_write_normal): Use the z
register constraint.
This same method could also
Follow-up Comment #2, bug #21623 (project avr-libc):
Definitely remove r30 and r31 from the clobber. The spm instruction doesn't
clobber the Z register, since it has the same value going out as coming in. If
it did modify the Z register, it should be listed with a read/write
constraint, as in +z
Thanks for the note, Jürgen. At the moment, I'm only trying to program
the ATmega8 using the AVR JTAG ICE mkII.
Cheers,
Shaun
On 1/8/07, Jürgen Schilling [EMAIL PROTECTED] wrote:
Hi Shaun,
I'll hope you know, that debugging with the ATmega8 and the JTAG ICE
mkII isn't possible. If you like to
26 matches
Mail list logo
