[avr-libc-dev] [bug #12865] Global Interrupts Explicitly Enabled by SIGNAL Macro
Update of bug #12865 (project avr-libc): Severity: 3 - Normal = 4 - Important Priority: 5 - Normal = 9 - Immediate ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12865 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #12865] Global Interrupts Explicitly Enabled by SIGNAL Macro
Follow-up Comment #3, bug #12865 (project avr-libc): This is known to work with ATmega128 and avr-libc 1.0.4. I've used it successfully myself. - What version of GCC and binutils are you using? - Can you try upgrading your toolset? The latest version of avr-libc is 1.2.3. Eric ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12865 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #12865] Global Interrupts Explicitly Enabled by SIGNAL Macro
Update of bug #12865 (project avr-libc): Status:None = Invalid Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12865 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [task #3719] Add new device: tiny85
Update of task #3719 (project avr-libc): Priority: 1 - Later = 8 Status:None = Ready For Test Percent Complete: 0% = 80% ___ Follow-up Comment #1: Patches in Patch Manager. ___ Reply to this item at: http://savannah.nongnu.org/task/?func=detailitemitem_id=3719 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [task #3726] Add new device: AT90PWM3
Update of task #3726 (project avr-libc): Status:None = Ready For Test ___ Reply to this item at: http://savannah.nongnu.org/task/?func=detailitemitem_id=3726 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #4049] Support for ATtiny25, Attiny45 and Attiny85
Update of patch #4049 (project avr-libc): Priority: 5 - Normal = 9 - Immediate ___ Reply to this item at: http://savannah.nongnu.org/patch/?func=detailitemitem_id=4049 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [task #3717] Add new device: tiny25
Update of task #3717 (project avr-libc): Priority: 1 - Later = 8 Status:None = Ready For Test Percent Complete: 0% = 80% ___ Follow-up Comment #1: Patches in Patch Manager. ___ Reply to this item at: http://savannah.nongnu.org/task/?func=detailitemitem_id=3717 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Re: [avr-gcc-list] dwarf2 information, is this a bug?
Björn Haase wrote: In reply to a message from July this year posted on avr-libc-list: Yes I think, Thorsten, that you found a bug. It seems that the binutils mainline does no longer assemble correctly the dwarf2 informations. E.g. I observe that avr-addr2line no longer finds the correct line number for newly assembled files. When using the rev. 2.16 avr-addr2line on files assembled with 2.14 the correct line numbers come out. So addr-2line seems to be functional in 2.16. My present estimation is that the problem is probably with gas or bfd. Bjoern. Hi Björn, Do you think the problem first showed up in 2.16? Would it be better off to stay with 2.15 until this issue is fixed in HEAD? Thanks Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Re: [avr-gcc-list] dwarf2 information, is this a bug?
Björn Haase wrote: Hi Björn, Do you think the problem first showed up in 2.16? Would it be better off to stay with 2.15 until this issue is fixed in HEAD? No. Last week I indeed had observed the same issue Torsten has reported. Today I have analyzed the issue and found out that the problems with 2.16 showed up for my applications only in conjunction with my new linker optimizations. It seems that Torsten's issue has been fixed meanwhile. I found out where the problem with my linker relaxation patch were and I have fixed the issue this afternoon. I will soon post a follow-up patch of the linker-relax optimization. My suggestion would be to be even less conservative: I'd even suggest that within two weeks time you could ship *mainline* binutils that includes linker relaxation: I observe that the code size decrease might justify it and in case that there are unexpected new problems, you simply would not need to switch --relax on. Thanks for the analysis. BTW: You are now employed by Atmel, Eric? You're observant. :-) Yes, I am, though I haven't made that widely public (though I suppose it will get around soon enough). I'm in their Colorado Springs offices. Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Re: [avr-gcc-list] dwarf2 information, is this a bug?
Patrick Blanchard wrote: On Mon, 2005-10-17 at 10:38 -0600, Eric Weddington wrote: Björn Haase wrote: BTW: You are now employed by Atmel, Eric? You're observant. :-) He's not the only one! I am following this thread but noticed the change. Yes, I am, though I haven't made that widely public (though I suppose it will get around soon enough). I'm in their Colorado Springs offices. It's great to know Atmel is looking in the right places for employees! Best Wishes Eric. I'll expect even greater things from you (and Atmel) now! :) Thanks. I hope to live up to everyone's expectations. However, now you know one of the main reasons why I've been so incredibly busy and haven't gotten a new WinAVR release out. But it is on my task list here so it will still happen. And though I cannot give out inside information, all I can say is that there some very good stuff going on here. And, yes, it does take time to put it all together to release it to the public. But I don't think people will be disappointed. Stay tuned Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Automated testing project
Joerg Wunsch wrote: As Peeter Vois wrote: I'm thinking what would I do with the testing environment. We could merge it with avr-libc project or create a new project for libc automated testing. I'm quite busy right now, and wish I'd already made avr-libc-1.4.0 reality. Anyway, after that happened, it already became pretty clear to me we need some sort of regression test. Currently, for any new device, I'm running a small test program on it to see whether the library adaptation for the new device actually works. After seeing how GCC uses dejagnu, I've already thought about using that for regression tests, but I'm open for any option here. One major showstopper could be the limited device support in simulavr/simulavrxx though. Basically, when extending the library for new devices, it would require the simulation to also cover that new device in order to make this a useful option. Right. All of the open source AVR simulators that I've seen (simulavr, simulavrxx, avrora) are incomplete wrt. covering all AVR devices. Simulation is probably the biggest hole in the entire open source AVR software development toolchain. But I definitely agree that a testsuite for avr-libc is needed and would be great to have. It's been on our todo list for probably over 2 years. Eric -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Automated testing project
Paul Schlie wrote: designated? designated by whom? I'm assuming you are referring to the quote below since you didn't take the time to trim it down. It was designated by the original author of SimulAVR, which is Theodore (Ted) A. Roth. Eric From: Joerg Wunsch [EMAIL PROTECTED] Reply-To: Joerg Wunsch [EMAIL PROTECTED] Date: Wed, 19 Oct 2005 09:35:06 +0200 To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] Automated testing project Forget simulavr, it's unmaintained. simulavrxx is the designated successor (it lives in the same savannah project) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] Re: [avr-gcc-list] assert.h not available!?
Torsten Landschoff wrote: Hi, I was wondering why assert.h is missing on avr. I am writing my own assert.h over and over so I'd like to have it in avr-libc as I assume that others would like to have it as well. The default action on assertion failure could be to dump a message to stderr and I'd suggest to make it configurable to use other means of reporting failure. What do you think? The devil's in the details. What other means did you have in mind? But this post is more appropriate for the avr-libc-dev list (which is now in the CC list). I suggest moving this thread over there. -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Has anything gone wrong with the new release of WinAVR ?
Nigel Winterbottom wrote: I know that avr-libc-1.2.5 is released but has something gone wrong with building WinAVR to cause such a lengthy delay in its release ? Hi Nigel, Sorry for the hassle. Take a look at this AVR Freaks post from me (EW): http://avrfreaks.net/index.php?name=PNphpBB2file=viewtopict=32338start=66sid=368be72003b53f897a648c5460426751 -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Great Header File Reorg done.
Joerg Wunsch wrote: I'm done with that great header file reorg. The files twi.h, crc16.h, delay.h, and parity.h have been moved to the new util/ subdir. The old files are now stubs referring to the new files. SIGNAL() has been renamed to ISR(). I've bumped the library version date once again, as I feel we are close to 1.4.0 now. I've also updated the documentation preview at http://www.sax.de/~joerg/avr-libc-user-manual/ Please have a look at it. Oh, and I added inp/outp/sbi/cbi back to compat/deprecated.h. Fantastic! Thanks for doing this! Hopefully the masses will now stop complaining about inp/outp/sbi/cbi. :-) -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [task #4217] Add new device: AT90RF135602
Update of task #4217 (project avr-libc): Status:None = Cancelled Open/Closed:Open = Closed ___ Follow-up Comment #2: Item cancelled because the AVR in this device is preprogrammed and cannot be accessed by the user. ___ Reply to this item at: http://savannah.nongnu.org/task/?func=detailitemitem_id=4217 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #15193] incorrect definition of IVSEL bit in MCUCR register
Update of bug #15193 (project avr-libc): Status:None = Confirmed ___ Follow-up Comment #1: Bug confirmed. In iocanxx.h the line: #defineIVSE1 should be: #defineIVSEL 1 Eric Weddington ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=15193 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] cli and sei should clobber memory
Joerg Wunsch wrote: As Eric Weddington wrote: You're at the right place. Submit a bug report in the avr-libc project bug tracker, and attach the patch to the bug report. That way this issue won't be forgotten. Wait: there's already a bug report open for that. Oh, sorry, my bad. I forgot to look. -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [ANN] pic30-libc
Stephan Walter wrote: To whom it may concern, I started a libc implementation for the PIC30/dsPIC family of microcontrollers made by Microchip. That's nice. However this is a mailing list for the developers for the avr-libc project, the Standard C library for the open source AVR toolchain. Please do not advertise other projects here, and especially do not post about other microprocessors on this mailing list. There are other, more appropriate mailing lists or forums about the Microchip PIC. This is not the place for it. Eric Weddington [One of the avr-libc admins] ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] About to release avr-libc 1.4.1
Joerg Wunsch wrote: With all outstanding patches added, and all bugs but the FP ones fixed, as well as my recent demo project changes merged, I now feel comfortable to roll an avr-libc 1.4.1 release. Thanks for doing this! Hopefully, Eric can then pick up this one for his finally upcoming new WinAVR version. I most certainly intend to, as I'm working on it right now. -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #4697] Add support for ATtiny24, Attiny44 and Attiny84
Follow-up Comment #1, patch #4697 (project avr-libc): The GCC patch here is not completely correct. The tinyx4 devices should be in the Classic + MOVW, = 8K. group. If you take a look at the datasheet, these devices include the MOVW opcode. Also take a look at Joerg's all inclusive patch here: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-gcc/files/ ___ Reply to this item at: http://savannah.nongnu.org/patch/?func=detailitemitem_id=4697 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Newbie: Help walking through the demos
Joerg Wunsch wrote: The demos are now installed for the first time as part of the normal make install process, regardless of whether you are building docs or not. Hi Joerg, [Sorry to hear you're not feeling well.] I'm not having success in seeing the demos in the installation diretory after make install. I'm taking a look at my build log now... -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Newbie: Help walking through the demos
Henrik Brix Andersen wrote: On Fri, Dec 30, 2005 at 01:55:40PM -0700, Eric Weddington wrote: I'm not having success in seeing the demos in the installation diretory after make install. Me neither - `make install` in avr-libc-1.4.1 does not install the examples here. I'll investigate this further tomorrow... It looks as if make install does not even descend into the /doc subdirectory. So it never descends into /doc/examples either. And this is with --disable-doc. I'm attempting a workaround -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Newbie: Help walking through the demos
Eric Weddington wrote: It looks as if make install does not even descend into the /doc subdirectory. So it never descends into /doc/examples either. And this is with --disable-doc. I'm attempting a workaround Ok, one workaround is to configure with --enable-doc then do: make -k all install The -k switch tells make to keep on going even in the presence of errors. So when building the docs fail, make will then continue with the install, and descend into /doc/examples and correctly install the examples. However, note that it installed them into: share/doc/avr-libc-1.4.1/examples The version name is appended in the directory name. I don't know if that was intended or not. -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Newbie: Help walking through the demos
Eric Weddington wrote: Eric Weddington wrote: It looks as if make install does not even descend into the /doc subdirectory. So it never descends into /doc/examples either. And this is with --disable-doc. I'm attempting a workaround Ok, one workaround is to configure with --enable-doc then do: make -k all install The -k switch tells make to keep on going even in the presence of errors. So when building the docs fail, make will then continue with the install, and descend into /doc/examples and correctly install the examples. However, note that it installed them into: share/doc/avr-libc-1.4.1/examples The version name is appended in the directory name. I don't know if that was intended or not. Sorry, false alarm. It correctly builds the directories, but no files were copied into the directories. :-( So the workaround failed. Time to manually copy. -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] iom406.h hardware definition file for ATmega406 available for a vr-libc...
Pieter Conradie wrote: Hi guys! I did the manual labour work and created the above mentioned file. Please contact me so that I can e-mail it to the responsible maintainer. Thanks for doing this! Go to the main avr-libc project on Savannah: http://savannah.nongnu.org/projects/avr-libc and put the file in a Patch Tracker. That way it won't get lost. Thanks -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] fmod() accuracy
Dmitry K. wrote: Hi. The fmod() function is not absolutely accurate. For example: fmod (101, 100) -- 9.536743e-01 fmod (101, 10) -- 1.015625e+00 The reason is too simple algorithm with float point arithmetic usage. fmod() is an important function. It is used in trigonometric: sin/cos/tan . After replacement of algorithm (to integral division) the fmod() became absolutely exact. Speed is up considarable. Size is increased a little (but the stack usage is reduced). Testing in progress... Fantastic! I'd rather take an accurate function over a slight increase in size any day. -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [task #5264] Add new devices: AT90USB646-647-1286-1287
Update of task #5264 (project avr-libc): Should be Finished on: Fri 06/16/06 at 14:00 = Fri 03/10/06 at 00:00 Priority: 5 - Normal = 7 - High Assigned to:None = arcanum Percent Complete: 0% = 20% ___ Follow-up Comment #1: Anatoly, I'm working on this one. I have a binutils patch that I will submit next week. I'm currently working on a gcc patch. ___ Reply to this item at: http://savannah.nongnu.org/task/?func=detailitemitem_id=5264 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [task #5264] Add new devices: AT90USB646-647-1286-1287
Update of task #5264 (project avr-libc): Status:None = In Progress ___ Reply to this item at: http://savannah.nongnu.org/task/?func=detailitemitem_id=5264 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] thins that need to be done?
Mark v/d W. wrote: Hi Everyone I've been wondering for some time now, how can I contribute to avr-gcc (and everything used with it), and what skills I need to be useful. Are there any jobs that need to be done? I hear a lot about floating point routines that need to be rewritten. Is there any way I could help out there? Mark v/d W. (microchip) First off, subscribe to the avr-libc-dev mailing list; that way your emails don't have to be approved to be posted to the list. ;-) You should familiarize yourself with CVS. Also, with the diff and patch tools. There are plenty of jobs that need to be done in avr-libc. Yes, we can always use a floating point maintainer. I'm not sure if the routines need to be rewritten (others can address that point). But I would certainly like to see 64-bit floating point (double) routines added to the library. We have an open position for a C++ maintainer; someone who is familiar with what is required for a C++ toolchain and can possibly get libsup++ built for the AVR. We also have a todo list, though it might be a bit out of date. And then there are always bugs to be fixed and new devices seem to come out every other month. Usually, new developers contribute patches to the avr-libc project (usually through the Patch Manager on the Savannah project). After a few patches, everything looks good, we can certainly give you write access to CVS. We're certainly not elitest, but you have to know the basics of the tools (CVS, diff, patch) and willing to work together on a cross-platform project. Note that the AVR toolchain can now be built for Linux, FreeBSD, OpenBSD, Mac OS X, Windows, and Solaris (and I can't remember if someone has tried building on NetBSD). HTH -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] thins that need to be done?
Joerg Wunsch wrote: As Joerg Wunsch wrote: Dmitry has already answered the question about floating point support. There's also the question of how to support 64-bit double floating point numbers. ... Also, we're still looking for someone who might want to take over C++ maintenance. ... I should have read my mail more carefully before replying -- Eric already mentioned all that as well. ;-) Well, it never hurts to put some more emphasis on these points. ;-) -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[Fwd: Re: [avr-libc-dev] thins that need to be done?]
Also forwarded to the list, since I messed up the address previously. Original Message Subject: Re: [avr-libc-dev] thins that need to be done? Date: Tue, 04 Apr 2006 09:28:01 -0600 From: Eric Weddington [EMAIL PROTECTED] To: Mark v/d W. [EMAIL PROTECTED] CC: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Links: Good online reference for CVS: http://cvsbook.red-bean.com/ Scroll down to the bottom for the online verion of the book. What platform do you development work on? Linux? FreeBSD? Windows? Eric Mark v/d W. wrote: Thanks everybody! I'll have a look at CVS and Patch etc. Any other pointers? Mark P.S.: I have registered myself with the mailing list. Eric Weddington wrote: Mark v/d W. wrote: Hi Everyone I've been wondering for some time now, how can I contribute to avr-gcc (and everything used with it), and what skills I need to be useful. Are there any jobs that need to be done? I hear a lot about floating point routines that need to be rewritten. Is there any way I could help out there? Mark v/d W. (microchip) First off, subscribe to the avr-libc-dev mailing list; that way your emails don't have to be approved to be posted to the list. ;-) You should familiarize yourself with CVS. Also, with the diff and patch tools. There are plenty of jobs that need to be done in avr-libc. Yes, we can always use a floating point maintainer. I'm not sure if the routines need to be rewritten (others can address that point). But I would certainly like to see 64-bit floating point (double) routines added to the library. We have an open position for a C++ maintainer; someone who is familiar with what is required for a C++ toolchain and can possibly get libsup++ built for the AVR. We also have a todo list, though it might be a bit out of date. And then there are always bugs to be fixed and new devices seem to come out every other month. Usually, new developers contribute patches to the avr-libc project (usually through the Patch Manager on the Savannah project). After a few patches, everything looks good, we can certainly give you write access to CVS. We're certainly not elitest, but you have to know the basics of the tools (CVS, diff, patch) and willing to work together on a cross-platform project. Note that the AVR toolchain can now be built for Linux, FreeBSD, OpenBSD, Mac OS X, Windows, and Solaris (and I can't remember if someone has tried building on NetBSD). HTH -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] thins that need to be done?
[Please reply to the list as well, thanks] It would probably be easier if you developed on Linux. To develop on Windows, you need to have a POSIX environment such as Cygwin or MinGW/MSYS, plus you need to be sure that changes have Unix line endings etc. It's just easier to develop on Linux. Eric Mark v/d W. wrote: Thanks, I'll have a read :-) . I usually develop on Windows (mainly due to my webcam not working in Linux), but I've got a running Linux installation. Mark Eric Weddington wrote: Links: Good online reference for CVS: http://cvsbook.red-bean.com/ Scroll down to the bottom for the online verion of the book. What platform do you development work on? Linux? FreeBSD? Windows? Eric Mark v/d W. wrote: Thanks everybody! I'll have a look at CVS and Patch etc. Any other pointers? Mark P.S.: I have registered myself with the mailing list. Eric Weddington wrote: Mark v/d W. wrote: Hi Everyone I've been wondering for some time now, how can I contribute to avr-gcc (and everything used with it), and what skills I need to be useful. Are there any jobs that need to be done? I hear a lot about floating point routines that need to be rewritten. Is there any way I could help out there? Mark v/d W. (microchip) First off, subscribe to the avr-libc-dev mailing list; that way your emails don't have to be approved to be posted to the list. ;-) You should familiarize yourself with CVS. Also, with the diff and patch tools. There are plenty of jobs that need to be done in avr-libc. Yes, we can always use a floating point maintainer. I'm not sure if the routines need to be rewritten (others can address that point). But I would certainly like to see 64-bit floating point (double) routines added to the library. We have an open position for a C++ maintainer; someone who is familiar with what is required for a C++ toolchain and can possibly get libsup++ built for the AVR. We also have a todo list, though it might be a bit out of date. And then there are always bugs to be fixed and new devices seem to come out every other month. Usually, new developers contribute patches to the avr-libc project (usually through the Patch Manager on the Savannah project). After a few patches, everything looks good, we can certainly give you write access to CVS. We're certainly not elitest, but you have to know the basics of the tools (CVS, diff, patch) and willing to work together on a cross-platform project. Note that the AVR toolchain can now be built for Linux, FreeBSD, OpenBSD, Mac OS X, Windows, and Solaris (and I can't remember if someone has tried building on NetBSD). HTH -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] Re: [avrdude-dev] Problems with -O2 and gcc-4.0 on Darwin
Joerg Wunsch wrote: So the code that's generated is equivalent to what you get with _BV() and with bitfields, only it's more type-safe. Well, using bit numbers is not our invention: it's Atmel's idea. We are basically bound to it since it's the de-facto standard for the AVR. Personally, I find it stupid as well, as any seasoned C programmer would have standardized the bitmasks instead of their numbers, but obviously, these header files are intented not only for C but also for assembly programmers, and these do need the bit numbers occasionally (like in SBI or CBI instructions). IYHO. :-) Personally I don't find thim as stupid; there are many different ways to achieve the same thing. As long as the bit numbers are constants then the compiler will do the heavy lifting of creating the bit mask, so no penalty is involved in using them. Sometimes I find it easier to think about the bit number needed than thinking about the bit mask. Bitfields have their place too, but I find it overkill when using them just to work with one bit. Plus, using the bitwise operators allows greater flexibility. Really, this conversation should be taken over to the avr-libc-dev mailing list, ... Agreed. CCed. -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Bit number/mask, Part 3000
Vic Wagner wrote: It's getting tiresome to keep reminding people that C (and C++, of course) has always had a mechanism for dealing with single bits (multiple bit fields, too) called, _big surprise_ bit fields go look it up on your favorite elementary book on your fave of the two languages. they don't require any changes to any compilers they don't pollute the global namespace with ugly #define symbols Or is it simply that hardware engineers can't figure out how to give NAMES to the bits (fields)? Markus, this is NOT directed at you in particular, but the whole embedded family. You don't seem familiar with the cons of bitfields: - Implementation defined (as Joerg Wunsch mentioned) - They cannot be used if a logical value covers non-contiguous bits - You still have to use bitwise operators to toggle bits, not just set and clear. as for Atmel's public definitions, someone there should be summarily drawn and quartered. I partuclarly mean the person that thnks that if there is only ONE item in a chip it should be named UCSRA, but if there are two, for example, they would be labelled UCSR0A and UCSR1A grow up folks, those of us who have been writing software for a few decades or so really really REALLY don't like to have to change our source because you're too braindead to name things correctly to start with. Look, these are names of bits and registers in a datasheet. The compiler implementations are where those names are defined and implemented. If you have a problem with it, then you shouldn't be complaining about Atmel, you should go to the compiler vendors. Atmel is not a compiler vendor. They make chips. This way of naming registers and bits is nothing new. And, historically, C language cross-compilers have implemented it like this. There are mechanisms available so you don't have to change your source code. You can always wrap things up in macros. .. This entire thread smacks of a solution looking for a problem. Somebody please show me the masses of people who are outraged at how registers are defined, at how difficult it is to manipulate registers, and how the avr-libc project has no clue what it is doing. Go ahead. Point me to the numerous messages on the avr-libc-dev mailing list, the avr-gcc-list mailing list, the avr-chat mailing list, the AVR Freaks Forums, the comp.arch.embedded newsgroup, Yahoo groups, etc where complaints are not being heard. If somebody wants to do a different implementation for themselves, that's fine. If you want to do something different for C++, that's great too. avr-libc is a Standard *C Language* library for the AVR for use with GCC. It is not designed for any other language. It is not designed to be used with any of the 5 known commercial AVR cross-compilers either. I can't speak for Joerg, or Marek, or any of the other members of the project, but AFAIK, we all listen to reasoned arguments and we are open to new ideas. But we don't appreciate indiscriminate mud-slinging. We are *all* trying to find solutions to problems. So, with that in mind, please show me a real problem. And a reasoned solution to said problem. This project then has to balance out many different trade-offs. I've even made proposals in the past that have been shot down because of conflicts and dealing with trade-offs. It's no big deal. Just keep at it. -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] RFC: Database for device properties.?
Uwe Fechner wrote: Björn Haase wrote: In this case, however, I'd like to suggest to try to find a format that could be edited by some sort of GUI. Any suggestions would be appreciated. Bjoern I think, xml is the format of choice. I made the same suggestion some time ago in the avr-freaks forum. At that time, I thought it would be a good idea, to evaluate the xml-database at runtime, and I was told that this would be too slow. But a code generator generating C code from an xml file should be the best solution. I have wrote some code-generators (xml to C) at work, using Borland Delphi. Why do yet another XML tool, when there are some freely available: http://sourceforge.net/projects/xmlstar This is an open source project that is XML manipulation tools that are command line driven. For editing xml-files there are many good solutions, e.g. emacs or oxygen or ... There is something like xml-forms, too. One problem is, that we cannot redistribute the xml device definition file from atmel without their permission (Jörn asked them for a permission and they said no.) Agreed. Therefore it might be a good idea, to create an own format, that can be filled from the atmel xml file (well, to 95%) with a little converter. Why? We would be converting from XML to C language, which will then be included in the toolchain source code. We don't need to create another format just for redistribution. -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] new, delete support
kashey wrote: Hi all. When be included support new and delete functions support in avr-libc? When we have a volunteer to add the support. -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] vargs and ... doesn't work?
Joerg Desch wrote: I couldn't debug the code, because avr-objcopy can't generate the coff file for AVR Studio. There is a separate patch to binutils for the ELF-COFF converstion. This patch is deprecated. AVR Studio has knowledge of the ELF file format with DWARF2 debugging information. -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] vargs and ... doesn't work?
Björn Haase wrote: Eric Weddington wrote on Freitag, 2. Juni 2006 18:36 : Joerg Desch wrote: I couldn't debug the code, because avr-objcopy can't generate the coff file for AVR Studio. There is a separate patch to binutils for the ELF-COFF converstion. This patch is deprecated. AVR Studio has knowledge of the ELF file format with DWARF2 debugging information. The only problem is, that 1.) gcc-4.2.x does not compile with dwarf2 right now due to lacking support for frame offset generation This is Bad News (tm). This is a blocker for building the next WinAVR release. DWARF2 support is necessary. Björn, do you know of the specific GCC bug # that pertains to this problem? Danke -- Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] ¿at90usb1287?
¡Hola! Yes, avr-libc has support for the at90usb1287. You can see a list of all supported devices in the avr-libc user manual. Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Javier Almansa Sobrino Sent: Wednesday, August 02, 2006 6:29 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] ¿at90usb1287? Hello. I'm new in this list and I would like to know if there is support for the AT90USB1287 on avr-libc. I have the USBKEY and I would like to be able to program it under linux. thanks in advance -- El Software es como el sexo: Solo mola cuando se hace libremente ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #16411] -fwhole-program optimization deletes ISRs
Update of bug #16411 (project avr-libc): Severity: 3 - Normal = 5 - Blocker Priority: 3 - Low = 9 - Immediate ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=16411 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #17470] Add API for CLKPR register to avr/power.h
Update of bug #17470 (project avr-libc): Priority: 5 - Normal = 9 - Immediate ___ Follow-up Comment #2: Raising priority. Target 1.4.5 for this bug. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17470 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] RE: [bug #16411] -fwhole-program optimization deletes ISRs
-Original Message- From: Joerg Wunsch [mailto:[EMAIL PROTECTED] Sent: Thursday, August 24, 2006 10:13 AM To: Ned Konz; Levi Harper; Joerg Wunsch; Eric Weddington; avr-libc-dev@nongnu.org Subject: [bug #16411] -fwhole-program optimization deletes ISRs Follow-up Comment #5, bug #16411 (project avr-libc): Please mind Björn Haase's latest changes to the linker script templates. He added several KEEP statements there. AFAIK these changes are not yet in binutils 2.17, they only have been added afterwards. (They might be present in his ATmega256x/linker relaxation patch set, I'm not sure.) Still, I'm opposed to officially support any of these features unless someone tests every aspect of them, and is also willing to add documentation for them. Otherwise, it will only become a support nightmare. Sorry, I currently complete ran out of time for that, so the someone above needs to be someone else, or it won't happen for the next avr-libc release. I understand your concern. However, for this one aspect of this bug, I think the concern is unfounded. Let's ignore the KEEP statements in the linker scripts for the moment. The original bug report stated: When using the -fwhole-program optimization on an AVR program containing an ISR, the optimizer apparently sees the ISR as uncalled and deletes it. Adding the __attribute__((used)) to the definition of ISR() fixes this. The GCC documentation for __attribute__((used)) states: This attribute, attached to a function, means that code must be emitted for the function even if it appears that the function is not referenced. This is useful, for example, when the function is referenced only in inline assembly. Adding __attribute__((used)) to all ISRs (defined in a user application) seems to be a reasonable change, regardless of whether -fwhole-program is being used or not. The compiler will make sure that the ISR code is emitted, even if -fwhole-program would want to kill it because there are no direct references to the ISR. I'm certainly willing to make this change. I disagree with the externally_visible attribute in Ned's latest patch to this bug report; Ned has already said that that can be removed. Going back to the KEEP statements in the linker scripts, I would rather that be analyzed as a separate issue from this bug report. Joerg, do you have any overwhelming objections to just this minimal change, beyond what you've already stated? Thanks Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #16411] -fwhole-program optimization deletes ISRs
Update of bug #16411 (project avr-libc): Assigned to:None = arcanum ___ Reply to this item at: http://savannah.nongnu.org/bugs/?16411 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #17470] Add API for CLKPR register to avr/power.h
Update of bug #17470 (project avr-libc): Assigned to:None = arcanum ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17470 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #15512] bootloader-utilities not IR-save
Update of bug #15512 (project avr-libc): Severity: 3 - Normal = 5 - Blocker Priority: 5 - Normal = 9 - Immediate ___ Reply to this item at: http://savannah.nongnu.org/bugs/?15512 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #17216] change to the ../util/delay.h header for increased functionality
Update of bug #17216 (project avr-libc): Priority: 5 - Normal = 9 - Immediate ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17216 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] RE: [bug #17470] Add API for CLKPR register to avr/power.h
-Original Message- From: Joerg Wunsch [mailto:[EMAIL PROTECTED] Sent: Thursday, August 24, 2006 1:07 PM To: Joerg Wunsch; Eric Weddington; avr-libc-dev@nongnu.org Subject: [bug #17470] Add API for CLKPR register to avr/power.h Follow-up Comment #4, bug #17470 (project avr-libc): What about making this avr/clock.h instead? Rather not. I'd even have preferred it to combine the power save register and sleep mode stuff into a single file rather than two; Except that it was already called sleep.h; it didn't make sense to put anything else in sleep.h that really doesn't have to do with sleeping. it doesn't make much sense to start one header file per control register. I agree; I'm just trying to group things logically with their names. If changing the system clock rate is only used for power savings, then I agree 100% it should be put in power.h. My only concern is if it is used *in some other way* other than for power savings. As things stand, I'll put it in power.h. Other compilers/libraries ship with about two or three header files for everything, we already have more than a dozen of them in the avr/ subdir. It's a feature, not a bug. We have fine-grained control. ;-) Thanks Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] Use of deprecated attribute
Hello, Should __attribute__((deprecated)) be used in the definition of SIGNAL() in interrupt.h? My concern would be that it is applied to the use of the function name, which in this case would be __vector_X (or somesuch) and the warning would be confusing to the end user. Reference: http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Function-Attributes.html#Functi on-Attributes Thoughts? Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Re: [avr-libc-commit] avr-libcChangeLoginclude/avr/interrupt.h incl...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Eric Weddington Sent: Monday, August 28, 2006 2:26 PM To: 'Joerg Wunsch'; avr-libc-dev@nongnu.org; 'Bernd Trog' Subject: RE: [avr-libc-dev] Re: [avr-libc-commit] avr-libcChangeLoginclude/avr/interrupt.h incl... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Joerg Wunsch Sent: Monday, August 28, 2006 1:51 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] Re: [avr-libc-commit] avr-libc ChangeLoginclude/avr/interrupt.h incl... As Bernd Trog wrote: * include/avr/interrupt.h: Add the 'externally_visible' attribute on all interrupt service routine macros. Note that 'externally_visible' is a new attribute. Introduced with 4.1.0, unknown to versions 4.1.0. Thanks for the heads-up. That means we have to encapsulate that using some preprocessor magic like: #if __GNUC__ = 4 # define __INTR_ATTRS used, externally_visible #else /* GCC 4.x */ # define __INTR_ATTRS used #endif ... #define ISR(vector)\ void vector (void) __attribute__ ((signal, __INTR_ATTRS)); \ void vector (void) etc. (Also needed in compat/deprecated.h and in the documentation.) Do we really need that? Or will previous versions just silently ignore this? I'm going to be finding out soon... Bah. Previous versions of gcc (3.4.6) gives a warning about an unused attribute. I'll take care of it. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #16411] -fwhole-program optimization deletes ISRs
Update of bug #16411 (project avr-libc): Status:None = Fixed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?16411 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #15512] bootloader-utilities not IR-save
Update of bug #15512 (project avr-libc): Status:None = Fixed Percent Complete: 0% = 100% Open/Closed:Open = Closed ___ Follow-up Comment #2: This is not really a bug in the code. The documentation only alluded to the fact that the user needs to handle disabling global interrupts by showing this in the code example. I've changed the documentation to now explicity say that the user needs to do this. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?15512 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #14855] Link Error relocation truncated to fit: R_AVR_13_PCREL
Follow-up Comment #7, bug #14855 (project avr-libc): Is this still a valid bug? ___ Reply to this item at: http://savannah.nongnu.org/bugs/?14855 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] GCC bug list
-Original Message- From: Joerg Wunsch [mailto:[EMAIL PROTECTED] Sent: Friday, September 01, 2006 3:24 PM To: avr-libc-dev@nongnu.org Cc: Eric Weddington Subject: Re: [avr-libc-dev] GCC bug list Just be careful, and always run CVS with the -n option first for whatever you're doing there, so you can see what would happen. Believe it or not, each time I'm updating something there, I follow the README description almost by the latter myself, including the -n part. ;-) Thanks, will do. :-) Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Patch #4461 (256x support)
-Original Message-
From: Anatoly Sokolov [mailto:[EMAIL PROTECTED]
Sent: Monday, September 11, 2006 4:54 PM
To: Eric Weddington; 'avr-libc-dev'
Subject: Re: [avr-libc-dev] Patch #4461 (256x support)
- Original Message -
From: Eric Weddington
To: 'avr-libc-dev'
Sent: Tuesday, September 12, 2006 2:20 AM
Subject: [avr-libc-dev] Patch #4461 (256x support)
All,
Any objection to add Patch #4461 (256x support) to HEAD and
1.4 branch?
https://savannah.nongnu.org/patch/?4461
In 'avr/iom2560.h' and 'avr/iom2561.h' files FLASHEND
should be 0x3
instead 0x2.
So noted. I'll make the change.
Also it is necessary to add changes to the documentation
files ('NEWS',
'doc/api/main_page.dox' and 'doc/api/using-tools.dox') and in
'include/avr/wdt.h' file.
Thanks for the list. I'll make the changes.
I've also had to make a couple of other minor changes in the header files
and regenerate the patch since the repository has changed.
I will attach the updated headers and patch to the Patch Tracker.
Any other objections? Or if these issues are met, can it be committed?
Thanks
Eric
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #4461] Add support for ATMega 2560-2561
Update of patch #4461 (project avr-libc): Assigned to:None = arcanum ___ Reply to this item at: http://savannah.nongnu.org/patch/?4461 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #4461] Add support for ATMega 2560-2561
Additional Item Attachment, patch #4461 (project avr-libc): File name: iom2560.h Size:1 KB Updated iom2560.h http://savannah.nongnu.org/patch/download.php?file_id=10734 ___ Reply to this item at: http://savannah.nongnu.org/patch/?4461 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #4461] Add support for ATMega 2560-2561
Additional Item Attachment, patch #4461 (project avr-libc): File name: iom2561.h Size:1 KB Updated iom2561.h http://savannah.nongnu.org/patch/download.php?file_id=10735 ___ Reply to this item at: http://savannah.nongnu.org/patch/?4461 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #4461] Add support for ATMega 2560-2561
Update of patch #4461 (project avr-libc): Status:None = Done Open/Closed:Open = Closed ___ Follow-up Comment #2: Patch applied to HEAD and 1.4 branch. Closed tracker. ___ Reply to this item at: http://savannah.nongnu.org/patch/?4461 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #5377] Fix for multiple dufinition error
Update of patch #5377 (project avr-libc): Priority: 5 - Normal = 7 - High ___ Reply to this item at: http://savannah.nongnu.org/patch/?5377 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #4829] Add support for ATmega640-1280-1281-2560-2561
Update of patch #4829 (project avr-libc): Priority: 5 - Normal = 7 - High ___ Follow-up Comment #1: Support for the ATmega256x devices are already in GNU Binutils (2.17+) and now in avr-libc (1.4.4+). Adding a different patch for GCC 4.1.x from the avr-ada project (on SF). ___ Additional Item Attachment: File name: gcc-4.1.0-mega256x.patch Size:14 KB Patch for GCC 4.1.x to add support for ATmega256x devices. http://savannah.nongnu.org/patch/download.php?file_id=10756 ___ Reply to this item at: http://savannah.nongnu.org/patch/?4829 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #3729] Printf for integers speed up
Update of patch #3729 (project avr-libc): Priority: 5 - Normal = 9 - Immediate ___ Reply to this item at: http://savannah.nongnu.org/patch/?3729 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [task #3693] Add new devices: mega 640-1280-1281-2560-2561
Update of task #3693 (project avr-libc): Percent Complete: 50% = 90% ___ Follow-up Comment #10: All that is left is support for ATmega2560 and ATmega2561 in GCC. Patch is available in Patch Tracker for GCC 4.1.x. More testing is needed for overall ATmega256x support. ___ Reply to this item at: http://savannah.nongnu.org/task/?3693 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] RE: [bug #17728] Errors building documentation in MinGW
-Original Message- From: Joerg Wunsch [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 3:21 PM To: Eric Weddington; Joerg Wunsch; avr-libc-dev@nongnu.org Subject: [bug #17728] Errors building documentation in MinGW Follow-up Comment #1, bug #17728 (project avr-libc): If this is really the log from a pristine run (i. e. after a make clean), there are several things fishy here: Hmm. You could be right. Can't remember. Rebuilding from clean cvs checkout. There's another strange detail in your log. Doxygen starts, and eventually spits out a number of messages like this one: Generating page index... Error: source ../../doc/examples/demo is not a readable file or directory... skipping. Error: source ../../doc/examples/largedemo is not a readable file or directory... skipping. Error: source ../../doc/examples/stdiodemo is not a readable file or directory... skipping. Maybe that's related? Good eye. I didn't catch on that it was the same list of files. Now why would doxygen barf on those? Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] RE: [bug #17728] Errors building documentation in MinGW
-Original Message- From: Joerg Wunsch [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 3:53 PM To: avr-libc-dev@nongnu.org Cc: Eric Weddington Subject: Re: [bug #17728] Errors building documentation in MinGW As Eric Weddington wrote: Good eye. I didn't catch on that it was the same list of files. Now why would doxygen barf on those? make seems to have some kind of troubles with them as well. I can't see your environment, so perhaps you can analyze that a bit. Perhaps it's some confusion between C:/ vs. /c/ or such? Good point. I'll see what I can find out, but it may take me some time. BTW, there's another issue about building the docs. I get an error: make[4]: Leaving directory `/c/avrdev/avrlibc/avr-libc/doc/examples/stdiodemo' make[3]: *** No rule to make target `../../../avr-libc/stamp-h1', needed by `doxygen.config'. Stop. make[3]: Leaving directory `/c/avrdev/avrlibc/build/doc/api' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/c/avrdev/avrlibc/build/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/avrdev/avrlibc/build' make: *** [all] Error 2 So I just removed the stamp-h1 file as a dependent, since there isn't a rule in that makefile (in doc/api) on how to build it. The rule is in the makefile on the root. Workaround patch is attached. However, the question is how should the problem really be fixed? I can open up a separate bug report if you like. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #17728] Errors building documentation in MinGW
Follow-up Comment #2, bug #17728 (project avr-libc): Deleted the make log, rebuilt from a clean checkout, and attached the new make log. ___ Additional Item Attachment: File name: avr-libc-make-log.tar.bz2 Size:102 KB New make log from clean build. http://savannah.nongnu.org/bugs/download.php?file_id=10758 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17728 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Re: AVR-libc-dev Digest, Vol 40, Issue 3
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of David Breeze
Sent: Thursday, September 14, 2006 3:44 AM
To: [EMAIL PROTECTED]; avr-libc-dev@nongnu.org
Subject: [avr-libc-dev] Re: AVR-libc-dev Digest, Vol 40, Issue 3
Btw., does anyone know why there are five linker scripts per
device/architecture? (.x, .xbn, .xn, .xr, .xu)
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
I asked the same question about 4 years ago. The answer I
got then, from Peter Jansen, was
from the binutils/ld/genscripts.sh source,
#Generate 5 or 6 script files from a master script template in
#$(srcdir)/scripttempl/${SCRIPT_NAME}.sh. Which one of the 5 or 6
#script files is actually used depends on command line options given
#to ld. (SCRIPT_NAMES was set in the emulparams_file)
#
#A .x script file is the default script
#A .xr script is for linking without relocation (-r flag)
#A .xu script is like .xr but *do* create constructors (-Ur flag)
#A .xn script is for linking with -n flag (mix text and data
on same page).
#A .xbn script is for linking with -N flag (mix text and data
on same page).
#A .xs script is for generating a shared library with the
--shared flag;
#it is only generated if $GENERATE_SHLIB_SCRIPT is set by the
emulation parameters
Thanks for bringing this up David! I've now committed this info to the
avr-libc FAQ in the user manual.
Eric
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] Updated bug list.
All, The AVR Toolchain bug list has been updated: http://www.nongnu.org/avr-libc/bugs.html Anatoly Sokolov has fixed GCC bug #26504. Thanks, Anatoly! Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] RE: [bug #17728] Errors building documentation in MinGW
-Original Message- From: Joerg Wunsch [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 3:53 PM To: avr-libc-dev@nongnu.org Cc: Eric Weddington Subject: Re: [bug #17728] Errors building documentation in MinGW As Eric Weddington wrote: Good eye. I didn't catch on that it was the same list of files. Now why would doxygen barf on those? make seems to have some kind of troubles with them as well. I can't see your environment, so perhaps you can analyze that a bit. Perhaps it's some confusion between C:/ vs. /c/ or such? Hmm. This might be something in my path. I run doxygen from the MSYS command line and I get the same doxygen warnings, but no errors. The difference is that my avr-libc build environment reduces the PATH to just a few directories. I'll have to look at it more tomorrow. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #17728] Errors building documentation in MinGW
Update of bug #17728 (project avr-libc): Assigned to:joerg_wunsch = arcanum Percent Complete: 0% = 20% ___ Follow-up Comment #3: I'm currently working on several fixes. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17728 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #17728] Errors building documentation in MinGW
Update of bug #17728 (project avr-libc): Percent Complete: 20% = 80% ___ Follow-up Comment #4: Fixed. Will be committing shortly. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17728 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #17815] Configure does not honor --mandir option
Update of bug #17815 (project avr-libc): Priority: 5 - Normal = 3 - Low ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17815 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #17728] Errors building documentation in MinGW
Update of bug #17728 (project avr-libc): Status:None = Fixed Percent Complete: 80% = 100% Open/Closed:Open = Closed ___ Follow-up Comment #5: Commited fix to 1.4 branch and HEAD. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17728 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] Building documentation in MinGW/MSYS
All, For the first time ever, the avr-libc documentation can finally be built on a MinGW/MSYS host! All of it: html, ps, pdf, and man pages. This is the first time I've ever been able to do this in the 4 years that I've been working on avr-libc. The patches to enable this have been committed on the 1.4 branch and HEAD. I will also add more to the documentation on exactly what tools are necessary. But for the impatient, here's the executive summary: avr-libc documentation requirements --- 1. Doxygen - http://www.stack.nl/~dimitri/doxygen/ 2. NetPbm - Get from GnuWin32 from http://gnuwin32.sourceforge.net/packages.html 3. fig2dev - Part of TransFig package, which is part of XFig. - Can get as part of WinFig package (XFig for Windows) from http://www.schmidt-web-berlin.de/WinFIG.htm 4. Latex - Miktex is latex for windows: http://www.miktex.org/. Full installation. 5. Ghostscript - http://www.cs.wisc.edu/~ghost/ The only unknown is with Miktex. It has a Basic Installation and a Full Installation. I don't know if only the Basic Installation is required. I went ahead and did the Full Installation and I know it works with that. Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] Avr-libc warnings
Hi Joerg, So, I was perusing the oft-neglected TODO file, and I noticed that you have a (very old) patch to fix a number of avr-libc build warnings. http://lists.nongnu.org/archive/html/avr-libc-dev/2002-08/msg00054.html Would the patch still be valid? The TODO said that the patch just needs some love before it's committed. What kind of special care does it need? Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
:Re: [avr-libc-dev] Building documentation in MinGW/MSYS
Sorry I'm responding so late to this; I didn't receive this message and I seem to be having intermittent problems with my subscription. :-( I only noticed Joerg's response after perusing the archives. As Eric Weddington wrote: I finally had the time to review all your changes, and about the only one I'm not really happy with is: * doc/api/Makefile.am (doxygen.confg): Remove the dependency on $(top_srcdir)/stamp-h1 as there is no rule in this Makefile to build it, which causes an error. The rule is located in the top level Makefile. I see your point, but some kind of dependency ought to be there to rebuild the docs in case something else has been changed. I think we simply need to find a better way to propagate a reconfiguration step that has been performed at the top level down into the docs build. I agree with you, I'm not very happy about that one either. I couldn't find a quick fix, and it seemed harmless enough to remove and it solved my immediate problem. I agree that there should be a dependency there. But I couldn't figure out how to get this working in the autotools. If anyone has a better idea, I'm certainly open to it. The only unknown is with Miktex. It has a Basic Installation and a Full Installation. I don't know if only the Basic Installation is required. I went ahead and did the Full Installation and I know it works with that. Just go ahead with the full version. For Unix systems, the teTeX distribution has now become the de-facto standard for LaTeX Co., and like MikTeX, it's an ``all inclusive'' system that installs as much as might ever be needed by default. Well it took so long to install the full version that I doubt I'll go back to the basic installation to find out! :-) Thanks Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #17470] Add API for CLKPR register to avr/power.h
Update of bug #17470 (project avr-libc): Status:None = Fixed Percent Complete: 0% = 100% Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17470 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] iousbxx6_7.h ? interrupt vectors misnumbered?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Joerg Wunsch Sent: Sunday, October 29, 2006 4:02 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] iousbxx6_7.h ? interrupt vectors misnumbered? As Julian Bleecker wrote: I am attempting to port some krufty IAR code to GCC for the AT90USB1287. Pester Atmel about it. They've got GCC code as well. Hey, Joerg: Do you remember which email address it is to pester that group in Atmel? Thanks Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [bug #3485] Using float arithmetic without linking with -lm result in incorrect code
-Original Message- From: Bob Paddock [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 6:47 AM To: avr-libc-dev@nongnu.org Cc: [EMAIL PROTECTED]; Andrea Baldoni; Eric Weddington; Joerg Wunsch Subject: Re: [avr-libc-dev] [bug #3485] Using float arithmetic without linking with -lm result in incorrect code Follow-up Comment #4, bug #3485 (project avr-libc): Bug #18169 has been marked as a duplicate. Using float arithmetic without linking with -lm result in incorrect code This is standard 'C', maybe it should be added to the FAQ? We have a task (in the tracker) to eventually merge libc and libm, which would avoid the problem altogether. Ideally, we'd rather have this solution in place, then to just document the existing problem. However, having said that, no one has done much work on this task to date that I know of. So I understand the need to document the existing problem... Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] WinAVR - gcc 3.4.6 - AVR Studio - DuoCore PC -Stackpointer problem
Hi Steffan, To help you, we would need to see a source code test case, with the actual error output that you described. Eric Weddington -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Steffen Rose Sent: Monday, November 20, 2006 2:30 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] WinAVR - gcc 3.4.6 - AVR Studio - DuoCore PC -Stackpointer problem Hello, our program works compiled with cygwin, Makefiles and WinAVR works correctly compiled on different PCs. But on ony System we have the following problem: The PC is a DuoCore PC and we use the IDE AVR Studio for compiling. The used Options are the same than the Makefile. Additional Options are used for creating needed Files for the AVR Studio (-M -MD ..). Now, we can see corrupt code on different positions. With minimal changes the error is on a total other place. On the one time the wrong parameters from the Stack frame is used. One time the Stackpointer High-byte is set to 0x00. Have anyone help for me? -- Regards Steffen Rose ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #5647] Patches to add ATmega3290P device to binutils, gcc.
URL: http://savannah.nongnu.org/patch/?5647 Summary: Patches to add ATmega3290P device to binutils, gcc. Project: AVR C Runtime Library Submitted by: arcanum Submitted on: Sunday 12/24/2006 at 11:52 Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any ___ Details: Patches to add ATmega3290P device to binutils, gcc. ___ File Attachments: --- Date: Sunday 12/24/2006 at 11:52 Name: binutils-2.17-atmega3290p.patch Size: 501B By: arcanum http://savannah.nongnu.org/patch/download.php?file_id=11594 --- Date: Sunday 12/24/2006 at 11:52 Name: gcc-4.1.1-atmega3290p.patch Size: 2kB By: arcanum http://savannah.nongnu.org/patch/download.php?file_id=11595 ___ Reply to this item at: http://savannah.nongnu.org/patch/?5647 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #5647] Patches to add ATmega3290P device to binutils, gcc.
Update of patch #5647 (project avr-libc): Assigned to:None = aesok ___ Reply to this item at: http://savannah.nongnu.org/patch/?5647 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] no malloc in vfscanf or vfprintf?
Go ahead and sumbit a bug report on the documentation, that way we don't forget the issue. Then one of us will go and double check the code. If the docs need fixing then we'll do just that. Thanks for catching this! Eric Weddington -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Galen Seitz Sent: Thursday, January 04, 2007 9:24 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] no malloc in vfscanf or vfprintf? The documentation at http://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html says By default, fdevopen() as well as the floating-point versions of the printf and scanf family require malloc(). Looking at the version 1.4.5 source code for vfscanf and vfprintf, it appears that the floating point buffers are local variables, and malloc is not used. Have I missed something, or should I submit a bug on the documentation? thanks, galen ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Anatoly Sokolov Sent: Tuesday, February 13, 2007 9:52 AM To: Anatoly Sokolov; Joerg Wunsch; [EMAIL PROTECTED]; avr-libc-dev@nongnu.org Subject: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it Follow-up Comment #1, bug #19050 (project avr-libc): Call main() as a normal function have some drawback: 1. Loss of two bytes of RAM for storing 'main' return address in stack. 2. Increase code size, if 'main' function has local variables. Now stack frames for 'main' function is setup by a following code: REG_Y (frame pointer) = RAM_END - frame_size SP = REG_Y Size = 4 instruction. If 'main' will be usual function, that in prologue will be a following code: PUSH REG_Y REG_Y = SP REG_Y = REG_Y - frame_size SP = REG_Y Size - 7/8 instruction and loss of two bytes more of RAM. And 7/8 more instructions in an epilogue of function. 3. If in 'main' function 'call-saved' registers (r2..r17) will be used, then they will be saved in a stack. Hi Anatoly, You make some very good points. Unfortunately, main() is already converted over to a normal function in gcc 4.x. Do you propose that we convert it back? Can someone remember what was the reasoning behind making main() a normal function? Is the reason still valid? Thanks Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it
-Original Message- From: Anatoly Sokolov [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 13, 2007 11:32 AM To: Eric Weddington; 'Joerg Wunsch'; Joerg Wunsch; avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it - Original Message - From: Eric Weddington [EMAIL PROTECTED] Sent: Tuesday, February 13, 2007 8:35 PM Subject: RE: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it You make some very good points. Unfortunately, main() is already converted over to a normal function in gcc 4.x. Do you propose that we convert it back? No. In oficial GCC 4.x main() do not converted to a normal function. 'atmega256' patch does it. Can someone remember what was the reasoning behind making main() a normal function? Is the reason still valid? Marek suggested to make main() a normal function, for simplification transitions to RTL prologues/epilogues: https://savannah.nongnu.org/task/?4355 I sent a patch to use RTL prologues/epilogues in GCC two months ago. 'main' function is processed separately, to be called with XJMP. Marek reason do not valid. Ah! Thank you for making this clear. Joerg, what do you think of this? Time to revisit the atmega256x patch? Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it
-Original Message- From: Joerg Wunsch [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 13, 2007 1:00 PM To: avr-libc-dev@nongnu.org Cc: 'Anatoly Sokolov'; Eric Weddington Subject: Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it As Eric Weddington wrote: Joerg, what do you think of this? Time to revisit the atmega256x patch? Well, maybe. I suggest we change gcrt1.S anyway: if we are not going to place the additional infinite loop behind itx, the only cost for doing so is a single CALL/RCALL plus the two (or three for the ATmega256x) bytes on the stack. As we already do have compilers around right now that treat main() as a normal function, this would simply get us onto the safe side avr-libc-wise. Anatoly, is this ok with you? In general, I agree with Anatoly's argumentation. However, I believe the C standard would require main() to be callable, so ideally the treatment of main() should be an option, and it should even default to being enabled (like we do for -mint8, although the consequences aren't so drastic as in the -mint8 case). In case we should ever implement 64-bit floats, I'd also like to see them being the default (for standards conformance reasons), with some option (say, -mdouble32) to revert to the current behaviour. Agreed with the 64-bit float behaviour. Btw., part of treating main() as a normal function was to remove the obsolete initialization of the stack pointer at the beginning of main()(when it's actually being already initialized early in .init2). I don't know whether that's alredy default GCC behaviour, or also came from Bjoern's ATmega256x patch. Yeah, we need to find out. Also, we should certainly ask Bjoern for any comments. I've forwarded him your email and have asked for comments. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] Next release version
All, I'm not looking to do an avr-libc release soon, but I wanted to ask about which version ought to be released next. Should it be the 1.6 branch because of the new floating point library? I'm thinking that that would be a very nice feature to release next. No rush... Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Next release version
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Joerg Wunsch Sent: Tuesday, February 13, 2007 1:55 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] Next release version As Eric Weddington wrote: Should it be the 1.6 branch because of the new floating point library? I'm thinking that that would be a very nice feature to release next. I thought of releasing a snapshot from the development branch (1.5) for the first time, so people could test the new FP library, while still maintaining the 1.4 branch for those who need to go the conservative route. Thanks. You're right (as always). That sounds like the best route. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [bug #19050] gcrt1.S should call main ratherthanjumping to it
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Joerg Wunsch Sent: Tuesday, February 13, 2007 2:28 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main ratherthanjumping to it As Anatoly Sokolov wrote: I would prefer to correspond to 'C' standard completely, but we are ready to pay such price, for that that function 'main()' to be callable? That's I would like to have that as a command-line option. We definately should adhere to the C standard by default, but by suggesting the users to use an option like -momit-mainframe (:-), they can adjust it to the current behaviour. Documentation needs to clarify the implications of using that option. As for suggesting that to the users, I think the Makefile templates (WinAVR, Mfile, AVR Studio Makefile generation) are already doing a good enough job, so many users probably wouldn't notice it at all. I'm sorry, could you clarify this? Are you suggesting that we will have to *add* a command-line option to get the smaller code? If so, this certainly doesn't help backwards-compatibility. So far, I've seen a couple of users (maybe) complaining on avrfreaks.net, not more, and in that case, it's already been the pathological case you've been quoting. Of course, if the command-line option is impossible for some reason (e.g. since it would make the RTL too complicated or whatever), we really have to see whether standards conformance or code bloat is more important for us. I like the ideal of standards conformance, but the bottom line is that I lean towards practicality and no code bloat. I would also prefer NOT adding a new command-line option to get the older smaller code. This induces versioning issues to achieve the same functionality. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [bug #19050] gcrt1.S should call main ratherthanjumping to it
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Björn Haase Sent: Tuesday, February 13, 2007 3:27 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main ratherthanjumping to it For similar reasons, I'd suggest to consider dropping -mcall-prologues which saved a little code size at the cost of speed, and made a lot of sense a few years ago, when flash sizes were much smaller than today. And, it probably wouldn't work with the new 3-byte PC devices anyway. (The option probably should still be accepted as a no-op, to avoid breaking existing Makefiles - it was only a hint, and the different prologues were not guaranteed, only used when they saved code size). Hello Marek, IMO -mcall-prologues is still precious. IMO the only real reason for existence of AVR are the small low-cost devices. And there -mcall-prologues could be *very* helpful. Bjoern beat me to it. ;-) I agree completely: -mcall-prologues is still desired if it produces smaller code. In fact, this brings up the question as to why it is not the default? Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [bug #19050] gcrt1.S should call mainratherthanjumping to it
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of David Brown Sent: Wednesday, February 14, 2007 1:23 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #19050] gcrt1.S should call mainratherthanjumping to it Marek Michalkiewicz wrote: It's a tradeoff: smaller, but slower. Marek Can the default be made dependant on the core? Certainly 3-byte PC cores will have enough program space, but the for the smaller cores, you normally want to save space. Alternatively, can the setting follow the optimisation flags? -Os gives call prologues, -O2 gives inline prologues? I like the latter scheme: -Os = -mcall-prologues, -O2 = -mno-call-prologues Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Re: [bug #19050] gcrt1.S should call mainratherthan jumping to it
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Anatoly Sokolov
Sent: Tuesday, February 13, 2007 4:23 PM
To: Joerg Wunsch; avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] Re: [bug #19050] gcrt1.S should
call mainratherthan jumping to it
- Original Message -
From: Joerg Wunsch [EMAIL PROTECTED]
As Anatoly Sokolov wrote:
These changes should be reverted:
- if (main_p)
-{
- fprintf (file, (\t
- AS1 (ldi,r28) ,lo8(%s - HOST_WIDE_INT_PRINT_DEC
) CR_TAB
- AS1 (ldi,r29) ,hi8(%s - HOST_WIDE_INT_PRINT_DEC
) CR_TAB
- AS2 (out,__SP_H__,r29) CR_TAB
- AS2 (out,__SP_L__,r28) \n),
-avr_init_stack, size, avr_init_stack, size);
-
- prologue_size += 4;
-}
- else if (minimize (frame_pointer_needed || live_seq 6))
+ if (minimize (frame_pointer_needed || live_seq 6))
That would restore the old (buggy) stack pointer initialization.
NO! NO! NO! Code which you see in the beginning of main() function:
ldi r28, 0x5D ; 93
ldi r29, 0x08 ; 8
out 0x3e, r29 ; 62
out 0x3d, r28 ; 61
no stack pointer initialization It is function frames
initialization!!!
It is no SP = RAMEND It is SP = FP= (RAMEND - size);
Where 'size' is size all local (unoptimized) variables.
This code compiled for ATmega32 device.
int main()
{
int i;
}
RAMEND for ATmega32 is defined as 0x85F. And SP != 0x085F, but
SP = RAMEND - sizeof(int) = 0x085F - 2 = 0x85D!!!
But, if the frame size is null it is possible to not
initialize function
frames:
- if (main_p)
+ if (main_p size != 0)
{
fprintf (file, (\t
AS1 (ldi,r28) ,lo8(%s - HOST_WIDE_INT_PRINT_DEC ) CR_TAB
AS1 (ldi,r29) ,hi8(%s - HOST_WIDE_INT_PRINT_DEC ) CR_TAB
AS2 (out,__SP_H__,r29) CR_TAB
AS2 (out,__SP_L__,r28) \n),
avr_init_stack, size, avr_init_stack, size);
prologue_size += 4;
}
It needs to be tested, probably the fream pointer (r28:r29)
is required to
the compiler.
Part of the problem here is that the issue with main() being a normal
function is that it is part of the mega256x patch. This brings up some
questions:
Is this portion (about main()) *required* for the mega256x patch?
Can these two be separated?
Can we start the process on getting the mega256x support committed to GCC
HEAD? And deal with the main() issue separately...
Eric
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Add ATmega32xxP devices in GCC
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Anatoly Sokolov Sent: Tuesday, February 20, 2007 10:43 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] Add ATmega32xxP devices in GCC Hello. ATmega32xx and ATmega32xxP devices have very few differences, it is one new bit in ATmega325xP devices and three bits in ATmega329xP devices. There are two variants how to add ATmega32xxP devices in the avr GCC toolchain: 1. Add full support ATmega32xxP devices in binutils/gcc/avr-libc (as the ATmega3290P device is now added). I prefer this variant. 2. Only to add new bits in 'iom32xx.h' files. How we shall add support of ATmega32xxP devices in avr toolchain? If we shall add support of ATmega32xxP devices in the compiler, whether it is possible to add at once support of ATmega64xxP devices or still early? Hi Anatoly, Sorry that this reply comes late. Yes, I agree with you on #1 above. I would rather not add just new bits to an already existing header file with conditional compilation. It makes it very messy. I don't know the status on any mega64xxP devices. I would say that for now, just do the mega32xxP devices. You've been doing so much work recently on adding new devices to the toolchain that I haven't been able to keep up with what you have been doing! :-) Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] printf() benchmarks.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Dmitry K. Sent: Tuesday, February 20, 2007 12:36 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] printf() benchmarks. Hi. A small printf() comparison of 1.4.5 and CVS versions: Avr-libc-1.4.5: Flash, bts Stack, bts Time, clks Function avr2 avr4 avr2 avr4 avr2 avr4 -- sprintf(s,%x,12345) 1914 1700 6868 5731 5598 sprintf(s,%d,12345) 1914 1700 6868 7054 6894 sprintf(s,%e,1.2345)4658 4158138 138 12025 9885 Avr-libc-CVS: Flash, bts Stack, bts Time, clks Function avr2 avr4 avr2 avr4 avr2 avr4 -- sprintf(s,%x,12345) 1690 1500 5757 1078 1010 sprintf(s,%d,12345) 1690 1500 5757 1714 1616 sprintf(s,%e,1.2345)3302 3004 6464 2502 2283 Notes: * Flash: include all needed modules. * Stack: include all enclosed calls, but without a place to args. * Time: without an args preparation. Now, I think, it is possible to assemle an experimental version. Wow! These are some great numbers Dmitry! :-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] OPTIMIZE_SPEED for avr5?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Curtis Maloney Sent: Tuesday, March 06, 2007 3:03 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5? Joerg Wunsch wrote: Perhaps we could offer different sets of libraries containing these functions in their speed-optimized version, in the same sense as we are already offering different sets of printf and scanf libraries. That way, the users can decide to use a different implementation if they prefer (say, -lc is equivalent to -lc_size while there's a different -lc_fast available). My vote is always towards more choice. But instead of -l, could we, perhaps, abuse the CPU type flag, and have (for example) avr5 for size, and avr5f for speed? I'm not quite sure how that would work as the --mcu flag just doesn't take an architecture type (like avr5) but the device name such as --mcu=atmega128. And again, how would the toolchain handle this? The driver (avr-gcc) would have to send special flags to the linker (ld) to map to a fixed library file name and automatically set an -l flag internally. This would mean target specific changes to both GCC and GNU Binutils that would never have a chance to get committed upstream. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] crtusb1287.o not found duing linking.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Andrew Straw Sent: Wednesday, March 07, 2007 2:16 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] crtusb1287.o not found duing linking. Hi, I've just built binutils (2.17), gcc (4.1.2), and avr-libc (1.4.5 and today's CVS) for avr using the instructions here: http://www.nongnu.org/avr-libc/user-manual/install_tools.html including the patch http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-gcc/file s/patch-newdevices Unfortunately, when my project gets to the final link step, I get the following error: /usr/local/avr/lib/gcc/avr/4.1.2/../../../../avr/bin/ld: crtusb1287.o: No such file: No such file or directory Did you also include the patches needed for Binutils?: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-binutils/files/ There's a new devices patch for binutils as well. If you don't include that then the assembler won't know the device, therefore the library (and startup code) won't be built for that device in avr-libc. HTH Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] crtusb1287.o not found duing linking.
Hmm, it looks to me like binutils 2.17 already knows about
this device
-- binutils-2.17/gas/config/tc-avr.c contains the following:
static struct mcu_type_s mcu_types[] =
{
...
{at90usb1287,AVR_ISA_M128,bfd_mach_avr5},
...
{NULL, 0, 0}
};
Furthermore, the patch you link doesn't mention my device, so I'm not
sure how it would help.
Oops, my bad. You're correct.
Additionally,
/usr/local/avr/avr/lib/avr5/crtusb1287.o was installed by avr-libc,
indicating that it did get built. Perhaps gcc doesn't look in this
directory? (The double avr looks a little suspicious to me.)
What's the prefix you used for binutils, gcc, and avr-libc?
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #19280] snprintf(s, 0, fmt, ...) write to foreign memory: s[-1]
Update of bug #19280 (project avr-libc): Priority: 5 - Normal = 9 - Immediate ___ Follow-up Comment #2: Is it too difficult to fix this in the 1.4 branch? Eric ___ Reply to this item at: http://savannah.nongnu.org/bugs/?19280 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #19079] sscanf %s eats 1 char too much
Update of bug #19079 (project avr-libc): Priority: 5 - Normal = 9 - Immediate ___ Reply to this item at: http://savannah.nongnu.org/bugs/?19079 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #19055] Error with function eeprom_write_word
Update of bug #19055 (project avr-libc): Priority: 5 - Normal = 9 - Immediate ___ Reply to this item at: http://savannah.nongnu.org/bugs/?19055 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
