tag:old.nabble.com,2006:forum-2008Nabble - AVR2009-11-24T08:15:16ZThe AVR family of microcontrollers from Atmel are economical, feature-rich microcontrollers featuring flash program memory. The entire family shares the same instruction set and basic architecture.tag:old.nabble.com,2006:post-26498816Re: Re: eeprom_read_byte and clr ret_hi2009-11-24T08:15:16Z2009-11-24T08:15:16ZWouter van GulikDavid Brown schreef:
<div class='shrinkable-quote'><br>> Wouter van Gulik wrote:
<br>>> David Brown schreef:
<br>>>> Wouter van Gulik wrote:
<br>>>>> David Brown schreef:
<br>>>>>> Weddington, Eric wrote:
<br>>>>>>>
<br>>>>>>>
<br>>>>>>>> -----Original Message----- From:
<br>>>>>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26498816&i=0" target="_top" rel="nofollow">avr-libc-dev-bounces+eric.weddington=atmel.com@...</a>
<br>>>>>>>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu. org]
<br>>>>>>>> On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009 12:21 AM To:
<br>>>>>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26498816&i=1" target="_top" rel="nofollow">avr-libc-dev@...</a> Subject: Re: [avr-libc-dev]
<br>>>>>>>> eeprom_read_byte and clr ret_hi
<br>>>>>>>>
<br>>>>>>>>>> eeprom_read_byte returns a uint8_t. Why does it clear r25?
<br>>>>>>>>>> eerd_byte.S: clr ret_hi
<br>>>>>>>>>>
<br>>>>>>>>>> Does the AVR ABI require that r25 be zeroed in a function
<br>>>>>>>> returning a
<br>>>>>>>>>> single byte? If not, this instruction could be removed.
<br>>>>>>>> This is a misty point. Look an example:
<br>>>>>>>>
<br>>>>>>>> unsigned char foo1 (unsigned char *p) { return *p; }
<br>>>>>>>>
<br>>>>>>>> extern unsigned char ext2 (void); int foo2 (void) { return ext2() +
<br>>>>>>>> 1; }
<br>>>>>>>>
<br>>>>>>>> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1() and
<br>>>>>>>> foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not clear R25 in
<br>>>>>>>> foo1().
<br>>>>>>>>
<br>>>>>>>> Note, the function return value is present only in expression. So
<br>>>>>>>> it is promoted to integer. So it would be better to clear R25 in
<br>>>>>>>> foo1() only (at one place).
<br>>>>>>>
<br>>>>>>> I agree that that is the way it should be.
<br>>>>>>>
<br>>>>>>
<br>>>>>> I'm a little confused by this - I hope this is not implying a
<br>>>>>> return to avr-gcc 4.2 R25 clearing? With avr-gcc 4.2, foo1() above
<br>>>>>> would clear R25 even though it is returning an 8-bit value. This
<br>>>>>> has always been a waste of time and space - caller functions make
<br>>>>>> no use of the cleared R25, and thus clear it again themselves (such
<br>>>>>> as in foo2() after calling ext2()). With avr-gcc 4.3, the extra
<br>>>>>> clear R25 instructions are omitted for functions returning 8-bit
<br>>>>>> values. This is the way it should be (unless the C standards
<br>>>>>> disagree...), IMHO. But it looks a little like you want foo1() to
<br>>>>>> clear R25 here?
<br>>>>>>
<br>>>>>>
<br>>>>>> Incidentally, avr-gcc 4.2.2 actually produces better code for
<br>>>>>> foo2() than avr-gcc 4.3.2.
<br>>>>>>
<br>>>>>> With 4.2.2, the code is:
<br>>>>>> foo2:
<br>>>>>> call ext2
<br>>>>>> ldi R25, lo8(0)
<br>>>>>> adiw r24,1
<br>>>>>> ret
<br>>>>>>
<br>>>>>> With 4.3.2 (and 4.3.0), we get:
<br>>>>>> foo2:
<br>>>>>> call ext2
<br>>>>>> mov r18, r24
<br>>>>>> ldi r19, lo8(0)
<br>>>>>> subi r18, lo8(-(1))
<br>>>>>> sbci r19, hi8(-(1))
<br>>>>>> movw r24, r18
<br>>>>>> ret
<br>>>>>>
<br>>>>>> Is this regression is news to you, I can take it up in the main
<br>>>>>> avr-gcc mailing list and/or a missed optimisation bug report.
<br>>>>>>
<br>>>>>
<br>>>>> This is "normal" GCC behaviour, caused by internal promotion to int
<br>>>>> types. Having the clr r25 would have saved the ldi r19. Altough
<br>>>>> these type of missed optimization are known for long, it
<br>>>>> (apparently) is difficult to fix them. IIRC the main problem is the
<br>>>>> carry bit propagation. I still don't now why exactly that is such a
<br>>>>> big problem, but then again I am no gcc expert.
<br>>>>>
<br>>>>
<br>>>> I understand about int promotion, and how it's a PITA to remove all
<br>>>> the extra code that the avr backend has to put in because the gcc
<br>>>> frontend has promoted the 8-bit data to 16-bit ints. However,
<br>>>> avr-gcc 4.2 /does/ do a clr R25 in the function returning an 8-bit
<br>>>> result, and then it clears it /again/ after calling it (as in foo2
<br>>>> above). That is definitely a waste, and it has been removed in 4.3+.
<br>>>>
<br>>>> The problem I have with the 4.3.2 code above is not the zeroing of
<br>>>> the upper byte - that's standard int promotion, and is required for
<br>>>> correct code. The problem is that the result of ext2() is first
<br>>>> moved into a new register pair and then promoted to an int - an
<br>>>> unnecessary move, which forces the subi/sbci pair instead of subw,
<br>>>> and requires an additional move before the ret instruction. In more
<br>>>> complex code, the wasted register resources may also be relevant.
<br>>>>
<br>>>
<br>>> You're right, I was not grasping the real problem. However using
<br>>> -fno-split-wide-types makes 4.3.2 behave like 4.2.2. Split wide types
<br>>> seems to be the problem here.
<br>>>
<br>>
<br>> You are correct - I hadn't thought of that. However,
<br>> -fno-split-wide-types is a workaround, rather than a solution. Ideally,
<br>> the good code should be produced regardless of that flag, since
<br>> split-wide-types is enabled implicitly by all -Ox flags. The
<br>> split-wide-types is also useful to improve some code sequences, such as
<br>> when you have 32-bit data but only want to look at part of it.
<br>>
</div><br>Yes of course it is a workaround, it might be a hint on where the
<br>problem is. I did some simple experiments and it seems that split wide
<br>type only enforces a copy to a new register pair, which makes it less
<br>efficient.
<br><br>HTH,
<br><br>Wouter
<br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26498816&i=2" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26497666Re: Re: eeprom_read_byte and clr ret_hi2009-11-24T06:41:50Z2009-11-24T06:41:50ZDavid Brown-4Wouter van Gulik wrote:
<div class='shrinkable-quote'><br>> David Brown schreef:
<br>>> Wouter van Gulik wrote:
<br>>>> David Brown schreef:
<br>>>>> Weddington, Eric wrote:
<br>>>>>>
<br>>>>>>
<br>>>>>>> -----Original Message----- From:
<br>>>>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26497666&i=0" target="_top" rel="nofollow">avr-libc-dev-bounces+eric.weddington=atmel.com@...</a>
<br>>>>>>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu. org]
<br>>>>>>> On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009 12:21 AM To:
<br>>>>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26497666&i=1" target="_top" rel="nofollow">avr-libc-dev@...</a> Subject: Re: [avr-libc-dev]
<br>>>>>>> eeprom_read_byte and clr ret_hi
<br>>>>>>>
<br>>>>>>>>> eeprom_read_byte returns a uint8_t. Why does it clear r25?
<br>>>>>>>>> eerd_byte.S: clr ret_hi
<br>>>>>>>>>
<br>>>>>>>>> Does the AVR ABI require that r25 be zeroed in a function
<br>>>>>>> returning a
<br>>>>>>>>> single byte? If not, this instruction could be removed.
<br>>>>>>> This is a misty point. Look an example:
<br>>>>>>>
<br>>>>>>> unsigned char foo1 (unsigned char *p) { return *p; }
<br>>>>>>>
<br>>>>>>> extern unsigned char ext2 (void); int foo2 (void) { return ext2() +
<br>>>>>>> 1; }
<br>>>>>>>
<br>>>>>>> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1() and
<br>>>>>>> foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not clear R25 in
<br>>>>>>> foo1().
<br>>>>>>>
<br>>>>>>> Note, the function return value is present only in expression. So
<br>>>>>>> it is promoted to integer. So it would be better to clear R25 in
<br>>>>>>> foo1() only (at one place).
<br>>>>>>
<br>>>>>> I agree that that is the way it should be.
<br>>>>>>
<br>>>>>
<br>>>>> I'm a little confused by this - I hope this is not implying a return
<br>>>>> to avr-gcc 4.2 R25 clearing? With avr-gcc 4.2, foo1() above would
<br>>>>> clear R25 even though it is returning an 8-bit value. This has
<br>>>>> always been a waste of time and space - caller functions make no use
<br>>>>> of the cleared R25, and thus clear it again themselves (such as in
<br>>>>> foo2() after calling ext2()). With avr-gcc 4.3, the extra clear R25
<br>>>>> instructions are omitted for functions returning 8-bit values. This
<br>>>>> is the way it should be (unless the C standards disagree...), IMHO.
<br>>>>> But it looks a little like you want foo1() to clear R25 here?
<br>>>>>
<br>>>>>
<br>>>>> Incidentally, avr-gcc 4.2.2 actually produces better code for foo2()
<br>>>>> than avr-gcc 4.3.2.
<br>>>>>
<br>>>>> With 4.2.2, the code is:
<br>>>>> foo2:
<br>>>>> call ext2
<br>>>>> ldi R25, lo8(0)
<br>>>>> adiw r24,1
<br>>>>> ret
<br>>>>>
<br>>>>> With 4.3.2 (and 4.3.0), we get:
<br>>>>> foo2:
<br>>>>> call ext2
<br>>>>> mov r18, r24
<br>>>>> ldi r19, lo8(0)
<br>>>>> subi r18, lo8(-(1))
<br>>>>> sbci r19, hi8(-(1))
<br>>>>> movw r24, r18
<br>>>>> ret
<br>>>>>
<br>>>>> Is this regression is news to you, I can take it up in the main
<br>>>>> avr-gcc mailing list and/or a missed optimisation bug report.
<br>>>>>
<br>>>>
<br>>>> This is "normal" GCC behaviour, caused by internal promotion to int
<br>>>> types. Having the clr r25 would have saved the ldi r19. Altough these
<br>>>> type of missed optimization are known for long, it (apparently) is
<br>>>> difficult to fix them. IIRC the main problem is the carry bit
<br>>>> propagation. I still don't now why exactly that is such a big
<br>>>> problem, but then again I am no gcc expert.
<br>>>>
<br>>>
<br>>> I understand about int promotion, and how it's a PITA to remove all
<br>>> the extra code that the avr backend has to put in because the gcc
<br>>> frontend has promoted the 8-bit data to 16-bit ints. However, avr-gcc
<br>>> 4.2 /does/ do a clr R25 in the function returning an 8-bit result, and
<br>>> then it clears it /again/ after calling it (as in foo2 above). That
<br>>> is definitely a waste, and it has been removed in 4.3+.
<br>>>
<br>>> The problem I have with the 4.3.2 code above is not the zeroing of the
<br>>> upper byte - that's standard int promotion, and is required for
<br>>> correct code. The problem is that the result of ext2() is first moved
<br>>> into a new register pair and then promoted to an int - an unnecessary
<br>>> move, which forces the subi/sbci pair instead of subw, and requires an
<br>>> additional move before the ret instruction. In more complex code, the
<br>>> wasted register resources may also be relevant.
<br>>>
<br>>
<br>> You're right, I was not grasping the real problem. However using
<br>> -fno-split-wide-types makes 4.3.2 behave like 4.2.2. Split wide types
<br>> seems to be the problem here.
<br>>
</div><br>You are correct - I hadn't thought of that. However,
<br>-fno-split-wide-types is a workaround, rather than a solution. Ideally,
<br>the good code should be produced regardless of that flag, since
<br>split-wide-types is enabled implicitly by all -Ox flags. The
<br>split-wide-types is also useful to improve some code sequences, such as
<br>when you have 32-bit data but only want to look at part of it.
<br><br>mvh.,
<br><br>David
<br><br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26497666&i=2" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26494658Re: Re: eeprom_read_byte and clr ret_hi2009-11-24T03:55:01Z2009-11-24T03:55:01ZWouter van GulikDavid Brown schreef:
<div class='shrinkable-quote'><br>> Wouter van Gulik wrote:
<br>>> David Brown schreef:
<br>>>> Weddington, Eric wrote:
<br>>>>>
<br>>>>>
<br>>>>>> -----Original Message----- From:
<br>>>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26494658&i=0" target="_top" rel="nofollow">avr-libc-dev-bounces+eric.weddington=atmel.com@...</a>
<br>>>>>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu. org]
<br>>>>>> On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009 12:21 AM To:
<br>>>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26494658&i=1" target="_top" rel="nofollow">avr-libc-dev@...</a> Subject: Re: [avr-libc-dev]
<br>>>>>> eeprom_read_byte and clr ret_hi
<br>>>>>>
<br>>>>>>>> eeprom_read_byte returns a uint8_t. Why does it clear r25?
<br>>>>>>>> eerd_byte.S: clr ret_hi
<br>>>>>>>>
<br>>>>>>>> Does the AVR ABI require that r25 be zeroed in a function
<br>>>>>> returning a
<br>>>>>>>> single byte? If not, this instruction could be removed.
<br>>>>>> This is a misty point. Look an example:
<br>>>>>>
<br>>>>>> unsigned char foo1 (unsigned char *p) { return *p; }
<br>>>>>>
<br>>>>>> extern unsigned char ext2 (void); int foo2 (void) { return ext2() +
<br>>>>>> 1; }
<br>>>>>>
<br>>>>>> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1() and
<br>>>>>> foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not clear R25 in
<br>>>>>> foo1().
<br>>>>>>
<br>>>>>> Note, the function return value is present only in expression. So
<br>>>>>> it is promoted to integer. So it would be better to clear R25 in
<br>>>>>> foo1() only (at one place).
<br>>>>>
<br>>>>> I agree that that is the way it should be.
<br>>>>>
<br>>>>
<br>>>> I'm a little confused by this - I hope this is not implying a return
<br>>>> to avr-gcc 4.2 R25 clearing? With avr-gcc 4.2, foo1() above would
<br>>>> clear R25 even though it is returning an 8-bit value. This has
<br>>>> always been a waste of time and space - caller functions make no use
<br>>>> of the cleared R25, and thus clear it again themselves (such as in
<br>>>> foo2() after calling ext2()). With avr-gcc 4.3, the extra clear R25
<br>>>> instructions are omitted for functions returning 8-bit values. This
<br>>>> is the way it should be (unless the C standards disagree...), IMHO.
<br>>>> But it looks a little like you want foo1() to clear R25 here?
<br>>>>
<br>>>>
<br>>>> Incidentally, avr-gcc 4.2.2 actually produces better code for foo2()
<br>>>> than avr-gcc 4.3.2.
<br>>>>
<br>>>> With 4.2.2, the code is:
<br>>>> foo2:
<br>>>> call ext2
<br>>>> ldi R25, lo8(0)
<br>>>> adiw r24,1
<br>>>> ret
<br>>>>
<br>>>> With 4.3.2 (and 4.3.0), we get:
<br>>>> foo2:
<br>>>> call ext2
<br>>>> mov r18, r24
<br>>>> ldi r19, lo8(0)
<br>>>> subi r18, lo8(-(1))
<br>>>> sbci r19, hi8(-(1))
<br>>>> movw r24, r18
<br>>>> ret
<br>>>>
<br>>>> Is this regression is news to you, I can take it up in the main
<br>>>> avr-gcc mailing list and/or a missed optimisation bug report.
<br>>>>
<br>>>
<br>>> This is "normal" GCC behaviour, caused by internal promotion to int
<br>>> types. Having the clr r25 would have saved the ldi r19. Altough these
<br>>> type of missed optimization are known for long, it (apparently) is
<br>>> difficult to fix them. IIRC the main problem is the carry bit
<br>>> propagation. I still don't now why exactly that is such a big problem,
<br>>> but then again I am no gcc expert.
<br>>>
<br>>
<br>> I understand about int promotion, and how it's a PITA to remove all the
<br>> extra code that the avr backend has to put in because the gcc frontend
<br>> has promoted the 8-bit data to 16-bit ints. However, avr-gcc 4.2 /does/
<br>> do a clr R25 in the function returning an 8-bit result, and then it
<br>> clears it /again/ after calling it (as in foo2 above). That is
<br>> definitely a waste, and it has been removed in 4.3+.
<br>>
<br>> The problem I have with the 4.3.2 code above is not the zeroing of the
<br>> upper byte - that's standard int promotion, and is required for correct
<br>> code. The problem is that the result of ext2() is first moved into a
<br>> new register pair and then promoted to an int - an unnecessary move,
<br>> which forces the subi/sbci pair instead of subw, and requires an
<br>> additional move before the ret instruction. In more complex code, the
<br>> wasted register resources may also be relevant.
<br>>
</div><br>You're right, I was not grasping the real problem. However using
<br>-fno-split-wide-types makes 4.3.2 behave like 4.2.2. Split wide types
<br>seems to be the problem here.
<br><br>HTH
<br><br>Wouter
<br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26494658&i=2" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26490260Xmega/AVRispMkII reset bug fixed2009-11-23T20:15:43Z2009-11-23T20:15:43ZErik Walthinsen-4I'm working on a contract that currently involves build stuff around the
<br>ATxmega16A4 chip, and so far have managed to bash a toolchain into
<br>shape, but was having problems with avrdude requiring me to completely
<br>disconnect the programmer from USB after every programming cycle, which
<br>was getting rather obnoxious.
<br><br>I compared the verbose avrdude output from the STK500 log generated by
<br>AVRstudio, and on a hunch added one missing command, and voila! fixed.
<br>Why that command has anything to do with hanging on 2nd program I have
<br>no idea, but so far it's working repeatedly.
<br><br>The fix is to call stk500v2_loadaddr(pgm,addr) just before the main
<br>block write loop in stk600_xprog_paged_write(). I'd provide a diff, but
<br>it's against 5.6 (which works, unlike 5.8 or svn...) and it's a trivial
<br>change.
<br><br>I will be filing a bug report with this information shortly.
<br><br><br>_______________________________________________
<br>avrdude-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26490260&i=0" target="_top" rel="nofollow">avrdude-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avrdude-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avrdude-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---AVRdude---Dev-f2009.html" embed="fixTarget[2009]" target="_top" >AVR - AVRdude - Dev</a></p>tag:old.nabble.com,2006:post-26488396RE: Expanding the ATxmega support in the toolchain2009-11-23T16:03:35Z2009-11-23T16:03:35ZWeddington, Eric
<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26488396&i=0" target="_top" rel="nofollow">avr-chat-bounces+eric.weddington=atmel.com@...</a>
<br>> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26488396&i=1" target="_top" rel="nofollow">avr-chat-bounces+eric.weddington=atmel.com@...</a>]
<br>> On Behalf Of Erik Walthinsen
<br>> Sent: Monday, November 23, 2009 12:17 AM
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26488396&i=2" target="_top" rel="nofollow">avr-chat@...</a>
<br>> Subject: Re: [avr-chat] Expanding the ATxmega support in the toolchain
<br>>
<br>> > 2. Let me know the exact chips you're interested in having
<br>> support for, and I'll take care of it for you.
<br>> Ideally all of the chips they list as available at this point:
<br>>
<br>> 64,128,192,256 A1
<br>> 64,128,192,256 A3
<br>> 16,32,64,128 A4
<br>>
<br>> The peripherals are identical in each of the A lines, so the headers
<br>> should be trivial if they don't already exist, it's just specific
<br>> references to most of those combinations that seem to be
<br>> missing in the
<br>> latest patches I can find.
<br>>
</div><br>Note that these header files are never trivial. There are automatically generated from the XML device files that are shipped with AVR Studio. If AVR Studio doesn't have the XML files, then we don't have the header files for them. Adding support for a device requires more than just adding a header file.
<br><br>Support for a fair number of those devices are already done. Some won't be done by the next release.
<br><br><br>_______________________________________________
<br>AVR-chat mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26488396&i=3" target="_top" rel="nofollow">AVR-chat@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-chat" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-chat</a><br><p>From forum: <a href="http://old.nabble.com/AVR---General-f2011.html" embed="fixTarget[2011]" target="_top" >AVR - General</a></p>tag:old.nabble.com,2006:post-26487160Re: eeprom_read_byte and clr ret_hi2009-11-23T14:25:13Z2009-11-23T14:25:13ZDavid Brown-40Weddington, Eric wrote:
<div class='shrinkable-quote'><br>>
<br>>
<br>>> -----Original Message----- From:
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26487160&i=0" target="_top" rel="nofollow">avr-libc-dev-bounces+eric.weddington=atmel.com@...</a>
<br>>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu. org]
<br>>> On Behalf Of David Brown Sent: Monday, November 23, 2009 3:25 AM
<br>>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26487160&i=1" target="_top" rel="nofollow">avr-libc-dev@...</a> Subject: [avr-libc-dev] Re:
<br>>> eeprom_read_byte and clr ret_hi
<br>>>
<br>>> Weddington, Eric wrote:
<br>>>>
<br>>>>> -----Original Message----- From:
<br>>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26487160&i=2" target="_top" rel="nofollow">avr-libc-dev-bounces+eric.weddington=atmel.com@...</a>
<br>>>>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu.
<br>>>>> org] On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009
<br>>>>> 12:21 AM To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26487160&i=3" target="_top" rel="nofollow">avr-libc-dev@...</a> Subject: Re:
<br>>>>> [avr-libc-dev] eeprom_read_byte and clr ret_hi
<br>>>>>
<br>>>>>>> eeprom_read_byte returns a uint8_t. Why does it clear r25?
<br>>>>>>> eerd_byte.S: clr ret_hi
<br>>>>>>>
<br>>>>>>> Does the AVR ABI require that r25 be zeroed in a function
<br>>>>> returning a
<br>>>>>>> single byte? If not, this instruction could be removed.
<br>>>>> This is a misty point. Look an example:
<br>>>>>
<br>>>>> unsigned char foo1 (unsigned char *p) { return *p; }
<br>>>>>
<br>>>>> extern unsigned char ext2 (void); int foo2 (void) { return
<br>>>>> ext2() + 1; }
<br>>>>>
<br>>>>> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1() and
<br>>>>> foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not clear R25
<br>>>>> in foo1().
<br>>>>>
<br>>>>> Note, the function return value is present only in expression.
<br>>>>> So it is promoted to integer. So it would be better to clear
<br>>>>> R25 in foo1() only (at one place).
<br>>>> I agree that that is the way it should be.
<br>>>>
<br>>> I'm a little confused by this - I hope this is not implying a
<br>>> return to avr-gcc 4.2 R25 clearing?
<br>>
<br>> No, that wasn't my intention. I was merely commenting that the return
<br>> type of the macro/function should not be made int (16-bit), that it
<br>> should be a byte (uint8_t) as the API name implicates. If it is
<br>> returned as a byte, then yes it is implied and I agree that R25
<br>> should not be cleared.
<br>>
</div><br>Ah, good - as I hoped. I just wanted to be sure.
<br><br>>
<br>>> Is this regression is news to you, I can take it up in the main
<br>>> avr-gcc mailing list and/or a missed optimisation bug report.
<br>>
<br>> Please fill out a bug report. That way it won't get lost.
<br><br>I've added it to the WinAVR bug tracker:
<br><<a href="https://sourceforge.net/tracker/?func=detail&aid=2902772&group_id=68108&atid=520074" target="_top" rel="nofollow">https://sourceforge.net/tracker/?func=detail&aid=2902772&group_id=68108&atid=520074</a>>
<br><br>Hope that helps!
<br><br>p.s. - I'm looking forward to gcc 4.5 with LTO. For small targets like
<br>the AVR, that should mean full program optimisation for everything,
<br>including the libraries.
<br><br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26487160&i=4" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26486911RE: binutils 2.202009-11-23T14:00:47Z2009-11-23T14:00:47ZWeddington, Eric
<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From:
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26486911&i=0" target="_top" rel="nofollow">avr-gcc-list-bounces+eric.weddington=atmel.com@...</a>
<br>> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
<br>> org] On Behalf Of Rolf Ebert
<br>> Sent: Monday, November 23, 2009 1:46 PM
<br>> To: 'AVR-GCC'
<br>> Subject: [avr-gcc-list] binutils 2.20
<br>>
<br>> while building the compiler (gcc-4.3.3) I get the following error:
<br>>
<br>> checking for avr-nm...
<br>> k/Data/Development/gcc-cvs/build/gcc-obj/./gcc/nm
<br>> checking for avr-ranlib... /mingw/avr_43_gnat/avr/bin/ranlib
<br>> checking for avr-strip... /mingw/avr_43_gnat/avr/bin/strip
<br>> checking whether ln -s works... yes
<br>> checking for avr-gcc...
<br>> /k/Data/Development/gcc-cvs/build/gcc-obj/./gcc/xgcc
<br>> -B/k/Data/Development/gcc-cvs/build/gcc-obj/./gcc/
<br>> -B/mingw/avr_43_gnat/avr/bin/ -B/mingw/avr_43_gnat/avr/lib/ -isystem
<br>> /mingw/avr_43_gnat/avr/include -isystem
<br>> /mingw/avr_43_gnat/avr/sys-include -mmcu=avrxmega4
<br>> checking for suffix of object files... configure: error:
<br>> cannot compute
<br>> suffix of object files: cannot compile
<br>> See `config.log' for more details.
<br>> make[1]: *** [configure-target-libgcc] Error 1
<br>> make[1]: Leaving directory `/k/Data/Development/gcc-cvs/build/gcc-obj'
<br>> make: *** [all] Error 2
<br>>
<br>>
<br>> I am using binutils 2.20 unpatched and the gcc-4.3.2 patches as
<br>> available from the WinAVR CVS repository. The gcc patches apply all
<br>> cleanly against gcc-4.3.3.
<br>>
<br>> It seams to me that the binutils still don't know about the
<br>> xmega chips.
</div><br>That is correct. You have to use a patched binutils with a patched gcc. The xmega patches have been written by myself and Anatoly Sokolov and I haven't submitted them upstream yet.
<br><br><br>_______________________________________________
<br>AVR-GCC-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26486911&i=1" target="_top" rel="nofollow">AVR-GCC-list@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-gcc-list" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-gcc-list</a><br><p>From forum: <a href="http://old.nabble.com/AVR---gcc-f2010.html" embed="fixTarget[2010]" target="_top" >AVR - gcc</a></p>tag:old.nabble.com,2006:post-26485830binutils 2.202009-11-23T12:46:16Z2009-11-23T12:46:16ZRolf Ebertwhile building the compiler (gcc-4.3.3) I get the following error:
<br><br>checking for avr-nm... k/Data/Development/gcc-cvs/build/gcc-obj/./gcc/nm
<br>checking for avr-ranlib... /mingw/avr_43_gnat/avr/bin/ranlib
<br>checking for avr-strip... /mingw/avr_43_gnat/avr/bin/strip
<br>checking whether ln -s works... yes
<br>checking for avr-gcc...
<br>/k/Data/Development/gcc-cvs/build/gcc-obj/./gcc/xgcc
<br>-B/k/Data/Development/gcc-cvs/build/gcc-obj/./gcc/
<br>-B/mingw/avr_43_gnat/avr/bin/ -B/mingw/avr_43_gnat/avr/lib/ -isystem
<br>/mingw/avr_43_gnat/avr/include -isystem
<br>/mingw/avr_43_gnat/avr/sys-include -mmcu=avrxmega4
<br>checking for suffix of object files... configure: error: cannot compute
<br>suffix of object files: cannot compile
<br>See `config.log' for more details.
<br>make[1]: *** [configure-target-libgcc] Error 1
<br>make[1]: Leaving directory `/k/Data/Development/gcc-cvs/build/gcc-obj'
<br>make: *** [all] Error 2
<br><br><br>I am using binutils 2.20 unpatched and the gcc-4.3.2 patches as
<br>available from the WinAVR CVS repository. The gcc patches apply all
<br>cleanly against gcc-4.3.3.
<br><br>It seams to me that the binutils still don't know about the xmega chips.
<br><br>rolf
<br><br><br>_______________________________________________
<br>AVR-GCC-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26485830&i=0" target="_top" rel="nofollow">AVR-GCC-list@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-gcc-list" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-gcc-list</a><br><p>From forum: <a href="http://old.nabble.com/AVR---gcc-f2010.html" embed="fixTarget[2010]" target="_top" >AVR - gcc</a></p>tag:old.nabble.com,2006:post-26481275RE: Re: eeprom_read_byte and clr ret_hi2009-11-23T08:17:00Z2009-11-23T08:17:00ZWeddington, Eric
<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From:
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26481275&i=0" target="_top" rel="nofollow">avr-libc-dev-bounces+eric.weddington=atmel.com@...</a>
<br>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu.
<br>> org] On Behalf Of David Brown
<br>> Sent: Monday, November 23, 2009 3:25 AM
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26481275&i=1" target="_top" rel="nofollow">avr-libc-dev@...</a>
<br>> Subject: [avr-libc-dev] Re: eeprom_read_byte and clr ret_hi
<br>>
<br>> Weddington, Eric wrote:
<br>> >
<br>> >
<br>> >> -----Original Message----- From:
<br>> >> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26481275&i=2" target="_top" rel="nofollow">avr-libc-dev-bounces+eric.weddington=atmel.com@...</a>
<br>> >> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu. org]
<br>> >> On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009 12:21 AM To:
<br>> >> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26481275&i=3" target="_top" rel="nofollow">avr-libc-dev@...</a> Subject: Re: [avr-libc-dev]
<br>> >> eeprom_read_byte and clr ret_hi
<br>> >>
<br>> >>>> eeprom_read_byte returns a uint8_t. Why does it clear r25?
<br>> >>>> eerd_byte.S: clr ret_hi
<br>> >>>>
<br>> >>>> Does the AVR ABI require that r25 be zeroed in a function
<br>> >> returning a
<br>> >>>> single byte? If not, this instruction could be removed.
<br>> >> This is a misty point. Look an example:
<br>> >>
<br>> >> unsigned char foo1 (unsigned char *p) { return *p; }
<br>> >>
<br>> >> extern unsigned char ext2 (void); int foo2 (void) { return ext2() +
<br>> >> 1; }
<br>> >>
<br>> >> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1() and
<br>> >> foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not clear R25 in
<br>> >> foo1().
<br>> >>
<br>> >> Note, the function return value is present only in expression. So
<br>> >> it is promoted to integer. So it would be better to clear R25 in
<br>> >> foo1() only (at one place).
<br>> >
<br>> > I agree that that is the way it should be.
<br>> >
<br>>
<br>> I'm a little confused by this - I hope this is not implying a
<br>> return to
<br>> avr-gcc 4.2 R25 clearing?
</div><br>No, that wasn't my intention. I was merely commenting that the return type of the macro/function should not be made int (16-bit), that it should be a byte (uint8_t) as the API name implicates. If it is returned as a byte, then yes it is implied and I agree that R25 should not be cleared.
<br><br>
<br>> Is this regression is news to you, I can take it up in the
<br>> main avr-gcc
<br>> mailing list and/or a missed optimisation bug report.
<br><br>Please fill out a bug report. That way it won't get lost.
<br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26481275&i=4" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26475688Re: eeprom_read_byte and clr ret_hi2009-11-23T02:24:38Z2009-11-23T02:24:38ZDavid Brown-4Weddington, Eric wrote:
<div class='shrinkable-quote'><br>>
<br>>
<br>>> -----Original Message----- From:
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26475688&i=0" target="_top" rel="nofollow">avr-libc-dev-bounces+eric.weddington=atmel.com@...</a>
<br>>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu. org]
<br>>> On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009 12:21 AM To:
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26475688&i=1" target="_top" rel="nofollow">avr-libc-dev@...</a> Subject: Re: [avr-libc-dev]
<br>>> eeprom_read_byte and clr ret_hi
<br>>>
<br>>>>> eeprom_read_byte returns a uint8_t. Why does it clear r25?
<br>>>>> eerd_byte.S: clr ret_hi
<br>>>>>
<br>>>>> Does the AVR ABI require that r25 be zeroed in a function
<br>>> returning a
<br>>>>> single byte? If not, this instruction could be removed.
<br>>> This is a misty point. Look an example:
<br>>>
<br>>> unsigned char foo1 (unsigned char *p) { return *p; }
<br>>>
<br>>> extern unsigned char ext2 (void); int foo2 (void) { return ext2() +
<br>>> 1; }
<br>>>
<br>>> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1() and
<br>>> foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not clear R25 in
<br>>> foo1().
<br>>>
<br>>> Note, the function return value is present only in expression. So
<br>>> it is promoted to integer. So it would be better to clear R25 in
<br>>> foo1() only (at one place).
<br>>
<br>> I agree that that is the way it should be.
<br>>
</div><br>I'm a little confused by this - I hope this is not implying a return to
<br>avr-gcc 4.2 R25 clearing? With avr-gcc 4.2, foo1() above would clear
<br>R25 even though it is returning an 8-bit value. This has always been a
<br>waste of time and space - caller functions make no use of the cleared
<br>R25, and thus clear it again themselves (such as in foo2() after calling
<br>ext2()). With avr-gcc 4.3, the extra clear R25 instructions are omitted
<br>for functions returning 8-bit values. This is the way it should be
<br>(unless the C standards disagree...), IMHO. But it looks a little like
<br>you want foo1() to clear R25 here?
<br><br><br>Incidentally, avr-gcc 4.2.2 actually produces better code for foo2()
<br>than avr-gcc 4.3.2.
<br><br>With 4.2.2, the code is:
<br>foo2:
<br> call ext2
<br> ldi R25, lo8(0)
<br> adiw r24,1
<br> ret
<br><br>With 4.3.2 (and 4.3.0), we get:
<br>foo2:
<br> call ext2
<br> mov r18, r24
<br> ldi r19, lo8(0)
<br> subi r18, lo8(-(1))
<br> sbci r19, hi8(-(1))
<br> movw r24, r18
<br> ret
<br><br>Is this regression is news to you, I can take it up in the main avr-gcc
<br>mailing list and/or a missed optimisation bug report.
<br><br>mvh.,
<br><br>David
<br><br><br><br>>> Possibly, it is needed to change eeprom_read_byte() definition to
<br>>> int return value. This can reduce summary size. Opinions?
<br>>
<br>> This does not make sense to me. Eeprom_read_byte() is supposed to
<br>> read, and return, a single byte. So why should it return a 16-bit
<br>> int? In my mind this would just make it more confusing to the end
<br>> user.
<br><br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26475688&i=2" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26473600Re: Expanding the ATxmega support in the toolchain2009-11-22T23:17:28Z2009-11-22T23:17:28ZErik Walthinsen-4Weddington, Eric wrote:
<br>> 1. The "architectures" that are listed in the toolchain have absolutely nothing to do with the architectures or families of chips. They are just convenient categories or groups to put chips in that have similar features that the toolchain needs to know about.
<br>Right, they're for things like different instruction availability,
<br>memory sizes, etc. I'm just not seeing any differences between the
<br>architectures as defined in binutils except for the name. Are there
<br>differences buried inside gcc (which I haven't had time yet to look at)?
<br><br>> 2. Let me know the exact chips you're interested in having support for, and I'll take care of it for you.
<br>Ideally all of the chips they list as available at this point:
<br><br>64,128,192,256 A1
<br>64,128,192,256 A3
<br>16,32,64,128 A4
<br><br>The peripherals are identical in each of the A lines, so the headers
<br>should be trivial if they don't already exist, it's just specific
<br>references to most of those combinations that seem to be missing in the
<br>latest patches I can find.
<br><br>I'm using the 16A4 in lieu of the 128A4 right now because I couldn't
<br>easily find a source of small quantity of the right package. A later
<br>stage of this contract will likely involve an A1 chip.
<br><br>Thanks,
<br> Omega
<br> aka Erik Walthinsen
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26473600&i=0" target="_top" rel="nofollow">omega@...</a>
<br><br><br>_______________________________________________
<br>AVR-chat mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26473600&i=1" target="_top" rel="nofollow">AVR-chat@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-chat" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-chat</a><br><p>From forum: <a href="http://old.nabble.com/AVR---General-f2011.html" embed="fixTarget[2011]" target="_top" >AVR - General</a></p>tag:old.nabble.com,2006:post-26472046RE: Expanding the ATxmega support in the toolchain2009-11-22T18:43:21Z2009-11-22T18:43:21ZWeddington, Eric<br>1. The "architectures" that are listed in the toolchain have absolutely nothing to do with the architectures or families of chips. They are just convenient categories or groups to put chips in that have similar features that the toolchain needs to know about.
<br><br>2. Let me know the exact chips you're interested in having support for, and I'll take care of it for you.
<br><br>3. And for support for the ATxmega16A4, I already have it done. The next release of WinAVR will be roughly mid-December. If you need the patches to build a Linux toolchain, I can send them on to you.
<br><br>Eric Weddington
<br><br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26472046&i=0" target="_top" rel="nofollow">avr-chat-bounces+eric.weddington=atmel.com@...</a>
<br>> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26472046&i=1" target="_top" rel="nofollow">avr-chat-bounces+eric.weddington=atmel.com@...</a>]
<br>> On Behalf Of Erik Walthinsen
<br>> Sent: Sunday, November 22, 2009 5:51 PM
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26472046&i=2" target="_top" rel="nofollow">avr-chat@...</a>
<br>> Subject: [avr-chat] Expanding the ATxmega support in the toolchain
<br>>
<br>> I've got boards ready to populate for a [paid] prototyping
<br>> project that
<br>> are going to be getting ATxmega16a4's (for lack of anybody selling
<br>> 64a4's...). The problem is, even the WinAVR patches don't
<br>> seem to show
<br>> any support for anything other than the 64a1 and 128a1.
<br>>
<br>> I'm going to be adding support for the 16a4, and probably every other
<br>> chip actually nominally available at this point, and submitting the
<br>> patches soon (since this is the next roadblock for me to blast through
<br>> on this contract).
<br>>
<br>> However, I'm *royally* confused by the presence of the avrxmega2-7
<br>> "architectures". There seems to be no correlation between the arch
<br>> number and the chip it's supposed to represent, as per the table at
<br>> <a href="http://www.nongnu.org/avr-libc/user-manual/using_tools.html" target="_top" rel="nofollow">http://www.nongnu.org/avr-libc/user-manual/using_tools.html</a> Further,
<br>> the table refers to a number of chips that don't even exist
<br>> (the D* series).
<br>>
<br>> From my understanding of both Atmel's very clearly stated goal, and a
<br>> lot of time reading the datasheets, there should be *1* "architecture"
<br>> for all the existing chips, that would be the atxmegaA. The
<br>> only other
<br>> that might make sense could be a <=64KB variant.
<br>>
<br>> Anyone able to shed light on what's up with these architectures and
<br>> whether they actually mean anything, or would it make sense
<br>> to collapse
<br>> them down as part of adding full support to all the current chips?
<br>>
<br>> TIA,
<br>> Omega
<br>> aka Erik Walthinsen
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26472046&i=3" target="_top" rel="nofollow">omega@...</a>
<br>>
<br>>
<br>> _______________________________________________
<br>> AVR-chat mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26472046&i=4" target="_top" rel="nofollow">AVR-chat@...</a>
<br>> <a href="http://lists.nongnu.org/mailman/listinfo/avr-chat" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-chat</a><br>>
</div><br><br>_______________________________________________
<br>AVR-chat mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26472046&i=5" target="_top" rel="nofollow">AVR-chat@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-chat" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-chat</a><br><p>From forum: <a href="http://old.nabble.com/AVR---General-f2011.html" embed="fixTarget[2011]" target="_top" >AVR - General</a></p>tag:old.nabble.com,2006:post-26471271Expanding the ATxmega support in the toolchain2009-11-22T16:50:39Z2009-11-22T16:50:39ZErik Walthinsen-4I've got boards ready to populate for a [paid] prototyping project that
<br>are going to be getting ATxmega16a4's (for lack of anybody selling
<br>64a4's...). The problem is, even the WinAVR patches don't seem to show
<br>any support for anything other than the 64a1 and 128a1.
<br><br>I'm going to be adding support for the 16a4, and probably every other
<br>chip actually nominally available at this point, and submitting the
<br>patches soon (since this is the next roadblock for me to blast through
<br>on this contract).
<br><br>However, I'm *royally* confused by the presence of the avrxmega2-7
<br>"architectures". There seems to be no correlation between the arch
<br>number and the chip it's supposed to represent, as per the table at
<br><a href="http://www.nongnu.org/avr-libc/user-manual/using_tools.html" target="_top" rel="nofollow">http://www.nongnu.org/avr-libc/user-manual/using_tools.html</a> Further,
<br>the table refers to a number of chips that don't even exist (the D* series).
<br><br>From my understanding of both Atmel's very clearly stated goal, and a
<br>lot of time reading the datasheets, there should be *1* "architecture"
<br>for all the existing chips, that would be the atxmegaA. The only other
<br>that might make sense could be a <=64KB variant.
<br><br>Anyone able to shed light on what's up with these architectures and
<br>whether they actually mean anything, or would it make sense to collapse
<br>them down as part of adding full support to all the current chips?
<br><br>TIA,
<br> Omega
<br> aka Erik Walthinsen
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26471271&i=0" target="_top" rel="nofollow">omega@...</a>
<br><br><br>_______________________________________________
<br>AVR-chat mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26471271&i=1" target="_top" rel="nofollow">AVR-chat@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-chat" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-chat</a><br><p>From forum: <a href="http://old.nabble.com/AVR---General-f2011.html" embed="fixTarget[2011]" target="_top" >AVR - General</a></p>tag:old.nabble.com,2006:post-26470398Re: eeprom_read_byte and clr ret_hi2009-11-22T14:45:04Z2009-11-22T14:45:04ZDmitry K.> > Possibly, it is needed to change eeprom_read_byte() definition
<br>> > to int return value. This can reduce summary size. Opinions?
<br>>
<br>> This does not make sense to me. Eeprom_read_byte() is supposed to read, and
<br>> return, a single byte. So why should it return a 16-bit int? In my mind
<br>> this would just make it more confusing to the end user.
<br><br>Agree, it was a bad idea.
<br>More, the definition of eeprom_read_byte() as int will
<br>decrease performance in cases, where Avr-gcc can omit
<br>integral promotion, for example:
<br> if (eeprom_read_byte(&x) < 10)
<br><br>Regards,
<br>Dmitry.
<br><br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26470398&i=0" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26467394Re: stdint.h problem with gcc2009-11-22T09:33:02Z2009-11-22T09:33:02ZAndrew HutchinsonI have posted patch to "ignore" gcc stdint test failure due to limit
<br>range of prtdiff for AVR (c99 wants +-65535)
<br>Though we could use "long" that is pointless with restriction on objects
<br>being <= 32767 bytes.
<br><br>There are several errors/problems remaining with avr-libc stdint.h - gcc
<br>version passes most (all?) tests.
<br>I would be grateful if someone could review this.
<br><br>Andy
<br><br><br>Andrew Hutchinson wrote:
<div class='shrinkable-quote'><br>> I have been going through the gcc tests for V4.5 and come across some
<br>> issues with avr-lic stdint.h
<br>>
<br>> The tests that fails are gcc/gcc/testsuite/gcc.dg/c99-stdint-1.c
<br>>
<br>> gcc will create it's own stdint.h and this is fine for V4.5. I have
<br>> attached this for reference.
<br>>
<br>> The definition of UINT8_MAX is unsigned e.g. 255U - this fails test.
<br>> 255 is ok
<br>> wchar limits are not defined- ok we dont have wchar.h but we should
<br>> still define the types.
<br>>
<br>> There is another issue related to ptrdiff type. This is posted as gcc
<br>> bug - since it is possible that this particular subtest is
<br>> inappropriate for avr.
<br>>
<br>> <a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42114" target="_top" rel="nofollow">http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42114</a><br>>
<br>> =================================================================
<br>> /* Copyright (C) 2008, 2009 Free Software Foundation, Inc.
<br>>
<br>> This file is part of GCC.
<br>>
<br>> GCC is free software; you can redistribute it and/or modify
<br>> it under the terms of the GNU General Public License as published by
<br>> the Free Software Foundation; either version 3, or (at your option)
<br>> any later version.
<br>>
<br>> GCC is distributed in the hope that it will be useful,
<br>> but WITHOUT ANY WARRANTY; without even the implied warranty of
<br>> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
<br>> GNU General Public License for more details.
<br>>
<br>> Under Section 7 of GPL version 3, you are granted additional
<br>> permissions described in the GCC Runtime Library Exception, version
<br>> 3.1, as published by the Free Software Foundation.
<br>>
<br>> You should have received a copy of the GNU General Public License and
<br>> a copy of the GCC Runtime Library Exception along with this program;
<br>> see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
<br>> <<a href="http://www.gnu.org/licenses/" target="_top" rel="nofollow">http://www.gnu.org/licenses/</a>>. */
<br>>
<br>> /*
<br>> * ISO C Standard: 7.18 Integer types <stdint.h>
<br>> */
<br>>
<br>> #ifndef _GCC_STDINT_H
<br>> #define _GCC_STDINT_H
<br>>
<br>> /* 7.8.1.1 Exact-width integer types */
<br>>
<br>> #ifdef __INT8_TYPE__
<br>> typedef __INT8_TYPE__ int8_t;
<br>> #endif
<br>> #ifdef __INT16_TYPE__
<br>> typedef __INT16_TYPE__ int16_t;
<br>> #endif
<br>> #ifdef __INT32_TYPE__
<br>> typedef __INT32_TYPE__ int32_t;
<br>> #endif
<br>> #ifdef __INT64_TYPE__
<br>> typedef __INT64_TYPE__ int64_t;
<br>> #endif
<br>> #ifdef __UINT8_TYPE__
<br>> typedef __UINT8_TYPE__ uint8_t;
<br>> #endif
<br>> #ifdef __UINT16_TYPE__
<br>> typedef __UINT16_TYPE__ uint16_t;
<br>> #endif
<br>> #ifdef __UINT32_TYPE__
<br>> typedef __UINT32_TYPE__ uint32_t;
<br>> #endif
<br>> #ifdef __UINT64_TYPE__
<br>> typedef __UINT64_TYPE__ uint64_t;
<br>> #endif
<br>>
<br>> /* 7.8.1.2 Minimum-width integer types */
<br>>
<br>> typedef __INT_LEAST8_TYPE__ int_least8_t;
<br>> typedef __INT_LEAST16_TYPE__ int_least16_t;
<br>> typedef __INT_LEAST32_TYPE__ int_least32_t;
<br>> typedef __INT_LEAST64_TYPE__ int_least64_t;
<br>> typedef __UINT_LEAST8_TYPE__ uint_least8_t;
<br>> typedef __UINT_LEAST16_TYPE__ uint_least16_t;
<br>> typedef __UINT_LEAST32_TYPE__ uint_least32_t;
<br>> typedef __UINT_LEAST64_TYPE__ uint_least64_t;
<br>>
<br>> /* 7.8.1.3 Fastest minimum-width integer types */
<br>>
<br>> typedef __INT_FAST8_TYPE__ int_fast8_t;
<br>> typedef __INT_FAST16_TYPE__ int_fast16_t;
<br>> typedef __INT_FAST32_TYPE__ int_fast32_t;
<br>> typedef __INT_FAST64_TYPE__ int_fast64_t;
<br>> typedef __UINT_FAST8_TYPE__ uint_fast8_t;
<br>> typedef __UINT_FAST16_TYPE__ uint_fast16_t;
<br>> typedef __UINT_FAST32_TYPE__ uint_fast32_t;
<br>> typedef __UINT_FAST64_TYPE__ uint_fast64_t;
<br>>
<br>> /* 7.8.1.4 Integer types capable of holding object pointers */
<br>>
<br>> #ifdef __INTPTR_TYPE__
<br>> typedef __INTPTR_TYPE__ intptr_t;
<br>> #endif
<br>> #ifdef __UINTPTR_TYPE__
<br>> typedef __UINTPTR_TYPE__ uintptr_t;
<br>> #endif
<br>>
<br>> /* 7.8.1.5 Greatest-width integer types */
<br>>
<br>> typedef __INTMAX_TYPE__ intmax_t;
<br>> typedef __UINTMAX_TYPE__ uintmax_t;
<br>>
<br>> #if !defined __cplusplus || defined __STDC_LIMIT_MACROS
<br>>
<br>> /* 7.18.2 Limits of specified-width integer types */
<br>>
<br>> #ifdef __INT8_MAX__
<br>> # undef INT8_MAX
<br>> # define INT8_MAX __INT8_MAX__
<br>> # undef INT8_MIN
<br>> # define INT8_MIN (-INT8_MAX - 1)
<br>> #endif
<br>> #ifdef __UINT8_MAX__
<br>> # undef UINT8_MAX
<br>> # define UINT8_MAX __UINT8_MAX__
<br>> #endif
<br>> #ifdef __INT16_MAX__
<br>> # undef INT16_MAX
<br>> # define INT16_MAX __INT16_MAX__
<br>> # undef INT16_MIN
<br>> # define INT16_MIN (-INT16_MAX - 1)
<br>> #endif
<br>> #ifdef __UINT16_MAX__
<br>> # undef UINT16_MAX
<br>> # define UINT16_MAX __UINT16_MAX__
<br>> #endif
<br>> #ifdef __INT32_MAX__
<br>> # undef INT32_MAX
<br>> # define INT32_MAX __INT32_MAX__
<br>> # undef INT32_MIN
<br>> # define INT32_MIN (-INT32_MAX - 1)
<br>> #endif
<br>> #ifdef __UINT32_MAX__
<br>> # undef UINT32_MAX
<br>> # define UINT32_MAX __UINT32_MAX__
<br>> #endif
<br>> #ifdef __INT64_MAX__
<br>> # undef INT64_MAX
<br>> # define INT64_MAX __INT64_MAX__
<br>> # undef INT64_MIN
<br>> # define INT64_MIN (-INT64_MAX - 1)
<br>> #endif
<br>> #ifdef __UINT64_MAX__
<br>> # undef UINT64_MAX
<br>> # define UINT64_MAX __UINT64_MAX__
<br>> #endif
<br>>
<br>> #undef INT_LEAST8_MAX
<br>> #define INT_LEAST8_MAX __INT_LEAST8_MAX__
<br>> #undef INT_LEAST8_MIN
<br>> #define INT_LEAST8_MIN (-INT_LEAST8_MAX - 1)
<br>> #undef UINT_LEAST8_MAX
<br>> #define UINT_LEAST8_MAX __UINT_LEAST8_MAX__
<br>> #undef INT_LEAST16_MAX
<br>> #define INT_LEAST16_MAX __INT_LEAST16_MAX__
<br>> #undef INT_LEAST16_MIN
<br>> #define INT_LEAST16_MIN (-INT_LEAST16_MAX - 1)
<br>> #undef UINT_LEAST16_MAX
<br>> #define UINT_LEAST16_MAX __UINT_LEAST16_MAX__
<br>> #undef INT_LEAST32_MAX
<br>> #define INT_LEAST32_MAX __INT_LEAST32_MAX__
<br>> #undef INT_LEAST32_MIN
<br>> #define INT_LEAST32_MIN (-INT_LEAST32_MAX - 1)
<br>> #undef UINT_LEAST32_MAX
<br>> #define UINT_LEAST32_MAX __UINT_LEAST32_MAX__
<br>> #undef INT_LEAST64_MAX
<br>> #define INT_LEAST64_MAX __INT_LEAST64_MAX__
<br>> #undef INT_LEAST64_MIN
<br>> #define INT_LEAST64_MIN (-INT_LEAST64_MAX - 1)
<br>> #undef UINT_LEAST64_MAX
<br>> #define UINT_LEAST64_MAX __UINT_LEAST64_MAX__
<br>>
<br>> #undef INT_FAST8_MAX
<br>> #define INT_FAST8_MAX __INT_FAST8_MAX__
<br>> #undef INT_FAST8_MIN
<br>> #define INT_FAST8_MIN (-INT_FAST8_MAX - 1)
<br>> #undef UINT_FAST8_MAX
<br>> #define UINT_FAST8_MAX __UINT_FAST8_MAX__
<br>> #undef INT_FAST16_MAX
<br>> #define INT_FAST16_MAX __INT_FAST16_MAX__
<br>> #undef INT_FAST16_MIN
<br>> #define INT_FAST16_MIN (-INT_FAST16_MAX - 1)
<br>> #undef UINT_FAST16_MAX
<br>> #define UINT_FAST16_MAX __UINT_FAST16_MAX__
<br>> #undef INT_FAST32_MAX
<br>> #define INT_FAST32_MAX __INT_FAST32_MAX__
<br>> #undef INT_FAST32_MIN
<br>> #define INT_FAST32_MIN (-INT_FAST32_MAX - 1)
<br>> #undef UINT_FAST32_MAX
<br>> #define UINT_FAST32_MAX __UINT_FAST32_MAX__
<br>> #undef INT_FAST64_MAX
<br>> #define INT_FAST64_MAX __INT_FAST64_MAX__
<br>> #undef INT_FAST64_MIN
<br>> #define INT_FAST64_MIN (-INT_FAST64_MAX - 1)
<br>> #undef UINT_FAST64_MAX
<br>> #define UINT_FAST64_MAX __UINT_FAST64_MAX__
<br>>
<br>> #ifdef __INTPTR_MAX__
<br>> # undef INTPTR_MAX
<br>> # define INTPTR_MAX __INTPTR_MAX__
<br>> # undef INTPTR_MIN
<br>> # define INTPTR_MIN (-INTPTR_MAX - 1)
<br>> #endif
<br>> #ifdef __UINTPTR_MAX__
<br>> # undef UINTPTR_MAX
<br>> # define UINTPTR_MAX __UINTPTR_MAX__
<br>> #endif
<br>>
<br>> #undef INTMAX_MAX
<br>> #define INTMAX_MAX __INTMAX_MAX__
<br>> #undef INTMAX_MIN
<br>> #define INTMAX_MIN (-INTMAX_MAX - 1)
<br>> #undef UINTMAX_MAX
<br>> #define UINTMAX_MAX __UINTMAX_MAX__
<br>>
<br>> /* 7.18.3 Limits of other integer types */
<br>>
<br>> #undef PTRDIFF_MAX
<br>> #define PTRDIFF_MAX __PTRDIFF_MAX__
<br>> #undef PTRDIFF_MIN
<br>> #define PTRDIFF_MIN (-PTRDIFF_MAX - 1)
<br>>
<br>> #undef SIG_ATOMIC_MAX
<br>> #define SIG_ATOMIC_MAX __SIG_ATOMIC_MAX__
<br>> #undef SIG_ATOMIC_MIN
<br>> #define SIG_ATOMIC_MIN __SIG_ATOMIC_MIN__
<br>>
<br>> #undef SIZE_MAX
<br>> #define SIZE_MAX __SIZE_MAX__
<br>>
<br>> #undef WCHAR_MAX
<br>> #define WCHAR_MAX __WCHAR_MAX__
<br>> #undef WCHAR_MIN
<br>> #define WCHAR_MIN __WCHAR_MIN__
<br>>
<br>> #undef WINT_MAX
<br>> #define WINT_MAX __WINT_MAX__
<br>> #undef WINT_MIN
<br>> #define WINT_MIN __WINT_MIN__
<br>>
<br>> #endif /* !defined __cplusplus || defined __STDC_LIMIT_MACROS */
<br>>
<br>> #if !defined __cplusplus || defined __STDC_CONSTANT_MACROS
<br>>
<br>> #undef INT8_C
<br>> #define INT8_C(c) __INT8_C(c)
<br>> #undef INT16_C
<br>> #define INT16_C(c) __INT16_C(c)
<br>> #undef INT32_C
<br>> #define INT32_C(c) __INT32_C(c)
<br>> #undef INT64_C
<br>> #define INT64_C(c) __INT64_C(c)
<br>> #undef UINT8_C
<br>> #define UINT8_C(c) __UINT8_C(c)
<br>> #undef UINT16_C
<br>> #define UINT16_C(c) __UINT16_C(c)
<br>> #undef UINT32_C
<br>> #define UINT32_C(c) __UINT32_C(c)
<br>> #undef UINT64_C
<br>> #define UINT64_C(c) __UINT64_C(c)
<br>> #undef INTMAX_C
<br>> #define INTMAX_C(c) __INTMAX_C(c)
<br>> #undef UINTMAX_C
<br>> #define UINTMAX_C(c) __UINTMAX_C(c)
<br>>
<br>> #endif /* !defined __cplusplus || defined __STDC_CONSTANT_MACROS */
<br>>
<br>> #endif /* _GCC_STDINT_H */
<br>>
<br>>
<br>>
<br>>
<br>>
</div><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26467394&i=0" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26465271RE: Float equivalents to double functions2009-11-22T05:21:16Z2009-11-22T05:21:16ZWeddington, Eric
<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From:
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26465271&i=0" target="_top" rel="nofollow">avr-libc-dev-bounces+eric.weddington=atmel.com@...</a>
<br>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu.
<br>> org] On Behalf Of Dmitry K.
<br>> Sent: Sunday, November 22, 2009 12:23 AM
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26465271&i=1" target="_top" rel="nofollow">avr-libc-dev@...</a>
<br>> Subject: Re: [avr-libc-dev] Float equivalents to double functions
<br>>
<br>> On Sunday 22 November 2009 12:32, Andrew Hutchinson wrote:
<br>> > Could someone add float variations of common functions to avr libc -
<br>> > this would match gcc expectations for available libc functions.
<br>>
<br>> Good observation.
<br>> If no objections, I will do this.
</div><br>No objections with me. Sounds like a good idea.
<br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26465271&i=2" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26465280RE: eeprom_read_byte and clr ret_hi2009-11-22T05:20:49Z2009-11-22T05:20:49ZWeddington, Eric
<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From:
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26465280&i=0" target="_top" rel="nofollow">avr-libc-dev-bounces+eric.weddington=atmel.com@...</a>
<br>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu.
<br>> org] On Behalf Of Dmitry K.
<br>> Sent: Sunday, November 22, 2009 12:21 AM
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26465280&i=1" target="_top" rel="nofollow">avr-libc-dev@...</a>
<br>> Subject: Re: [avr-libc-dev] eeprom_read_byte and clr ret_hi
<br>>
<br>> > > eeprom_read_byte returns a uint8_t. Why does it clear r25?
<br>> > > eerd_byte.S:
<br>> > > clr ret_hi
<br>> > >
<br>> > > Does the AVR ABI require that r25 be zeroed in a function
<br>> returning a
<br>> > > single byte? If not, this instruction could be removed.
<br>>
<br>> This is a misty point.
<br>> Look an example:
<br>>
<br>> unsigned char foo1 (unsigned char *p)
<br>> {
<br>> return *p;
<br>> }
<br>>
<br>> extern unsigned char ext2 (void);
<br>> int foo2 (void)
<br>> {
<br>> return ext2() + 1;
<br>> }
<br>>
<br>> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1()
<br>> and foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not
<br>> clear R25 in foo1().
<br>>
<br>> Note, the function return value is present only in expression.
<br>> So it is promoted to integer. So it would be better to clear
<br>> R25 in foo1() only (at one place).
</div><br>I agree that that is the way it should be.
<br>
<br>> Possibly, it is needed to change eeprom_read_byte() definition
<br>> to int return value. This can reduce summary size. Opinions?
<br><br>This does not make sense to me. Eeprom_read_byte() is supposed to read, and return, a single byte. So why should it return a 16-bit int? In my mind this would just make it more confusing to the end user.
<br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26465280&i=2" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26463284Re: Float equivalents to double functions2009-11-21T23:22:28Z2009-11-21T23:22:28ZDmitry K.On Sunday 22 November 2009 12:32, Andrew Hutchinson wrote:
<br>> Could someone add float variations of common functions to avr libc -
<br>> this would match gcc expectations for available libc functions.
<br><br>Good observation.
<br>If no objections, I will do this.
<br><br>Regards,
<br>Dmitry.
<br><br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26463284&i=0" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26463279Re: eeprom_read_byte and clr ret_hi2009-11-21T23:21:07Z2009-11-21T23:21:07ZDmitry K.> > eeprom_read_byte returns a uint8_t. Why does it clear r25?
<br>> > eerd_byte.S:
<br>> > clr ret_hi
<br>> >
<br>> > Does the AVR ABI require that r25 be zeroed in a function returning a
<br>> > single byte? If not, this instruction could be removed.
<br><br>This is a misty point.
<br>Look an example:
<br><br> unsigned char foo1 (unsigned char *p)
<br> {
<br> return *p;
<br> }
<br><br> extern unsigned char ext2 (void);
<br> int foo2 (void)
<br> {
<br> return ext2() + 1;
<br> }
<br><br>Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1()
<br>and foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not
<br>clear R25 in foo1().
<br><br>Note, the function return value is present only in expression.
<br>So it is promoted to integer. So it would be better to clear
<br>R25 in foo1() only (at one place).
<br><br>Possibly, it is needed to change eeprom_read_byte() definition
<br>to int return value. This can reduce summary size. Opinions?
<br><br>Regards,
<br>Dmitry.
<br><br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26463279&i=0" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26462385Float equivalents to double functions2009-11-21T18:32:48Z2009-11-21T18:32:48ZAndrew HutchinsonCould someone add float variations of common functions to avr libc -
<br>this would match gcc expectations for available libc functions.
<br><br>As float == double there is little effort required.
<br><br>Also I note that this and similar functions would avoids this hack on
<br>TI benchmark, so it has practical use in code compatibility.
<br><br>#include <math.h>
<br><br>#ifdef __AVR__
<br># define atanf(x) atan(x)
<br># define cosf(x) cos(x)
<br># define expf(x) exp(x)
<br># define logf(x) log(x)
<br># define sinf(x) sin(x)
<br># define sqrtf(x) sqrt(x)
<br>#endif
<br><br><br>Andy
<br><br><br><br><br><br><br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462385&i=0" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26458648New AVR Dragon software (Studio 4.18rc4) won't cooperate2009-11-21T09:41:34Z2009-11-21T09:41:34Zhcz-2<br>AVR Studio 4.18 comes with AVR Dragon software which removes the 32k
<br>debugging barrier. So I happily installed AVR Studio 4.18 Release
<br>Candidate 4 from <a href="http://www.atmel.no/beta_ware/" target="_top" rel="nofollow">http://www.atmel.no/beta_ware/</a> on a Windows machine
<br>and updated my 2 Dragons.
<br><br>The result was: they cooperated neither with avrdude nor with avarice
<br>any more, reporting wrong device IDs (avarice: 0xffff for both
<br>ATmega32 and ATmega644, avrdude: 0x70febb instead of 0x139307 for an
<br>ATmega8). I had to reinstall an older version of AVR Studio and
<br>downgrade the Dragons using it to get them into a usable state again.
<br><br>Did anybody encounter the same issue? Or is an updated version of
<br>these tools available or planned?
<br><br><br>Heike
<br><br><br>_______________________________________________
<br>AVR-chat mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458648&i=0" target="_top" rel="nofollow">AVR-chat@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-chat" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-chat</a><br><p>From forum: <a href="http://old.nabble.com/AVR---General-f2011.html" embed="fixTarget[2011]" target="_top" >AVR - General</a></p>tag:old.nabble.com,2006:post-26457803[bug #28066] dragon_jtag and atxmega128A1 fails chip erase2009-11-21T07:54:51Z2009-11-21T07:54:51ZSylvain Beucler-4<br>Follow-up Comment #1, bug #28066 (project avrdude):
<br><br>Some more data
<br><br>Added usb messages sniffed from AVR Studio 4.18 (b684) pressing the "erase
<br>device" button; grouped by sequence numbers.
<br><br>It seems to be an undocumented command, 0x34 (sequence number 0x17 in the usb
<br>dump).
<br><br>(file #19100)
<br> _______________________________________________________
<br><br>Additional Item Attachment:
<br><br>File name: usb-dump-avrstudio.txt Size:0 KB
<br><br><br> _______________________________________________________
<br><br>Reply to this item at:
<br><br> <<a href="http://savannah.nongnu.org/bugs/?28066" target="_top" rel="nofollow">http://savannah.nongnu.org/bugs/?28066</a>>
<br><br>_______________________________________________
<br> Message sent via/by Savannah
<br> <a href="http://savannah.nongnu.org/" target="_top" rel="nofollow">http://savannah.nongnu.org/</a><br><br><br><br>_______________________________________________
<br>avrdude-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26457803&i=0" target="_top" rel="nofollow">avrdude-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avrdude-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avrdude-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---AVRdude---Dev-f2009.html" embed="fixTarget[2009]" target="_top" >AVR - AVRdude - Dev</a></p>tag:old.nabble.com,2006:post-26451841[bug #28066] dragon_jtag and atxmega128A1 fails chip erase2009-11-20T15:19:43Z2009-11-20T15:19:43ZSylvain Beucler-4<br>URL:
<br> <<a href="http://savannah.nongnu.org/bugs/?28066" target="_top" rel="nofollow">http://savannah.nongnu.org/bugs/?28066</a>>
<br><br> Summary: dragon_jtag and atxmega128A1 fails chip erase
<br> Project: AVR Downloader/UploaDEr
<br> Submitted by: None
<br> Submitted on: Fri 20 Nov 2009 11:19:41 PM UTC
<br> Category: None
<br> Severity: 3 - Normal
<br> Priority: 5 - Normal
<br> Item Group: None
<br> Status: None
<br> Privacy: Public
<br> Assigned to: None
<br> Originator Name: Andreas
<br> Originator Email: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26451841&i=0" target="_top" rel="nofollow">alohre@...</a>
<br> Open/Closed: Open
<br> Discussion Lock: Any
<br><br> _______________________________________________________
<br><br>Details:
<br><br>Programmer: dragon_jtag
<br>Part: ATXMEGA128A1
<br>avrdude svnrev: 879
<br><br>commandline: avrdude -vvvvvv -c dragon_jtag -p x128a1 -P usb -e 2>
<br>full-output.log
<br><br>error message:
<br>jtagmkII_chip_erase(): bad response to chip erase command:
<br>RSP_ILLEGAL_COMMAND
<br>For full output see attached logfile.
<br><br>The dragon is running latest firmware, upgraded in AVR Studio 4.18 (b684) the
<br>firmwareversion reported in the sign-on message is 6.04
<br><br><br><br><br><br> _______________________________________________________
<br><br>File Attachments:
<br><br><br>-------------------------------------------------------
<br>Date: Fri 20 Nov 2009 11:19:42 PM UTC Name: full-output.log Size: 30kB
<br>By: None
<br><br><<a href="http://savannah.nongnu.org/bugs/download.php?file_id=19096" target="_top" rel="nofollow">http://savannah.nongnu.org/bugs/download.php?file_id=19096</a>>
<br><br> _______________________________________________________
<br><br>Reply to this item at:
<br><br> <<a href="http://savannah.nongnu.org/bugs/?28066" target="_top" rel="nofollow">http://savannah.nongnu.org/bugs/?28066</a>>
<br><br>_______________________________________________
<br> Message sent via/by Savannah
<br> <a href="http://savannah.nongnu.org/" target="_top" rel="nofollow">http://savannah.nongnu.org/</a><br><br><br><br>_______________________________________________
<br>avrdude-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26451841&i=1" target="_top" rel="nofollow">avrdude-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avrdude-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avrdude-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---AVRdude---Dev-f2009.html" embed="fixTarget[2009]" target="_top" >AVR - AVRdude - Dev</a></p>tag:old.nabble.com,2006:post-26451482Re: dragon_jtag and atxmega128A1 fails on chip erase2009-11-20T14:48:03Z2009-11-20T14:48:03ZJoerg WunschAs Andreas Løhre wrote:
<br><br>> When trying to erase and program the ATXMEGA128A1 with latest svn
<br>> (rev. 879) using dragon_jtag:
<br><br>I haven't been able to test a Dragon firmware that supports the Xmega.
<br>Quite possible there are still bugs with that.
<br><br>Please file a bug tracker for this.
<br><br>--
<br>cheers, J"org .-.-. --... ...-- -.. . DL8DTL
<br><br><a href="http://www.sax.de/~joerg/" target="_top" rel="nofollow">http://www.sax.de/~joerg/</a> NIC: JW11-RIPE
<br>Never trust an operating system you don't have sources for. ;-)
<br><br><br>_______________________________________________
<br>avrdude-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26451482&i=0" target="_top" rel="nofollow">avrdude-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avrdude-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avrdude-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---AVRdude---Dev-f2009.html" embed="fixTarget[2009]" target="_top" >AVR - AVRdude - Dev</a></p>tag:old.nabble.com,2006:post-26451467Re: Re: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE2009-11-20T14:47:09Z2009-11-20T14:47:09ZJoerg WunschAs Shaun Jackman wrote:
<br><br>> My target is the AT90PWM316, which supports ISP and DebugWire, but
<br>> not JTAG. I believe I'm operating in ISP mode and not DebugWire
<br>> mode. Shouldn't this command be supported in this configuration?
<br><br>No, ISP mode doesn't know a "GO" command, because it is not a
<br>debugging mode. It asserts /RESET all the time anyway, and as soon as
<br>you leave ISP mode, the target is supposed to start, as /RESET is
<br>being deasserted.
<br><br>In contrast, the debugging modi (JTAG or debugWIRE) can arbitrarily
<br>stop and resume CPU operation; the latter is what CMND_GO is intended
<br>for.
<br><br>The attempt to send a CMND_GO command even in ISP mode is a benign bug
<br>that slipped in somehow in one of the recent releases.
<br><br>--
<br>cheers, J"org .-.-. --... ...-- -.. . DL8DTL
<br><br><a href="http://www.sax.de/~joerg/" target="_top" rel="nofollow">http://www.sax.de/~joerg/</a> NIC: JW11-RIPE
<br>Never trust an operating system you don't have sources for. ;-)
<br><br><br>_______________________________________________
<br>avrdude-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26451467&i=0" target="_top" rel="nofollow">avrdude-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avrdude-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avrdude-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---AVRdude---Dev-f2009.html" embed="fixTarget[2009]" target="_top" >AVR - AVRdude - Dev</a></p>tag:old.nabble.com,2006:post-26450934Internal oscillator calibration2009-11-20T13:56:58Z2009-11-20T13:56:58ZShaun JackmanI'm attempting to use the AVR JTAG ICE mkII to calibrate the internal
<br>8 MHz oscillator of the AT90PWM316. I downloaded the source code that
<br>runs on the target device from application note AVR0053 and compiled
<br>it using the open source assembler avra. I flashed the target device
<br>using avrdude and set its fuses to use the internal 8 MHz RC
<br>oscillator (lfuse=0xa2). I then ran avrdude -O to start the
<br>calibration, which is intended to store the result in EEPROM. However,
<br>afterwards the EEPROM is still empty.
<br><br>Has anyone successfully used the OSCCAL calibration routine specified
<br>in AVR053 with avrdude?
<br><br>The man page should mention that the target device requires special
<br>firmware to be able to use the OSCCAL feature. The man page makes it
<br>sound as though the programmer does it all automagically with no help
<br>from the target.
<br><br>Thanks,
<br>Shaun
<br><br><br>_______________________________________________
<br>avrdude-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26450934&i=0" target="_top" rel="nofollow">avrdude-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avrdude-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avrdude-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---AVRdude---Dev-f2009.html" embed="fixTarget[2009]" target="_top" >AVR - AVRdude - Dev</a></p>tag:old.nabble.com,2006:post-26450872dragon_jtag and atxmega128A1 fails on chip erase2009-11-20T13:52:32Z2009-11-20T13:52:32ZAndreas LøhreHello
<br><br>When trying to erase and program the ATXMEGA128A1 with latest svn
<br>(rev. 879) using dragon_jtag:
<br>avrdude -vvvvv -c dragon_jtag -p x128a1 -P usb -e -U flash:w:testing.hex
<br>it errs out with the error below.
<br><br>There is no problem programming the part without the erase option.
<br><br><br><br>avrdude: erasing chip
<br>avrdude: jtagmkII_chip_erase(): Sending chip erase command:
<br>avrdude: jtagmkII_send(): sending 1 bytes
<br>avrdude: Sent: . [1b] . [16] . [00] . [01] . [00] . [00] . [00] . [0e]
<br>. [13] . [a9] . [e2]
<br>avrdude: jtagmkII_recv():
<br>avrdude: Recv: . [1b]
<br>avrdude: Recv: . [16]
<br>avrdude: Recv: . [00]
<br>avrdude: Recv: . [01]
<br>avrdude: Recv: . [00]
<br>avrdude: Recv: . [00]
<br>avrdude: Recv: . [00]
<br>avrdude: Recv: . [0e]
<br>avrdude: Recv: . [aa]
<br>avrdude: Recv: . [e3]
<br>avrdude: Recv: . [ca]
<br><br>avrdude: jtagmkII_recv(): Got message seqno 22 (command_sequence == 22)
<br><br>Raw message:
<br>0xaa
<br>Illegal command
<br><br>avrdude: jtagmkII_chip_erase(): bad response to chip erase command:
<br>RSP_ILLEGAL_COMMAND
<br>avrdude: jtagmkII_program_disable(): Sending leave progmode command:
<br>avrdude: jtagmkII_send(): sending 1 bytes
<br>avrdude: Sent: . [1b] . [17] . [00] . [01] . [00] . [00] . [00] . [0e]
<br>. [15] [20] . [06]
<br>avrdude: jtagmkII_recv():
<br>avrdude: Recv: . [1b]
<br>avrdude: Recv: . [17]
<br>avrdude: Recv: . [00]
<br>avrdude: Recv: . [01]
<br>avrdude: Recv: . [00]
<br>avrdude: Recv: . [00]
<br>avrdude: Recv: . [00]
<br>avrdude: Recv: . [0e]
<br>avrdude: Recv: . [80]
<br>avrdude: Recv: . [04]
<br>avrdude: Recv: . [c5]
<br><br>avrdude: jtagmkII_recv(): Got message seqno 23 (command_sequence == 23)
<br><br>Raw message:
<br>0x80
<br>OK
<br><br><br><br><br>Dragon info:
<br><br>JTAG clock : 891.7 kHz (1.1 us)
<br>JTAG ICE mkII sign-on message:
<br>Communications protocol version: 1
<br>M_MCU:
<br> boot-loader FW version: 255
<br> firmware version: 6.04
<br> hardware version: 1
<br>S_MCU:
<br> boot-loader FW version: 255
<br> firmware version: 6.04
<br> hardware version: 7
<br>Serial number: 00:a2:00:00:77:21
<br>Device ID: AVRDRAGON
<br><br><br>.Andreas
<br><br><br>_______________________________________________
<br>avrdude-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26450872&i=0" target="_top" rel="nofollow">avrdude-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avrdude-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avrdude-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---AVRdude---Dev-f2009.html" embed="fixTarget[2009]" target="_top" >AVR - AVRdude - Dev</a></p>tag:old.nabble.com,2006:post-26450815Re: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE2009-11-20T13:47:45Z2009-11-20T13:47:45ZShaun Jackman2009/11/17 Shaun Jackman <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26450815&i=0" target="_top" rel="nofollow">sjackman@...</a>>:
<br>> I am using a Atmel JTAG ICE mkII with a AT90PWM316. Whenever avrdude
<br>> exits, it prints the following error message:
<br>>
<br>> avrdude: jtagmkII_close(): bad response to GO command:
<br><br>RSP_ILLEGAL_EMULATOR_MODE
<br>The application note AVR067 says that
<br><br>CMND_GO
<br>RSP_ILLEGAL_EMULATOR_MODE
<br>The operation cannot be performed in this emulator mode. (JTAG / DebugWire).
<br><br>My target is the AT90PWM316, which supports ISP and DebugWire, but not
<br>JTAG. I believe I'm operating in ISP mode and not DebugWire mode.
<br>Shouldn't this command be supported in this configuration?
<br><br>Cheers,
<br>Shaun
<br><br><br>_______________________________________________
<br>avrdude-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26450815&i=1" target="_top" rel="nofollow">avrdude-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avrdude-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avrdude-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---AVRdude---Dev-f2009.html" embed="fixTarget[2009]" target="_top" >AVR - AVRdude - Dev</a></p>tag:old.nabble.com,2006:post-26444816RE: How to move VTABLE to FLASH?2009-11-20T07:02:49Z2009-11-20T07:02:49ZStu Bell> As you know when programming in C++ on AVR the gcc puts the
<br>> class VTABLE in SRAM, that is ok, but wastes precious space.
<br>> VTABLE is generated during compilation and is constant during
<br>> program execution, so I think it is better to put it into
<br>> FLASH memory. Of course to do that I need to patch gcc, and
<br>> here is my problem. I'm just beginner and making such
<br>> modifications in gcc is just beyond my skills. So maybe
<br>> someone can do that, or give me some clues how to start? I
<br>> know that I need to change some insns, but how to start?
<br><br>After you've read the tutorial on C++ and GCC:
<br><<a href="http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=59453" target="_top" rel="nofollow">http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=59453</a><br>>
<br><br>check out the huge list of links for newbies:
<br><<a href="http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=70673" target="_top" rel="nofollow">http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=70673</a><br>>
<br><br>Best regards,
<br><br>Stu Bell
<br>DataPlay (DPHI, Inc.)
<br><br><br><br>_______________________________________________
<br>AVR-GCC-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26444816&i=0" target="_top" rel="nofollow">AVR-GCC-list@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-gcc-list" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-gcc-list</a><br><p>From forum: <a href="http://old.nabble.com/AVR---gcc-f2010.html" embed="fixTarget[2010]" target="_top" >AVR - gcc</a></p>tag:old.nabble.com,2006:post-26441420Re: assembly-c mix and interrupts2009-11-20T02:47:45Z2009-11-20T02:47:45ZDavid Brown-4Julius Luukko wrote:
<div class='shrinkable-quote'><br>> (note to the list: Alexander replied me off-list but I am replying to the list
<br>> also)
<br>>
<br>> On Thursday 19 November 2009, you wrote:
<br>>> Thanks for your reply,
<br>>> I understand that it is VERY important to store/restore the SREG in an
<br>>> interrupt function. Can you please confirm for me that the ISR() c macro
<br>>> does this for me and also, does your advice extend to functions outside the
<br>>> interrupt routine? I have found reference material stating which registers
<br>>> should be stored, but none of them mention the SREG in any way.
<br>>>
</div><br>The register set is divided into "volatile" or "call-used" registers,
<br>"non-volatile" or "call-saved" registers, and fixed-function registers.
<br> This division is chosen by avr-gcc - it is not hardware dependent.
<br>When working with assembly, you can make up your own rules, but this is
<br>how things interact with C code.
<br><br>When the compiler is generated code for a function, it can assume that
<br>it can do as it likes for the call-used registers, but if it uses the
<br>call-saved registers it must preserve them at the entry to the function,
<br>and restore them on exit. Similarly, it can assume that whenever it
<br>calls another function, the call-used registers will be trashed but the
<br>call-saved registers will be preserved.
<br><br>R0 is used as a temporary register - individual instruction sequences
<br>will use it freely. R1 is assumed to be always 0, although some code
<br>sequences will use it temporarily (and restore it to 0 afterwards). The
<br>SREG is considered a "call-used" register.
<br><br>So any function generated by the compiler, or compatible functions
<br>written in assembly by hand, can freely use the call-used registers
<br>(SREG, r18-r27, r30-r31) without preserving or restoring them. But if
<br>it wants to use the call-saved registers (r2-r17, r28-r29), it must save
<br>them on entry and restore them on exit.
<br><br>An interrupt routine must also preserve any call-used registers it
<br>needs, including SREG and r0. It must also preserve the current r1 and
<br>set it to 0 before certain compiler-generated code is executed. If the
<br>interrupt routine is going to call other functions, it must preserve
<br>/all/ the call-used registers, since the other functions may trash them.
<br> On the other hand, it does not need to preserve any of the call-saved
<br>registers, as the called function will preserve these as needed.
<br><br>>
<br>> I can't provide you with a reference but AFAIK this is done on the gcc level
<br>> (which I know nothing about). The actual definition in the avr-libc source
<br>> does not show it:
<br>>
<br>> <<a href="http://cvs.savannah.gnu.org/viewvc/avr-libc/include/avr/interrupt.h?revision=1.25.2.1&root=avr-libc&view=markup" target="_top" rel="nofollow">http://cvs.savannah.gnu.org/viewvc/avr-libc/include/avr/interrupt.h?revision=1.25.2.1&root=avr-libc&view=markup</a>>
<br>>
<br><br>(Always put links inside < and > brackets - that way email programs
<br>won't mangle them by splitting the line.)
<br><br>> Anyway, SREG should always be stored to the stack when using the ISR() macro.
<br>> Maybe someone can provide with a reference to prove this.
<br>>
<br><br>It is, as you say, done at the gcc level. The provided ISR macros are
<br>wrappers that give the function the "signal" attribute, which causes gcc
<br>to preserve SREG and all the volatile call-used registers (if they are
<br>used), and to use the "rti" instruction at the end.
<br><br>The compiler gets this stuff right (if it didn't, someone would have
<br>noticed before now!) - it is much easier to rely on the compiler to
<br>generate correct code here from an ISR written in C, than to try and
<br>write it by hand in assembly.
<br><br>mvh.,
<br><br>David
<br><br><br><div class='shrinkable-quote'><br>> An excerpt from a C generated ISR () shows an example (I don't remember which
<br>> version of gcc or avr-libc was used, this was just easily found):
<br>>
<br>> 00000108 <__vector_18>:
<br>> 108: 1f 92 push r1
<br>> 10a: 0f 92 push r0
<br>> 10c: 0f b6 in r0, 0x3f ; 63
<br>> 10e: 0f 92 push r0
<br>> 110: 11 24 eor r1, r1
<br>> 112: 8f 93 push r24
<br>> 114: 9f 93 push r25
<br>> 116: ef 93 push r30
<br>> 118: ff 93 push r31
<br>>
<br>> SREG is memory mapped to 0x3f. As you can see, you can't push SREG directly,
<br>> you must use a register for that and therefore you must push the register
<br>> first.
<br>>
<br>> One thing to note also in the excerpt is the clearing of r1 (eor r1, r1). If
<br>> you intend to call C functions from your assembly ISR, you must do this also.
<br>> This might provide you with some more information
<br>>
<br>> <a href="http://www.nongnu.org/avr-libc/user-manual/inline_asm.html" target="_top" rel="nofollow">http://www.nongnu.org/avr-libc/user-manual/inline_asm.html</a><br>>
<br>> Julius
<br>>
<br>>>> From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26441420&i=0" target="_top" rel="nofollow">Julius.Luukko@...</a>
<br>>>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26441420&i=1" target="_top" rel="nofollow">avr-gcc-list@...</a>
<br>>>> Subject: Re: [avr-gcc-list] assembly-c mix and interrupts
<br>>>> Date: Thu, 19 Nov 2009 15:34:16 +0200
<br>>>> CC: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26441420&i=2" target="_top" rel="nofollow">zhpctw3dash@...</a>
<br>>>>
<br>>>> On Thursday 19 November 2009, darkschine wrote:
<br>>>>> Before I continue, I would like to suggest a resolution to my problem.
<br>>>>> I am using the ATmega328P
<br>>>>> My assembly code follows a standard that ALL registers used are pushed
<br>>>>> and popped from the stack. However, my assembly code does NOT store the
<br>>>>> SREG. Could this be causing my problems?
<br>>>> You can do next to nothing without modifying the SREG. Why don't you add
<br>>>> pushing the SREG also to the stack. I wouldn't dare to not to save it.
<br>>>>
<br>>>> --
<br>>>> Julius
<br>>> _________________________________________________________________
<br>>> Looking for a date? View photos of singles in your area!
<br>>> <a href="http://clk.atdmt.com/NMN/go/150855801/direct/01/" target="_top" rel="nofollow">http://clk.atdmt.com/NMN/go/150855801/direct/01/</a><br>>
<br>>
</div><br><br><br>_______________________________________________
<br>AVR-GCC-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26441420&i=3" target="_top" rel="nofollow">AVR-GCC-list@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-gcc-list" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-gcc-list</a><br><p>From forum: <a href="http://old.nabble.com/AVR---gcc-f2010.html" embed="fixTarget[2010]" target="_top" >AVR - gcc</a></p>tag:old.nabble.com,2006:post-26441192[bug #28058] parameter checking in pgm_read_xxx()2009-11-20T02:32:07Z2009-11-20T02:32:07ZSylvain Beucler-4<br>URL:
<br> <<a href="http://savannah.nongnu.org/bugs/?28058" target="_top" rel="nofollow">http://savannah.nongnu.org/bugs/?28058</a>>
<br><br> Summary: parameter checking in pgm_read_xxx()
<br> Project: AVR C Runtime Library
<br> Submitted by: wek
<br> Submitted on: Fri 20 Nov 2009 10:32:06 AM GMT
<br> Category: Feature Request
<br> Severity: 3 - Normal
<br> Priority: 5 - Normal
<br> Item Group: Header files
<br> Status: None
<br> Percent Complete: 0%
<br> Assigned to: None
<br> Open/Closed: Open
<br> Discussion Lock: Any
<br> Release: Any
<br> Fixed Release: None
<br><br> _______________________________________________________
<br><br>Details:
<br><br>The pgm_read_xxx() functions in <avr/pgmspace.h> are currently implemented as
<br>macros, casting the parameter to (uint16_t).
<br><br>While the parameter is supposed to be a pointer, this enables to use any
<br>garbage (read: non-pointer expression used by error) quietly.
<br><br>Opposed to this are the similar accessing functions in eeprom.h.
<br><br>It is therefore suggested, that these macros to be replaced by the following
<br>constructions:
<br><br>// #define pgm_read_byte(address_short) pgm_read_byte_near(address_short)
<br>__attribute__((__always_inline__)) static uint8_t pgm_read_byte(const PROGMEM
<br>uint8_t *);
<br>static uint8_t pgm_read_byte(const PROGMEM uint8_t *addr) {
<br> return __LPM((uint16_t)(addr));
<br>}
<br><br><br>// #define pgm_read_word(address_short) pgm_read_word_near(address_short)
<br>__attribute__((__always_inline__)) static uint16_t pgm_read_word(const
<br>PROGMEM uint16_t *);
<br>static uint16_t pgm_read_word(const PROGMEM uint16_t *addr) {
<br> return __LPM_word((uint16_t)(addr));
<br>}
<br><br><br>// #define pgm_read_dword(address_short)
<br>pgm_read_dword_near(address_short)
<br>__attribute__((__always_inline__)) static uint32_t pgm_read_dword(const
<br>PROGMEM uint32_t *);
<br>static uint32_t pgm_read_dword(const PROGMEM uint32_t *addr) {
<br> return __LPM_dword((uint16_t)(addr));
<br>}
<br><br>I am not expert enough to judge whether the functions may be tagged also with
<br>the __pure__ attribute.
<br><br>A discussion on the topic is on
<br><a href="http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=85490" target="_top" rel="nofollow">http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=85490</a> .
<br><br>Jan Waclawek
<br><br><br><br><br> _______________________________________________________
<br><br>Reply to this item at:
<br><br> <<a href="http://savannah.nongnu.org/bugs/?28058" target="_top" rel="nofollow">http://savannah.nongnu.org/bugs/?28058</a>>
<br><br>_______________________________________________
<br> Message sent via/by Savannah
<br> <a href="http://savannah.nongnu.org/" target="_top" rel="nofollow">http://savannah.nongnu.org/</a><br><br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26441192&i=0" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26440659Re: assembly-c mix and interrupts2009-11-20T01:41:58Z2009-11-20T01:41:58ZJulius Luukko(note to the list: Alexander replied me off-list but I am replying to the list
<br>also)
<br><br>On Thursday 19 November 2009, you wrote:
<br>> Thanks for your reply,
<br>> I understand that it is VERY important to store/restore the SREG in an
<br>> interrupt function. Can you please confirm for me that the ISR() c macro
<br>> does this for me and also, does your advice extend to functions outside the
<br>> interrupt routine? I have found reference material stating which registers
<br>> should be stored, but none of them mention the SREG in any way.
<br>>
<br><br>I can't provide you with a reference but AFAIK this is done on the gcc level
<br>(which I know nothing about). The actual definition in the avr-libc source
<br>does not show it:
<br><br><a href="http://cvs.savannah.gnu.org/viewvc/avr-" target="_top" rel="nofollow">http://cvs.savannah.gnu.org/viewvc/avr-</a><br>libc/include/avr/interrupt.h?revision=1.25.2.1&root=avr-libc&view=markup
<br><br>Anyway, SREG should always be stored to the stack when using the ISR() macro.
<br>Maybe someone can provide with a reference to prove this.
<br><br>An excerpt from a C generated ISR () shows an example (I don't remember which
<br>version of gcc or avr-libc was used, this was just easily found):
<br><br>00000108 <__vector_18>:
<br> 108: 1f 92 push r1
<br> 10a: 0f 92 push r0
<br> 10c: 0f b6 in r0, 0x3f ; 63
<br> 10e: 0f 92 push r0
<br> 110: 11 24 eor r1, r1
<br> 112: 8f 93 push r24
<br> 114: 9f 93 push r25
<br> 116: ef 93 push r30
<br> 118: ff 93 push r31
<br><br>SREG is memory mapped to 0x3f. As you can see, you can't push SREG directly,
<br>you must use a register for that and therefore you must push the register
<br>first.
<br><br>One thing to note also in the excerpt is the clearing of r1 (eor r1, r1). If
<br>you intend to call C functions from your assembly ISR, you must do this also.
<br>This might provide you with some more information
<br><br><a href="http://www.nongnu.org/avr-libc/user-manual/inline_asm.html" target="_top" rel="nofollow">http://www.nongnu.org/avr-libc/user-manual/inline_asm.html</a><br><br>Julius
<br><div class='shrinkable-quote'><br>> > From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26440659&i=0" target="_top" rel="nofollow">Julius.Luukko@...</a>
<br>> > To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26440659&i=1" target="_top" rel="nofollow">avr-gcc-list@...</a>
<br>> > Subject: Re: [avr-gcc-list] assembly-c mix and interrupts
<br>> > Date: Thu, 19 Nov 2009 15:34:16 +0200
<br>> > CC: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26440659&i=2" target="_top" rel="nofollow">zhpctw3dash@...</a>
<br>> >
<br>> > On Thursday 19 November 2009, darkschine wrote:
<br>> > > Before I continue, I would like to suggest a resolution to my problem.
<br>> > > I am using the ATmega328P
<br>> > > My assembly code follows a standard that ALL registers used are pushed
<br>> > > and popped from the stack. However, my assembly code does NOT store the
<br>> > > SREG. Could this be causing my problems?
<br>> >
<br>> > You can do next to nothing without modifying the SREG. Why don't you add
<br>> > pushing the SREG also to the stack. I wouldn't dare to not to save it.
<br>> >
<br>> > --
<br>> > Julius
<br>>
<br>> _________________________________________________________________
<br>> Looking for a date? View photos of singles in your area!
<br>> <a href="http://clk.atdmt.com/NMN/go/150855801/direct/01/" target="_top" rel="nofollow">http://clk.atdmt.com/NMN/go/150855801/direct/01/</a></div><br><br>--
<br>D.Sc. Julius Luukko
<br>Laboratory of Control Engineering and Digital Systems
<br>Lappeenranta University of Technology, FINLAND
<br>phone:+358-5-621 6713, fax:+358-5-621 6799, www: <a href="http://www.ee.lut.fi" target="_top" rel="nofollow">http://www.ee.lut.fi</a><br><br><br><br>_______________________________________________
<br>AVR-GCC-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26440659&i=3" target="_top" rel="nofollow">AVR-GCC-list@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-gcc-list" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-gcc-list</a><br><p>From forum: <a href="http://old.nabble.com/AVR---gcc-f2010.html" embed="fixTarget[2010]" target="_top" >AVR - gcc</a></p>tag:old.nabble.com,2006:post-26439509Re: assembly-c mix and interrupts2009-11-19T23:41:26Z2009-11-19T23:41:26ZErik Christiansen-2On Thu, Nov 19, 2009 at 05:08:45AM -0800, darkschine wrote:
<br>> My assembly code follows a standard that ALL registers used are pushed and
<br>> popped from the stack. However, my assembly code does NOT store the SREG.
<br>> Could this be causing my problems?
<br><br>If it is in the interrupt routine that cpu status is not preserved, then
<br>it must be obvious that execution of any interrupted code with a
<br>condition test at the return point will at times be corrupted. And that
<br>can of course be anywhere in the code.
<br><br>If the assembler code is only reached by call and return, then I expect
<br>your problem lies elsewhere, unless you're modifying r1, and not leaving
<br>it cleared on return.
<br><br>Also, there is limited merit in preserving any register that your code
<br>does not use, or the volatile registers: r18-r27, r30-r31.
<br><br>> I am coming across a problem in a fairly large project where the system
<br>> seems to display incorrect data on the LCD screen and eventually reset
<br>> itself. Other symptoms include displaying incorrect data when string
<br>> constants are transfered to the LCD. The worst case of the problem has been
<br>> uninitiated transfer to a part in the program requiring text input from the
<br>> user.
<br><br>That could perhaps be stack corruption. Have you triple checked the
<br>number and order of every assembler push and pop, using three different
<br>people?
<br><br>> The problem has proved very difficult to debug since modifying the code can
<br>> cause unpredictable behaviour of the error.
<br><br>But what happened when the SREG was pushed, to see if that would help?
<br><br>> I believe that the problem first appeared as a global variable changing its
<br>> value for no reason. The problem was corrected by declaring the global
<br>> variable as static which I then considered to be the standard, but am now
<br>> thinking it only masked the problem by storing the variable in a different
<br>> location or modifying the compilation structure.
<br><br>It is good to see you're recovering from the denial of clear evidence of
<br>deeper problems. The system will never be reliable until the underlying
<br>problem is found and removed.
<br><br>> Now, all functions seem to be operating correctly and all unit tests pass,
<br>> until interrupt routines are enabled.
<br><br>If it is in the interrupt routine that cpu status is not preserved, then
<br>it must be obvious that execution of any interrupted code with a
<br>condition test at the return point will at times be corrupted.
<br><br>> Can anyone provide any insight into this problem or provide some debugging
<br>> techniques to help identify it?
<br><br>If the "uninitiated transfer" occurs repeatedly, then displaying the
<br>return address found on the stack reveals where the "uninitiated transfer"
<br>occurred. If there is no call there, then it is likely that you returned
<br>to the start of the input routine, perhaps using a data value as return
<br>address.
<br><br>It is often necessary to fix the biggest bug in order to spot the
<br>smaller ones hiding behind it. Attacked methodically, it can be quite
<br>gratifying, though mostly when it's over, I must admit. :-)
<br><br>Erik
<br><br>P.S. I've written all my ISRs in assembler, on a variety of 8 and 32 bit
<br>platforms, and it is not intrinsically risky, but if the absolutely
<br>essential need to save cpu status is not immediately clear, then writing
<br>them in C could be a wise alternative, which simultaneously eliminates
<br>any push-pop mismatch issues.
<br><br><br>_______________________________________________
<br>AVR-GCC-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26439509&i=0" target="_top" rel="nofollow">AVR-GCC-list@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-gcc-list" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-gcc-list</a><br><p>From forum: <a href="http://old.nabble.com/AVR---gcc-f2010.html" embed="fixTarget[2010]" target="_top" >AVR - gcc</a></p>tag:old.nabble.com,2006:post-26437418stdint.h problem with gcc2009-11-19T18:11:30Z2009-11-19T18:11:30ZAndrew HutchinsonI have been going through the gcc tests for V4.5 and come across some
<br>issues with avr-lic stdint.h
<br><br>The tests that fails are gcc/gcc/testsuite/gcc.dg/c99-stdint-1.c
<br><br>gcc will create it's own stdint.h and this is fine for V4.5. I have
<br>attached this for reference.
<br><br>The definition of UINT8_MAX is unsigned e.g. 255U - this fails test. 255
<br>is ok
<br>wchar limits are not defined- ok we dont have wchar.h but we should
<br>still define the types.
<br><br>There is another issue related to ptrdiff type. This is posted as gcc
<br>bug - since it is possible that this particular subtest is inappropriate
<br>for avr.
<br><br><a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42114" target="_top" rel="nofollow">http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42114</a><br><br>=================================================================
<br>/* Copyright (C) 2008, 2009 Free Software Foundation, Inc.
<br><br>This file is part of GCC.
<br><br>GCC is free software; you can redistribute it and/or modify
<br>it under the terms of the GNU General Public License as published by
<br>the Free Software Foundation; either version 3, or (at your option)
<br>any later version.
<br><br>GCC is distributed in the hope that it will be useful,
<br>but WITHOUT ANY WARRANTY; without even the implied warranty of
<br>MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
<br>GNU General Public License for more details.
<br><br>Under Section 7 of GPL version 3, you are granted additional
<br>permissions described in the GCC Runtime Library Exception, version
<br>3.1, as published by the Free Software Foundation.
<br><br>You should have received a copy of the GNU General Public License and
<br>a copy of the GCC Runtime Library Exception along with this program;
<br>see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
<br><<a href="http://www.gnu.org/licenses/" target="_top" rel="nofollow">http://www.gnu.org/licenses/</a>>. */
<br><br>/*
<br> * ISO C Standard: 7.18 Integer types <stdint.h>
<br> */
<br><br>#ifndef _GCC_STDINT_H
<br>#define _GCC_STDINT_H
<br><br>/* 7.8.1.1 Exact-width integer types */
<br><br>#ifdef __INT8_TYPE__
<br>typedef __INT8_TYPE__ int8_t;
<br>#endif
<br>#ifdef __INT16_TYPE__
<br>typedef __INT16_TYPE__ int16_t;
<br>#endif
<br>#ifdef __INT32_TYPE__
<br>typedef __INT32_TYPE__ int32_t;
<br>#endif
<br>#ifdef __INT64_TYPE__
<br>typedef __INT64_TYPE__ int64_t;
<br>#endif
<br>#ifdef __UINT8_TYPE__
<br>typedef __UINT8_TYPE__ uint8_t;
<br>#endif
<br>#ifdef __UINT16_TYPE__
<br>typedef __UINT16_TYPE__ uint16_t;
<br>#endif
<br>#ifdef __UINT32_TYPE__
<br>typedef __UINT32_TYPE__ uint32_t;
<br>#endif
<br>#ifdef __UINT64_TYPE__
<br>typedef __UINT64_TYPE__ uint64_t;
<br>#endif
<br><br>/* 7.8.1.2 Minimum-width integer types */
<br><br>typedef __INT_LEAST8_TYPE__ int_least8_t;
<br>typedef __INT_LEAST16_TYPE__ int_least16_t;
<br>typedef __INT_LEAST32_TYPE__ int_least32_t;
<br>typedef __INT_LEAST64_TYPE__ int_least64_t;
<br>typedef __UINT_LEAST8_TYPE__ uint_least8_t;
<br>typedef __UINT_LEAST16_TYPE__ uint_least16_t;
<br>typedef __UINT_LEAST32_TYPE__ uint_least32_t;
<br>typedef __UINT_LEAST64_TYPE__ uint_least64_t;
<br><br>/* 7.8.1.3 Fastest minimum-width integer types */
<br><br>typedef __INT_FAST8_TYPE__ int_fast8_t;
<br>typedef __INT_FAST16_TYPE__ int_fast16_t;
<br>typedef __INT_FAST32_TYPE__ int_fast32_t;
<br>typedef __INT_FAST64_TYPE__ int_fast64_t;
<br>typedef __UINT_FAST8_TYPE__ uint_fast8_t;
<br>typedef __UINT_FAST16_TYPE__ uint_fast16_t;
<br>typedef __UINT_FAST32_TYPE__ uint_fast32_t;
<br>typedef __UINT_FAST64_TYPE__ uint_fast64_t;
<br><br>/* 7.8.1.4 Integer types capable of holding object pointers */
<br><br>#ifdef __INTPTR_TYPE__
<br>typedef __INTPTR_TYPE__ intptr_t;
<br>#endif
<br>#ifdef __UINTPTR_TYPE__
<br>typedef __UINTPTR_TYPE__ uintptr_t;
<br>#endif
<br><br>/* 7.8.1.5 Greatest-width integer types */
<br><br>typedef __INTMAX_TYPE__ intmax_t;
<br>typedef __UINTMAX_TYPE__ uintmax_t;
<br><br>#if !defined __cplusplus || defined __STDC_LIMIT_MACROS
<br><br>/* 7.18.2 Limits of specified-width integer types */
<br><br>#ifdef __INT8_MAX__
<br># undef INT8_MAX
<br># define INT8_MAX __INT8_MAX__
<br># undef INT8_MIN
<br># define INT8_MIN (-INT8_MAX - 1)
<br>#endif
<br>#ifdef __UINT8_MAX__
<br># undef UINT8_MAX
<br># define UINT8_MAX __UINT8_MAX__
<br>#endif
<br>#ifdef __INT16_MAX__
<br># undef INT16_MAX
<br># define INT16_MAX __INT16_MAX__
<br># undef INT16_MIN
<br># define INT16_MIN (-INT16_MAX - 1)
<br>#endif
<br>#ifdef __UINT16_MAX__
<br># undef UINT16_MAX
<br># define UINT16_MAX __UINT16_MAX__
<br>#endif
<br>#ifdef __INT32_MAX__
<br># undef INT32_MAX
<br># define INT32_MAX __INT32_MAX__
<br># undef INT32_MIN
<br># define INT32_MIN (-INT32_MAX - 1)
<br>#endif
<br>#ifdef __UINT32_MAX__
<br># undef UINT32_MAX
<br># define UINT32_MAX __UINT32_MAX__
<br>#endif
<br>#ifdef __INT64_MAX__
<br># undef INT64_MAX
<br># define INT64_MAX __INT64_MAX__
<br># undef INT64_MIN
<br># define INT64_MIN (-INT64_MAX - 1)
<br>#endif
<br>#ifdef __UINT64_MAX__
<br># undef UINT64_MAX
<br># define UINT64_MAX __UINT64_MAX__
<br>#endif
<br><br>#undef INT_LEAST8_MAX
<br>#define INT_LEAST8_MAX __INT_LEAST8_MAX__
<br>#undef INT_LEAST8_MIN
<br>#define INT_LEAST8_MIN (-INT_LEAST8_MAX - 1)
<br>#undef UINT_LEAST8_MAX
<br>#define UINT_LEAST8_MAX __UINT_LEAST8_MAX__
<br>#undef INT_LEAST16_MAX
<br>#define INT_LEAST16_MAX __INT_LEAST16_MAX__
<br>#undef INT_LEAST16_MIN
<br>#define INT_LEAST16_MIN (-INT_LEAST16_MAX - 1)
<br>#undef UINT_LEAST16_MAX
<br>#define UINT_LEAST16_MAX __UINT_LEAST16_MAX__
<br>#undef INT_LEAST32_MAX
<br>#define INT_LEAST32_MAX __INT_LEAST32_MAX__
<br>#undef INT_LEAST32_MIN
<br>#define INT_LEAST32_MIN (-INT_LEAST32_MAX - 1)
<br>#undef UINT_LEAST32_MAX
<br>#define UINT_LEAST32_MAX __UINT_LEAST32_MAX__
<br>#undef INT_LEAST64_MAX
<br>#define INT_LEAST64_MAX __INT_LEAST64_MAX__
<br>#undef INT_LEAST64_MIN
<br>#define INT_LEAST64_MIN (-INT_LEAST64_MAX - 1)
<br>#undef UINT_LEAST64_MAX
<br>#define UINT_LEAST64_MAX __UINT_LEAST64_MAX__
<br><br>#undef INT_FAST8_MAX
<br>#define INT_FAST8_MAX __INT_FAST8_MAX__
<br>#undef INT_FAST8_MIN
<br>#define INT_FAST8_MIN (-INT_FAST8_MAX - 1)
<br>#undef UINT_FAST8_MAX
<br>#define UINT_FAST8_MAX __UINT_FAST8_MAX__
<br>#undef INT_FAST16_MAX
<br>#define INT_FAST16_MAX __INT_FAST16_MAX__
<br>#undef INT_FAST16_MIN
<br>#define INT_FAST16_MIN (-INT_FAST16_MAX - 1)
<br>#undef UINT_FAST16_MAX
<br>#define UINT_FAST16_MAX __UINT_FAST16_MAX__
<br>#undef INT_FAST32_MAX
<br>#define INT_FAST32_MAX __INT_FAST32_MAX__
<br>#undef INT_FAST32_MIN
<br>#define INT_FAST32_MIN (-INT_FAST32_MAX - 1)
<br>#undef UINT_FAST32_MAX
<br>#define UINT_FAST32_MAX __UINT_FAST32_MAX__
<br>#undef INT_FAST64_MAX
<br>#define INT_FAST64_MAX __INT_FAST64_MAX__
<br>#undef INT_FAST64_MIN
<br>#define INT_FAST64_MIN (-INT_FAST64_MAX - 1)
<br>#undef UINT_FAST64_MAX
<br>#define UINT_FAST64_MAX __UINT_FAST64_MAX__
<br><br>#ifdef __INTPTR_MAX__
<br># undef INTPTR_MAX
<br># define INTPTR_MAX __INTPTR_MAX__
<br># undef INTPTR_MIN
<br># define INTPTR_MIN (-INTPTR_MAX - 1)
<br>#endif
<br>#ifdef __UINTPTR_MAX__
<br># undef UINTPTR_MAX
<br># define UINTPTR_MAX __UINTPTR_MAX__
<br>#endif
<br><br>#undef INTMAX_MAX
<br>#define INTMAX_MAX __INTMAX_MAX__
<br>#undef INTMAX_MIN
<br>#define INTMAX_MIN (-INTMAX_MAX - 1)
<br>#undef UINTMAX_MAX
<br>#define UINTMAX_MAX __UINTMAX_MAX__
<br><br>/* 7.18.3 Limits of other integer types */
<br><br>#undef PTRDIFF_MAX
<br>#define PTRDIFF_MAX __PTRDIFF_MAX__
<br>#undef PTRDIFF_MIN
<br>#define PTRDIFF_MIN (-PTRDIFF_MAX - 1)
<br><br>#undef SIG_ATOMIC_MAX
<br>#define SIG_ATOMIC_MAX __SIG_ATOMIC_MAX__
<br>#undef SIG_ATOMIC_MIN
<br>#define SIG_ATOMIC_MIN __SIG_ATOMIC_MIN__
<br><br>#undef SIZE_MAX
<br>#define SIZE_MAX __SIZE_MAX__
<br><br>#undef WCHAR_MAX
<br>#define WCHAR_MAX __WCHAR_MAX__
<br>#undef WCHAR_MIN
<br>#define WCHAR_MIN __WCHAR_MIN__
<br><br>#undef WINT_MAX
<br>#define WINT_MAX __WINT_MAX__
<br>#undef WINT_MIN
<br>#define WINT_MIN __WINT_MIN__
<br><br>#endif /* !defined __cplusplus || defined __STDC_LIMIT_MACROS */
<br><br>#if !defined __cplusplus || defined __STDC_CONSTANT_MACROS
<br><br>#undef INT8_C
<br>#define INT8_C(c) __INT8_C(c)
<br>#undef INT16_C
<br>#define INT16_C(c) __INT16_C(c)
<br>#undef INT32_C
<br>#define INT32_C(c) __INT32_C(c)
<br>#undef INT64_C
<br>#define INT64_C(c) __INT64_C(c)
<br>#undef UINT8_C
<br>#define UINT8_C(c) __UINT8_C(c)
<br>#undef UINT16_C
<br>#define UINT16_C(c) __UINT16_C(c)
<br>#undef UINT32_C
<br>#define UINT32_C(c) __UINT32_C(c)
<br>#undef UINT64_C
<br>#define UINT64_C(c) __UINT64_C(c)
<br>#undef INTMAX_C
<br>#define INTMAX_C(c) __INTMAX_C(c)
<br>#undef UINTMAX_C
<br>#define UINTMAX_C(c) __UINTMAX_C(c)
<br><br>#endif /* !defined __cplusplus || defined __STDC_CONSTANT_MACROS */
<br><br>#endif /* _GCC_STDINT_H */
<br><br><br><br><br><br><br>_______________________________________________
<br>AVR-libc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26437418&i=0" target="_top" rel="nofollow">AVR-libc-dev@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-libc-dev" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-libc-dev</a><br><p>From forum: <a href="http://old.nabble.com/AVR---Libc---Dev-f2012.html" embed="fixTarget[2012]" target="_top" >AVR - Libc - Dev</a></p>tag:old.nabble.com,2006:post-26435960Re: assembly-c mix and interrupts2009-11-19T15:19:26Z2009-11-19T15:19:26ZDavid Brown-40darkschine wrote:
<br>> Before I continue, I would like to suggest a resolution to my problem. I am
<br>> using the ATmega328P
<br>> My assembly code follows a standard that ALL registers used are pushed and
<br>> popped from the stack. However, my assembly code does NOT store the SREG.
<br>> Could this be causing my problems?
<br>>
<br><br>We can't say for sure if this is /the/ cause of your problems, but we
<br>can pretty much guarantee that it will lots of problems. Make sure you
<br>save the SREG.
<br><br>A far better solution in most cases would be to re-write the interrupt
<br>routine in C. The compiler will then make sure that all necessary
<br>registers, including SREG, are saved and restored properly. The days of
<br>having to write interrupt routines in assembly are far in the past,
<br>except for very exceptional cases.
<br><br><br><br>_______________________________________________
<br>AVR-GCC-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26435960&i=0" target="_top" rel="nofollow">AVR-GCC-list@...</a>
<br><a href="http://lists.nongnu.org/mailman/listinfo/avr-gcc-list" target="_top" rel="nofollow">http://lists.nongnu.org/mailman/listinfo/avr-gcc-list</a><br><p>From forum: <a href="http://old.nabble.com/AVR---gcc-f2010.html" embed="fixTarget[2010]" target="_top" >AVR - gcc</a></p>