As Eric Weddington wrote:
Modified: trunk/avr-libc/crt1/gcrt1.S
===
--- trunk/avr-libc/crt1/gcrt1.S 2010-03-31 04:27:34 UTC (rev 2113)
+++ trunk/avr-libc/crt1/gcrt1.S 2010-03-31 05:12:22 UTC (rev 2114)
@@ -175,6
As Eric Weddington wrote:
First, I don't know if all of avr-libc would pass the pedantic check
anyway because we use extensions, which is not strict ISO C.
All extensions are supposed to be properly protected (either by
marking them as __extension__, or by using the double-underlined
versions
Hi Anitha,
1. What purpose do GPIO and CPU definitions serve?
As far as I understand (disclaimer: I didn't do much with Xmegas so
far), they are just IO register blocks as any other IO register block
in the Xmega. If you look into the Xmega A datasheet, chapter 3 (AVR
CPU), there is a section
Update of bug #29280 (project avr-libc):
Status:None = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Boyapati, Anitha wrote:
% svn ls svn+ssh://joerg_wun...@svn.savannah.nongnu.org/avr-libc/
Starts working now. Thanks Joerg!
Great! Good luck with working on SVN then, Anitha!
The Savannah website offers customized instruction pages for everybody
who is logged in. When I go there, I
As Clemens Koller wrote:
Well, regarding Mercurial that is (or was?) a matter of the
licensing...
Politics. :) For a VCS, I wouldn't care much, as long as its
license doesn't try to dictate anything about the source code
I'm going to shuffle into it. savannah.nongnu.org offers CVS,
SVN, Git,
Hi Anitha,
Should I save sshv2 public key somewhere?
Sure, you should.
Let me know the process.
Go to My account configuration (left panel). On the right-hand
side, there's a headline Authentication Setup. For me, there's an
entry Edit the 1 SSH Public Key registered, I guess it's named
As Boyapati, Anitha wrote:
I've told the savannah admins that the old CVS repository might be
removed, don't know whether they already did.
I don't understand. Is this the reason why I am getting the message
when trying to check out anon using svn?
No, anonymous SVN is not supposed to be
As Weddington, Eric wrote:
Hmm. Anatoly had previously mentioned to me that builtins.h
shouldn't actually go into avr-libc. But I can't seem to find the
emails right now where we discussed this.
I figured we did already distribute it to the masses as part of
WinAVR, so instead of applying a
As Timo Sandmann wrote:
JFYI __builtin_avr_fmul(), __builtin_avr_fmuls(),
__builtin_avr_fmulsu() don't work for me (they produce internal
compiler errors).
Maybe Anatolyj can say something about that. If it doesn't work, we
should certainly drop it, but then, WinAVR (or whatever its
As Weddington, Eric wrote:
IIRC, Anatoly mentioned that the builtin.h header file should
probably be in GCC, as other targets have builtin functions too, and
we should model the AVR after other ports. I'll have to double-check
all that, but I can't do that until later in the day for me.
As Clemens Koller wrote:
Maybe I missed some discussions but did you consider moving towards
Git as a distributed SCM tool?
Nobody ever brought that up when we discussed it previously (while
switching to SVN has been requested). I don't see any real advantage
either, although I confess I
As Joerg Wunsch wrote:
Once that support request has been completed by the admins, we could
start using
svn+ssh://svn.savannah.nongnu.org/avr-libc/trunk
OK, that's done. Let's see whether the commit mailing list still
works...
--
cheers, Jorg
Follow-up Comment #2, bug #29235 (project avr-libc):
Minor remark:
I'm dual-minded about that. Formally not allowing a comma at the end
of an enumeration has been an accidental syntactical mistake in the
original C standard, and C99 got away with that mistake by changing
the rules in a way so
As Dmitry K. wrote:
But, what is a reason for migration?
Well, I've started to use SVN in a number of projects in the past
years, and found it mostly better than CVS as a general opinion. That
starts with simple things in day-to-day operation, like svn status
giving you a simple one-line
As Joerg Wunsch wrote:
While the migration has already been done on savannah, there's still
some permission issue with the SVN tree. I haven't been able to
commit anything by now.
All is fine now. The restless Sylvain Beucler from the savannah
admin team fixed the remaining issues. Please
As Weddington, Eric wrote:
Drop the (pointless) svn:executable attribute on those files
that had been inherited from CVS.
Oh, *thank you* for doing this. Sorry for the hassle, as most of
those are probably my fault for committing too fast.
Well, it's simply that CVS always inherited the x
As Weddington, Eric wrote:
I noticed that the web pages are still under CVS. Is this normal
procedure?
Yes, it is. But I don't think that matters much.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never
For those who do not follow the avr-libc-commit list:
As Joerg Wunsch wrote:
Revision: 2103
http://svn.sv.gnu.org/viewvc/?view=revroot=avr-libcrevision=2103
Author: joerg_wunsch
Date: 2010-03-17 05:16:10 + (Wed, 17 Mar 2010)
Log Message:
---
Probe the compiler
What's the general opinion about moving avr-libc to SVN before
releasing 1.7.0? Are there any objections among the active
developers?
If not, I'd like to prepare a SVN migration SVN dump image, and submit
it to the savannah admins for import.
--
cheers, Jorg .-.-. --... ...--
As Joerg Wunsch wrote:
I suggest a freeze right now then.
OK, I ran cvs2svn here, and filed the resulting SVN dump file for
migration at the Savannah admins.
https://savannah.gnu.org/support/index.php?107311
Once that support request has been completed by the admins, we could
start using
svn
As Christopher Hrabia wrote:
I recognized that for mostly all print functions a _P version
exists, besides of vprintf.
#define vprintf_P(fmt, ...) vfprintf(stdout, fmt, __VA_ARG__)
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
Follow-up Comment #1, bug #28921 (project avr-libc):
After some ongoing discussion about this in the (German)
mikrocontroller.net forum, it turns out that adding
-mrelax (or -Wl,--relax) appears to fix this. So linker
relaxations are probably mandatory when working with function
pointers and
As Weddington, Eric wrote:
I agree that there is not a convenient place to put such a
macro. But I would also argue now that we do not need to have such a
macro in avr-libc. The only use for the NOP instruction is for some
sort of delay, typically by a specific number of cycles.
Well, there
Update of bug #28882 (project avr-libc):
Category:Build Infrastructure = None
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:
Follow-up Comment #1, bug #28881 (project avr-libc):
You guessed it: there's no real place for the nop() macro
to go into. That's the main reason it's not yet there.
I disagree about the BREAK instruction though: its only
purpose it to implement soft breakpoints, so it really
only makes sense
As Joerg Wunsch wrote:
OK, try again, please. *blush* I accidentally tagged against
my local mirror rather than savannah...
Alternatively, use avr-libc 1.6.8.
I just decided to roll a new release. Originally, my intention was to
fix some of the more critical bugs before doing that, but I
As Weddington, Eric wrote:
Sounds good. Although why not use 1.7.0? AFAIK, no one has ever done
a public release using HEAD as 1.7.0. As maintainers, we ultimately
decide what the release versions will be. I'm concerned that users
will ask us what happened to 1.7.0 if we jump to 1.7.1.
I
As Weddington, Eric wrote:
Incidentally, is there a reason why avr-libc is hosted with CVS
rather than Subversion?
(Btw., applying the tag wasn't as painful even with CVS as I thought.
But yes, it's simpler and more consistent in SVN.)
Age of the project. We have logs going back to 1999. I
As Weddington, Eric wrote:
That is, from 2010-01-10? (I hope the actual timestamp on that day
doesn't matter as nobody committed anything then.)
Well I had to do a respin, so the actual date is 2010-01-20.
Alas, the granularity of my tape backups for that area is worse than I
excpected;
As Galen Seitz wrote:
A command similar to the following should apply the appropriate tag
to the repository.
I doubt, because it will apply the tag to the head, but Eric has been
using the 1.6 branch to produce the source tree.
Using -D (for a date) and -r (for a branch tag) together is one
As Joerg Wunsch wrote:
Using -D (for a date) and -r (for a branch tag) together is one of
the really weak points of CVS.
I spoke too soon, it seems. It appears there's been something done
about that deficiency in CVS within recent years. I could
successfully update a checked out tree
Update of bug #28837 (project avr-libc):
Status:None = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As ?? wrote:
Hello everyone! Help make the first steps in the avr-libs.
Duplicate posting. Has also been posted to avr-gcc-list (where
it actually belongs to). Please followup there.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
As Paul Rathgeb wrote:
Unfortunately, I don't found informations about the avr-libc support for
this controller. ATMEGA16U4 seems supported, but I don't know if I can
use this MCU type for the compilation.
ATmega16U2 is supported by avr-libc, provided your compiler has been
patched to support
Update of bug #28756 (project avr-libc):
Status: Need Info = Confirmed
___
Follow-up Comment #13:
I can now see the problem with that code. They stupidly
parenthesize the call to
Update of bug #28756 (project avr-libc):
Status: Confirmed = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #8, bug #28756 (project avr-libc):
Yes, the ATmega128RFA1 was (accidentally) missing from the
list of supported MCUs for clock prescaling in avr-libc 1.6.6.
However, the error Timur is getting is completely different:
../main.c:105: error: expected expression before 'do'
Follow-up Comment #10, bug #28756 (project avr-libc):
I have the same error with AT90USB1287
Source code?
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?28756
___
Message
Follow-up Comment #4, bug #28756 (project avr-libc):
do { ... } while(0) is *not* an infinite loop. Think again
about it.
Sorry, I still cannot reproduce any error. The project in
the attachment did apparently compile fine (it contains an
ELF file, after all!), and when I recompile it, I
Follow-up Comment #6, bug #28756 (project avr-libc):
Thanks for the error message. Still, I cannot reproduce
the problem. For reference, this is my source code file:
#include power.h
void prescaler_1(void)
{
clock_prescale_set(clock_div_1);
}
and compile it with
avr-gcc -O
Update of bug #28756 (project avr-libc):
Status:None = Need Info
___
Follow-up Comment #1:
Please attach a file to reproduce this problem, as well as
a simple Makefile or command-line
Update of bug #28688 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Weddington, Eric wrote:
It's not the title but the group name. We've been using
underscores there for years.
Agreed. It sounds like a regression on the part of doxygen.
Not exactly. We're modifying a file that has been generated by
doxygen (e.g. to make long tables properly split
As Weddington, Eric wrote:
Joerg can you confirm that this is a problem?
Yes, it's a doxygen 1.6.x problem it seems. I'd like to find
a generic solution though, as simply changing the number of
underscores will just move the issue to doxygen 1.5.x.
--
cheers, Jorg .-.-. --...
As Andrew Stevenson wrote:
Yes, it's a doxygen 1.6.x problem it seems. I'd like to find
a generic solution though, as simply changing the number of
underscores will just move the issue to doxygen 1.5.x.
Changing the title of the page to not use any special chars would
probably avoid the
As Boyapati, Anitha wrote:
Ok. I got it. The issue is talking about the case when all the free
*heap* (or 'cake' as you put it) is exhausted; but has a malloc'ed
free'd chunk (or realloc'ed) at the end in which case the 'top
address'(?) should be allowed to move backwards.
Yes, that's the
As Boyapati, Anitha wrote:
Do we have an English version of the page referred in the bug
report? http://www.mikrocontroller.net/topic/147150
Nope, after all, it's a (German-language) forum, so it's naturally
that people do not translate their entries.
I think the most important one (to you)
As Boyapati, Anitha wrote:
As trivial as it may seem, I would like to know if the phrase
(largest chunk) is a simple case of typo (or my understanding got
skewed somewhere?).
Anitha, you're a good observer. ;-) Yes, it's a typo, nothing
more.
--
cheers, Jorg .-.-. --...
As Daniele Basile wrote:
If you want I can post the code, and contribute it to avr libc.
Let me know what you think.
Sounds interesting. Please submit it as a patch here:
https://savannah.nongnu.org/patch/?group=avr-libc
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
As Weddington, Eric wrote:
cc1.exe: error: missing argument to -mmcu=
Your GNU make is too old.
http://lists.gnu.org/archive/html/avr-libc-dev/2009-07/msg1.html
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC:
As Zitt Zitterkopf wrote:
Does anyone have a iocompat.h file which is compatible with the
Tiny13 so that I can begin playing with the demo?
Sorry, that demo has been written for devices where timer 1 offers a
16-bit timer. The ATtiny13 only offers an 8-bit timer, so rewriting
the demo might
As Ruddick Lawrence wrote:
I think LibAVR might be too confusing.
I agree, though I also see Eric's point: assuming it will really
become an object library, a link specification like -lavr looks
good.
But then, just because the object library is named libavr.a, nobody
says this must exactly
As Frédéric Nadeau wrote:
I volunteer to start the project.
Great!
I suggest we open a hosting on Savannha so that we can have a
separate mailing list and start discussion on that specific
project. From there on we could lay out a distribution plan,
compilation method, etc.
Do you really
As Weddington, Eric wrote:
Regarding naming, here's another thought: Why does it even have to
have a separate name? If it's part of avr-libc, then let it be that:
just a part of avr-libc. The library that is built could be named
'libavr.a' and one links to it with '-lavr', but it's still
As David Brown wrote:
One thing I'd like to suggest is that the library be divided into
separate areas. In particular, I'd like to see a stable area and
a staging or experimental area.
I don't mind that, just one remark: unless you got lots of people who
are eager to test it, there's some
As Ruddick Lawrence wrote:
I guess the first thing to figure out is
how you (and the other developers/maintainers) define the scope of avr-libc,
and how best to design a complementary library (if at all) to house useful
code that is outside of that scope.
Ideally, if there were enough
As Ron Kreymborg wrote:
I now have a little more spare time, so would be willing to join as
a volunteer for this library.
As Frédéric Nadeau wrote:
I started such a project at the beginning of the year. Please check
at: http://code.google.com/p/avr-drv/
[...] I'm
willing to work on that
As Frédéric Nadeau wrote:
Someone knows what happend to the idea of adding pin description in
io.h?
No, what are you referring to?
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating
As Boyapati, Anitha wrote:
This means when a user requests say for x bytes from heap, he will
get x+2 bytes.
Yes, but keep in mind that this will *only* happen if the request is
satisfied from a freelist entry that was exactly x+2 bytes long (as
such an entry could not be split into an actual
Update of bug #27425 (project avr-libc):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #2:
As Stefan wrote,
As Weddington, Eric wrote:
Instructions such as sts that use two words (32 bits) are not
guaranteed to be executed before an interrupt may fire.
Have you tested this on the ATmega1281?
This behaviour would surprise me a bit, given that the datasheet
chapter about interrupt latency
As rr wrote:
../../bfd/elf32-avr.c: In function 'bfd_elf_avr_final_write_processing':
../../bfd/elf32-avr.c:1331: error: 'bfd_mach_avrxmega1' undeclared
(first use in this function)
One of Eric's patch patches a file that is then to be used as a master
to generate some other files from. You
As Weddington, Eric wrote:
But now that it works, can we update the util/delay.h to use it?
Patches welcome.
The big thing I'm seeing with __delay_cycles is: How to *detect* it
from util/delay.h?
Either, the patch (and future public implementation) can announce
itself by the existence of a
As Weddington, Eric wrote:
cc1.exe: error: missing argument to -mmcu=
make[5]: *** [eerd_block_at90s1200.o] Error 1
dejavu... Trying to remember...
Ah, now I remember: you have to upgrade your GNU make.
I discovered this while you were on vacation, see here:
Follow-up Comment #1, bug #27201 (project avr-libc):
The problem is that accessing the union (and also struct,
for byte-wide access) elements without naming the union
itself is a GCC extension, so it is turned off when compiling
with -std=c99.
It appears to me that prepending the entire union
There have been so many bugfixes and nice improvements (in particular
by Dmitry) lately, so I decided it would be worth the while releasing
a new version.
1.6.7 is out. Web page updates (documentation etc.) are not yet done.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
As Dmitry K. wrote:
Thanks, I shall fix it.
Thank you very much.
Alas, I have not build the Xmega compiler yet.
If it helps you, Bingo600 updated his Linux build script on
avrfreaks recently, so that one also support the Xmega now.
--
cheers, Jorg .-.-. --... ...-- -.. .
After savannah's disk failure, the CVS repository has been restored
again. I don't see any differences between my last rsync mirrored
copy of the repository and the restored one, so I think nothing is
lost.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
Follow-up Comment #3, bug #26365 (project avr-libc):
Shall I submit it as a series of feature requests, rather?
I'm afraid nobody will have the time to really implement that
unless you're accompanying it with patches.
___
Reply to this
As Jan Waclawek wrote:
What is then the appropriate form of posting feature requests, which
are not likely to be implemented immediately, but still might be an
inspiration for anybody who has time to pick up older ideas in the
future?
As Eric said, starting to discuss those ideas on the
Update of bug #26022 (project avr-libc):
Status:None = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Weddington, Eric wrote:
I don't think there's a reason to have that as a builtin, when it can
be so conveniently had as an inline asm statement. That's much
different from __delay_cycles.
There is already a precedent.
That doesn't make it better -- in particular not for instructions
As Weddington, Eric wrote:
Likewise, the same goes for using nop(), as tempting as it is.
Again, _NOP() would be fine, as will __nop().
Hmm. I think that might be included as part of the new builtins for
the AVR port.
I don't think there's a reason to have that as a builtin, when it can
As Eric Weddington wrote:
Update of bug #25930 (project avr-libc):
Priority: 5 - Normal = 9 - Immediate
Assigned to:None = arcanum
Just FYI: I'd also like to add a regression test to the testsuite for
As Harald Kipp wrote:
According to the document above, this may not work as expected. It
should have been
# define sei() __asm__ __volatile__ (sei :: memory)
I think we've been at that discussion before, and eventually agreed
there's no point why sei() should imply a memory barrier. I
As Weddington, Eric wrote:
Anyway, it might make sense to provide an additional macro like
__memory_barrier() that expands to __asm__
__volatile__(::memory).
If we do that, we might as well make it a public symbol, yes?:
#define memory_barrier() __asm__ __volatile__(::memory)
If we
Update of bug #25876 (project avr-libc):
Status:None = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Joerg Wunsch wrote:
4. bug-22828 and other EEPROM tests: seems, this is a
Simulavr problem. The 0.1.2.1 version is correct. I will
look this in details.
As time permits, I'll also look into that.
Strange, another site, different compilers but the same version of
simulavr
As Dmitry K. wrote:
My desktop (Glibc) documents isinf() that return -1/0/+1
and links to BSD 4.3 compatibility. The date of man page
is 1993.
OK, the FreeBSD man page says this:
HISTORY
The fpclassify(), isfinite(), isinf(), isnan(), and isnormal()
macros were added in FreeBSD 5.1.
Update of bug #25723 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:
As Bob Paddock wrote:
What I'd really like to see is the ability to read the signature of
the chip itself at run time.
You can do that for all recent AVRs, but the legacy parts didn't
support that feature.
There's been an avr-libc API around for it for many years:
As Weddington, Eric wrote:
Some concerns:
Simulate: regression/bug-22828.c atmega128 ... *** simulate failed: 24
Simulate: regression/bug-22828.c at90s8515 ... *** simulate failed: 24
Strange enough, for me this only fails for the AT90S8515 simulation,
but works for the ATmega128
As Weddington, Eric wrote:
I wonder whether there's a point in using a struct rather than a
three-byte array?
In theory, it doesn't really matter. It seems the OP (on the Freaks
thread) did a little copy and past from the fuses header file. Is
there a reason you have for the preference?
As Weddington, Eric wrote:
Since we're in the middle of a release, I'll hold off on this until
1.6.6.
Fine, that'll also allow for the documentation to magically
appear. :-)
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
Update of bug #22567 (project avr-libc):
Status:None = Duplicate
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:
As Dmitry K. wrote:
Thanks a lot for your timely analysis, it is much appreciated, Dmitry!
2. isinf()
See the GCC bug #35509. Avr-libc's isinf() work fine.
Hovever, since 4.3 branch the GCC replaces it with
themselves inline code, which return the +1 value for
negative infinity. This is
Follow-up Comment #3, bug #25723 (project avr-libc):
I’m now playing with a couple of fixes, but need
to figure out how to get a ‘blessed’ fix into lib-avr.
Please file it as the output of cvs diff -u.
I guess I'll also somehow setup a test script for the test
suite.
As Dennis W. Tokarski wrote:
/usr/lib/gcc/avr/4.3.3/../../../../avr/bin/ld: crtm1280.o: No such file: No
such file or directory
/usr/lib/gcc/avr/4.3.3/../../../../avr/bin/ld: crtm1281.o: No such file: No
such file or directory
/usr/lib/gcc/avr/4.3.3/../../../../avr/bin/ld: crtm128.o: No
Update of patch #6720 (project avr-libc):
Status:None = Done
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Joerg Wunsch wrote:
As your inline asm statement cannot ensure this cannot happen because
it is not specified in the parameter lists of the statements (even if
not right now, who knows what will happen with it next year?), I
cannot really understand your resistance against using
As Weddington, Eric wrote:
I created a temporary variable, and gave it the d constraint. The
compiler then created assembly code to initialize that variable
(register) to 0, and then the next line overwrote that register with
the value read in from the I/O register. Very strange.
Strange,
As Weddington, Eric wrote:
So the timing is split into 2 steps.
- Set BODS | BODSE
- Within 4 cycles, set BODS and clear BODSE
- Withing 3 cycles, sleep.
So I believe the timing constraints could still be matched.
Seems so.
What I like about your piece of code is that it would
As Weddington, Eric wrote:
I would say that that comparison is unfair. This is nothing so
dangerous as self-modifying code. Just because both are unobvious,
doesn't make them equivalent situations.
Well, the self-modifying code wasn't really dangerous either. It's
only been unobvious (to the
As Weddington, Eric wrote:
[...] I want to make sure that with the macro, gcc won't do
something weird like:
in r24,85-32
/* #APP */
; 61 test.c 1
ori r24,96
; 0 2
/* #NOAPP */
out 85-32,r24
/* #APP */
; 61 test.c 1
andi r25,-33
; 0 2
/* #NOAPP
As Weddington, Eric wrote:
Could you elaborate on your question?
The FAQ explains that you'd have to make special arrangement to
convince the compiler to generate an 8-bit only instruction sequence,
while the compiler apparently is smart enough now to figure that out
by itself.
It would be
As Weddington, Eric wrote:
[Things that don't work on Solaris' /bin/sh]
. shell arithmetics, use expr instead.
Ok, I'm not a Unix guy. What do you mean by the last statement
above? Does this mean that my solution won't work on Solaris?
Ah well, you're right. It's the $(( ... )) stuff,
As Weddington, Eric wrote:
New patch attached.
Without testing, looks fine to me.
Ruud's patch has some merit as well...
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you
Follow-up Comment #4, bug #21805 (project avr-libc):
Another possible optimization I'm just noticing: the generated
code looks like:
ldi r24, 0xFF
ldi r25, 0x03
movwr30, r24
i.e. a parameter is passed in r24:25, and then moved into
r30:31. This might IMHO become more optimal (with
As Steve Franks wrote:
Is this really just for the convinienece of using F_CPU? I grabbed
delay_loop_2(), put it in a for() loop, and my code went from 4k to
1k...
After all, the convenience of using F_CPU and times in microseconds
and milliseconds is *the* difference between _delay_us and
401 - 500 of 868 matches
Mail list logo
