Re: [avr-libc-dev] [bug #12739] Gcc assumes that target libc provides ffs function

As Eric Weddington wrote: > For reference, the ffs function can be found in newlib. > Which probably took it straight from the BSD lib. ;-) As the function is so simple, and the BSD copyright matches our copyright (clause 3 may officially be om

Re: [avr-libc-dev] [bug #12739] Gcc assumes that target libc provides ffs function

As Dmitry K. wrote: > I have look 'ffs' from newlib (1.12.0). It take up to 800 (!) > clocks. Reason: shift is included to loop. The slightly modified BSD code (counter reduced to 8 bits) yields sbiw r24,0 breq .L1 ldi r18,lo8(1) .L9: sbrc r24,0 rjmp .L8

Re: [avr-libc-dev] [bug #12739] Gcc assumes that target libc provides ffs function

As Dmitry K. wrote: > > This makes 6 clocks per cycle, so up to ~ 100 clocks max. > Misprint: 7 clocks per cycle (rjmp). OK, I've confused that with the number of code words. > > I'm interested in seeing Dmitry's code... > > I have use byte-width shift: > >#define val_lo r24 >#define

Re: [avr-libc-dev] Question regarding avrlibc, version 1.2.3 and automake 1.9.1

As Marvin Dickens wrote: > You need to use automake version 1.4 (preferrable 1.4-p5). > You are using automake (GNU automake) 1.9.1. Unless you want to roll your own avr-libc version from CVS, you don't need to run automake/autoconf yourself. Just running ./doconf ought to be sufficient for the

Re: [avr-libc-dev] Question regarding avrlibc, version 1.2.3 and automake 1.9.1

As Björn Haase wrote: > Is there a simple way for having several versions of automake on the > same machine? Rename them to a different name. For example, the FreeBSD ports collection installs automake14, automake15, and automake19, autoconf213, autoconf253, and autoconf259 (no automake or autoc

[avr-libc-dev] [bug #12817] arguments eeprom functions

Update of bug #12817 (project avr-libc): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #1: The idea is that

Re: [avr-libc-dev] [bug #12941] Table of Signal Names in "Interrupts and Signals" is wrong/incomplete

As anonymous wrote: > in tableshould be > --- > SIG_INTERRUPT0 SIG_INT0 > SIG_INPUT_CAPTURE1 SIG_TIMER1_CAPT > SIG_OVERFLOW1 SIG_TIMER1_OVF Based on what source? I don't think we ever followed the names given in the datashee

[avr-libc-dev] Re: Interrupt and signal on UART

As gianni rossi wrote: > I found a problem when I tried to handle INTERRUPT > on UART: > If "SIGNAL" is used to define the handler function > it works, is I use "INTERRUPT" the function halts. Sure. It will recurse to dead if you re-enable interrupts before you've read/written UDC, and thus cle

Re: [avr-libc-dev] [bug #13106] wrong handle of union definitions in bitfields

As Markus Königshaus wrote: > typedef struct > { > uint8_t b_bit0 : 1; > uint8_t b_bit1 : 1; > uint8_t b_bit2 : 1; > union >{ > uint8_t b_union0 : 1; > uint8_t b_union1 : 1; >}; > uint8_t reserve : 4; > } _T_bitfield; > _T_bitfield bitfield; > bitfield.b_union1 = 1; > /

[avr-libc-dev] [bug #13106] wrong handle of union definitions in bitfields

Update of bug #13106 (project avr-libc): Status:None => Invalid ___ Follow-up Comment #1: See email to the avr-libc-dev list. This is a C compiler issue, and even one far out in "impl

[avr-libc-dev] [patch #3997] trivial port to binutils-2.16.90

Update of patch #3997 (project avr-libc): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: Duplicate for bu

[avr-libc-dev] [bug #13116] missing include gards

Update of bug #13116 (project avr-libc): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: Duplicate for bug

[avr-libc-dev] [bug #13106] wrong handle of union definitions in bitfields

Update of bug #13106 (project avr-libc): Open/Closed:Open => Closed ___ Reply to this item at:

Re: [avr-libc-dev] problem building avr-libc using gcc 4.0.0

As Brian Dean wrote: > I'm trying to build avr-libc using avr-gcc built from gcc 4.0.0. > The build fails as follows: (Btw., it's not GCC 4.x that matters but the assembler from binutils 2.16.) Known bug, see: https://savannah.nongnu.org/bugs/?func=detailitem&item_id=12033 As a temporary worka

[avr-libc-dev] [bug #13226] ERROR of PRINTF_LIB_FLOAT of WinAVR-20050214.

Update of bug #13226 (project avr-libc): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #1: As replied in the

Re: [avr-libc-dev] ATtiny 25/45/85 support

As David Carr wrote: > Is there a list of all SIG_* somewhere? The avr-libc doc is supposed to have an exhaustive list of all names. Alas, I recently noticed we are rather inconsistent in the naming. > Also, where does > the number in _VECTOR(#) come from? It corresponds to the vector order in

[avr-libc-dev] [bug #13281] unable to compile for multiple defines of macros: macros.inc multiple includes

Update of bug #13281 (project avr-libc): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: dup for bug #1203

Re: [avr-libc-dev] Documentation/Lib mismatch for inverse( ) function in math lib?

As Wouter van Gulik wrote: > I think there is a documentation flaw for the math lib. The > documentation states there is function: double inverse(double ). Hmm, I was not aware that this function was actually exported and documented to be exported. I recently renamed all supposedly internal (to

Re: [avr-libc-dev] [bug #1929] -Inf not detected

As Anatoly Sokolov wrote: > No this bug in gcc-4.0.0/avrlibc-1.2.3. > Test case work fine with all compare operation ( <, >, =>, <=). I think the problems only arise as soon as library functions are involved. The compiler's handling itself is OK, but FPlib only supports a very simplified approac

Re: [avr-libc-dev] Documentation/Lib mismatch for inverse( ) function in math lib?

As Wouter van Gulik wrote: > Aha, but by accident it was exported to documentation. That's clear > for me now. I think it used to be exported to documentation on purpose once, but I didn't notice that detail when I renamed all supposedly internal functions, and silently assumed inverse() to be of

Re: [avr-libc-dev] Re: [bug #13241] ADHSM missing from iom16.h

As E. Weddington wrote: > >ATmega16 datashet (2466K?AVR?04/05) on page 342: > > > >Changes from Rev. > >2466E-10/02 to Rev. > >2466F-02/03 > > > >... > >8. Removed ADHSM completely. > >... > Thanks, Anatoly! Btw., I've asked [EMAIL PROTECTED] for the reasoning behind that. They replied to me, bu

[avr-libc-dev] [bug #13341] Remove ADCHSM bit from header files

URL: Summary: Remove ADCHSM bit from header files Project: AVR C Runtime Library Submitted by: joerg_wunsch Submitted on: Wed 06/08/05 at 20:27 Category: He

Re: [avr-libc-dev] Re: [bug #13241] ADHSM missing from iom16.h

As E. Weddington wrote: > >In that light, I think we should change our header files to remove > >the bit as well, > Do you mean just the can128 header? Or are there others that you're > thinking of? % grep HSM ~/src/avr-libc/include/avr/io*.h /home/joerg/src/avr-libc/include/avr/iocan128.h:#defi

Re: [avr-libc-dev] mistake in avr libc 1.2.3 manual

As Julien Luethi [Alpsens Technologies SA] wrote: > in the faq "How do I use a #define'd constant in an asm statement?", > the deprecated macro sbi() is mentionned in the note. This had been reported as bug #12040, and was fixed in revision 1.37 of faq.dox. Alas, no new avr-libc version has been

Re: [avr-libc-dev] wdt problem with mega 88

As [EMAIL PROTECTED] wrote: > I would expect this program to wait for a time and then turn on an > led indefinately. I don't have an ATmega88 around to test against, only an ATmega8. I've inverted the logic for the LED (as the STK500 uses low-active LEDs) and tried it on an ATmega8 in the STK500.

Re: [avr-libc-dev] Re: [avrdude-dev] [bug #9787] avrdude 4.4.0 correct butterfly interface

As E. Weddington wrote: > >No... I didn't have the time to fiddle around to get it running - I > >couldn't > >find any support/help for building the toolchain on a NetBSD system... > The avr-libc user manual contains docs on how to build the AVR > toolchain. The easiest starting point would pro

Re: [avr-libc-dev] [bug #12993] "__EICR" redefined warning ATmega8

As Anatoly Sokolov wrote: > Update of bug #12993 (project avr-libc): > > Status:None => Fixed > Open/Closed:Open => Closed Anatoly, thank you very much for all your recent fixes. You've asked me for a review, so I just ran a

Re: [avr-libc-dev] small typo

As Torsten Mohr wrote: > in avr-libc-user-manual-1.2.3 it says in 5.20.2.5: > > sei() enables interrupts by CLEARING the global interrupt flag. > > it should be by SETTING, right? Yes, it should, please file a bug report for this. (Also, it says "interrupt mask" instead of "interrupt flag".) -

Re: [avr-libc-dev] [bug #12993] "__EICR" redefined warning ATmega8

As Joerg Wunsch wrote: > The only remaining thing to do is to merge everything into the 1.2 > branch (CVS name: avr-libc-1_2-branch) where appropriate. Oops, sorry -- I didn't notice you've already done that! So thanks for all your support again! -

Re: [avr-libc-dev] [bug #12993] "__EICR" redefined warning ATmega8

As E. Weddington wrote: > Oh, that's probably my fault. I mention updating the bug list in the > NEWS file in my ChangeLog entries. Oh, well. :-) And you also started to indent changelog entries by 4 spaces instead of the commonly used hard tab. :-)) Overall, I'm *very* glad about Anatoly joinin

Re: [avr-libc-dev] making malloc() and free() reentrant safe

As Branislav Katreniak wrote: > I want to use a multitasking OS in my project. What is the best way > to encapsulate all calls to malloc() and free() with a > synchronization primitives? I want all calls to these functions > (even from other libc functions) to be reentrant safe and ideally > I'd l

[avr-libc-dev] Eric and me are heading for vacation

Just to let you know so nobody wonders about the silence in case you might expect one of us to answer your urgent questions... Both Eric and me are heading for vacation, and incidentally, our schedules overlap quite a bit. So for the first two weeks in July, don't hold your breath until one of us

Re: [avr-libc-dev] [bug #12993] "__EICR" redefined warning ATmega8

As E. Weddington wrote: > >A very rousing: me too!! :-) > Oh, Jörg, should we mention this both the in the NEWS file as well > as a News item in the avr-libc project on Savannah? I'm not so sure about the NEWS file, I merely thought of it as kind of release notes, so with boring technical detail

Re: [avr-libc-dev] Change EEPROM SFR definition.

As Anatoly Sokolov wrote: > In new ATMega devices EEPROM support registers are located to other > addresses than in AT90S/old ATMega/ ATTiny, it does illogical and > error prone the generalized definition of these registers in IO.h. These registers have once already been defined in each individua

Re: [avr-libc-dev] making malloc() and free() reentrant safe

As Russell Shaw wrote: > >If you need stdio functions that call malloc, hmm, I think that'll > >put something else onto your list of non-reentrant functions ;-), > >but still, you could just import the implementations for > >malloc/free into your own application, and make them thread-safe. > What

Re: [avr-libc-dev] Change EEPROM SFR definition.

As Anatoly Sokolov wrote: > >>1.To define EEPROM SFR and corresponding bits in device ioX.h > >>files. > >>2. In io.h for support EEPROM library define EEPROM SFR only if > >>any of __ AVR_device __ is not defined and defined __ > >>COMPILING_AVR_LIBC __. > >I don't see much point in changin

Re: [avr-libc-dev] Change EEPROM SFR definition.

As Anatoly Sokolov wrote: > >Are you willing to do that? > > Yes, I shall do that. Spasibo bolshoye. I think Eric's going to leave for vacation anytime soon now. I've still got a day or two to stay here, but I'll probably not be very responsive here in the mailing list(s) anymore. -- cheers,

[avr-libc-dev] [bug #12033] macros.inc need to be protected from multiple inclusion.

Update of bug #12033 (project avr-libc): Percent Complete: 20% => 90% ___ Reply to this item at:

[avr-libc-dev] bug #12033 (macros.inc)

After finally building binutils-2.16 here, I finally committed everything I've got sitting in my tree that was supposed to fix bug #12033. As already mentioned a number of times, instead of making the supposedly internal file macros.inc idempotent, I rather changed all consumers of that file to in

Re: [avr-libc-dev] bug #12033 (macros.inc)

As John Altstadt wrote: > I raised bug #13416 about the autoconf problem against > avr-libc-1.2.3. I'm afraid I have to close that bug some day unresolved. First, we could not fix a released version of the source code anyway. Second, avr-libc's configuration currently only has a `supported' sta

[avr-libc-dev] [bug #12033] macros.inc need to be protected from multiple inclusion.

Update of bug #12033 (project avr-libc): Status:None => Fixed Percent Complete: 90% => 100% Open/Closed:Open => Closed ___

Re: [avr-libc-dev] bug #12033 (macros.inc)

As Wojtek Kaniewski wrote: > >This has not been merged yet into the 1.2 branch, I'd appreciate if > >others could test whether everything is OK before I merge it. > cvs head compiles fine with binutils 2.16.91.0.1 and gcc 3.4.4. Thanks for the feedback. I've merged the fix to the 1.2 branch, an

Re: [avr-libc-dev] bug #12033 (macros.inc)

As Russell Shaw wrote: > I recently found autoconf/automake has support for that (after > reading the large auto* manuals again). Updating the system to > the latest autotools is something i'll have a go at again some > time. In case you're going to look at this before I'll return from vacation,

Re: [avr-libc-dev] making malloc() and free() reentrant safe

As Russell Shaw wrote: > >>What stdio functions call malloc? > >Currently, fdevopen() ..., and the full-featured (...) versions of > >vfscanf() and vfprintf(). ... > If the prolog stack-checking code gets done, then it could revert to > just using the stack. Curious, what would happen if space

Re: [avr-libc-dev] Change EEPROM SFR definition.

As Anatoly Sokolov wrote: > Im move the EE* register and bit names into each individual ioXXX.h > file and change io.h. Plaece check up changes on CVS tree if they is > ok I shall submit them on avr-libc-1_2-branch. Spasibo bolshoye, what a tremendous amount of work! I reviewed the CVS diff, all

[avr-libc-dev] avr-libc-1.2.4 released

I just released version 1.2.4 of avr-libc. Anatoly did merge his recent bugfixes into 1.2 before (the large EE* register name move between header files, as well as a fix for the watchdog for newer AVRs. I then noticed I needed another fix for recent versions of doxygen (1.4.x) as well as LaTeX (3

[avr-libc-dev] [bug #13416] autoconf version does not match various AVR Libc config files

Update of bug #13416 (project avr-libc): Open/Closed:Open => Closed ___ Follow-up Comment #2: Sorry, this all looks like an autoconf problem to me. I've been using autoconf-1.4 (called by

Re: [avr-libc-dev] New eeprom library. Comments please

As Nigel Winterbottom wrote: > The Attachment was missing (me being a buffoon). Now Added. OK, I had a look at it. At first, please let me thank you for your effort and time spent into it. I'm definately interested. Anyway, as already mentioned, I'd much prefer a diff -u output (like "cvs diff

Re: [avr-libc-dev] Upgrade to use the latest auto tools.

As Nigel Winterbottom wrote: > Your question to Anatoly also applies from me to you, I cannot find > your eeprom patches. Bjoern's EEPROM patches did make it to the list though, unlike Anatoly's patch (which I think he simply forgot to attach). Folks, please keep in mind that the list server str

Re: [avr-libc-dev] [bug #13341] Remove ADHSM bit from header files

As Anatoly Sokolov wrote: > Update of bug #13341 (project avr-libc): > > Status:None => Fixed > Open/Closed:Open => Closed > > ___ > > Follow-up Comment #2: > > Fixed

[avr-libc-dev] I intend to roll avr-libc-1.2.5 by tomorrow

Hi all, I noticed quite a bit late there's a FreeBSD ports freeze for the upcoming FreeBSD 6.0 version by Monday. As I intend to upgrade my FreeBSD ports for the AVR tools to the respective latest versions (including patches for new devices as they appear the be OK), I'd also like to roll an avr-

[avr-libc-dev] [patch #3787] Add infrastructure support for AT90PWMx devices

Additional Item Attachment, patch #3787 (project avr-libc): File name: patch-binutils-2.16-pwmX.diff Size:1 KB patch for binutils-2.16, with full path names ___

Re: [avr-libc-dev] I intend to roll avr-libc-1.2.5 by tomorrow

As Björn Haase wrote: > Open question for issue 1) was if adiw may be safely used in the > library for all of the devices. Since the present state of eeprom > functions makes use of adiw in the eeprom_read_word, I'd simply > assume that the present library implementation is correct and I > could u

Re: [avr-libc-dev] [EEPROM] patch take 2: Fix mis-feature of lacking EEPROM support for many targets / rewrite of eeprom functions

As Björn Haase wrote: > thank's for again preparing a release. Here is the corrected patch > containing the three fixes I had written about a couple of hours > ago. OK, as indicated, that's stuff for tomorrow for me (unless Anatoly beats me on this ;-). I'll also try to integrate as many of the

[avr-libc-dev] Re: [EEPROM] patch take 3: Fix mis-feature of lacking EEPROM support for many targets / rewrite of eeprom functions

As Björn Haase wrote: > according to your request, I have spend the time to make the > remaining block transfers more efficient. ... > Differing from my initial suggestion, I now agree with you that two > dedicated write word and read word functions are useful. Take 3 > implements them. Björn,

[avr-libc-dev] [patch #4189] Document replacement for sbi/cbi instructions

Update of patch #4189 (project avr-libc): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed __

[avr-libc-dev] [patch #4137] Fix for bug #12646

Update of patch #4137 (project avr-libc): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed __

[avr-libc-dev] [bug #12646] strtod returns error for valid input

Update of bug #12646 (project avr-libc): Status:None => Fixed Assigned to:None => joerg_wunsch Open/Closed:Open => Closed ___

[avr-libc-dev] Version 1.2.5 of avr-libc has been released.

Only 10 days after the previous release, I'm happy to announce yet another release of avr-libc. The major reason for a quick followup is to allow for distribution maintainers to pick up the most recent changes as early as possible. This is a bugfix-only release. See the NEWS file at: http://www.

Re: [avr-libc-dev] Not building crtm32.0

As Curtis Maloney wrote: > avr-libc does not build crtm*.o unless I give --with-multilib=avr5 > (undocumented, it seems) to configure. Please read the documentation (*). You're not supposed to run ./configure, but to use ./doconf (or run configure from within a different directory -- that's all

Re: [avr-libc-dev] Not building crtm32.0

As Curtis Maloney wrote: > In that case, someone should fix the INSTALL file in the tarball. > Although it starts with a note saying "doconf" is the simplest way, > it still goes on with a lot of other generic 'configure' stuff. > I just looked for the "Basic Installation" heading, and went from

Re: [avr-libc-dev] Not building crtm32.0

As Björn Haase wrote: > Simply, I think that in case that it turns out that there are good > reasons for using a non-standard procedure for building the lib also > in the future: Maybe it's better to avoid to name the configure > script "configure" :-). I have no idea whether this is even possibl

Re: [avr-libc-dev] eeproms and interrupts

As Bernard Fouché wrote: > ("brberie" showing that reads/writes to eeprom can be perturbated by > interrupts) and the current state of > eeprom_{read|write}_{byte|block} in avr-libc-1.2.5, is there > something to change in avr-libc eeprom management routines to be > sure that no interrupt can make

Re: [avr-libc-dev] eeproms and interrupts

As Bernard Fouché wrote: > Well there are not re-entrant but interrupt safe, even for eeprom > access since eeprom_write_* blocks interrupts correctly. You're right. It's more about reentrancy problems. We could add reentrant functions if needed. They are commonly denoted by appending the suff

Re: [avr-libc-dev] eeproms and interrupts

As Branislav Katreniak wrote: > But what about applications using preemtive kernel? Library > functions which do not access periferials are all thread safe > (except that using malloc() and free()). Why should the > documentation say something different? See Bernard's reply and my followup. Seri

Re: [avr-libc-dev] eeproms and interrupts

As Björn Haase wrote: > I think that it would be appropriate to add such a statement. I just opened a bug report for this (#14068). > (Actually, knowing that I myself usually start reading all the > details of the manual only when I have encountered problems, I don't > have much hope that this p

[avr-libc-dev] [bug #14068] Document non-reentrancy of some library functions

URL: Summary: Document non-reentrancy of some library functions Project: AVR C Runtime Library Submitted by: joerg_wunsch Submitted on: Tue 08/09/05 at 22:42

Re: [avr-libc-dev] compiler

As Dharmesh Patel wrote: > We are intrested to purchase C & C++ Compiler-WINAVR > Tell How can we purchase? You cannot, as it is not being sold -- it is free. > Is it available in Gujarat, India? then send contact details If you've got Internet access, it is available in Gujarat, India. See h

[avr-libc-dev] Re: "autconf" branch merged back to HEAD

As Joerg Wunsch wrote: > I just merged the "autoconf" branch back to the HEAD of CVS. Btw., the doxygen build is not yet there, I'll work on this next. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/

[avr-libc-dev] "autconf" branch merged back to HEAD

I just merged the "autoconf" branch back to the HEAD of CVS. You do need current versions of autoconf and automake (2.57 and 1.7 needed, 2.59 and 1.9 resp. recommended). The old "doconf" and "domake" scripts are gone! "reconf" has been renamed "bootstrap" now, as this is a more generic name. No

Re: [avr-libc-dev] sscanf

As Darcy Watkins wrote: > The return value should be the number of fields assigned (and not > count those with assignment suppressed). That half-sentence in the brackets is your own though. I wish the standard had that explicit wording. But it appears you are right, it's the number of assignmen

Re: [avr-libc-dev] sscanf

As David Breeze wrote: > Whilst not the ANSI text K & R second edition also says "It returns > as its value the number of successfully matched and assigned input > items" The standard (draft) says: ``The fscanf function returns the value of the macro EOF if an input failure occurs'' before any c

[avr-libc-dev] Re: "autconf" branch merged back to HEAD

As Joerg Wunsch wrote: > > I just merged the "autoconf" branch back to the HEAD of CVS. > Btw., the doxygen build is not yet there, I'll work on this next. Back there, too. I disabled building the demos as part of the documentation. It's a lot of headache (as y

[avr-libc-dev] [task #3623] Upgrade to use the latest auto tools.

Update of task #3623 (project avr-libc): Status: In Progress => Done Open/Closed:Open => Closed ___ Reply to this item at:

Re: [avr-libc-dev] Re: "autconf" branch merged back to HEAD

As Joerg Wunsch wrote: > I disabled building the demos as part of the documentation. It's > a lot of headache (as you cannot count on an already installed > instance of avr-libc for the libraries) with only little or null > value (IMO). Umm, I take that back. ;-) The reason

[avr-libc-dev] New layout for documentation

Hi, I've made a stab on a slightly new layout for our documentation. Please have a look at http://www.sax.de/~joerg/avr-libc-user-manual/index.html Opinions? -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Neve

[avr-libc-dev] [bug #14068] Document non-reentrancy of some library functions

Update of bug #14068 (project avr-libc): Status:None => Fixed Open/Closed:Open => Closed ___ Reply to this item at:

[avr-libc-dev] Re: New layout for documentation

As Joerg Wunsch wrote: > I've made a stab on a slightly new layout for our documentation. > Please have a look at > http://www.sax.de/~joerg/avr-libc-user-manual/index.html Some downloads, but no opinions stated, except one who sent me a private mail that he likes the new

Re: [avr-libc-dev] Re: New layout for documentation

As E. Weddington wrote: > >Opinions? > Sweet! Fine! > How soon can you get it up on the avr-libc web site?! ;-) As the web site by convention documents the latest stable release: as soon as 1.4.0 is out. (See below.) My intention was to apply all those new device patches that are marked as `

Re: [avr-libc-dev] What happened to Tiny25/45/85?

As David Carr wrote: > A while back there was a string of patches submitted by Anatoly to > add support for the Tiny25/45/85 devices. In fact this work is > listed in patch #4049. Strangely though, I don't see any of it in > CVS. Sure, nobody so far found the time to integrate them, and we (Ana

[avr-libc-dev] [patch #2923] Add infrastructure support for new AVR devices.

Update of patch #2923 (project avr-libc): Open/Closed:Open => Closed ___ Reply to this item at: ___

Re: [avr-libc-dev] Re: New layout for documentation

As John Devereux wrote: > > Some downloads, but no opinions stated, except one who sent me a > > private mail that he likes the new layout. > I think it's great! A big improvement. Well, I'm really glad people love it. It's always hard to know whether stylistic changes like this one actually ma

[avr-libc-dev] Are there any autoconf/automake experts around?

With the new setup, it seems automake insists on have a "C compiler that can create executables", no matter what I'm trying. Of course, on a virgin system, avr-gcc cannot create an "executable" in automake's opinion, as there is no library (yet). All this must somehow happen inside the single cal

Re: [avr-libc-dev] Re: New layout for documentation

As Wojtek Kaniewski wrote: [Btw., your missing capitalization makes reading your message rather hard.] > >Well, I'm really glad people love it. It's always hard to know > >whether stylistic changes like this one actually match other > >people's opinions as well. > then probably i must be the on

Re: [avr-libc-dev] Are there any autoconf/automake experts around?

As Dave Hylands wrote: > Hi J"org, Thanks for the quick follow, Dave. > Even without the run-time library, you should still be able to > produce an "executable" (using the -nostdlib options et al). That was my first idea, too, so I tried that, to no avail. The check that fails is the one that

[avr-libc-dev] [patch #3787] Add infrastructure support for AT90PWMx devices

Follow-up Comment #4, patch #3787 (project avr-libc): BEWARE: the GCC patch is bad. The AT90PWMx devices have SRAM starting at 0x[800]100, the patch doesn't take that into account. ___ Reply to this item at:

[avr-libc-dev] [task #3726] Add new device: AT90PWM3

Update of task #3726 (project avr-libc): Percent Complete: 80% => 90% ___ Follow-up Comment #2: avr-libc is done. ___ Reply to this

[avr-libc-dev] [task #3725] Add new device: AT90PWM2

Update of task #3725 (project avr-libc): Percent Complete: 80% => 90% ___ Follow-up Comment #2: avr-libc is done. ___ Reply to this

[avr-libc-dev] [patch #3787] Add infrastructure support for AT90PWMx devices

Update of patch #3787 (project avr-libc): Status:None => In Progress ___ Reply to this item at: ___

Re: [avr-libc-dev] Re: New layout for documentation

As Christopher X. Candreva wrote: > While not optimal, the previous tree was probably the ONLY > side-navigation I've ever liked on a web site. I found it very easy > to use for online reference. The new page, so far, I do not find > easy to jump around and use for reference. I'm open for any s

[avr-libc-dev] [task #3594] Add new devices: 329-3290-649-6490

Update of task #3594 (project avr-libc): Percent Complete: 0% => 90% ___ Follow-up Comment #1: avr-libc done. ___ Reply to this ite

[avr-libc-dev] [patch #4080] Add support for ATMega 329-3290-649-6490

Update of patch #4080 (project avr-libc): Status:None => In Progress ___ Follow-up Comment #2: avr-libc done. ___ Reply to this it

Re: [avr-libc-dev] Are there any autoconf/automake experts around?

As Wojtek Kaniewski wrote: > There is an undocumented macro AC_NO_EXECUTABLES which turns off the > behavior you're talking about when placed before AC_PROG_CC. Well, yes, that's what I eventually found out by digging through the M4 files. > Unfortunately it can and probably will disappear somed

Re: [avr-libc-dev] Problem with _delay_ms()

As Curtis Maloney wrote: > The new code called it twice, with different values. So the > inline-able function was not inlined, and thus the constant > wasn't cleaned up. Ouch. > I fixed this by giving the function declaration > __attribute__((always_inline))... Yes, that's a

Re: [avr-libc-dev] Are there any autoconf/automake experts around?

As Wojtek Kaniewski wrote: (Setting CFLAGS in autoconf before AC_PROG_CC.) > >...and it didn't work. > It works for me. [...] > After adding CFLAGS="-c" before AC_PROG_CC, configure says: >checking for C compiler default output file name... b.out

[avr-libc-dev] User-visible library version numbers

It has been requested every now and then that there be a user-visible library version number. I'm about to start this with the impending release of the 1.4 branch, so here are a few questions. What to put in there? . __AVR_LIBC_VERSION__ "1.4.0" /* a string */ . __AVR_LIBC_MAJOR__ 1/*

Re: [avr-libc-dev] wdt.h watchdog code - will an interrupt mess up the timing ?

As Jeff Kowing wrote: > My concern is that since global interrupts are potentially > re-enabled on line 5, what prevents an interrupt routine from > triggering before line 6 gets executed ? I believe that the > instruction following a "sei" instruction is guaranteed to execute > before any pendin

Re: [avr-libc-dev] User-visible library version numbers

As Russell Shaw wrote: > Maybe the release date could be added as an extra macro: 050825 for > Aug. 5th, 2005. OK, except I'd use MMDD. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operatin

Re: [avr-libc-dev] User-visible library version numbers

As Bob Paddock wrote: > > >. __AVR_LIBC_VERSION__ "1.4.0" /* a string */ > > >. __AVR_LIBC_MAJOR__ 1/* three integers */ > > >. __AVR_LIBC_MINOR__ 4 > > >. __AVR_LIBC_TINY__0 > As do I. GCC refers to _TINY_ as _PATCHLEVEL, see below. I'm not that happy about `patchlevel' (actua

Re: [avr-libc-dev] User-visible library version numbers

As Bob Paddock wrote: > 'releaselevel' sounds better than _PATCHLEVEL_ which implies bugs, > and _TINY_ is a bit to vague, since there are TINY AVR parts. Well, yes. > > I feel the standardized macro to have a single test for a > > particular release to be a big win. > Yes to both items, single

  1   2   3   4   5   6   7   8   9   10   >