Re: [avr-libc-dev] %f
As Steve Franks wrote: I know no one else in their right mind uses floating point printf/scanf. Why not? That said, the double format, float arg warning is a bit tedious (when you have a giant string parser in a mega128). It's only tedious as the AVR currently doesn't support 64-bit doubles, so sizeof(float) == sizeof(double). Applying the correct type casts is thus a matter of ``living to the letter of the standard'' without having any practical impact. Wouldn't the correct notation be %f - float; %lf - double? No, it wouldn't. You cannot pass a float in a variable argument list, because the elements of a variable argument list are subject to default argument proomotion, where each float value will be promoted to double. You are supposed to cast it to (double) to make this explicit (to the brain of the developer) -- that's what the warning is telling you. I further notice %f is a double in printf, but a pointer to float in scanf. Yes, it is. %lf denotes a pointer to double in scanf(). %lf is identical to %f in printf(). Has this been addressed already? Yes, it has. By the C standard, section 7.9.16.1 (fprintf), and 7.9.16.2 (fscanf), and 6.5.2.2 (function calls, that's where the argument promotion is described). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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): Status:None = Wont Do Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Follow-up Comment #2: We now fully support all mentioned AVR devices. ___ 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] avr-libc 1.4.5 released
I just released avr-libc 1.4.5. Since the upload server dropped connection while I've been uploading all the documentation files, there's now a half-transferred PostScript version of the docs in the queue that needs manual intervention by the savannah folks before I can retransmit it. Thus the PS docs are currently unavailable. Everything else is in place. Source releases and documentation files can be found at: http://download.savannah.gnu.org/releases/avr-libc/ Binary releases (OS-independant) can be found at: http://download.savannah.gnu.org/releases/avr/ The public documentation on the web site has been updated as well: http://www.nongnu.org/avr-libc/user-manual/ Finally, here's the NEWS entry for that release: *** Changes in avr-libc-1.4.5: * Bugs fixed: [no-id] Make include/avr/sfr_defs.h -Wundef safe. [no-id] Make include/avr/eeprom.h -Wundef safe. [no-id] Fix the timing of the HD44780 driver in the stdiodemo. [#15512] Bootloader macros not interrupt safe. [#16125] HD44780 data bit assignment restrictive [#16434] EMPTY_INTERRUPT has no misspelled vector checking [#16411] Add 'used' and 'externally_visible' attributes to all ISR macros. [#16441] eeprom.h should use __asm__ [#16868] depricated.h: outp() arguments order misprint [#17068] wdt.h file: __AVR_ATmeg324P__ spelling mistake [#17470] Add API for CLKPR register. [#17551] Update documentation to point to issues with gcc4.1 [#17591] /avr-libc/libm/fplib/fp_split.S error return will fail for 3-Byte PC devices [#17608] Add ISR_ALIAS() to avr/interrupt.h * Other changes: - New Power Management API in avr/power.h. This provides C language macros to manipulate the Power Reduction Register(s) and the System Clock Prescaler register across multiple processors. * New devices supported: + ATmega165P + ATmega169P + ATmega2560 [patch #4461] + ATmega2561 [patch #4461] -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #16868] depricated.h: outp() arguments order misprint
Update of bug #16868 (project avr-libc): Status:None = Fixed Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?16868 ___ 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 #16125] HD44780 data bit assignment restrictive
Update of bug #16125 (project avr-libc): Status:None = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?16125 ___ 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 #17551] Update documentation to point to issues with gcc4.1
Update of bug #17551 (project avr-libc): Status:None = Fixed Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17551 ___ 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 #17591] /avr-libc/libm/fplib/fp_split.S error return will fail for 3-Byte PC devices
Update of bug #17591 (project avr-libc): Status:None = Fixed Assigned to:None = joerg_wunsch Percent Complete: 80% = 100% Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17591 ___ 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: bootloader for AVR USB DFU
As Andrew Straw wrote: I agree that sounds like a good idea to include in AVRDUDE. What is the bootloader you mention with the there is already one? I had to dig up some old email where someone mentioned this to me. Here's the URL: http://dfu-programmer.sourceforge.net With the ability to load firmware without unplugging a USB device, however, it would be nice to have a library that could do this from within an application without needing to install/run AVRDUDE. I think AVRDUDE could also become a library, if someone wants to spend a bit of work into it. Most of the internal functions are already static, albeit a few programmers have to expose interface to other programmers (like the stk500v2 and jtagmkII programmers share quite a bit of code in order to implement ISP mode through the JTAG ICE mkII). It probably requires some cleanup in main.c, and to document how to use it. But that needs to be discussed on the avrdude-dev mailing list rather than here. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] bootloader for AVR USB DFU
As Javier Almansa Sobrino wrote: You mean, you wrote a program on the Unix host to talk to the bootloader in the AT90USBKEY? yes Only FYI: as the message didn't have a To header, I didn't realize it also went to the list, and wrote Javier a private reply. In short: yes, I think it would be a great addition to AVRDUDE. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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
As Eric Weddington wrote: 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. Congratulations! 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. 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. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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 #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: make[4]: Entering directory `/c/avrdev/avrlibc/avr-libc/doc/examples/demo' make[4]: Nothing to be done for `dox'. (etc. pp.) That's where the EPS versions of these image files are supposed to be created. Here's the extract from my log: gmake[4]: Entering directory `/home/joerg/src/avr-libc/doc/examples/largedemo' jpegtopnm largedemo-setup.jpg |\ pnmtops -noturn -dpi 180 -equalpixels \ largedemo-setup.eps jpegtopnm: WRITING PPM FILE pnmtops: writing color PostScript... jpegtopnm largedemo-wiring.jpg |\ pnmtops -noturn -dpi 180 -equalpixels \ largedemo-wiring.eps jpegtopnm: WRITING PPM FILE pnmtops: writing color PostScript... jpegtopnm largedemo-wiring2.jpg |\ pnmtops -noturn -dpi 180 -equalpixels \ largedemo-wiring2.eps jpegtopnm: WRITING PPM FILE pnmtops: writing color PostScript... gmake[4]: Leaving directory `/home/joerg/src/avr-libc/doc/examples/largedemo' These Makefiles in the example subdirectories are static ones, i.e. not created by automake. Somehow, make must have got the opinion everything has already been done. Do these files (like largedemo-wiring.eps) exist at all, maybe just in a different directory? Otherwise, you probably have to run make in that directory with debugging enabled, in order to see what it is going to evaluate, and why it comes to the conclusion nothing were to be done. 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? ___ 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] 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? Under Unix, I'd use a syscall tracer to see which file names it is looking for. I've got no idea about a comparable Windows tool. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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 #17728] Errors building documentation in MinGW
As Eric Weddington wrote: BTW, what version of doxygen is known to work? I'm using 1.4.7. I've still got a 1.4.6 here, but I don't think that's the issue. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Bootstrap and automake 1.8.2
As Eric Weddington wrote: I can successfully build avr-libc, 1.4 branch, with automake 1.8.2. on MinGW/MSYS. However, the bootstrap script looks for and requires 1.9.x. Can I commit a change to the bootstrap script to allow automake 1.8.x? Or is there some overwhelming reason not to do this? The comments say automake 1.9 were required. I am not sure whether it will work on automake 1.8.x at all. Version 1.9 is more than two years old (2004-07-28), is there really no chance to get a MinGW one of it? If it works, and doesn't break the 1.9 builds, well, you might relax the check. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #16868] depricated.h: outp() arguments order misprint
Update of bug #16868 (project avr-libc): Priority: 5 - Normal = 7 - High ___ Reply to this item at: http://savannah.nongnu.org/bugs/?16868 ___ 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-commit] avr-libc ChangeLog include/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.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] printf_P is not reenterable
As Alexey Boyko wrote: Another variant - initialize stdout for each thread, and use fprintf with different stdout in different thread. That's not possible for avr-libc itself, as threads itself are out of the scope of avr-libc (and most likely are the subject of some kind of RTOS). Of course, a thread library could encapsulate that if desired. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #17561] headers returning PORTx, PINx and DDRx incorrectly for Mega168
Update of bug #17561 (project avr-libc): Status:None = Need Info Assigned to:None = joerg_wunsch ___ Follow-up Comment #3: Sorry, but that's exactly the IO addresses these ports are supposed to live at. You've been confusing IO addresses and memory (MMIO) addresses. For example, PINB is at IO address 0x03 (to be used in IN or OUT instructions), or at memory address 0x23 (to be used in LDS or STS instructions). ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17561 ___ 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] printf_P is not reenterable
As Alexey Boyko wrote:
I found, that printf_P (and other xxprintf_P) is not reenterable.
(I am using some sort of thread switching library)
Yes, agreed. We don't pretend it were:
``General information about this library
...
Unless otherwise noted, functions of this library are not guarenteed
to be reentrant. In particular, any functions that store local state
are known to be non-reentrant, as well as functions that manipulate IO
registers like the EEPROM access routines. If these functions are used
within both, standard and interrupt context, undefined behaviour will
result.''
OK, you might file a (documentation) bug report so the stdio _P
function will also explicitly mentioned there.
I've solve this by adding this function body in program:
int printf_P(const char *fmt, ...)
{
va_list ap;
int i;
va_start(ap, fmt);
//stdout-flags |= __SPGM;
i = vfprintf(stdout, fmt, ap);
//stdout-flags = ~__SPGM;
But of course, that's not a generally applicable solution.
The only solution I could quickly imagine of is to not use vfprintf()
as the central backend function but something like
__vfprintf_internal() that gets an additional argument to tell about
whether the format string is in RAM or ROM. Then, all the wrapper
functions would have to be rewritten to accomodate for the new
interface.
Same applies to the scanf() family.
If someone was willing to provide a patch for that, I wouldn't mind.
Otherwise, it's got a low priority on my list of things to do.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
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
As Eric Weddington wrote: Joerg, do you have any overwhelming objections to just this minimal change, beyond what you've already stated? No, I'd only like to see the following three options (compiler or linker): -fwhole-program -ffunction-sections --gc-sections to be announced only once we are reasonably sure they have all been thoroughly tested, in any respect (interrupt handlers, .initN sections, C++ constructors/destructores come to mind), and then only if they get documented in the section Using the GNU tools. Of course, I don't mind *fixing* them gradually before that time. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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
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; it doesn't make much sense to start one header file per control register. 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. ___ 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 #17470] Add API for CLKPR register to avr/power.h
URL: http://savannah.nongnu.org/bugs/?17470 Summary: Add API for CLKPR register to avr/power.h Project: AVR C Runtime Library Submitted by: joerg_wunsch Submitted on: Saturday 08/19/06 at 08:34 Category: Header Severity: 3 - Normal Priority: 5 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Percent Complete: 0% Originator Email: [EMAIL PROTECTED] Open/Closed: Open ___ Details: The item discussed in this thread: http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopict=40579 appears to be a useful addition to the power management subsystem. It requires a timed sequence of instructions, which is a typical candidate for an abstraction in a header file. Note that the implementation outlined there does not cover the entire family of AVRs yet. ___ 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] AT90USBxxx
As Michael Roland wrote: The datasheet for the AT90USB64/128 (7593D-AVR-07/06, Register Summary on page 415) states that the start of frame generation enable flag (bit 0) is called SOFEN. Is this (SOFE vs. SOFEN) a typo or an intentional naming difference. This appears to be a typo, please file a bug report for it. Although the Register Summary on page 416 of the datasheet does not mention the ADC high speed mode flag ADHSM (bit 7) it is described on page 333 (ADC register description). The ADHSM bit has been deprecated and officially withdrawn for all AVRs, as it is not needed, and the only effect it was causing was an increased power consumption. You might want to file a bug report with Atmel for this datasheet still mentioning it, that's probably just a cut'n'paste-o. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] AT90USBxxx
As Michael Roland wrote: ... (SOFE vs. SOFEN) ... This appears to be a typo, please file a bug report for it. I did so. Unfortunately I did not look into the CVS before submitting the report :-( : The typo had already been fixed in the latest revision. Well, I did check CVS before, but got fooled by another instance of SOFE still being defined (but that's the correct one). I've had a dejavu of it being already fixed, but got confused then myself. OK, I closed the bug report, thanks anyway! -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] depricated.h: outp() arguments order?
As Dmitry K. wrote: Possible, this is more convenient, but the older Avr-libc releases use another order: outp(val,port): val -- port. Please file a bug report. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] Re: Compiling avr-libc on Mac OS X fails...
As Frank Goenninger wrote: avr-gcc -I../../../../common -I../../../../include -x assembler-with- cpp -Wa,-gstabs -mmcu=at90s1200-c ../../../../crt1/gcrt1.S /usr/libexec/gcc/darwin/i386/as: Flag option -m has already been seen! ^^^ Your compiler uses the native system's assembler it seems. Somehow the configuration options (i. e. the --prefix setting) between the avr-binutils and avr-gcc appear to mismatch. For a test, you could override GCC's idea where to look for the backend programs using the -B option, but usually it's best to rather fix the configuration instead. Note that avr-gcc doesn't want to call avr-as by that name but rather by its native name as only. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Re: Compiling avr-libc on Mac OS X fails...
As Frank Goenninger wrote: Your compiler uses the native system's assembler it seems. Yeah, I figured. Why? I have the avr binutils in my path... The compiler looks it up into its recorded prefix, not in $PATH. If only I knew where to look ... Seems as if I have to manipulate the configure script for gcc... Normally not, but maybe you should give both (binutils and GCC) a --prefix. To find out where it looks for it, perhaps you've got some syscall tracer. Under FreeBSD, I've got ktrace for that, no idea whether MacOS X has kept that name. Note that avr-gcc doesn't want to call avr-as by that name but rather by its native name as only. Why? This would mean to conflict with the as I need for the gcc for OS X ?!? Not really. avr-as is the frontend name for users to call, it's supposed to be in $PATH. as is the backend name, as the compiler calls it. On my FreeBSD, the frontend is /usr/local/bin/avr-as, but the backend in /usr/local/avr/bin/as. avr-gcc calls the latter one. Vy 73 de Frank DG1SBG ;-) tnx. Hope to be QRV next week as OZ/DL8DTL, but only on frequencies 30 MHz. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] build fails on x86_64 GNU/Linux, missing stddef.h
As Henrik Brix Andersen wrote: ... The GCC-installed files are under /usr/[local/]lib/gcc/avr/4.1.0. Under Gentoo Linux we also put the gcc files under /usr/lib/ So the trick would probably to explain to Galen what is needed for this to happen. I can't contribute much here, as this entire lib64 thing appears to be a Linux-specific one to me. FreeBSD, even on 64-bit archs, always uses .../lib, but has a specific .../lib32 for the i386 emulation libraries on the amd64 arch. Other 64-bit archs (sparc64, alpha) don't offer 32-bit emulation anyway. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] more accuracy...
As David Carr wrote: AVR float: 2476.245361328125 error: 23.754638671875 Which is fairly well in line with the 32-bit float results from the i386. Is there a way to have sizeof(double) == 8? Currently not. Volunteers are needed to hammer all this out, in particular to establish enough library support for this to ever become a useful option. Considering that the AVR is 8bit and has no hardware floating point, being only 12x slower than the 386 is impressive especially considering it runs at 1/5 the clock speed. Yes, indeed. I think the key point here is that the avr-libc math libraries are carefully manually tuned. OK, but so is the FPU hardware implementation of the i387... -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] build fails on x86_64 GNU/Linux, missing stddef.h
As Galen Seitz wrote: I've changed the install step to do the following, though I'm not certain if this is the correct solution. make DESTDIR=$RPM_BUILD_ROOT install Probably it is. Both FreeBSD and Gentoo use portage, correct? Where do I look to see how these steps are performed on those systems? The basic idea behind the FreeBSD ports or Gentoo portage is that each port only describes its own specific setup in a meta-Makefile, plus a couple of description files, plus possibly patches. The main logic sits in a dozen or so (at least on FreeBSD) include Makefiles that form the ports framework. For FreeBSD, these are heavily tied to the BSD make intrinsics (and if BSD make misses a feature that is needed, it will simply be added), so my guess is that Gentoo has adapted that framework for GNU make instead. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] gcc patches
As David Carr wrote: Take a look at Joerg's work at: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-gcc/files/ http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-binutils/files/ I too am curious about gcc 4.1... http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-gcc-devel/files/ -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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.?
As Eric Weddington wrote: Atmel distributes a lot of this information in AVR Studio as XML files. Unfortunately, we are not allowed to redistribute them. In theory, you are not even allowed to have them at all on a non-Windows machine: the only permitted way to redistribute AVR Studio (which they are bundled with) is as the entire installation package, and that package cannot be run except on native Windows (not even under Wine). There's no option to extract anything out of it besides running the full installer. :-( This is somewhat braindead. If there's someone knowledgable with XSL, it might be an option to use XSL stylesheets to extract the required information out of these files. We might have to add local information anyway. database ---HEADER_FILE_GENERATOR1--- header file for gcc database ---HEADER_FILE_GENERATOR2--- header file for binutils It would be way cool if GCC and binutils used some kind of external file for that information, so we don't have to patch their binaries in order to add each new MCU type. However, I've got no idea whether a feature like that one would get accepted by the binutils and GCC maintainers. database ---HEADER_FILE_GENERATOR3--- header file for avr-libc Btw., there are already some stubs around in avr-libc to do this. Ted Roth's idea was to extract the desired information out of the Atmel XML files, compile some avr-libc specific XML file out of it (which can legally be stored as part of avr-libc), and eventually generate a header file out of that one. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] Releases avr-libc 1.4.4
Just uploading the release files to savannah... Binary release, Web page updates, and any kind of announcement not yet done. As it's close to midnight here, I have to defer that for tomorrow. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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?
As Mark v/d W. wrote: 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? 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. If you're interested, perhaps you can collaborate with Dmitry on this. Basically, C99 requires double to be 64 bits long, but currently we do not comply with this. Changing this would first require some library support for the missing pieces, and then changes to the compiler to offer 64 bit double at least as an option (e. g. similar to the already existing -mint8 option). Also, we're still looking for someone who might want to take over C++ maintenance. This in particular requires to get GCC's libsupc++ compilable (and feeding the required changes back to GCC -- this requires you need to do the FSF paperwork on their copyright), plus setting up some tests to ensure things actually work the way they ought to, as well as continually maintaining that part as needed. So obviously, despite of the time required to handle that, you should have enough of C++ knowledge to know what is needed for all of this. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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?
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. ;-) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] multiple -Tdata options passed to the linker for some AVRs
See: http://sourceware.org/bugzilla/show_bug.cgi?id=1272 Suddenly with binutils 2.16, the -Tdata option passed to the linker ceased to work, while --section-start,.data= remained functional. Carlos Lamas analyzed in a thread at avrfreaks.net: http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopicp=208997 that this is due to the way the compiler overrides the generic RAM location supplied by the linker scripts for all AVRs with extended IO register space. In fact, adding -v to the linker command line reveals the problem: /usr/local/lib/gcc/avr/3.4.4/../../../../avr/bin/ld -m avr5 -Tdata 0x800100 -o foo.elf /usr/local/lib/gcc/avr/3.4.4/../../../../avr/lib/avr5/crtm128.o -L/usr/local/lib/gcc/avr/3.4.4/avr5 -L/usr/local/lib/gcc/avr/3.4.4 -L/usr/local/lib/gcc/avr/3.4.4/../../../../avr/lib/avr5 -L/usr/local/lib/gcc/avr/3.4.4/../../../../avr/lib -Tdata=0x8011000 /var/tmp//ccG96yi3.o -lgcc -lc -lgcc There are two -Tdata options passed down to the linker. Obviously, the order of evaluation has been changed between binutils 2.15 and 2.16, but we can hardly blame them for this. This is a genuine problem of our current setup. Carlos claims only reverting to per-device linker scripts would cure that. While for sure, they have some merit (e. g. the linker would be able to flag overflown sections accurately except for devices that can drive external RAM), I'm somewhat reluctant to make that step due to the increasing maintenance overhead. Are there any other ideas how to circumvent that problem? Btw., does anyone know why there are five linker scripts per device/architecture? (.x, .xbn, .xn, .xr, .xu) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #15519] AT90CAN* processors incorrectly identified as AT90S family
As Ned Konz wrote: The AT90CAN processors (like the AT90CAN128 and its smaller variants) actually are Atmega family processors, despite their names. However, the AVR-libc user manual identifies them as AT90S processors. Atmel itself seems to categorize them to neither group, they created their own CAN AVR group. Likewise, the AT90PWM2/3 devices form their own Lighting AVR category. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] problems with divisions using libgcc.a
As Ingo Heffe wrote: If a division-command with a divisor, that can't be expressed by a shift-operation (e.g. variable /= 10;) is implemented, the linker causes an error undefined reference to __udivmodhi4. Either your software configuration is broken/inconsistent, or your compiler and linker commands disagree on the -mmcu= option used. You wrote you are using cdk4avr: they appear to be seriously out of date these days (alas). You'd be much better compiling your own tools then. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] avr-libc 1.4.3 released
Only a couple of bugfixes, but as Eric Weddington is about to re-roll his latest WinAVR release for other reasons, I decided to ship out avr-libc 1.4.3 right now. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #15494] Compile warning and errors if compiler flag -Wundef flag specified
Update of bug #15494 (project avr-libc): Status:None = Fixed Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Follow-up Comment #1: I could not reproduce the problem, but I see what has been causing this, and fixed it. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=15494 ___ 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 #15466] iomx8.h file has incorrect bit fields for TIMSK1
Update of bug #15466 (project avr-libc): Status:None = Invalid Open/Closed:Open = Closed ___ Follow-up Comment #1: Please upgrade your avr-libc. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=15466 ___ 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] avr-libc 1.4.2 released
It's done. Key points: . Example installation fixed for --disable-doc builds. . RPM specs fixed (thanks to Galen Seitz!) . ATtiny261/461/861 supported (thanks to Anatoly Sokolov!) . Various doc updates in particular in the examples. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Is CVS free for reading?
As Dmitry K. wrote: is Arv-libc CVS free for reading? Yes, but the location of the CVS repository has changed. See: https://savannah.nongnu.org/cvs/?group=avr-libc https://savannah.gnu.org/forum/forum.php?forum_id=4168 -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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
As Eric Weddington wrote:
Sorry, false alarm.
It correctly builds the directories, but no files were copied into
the directories. :-( So the workaround failed.
Time to manually copy.
I fixed it the way which I think is the correct one. Instead of
making the doc/ subdir conditional for --enable-doc, I made the
doc/api/ subdir conditional, and we always descend into doc/. That
way, doc/examples/ will always be processed.
Note that even for --disable-doc, the --disable-versioned-doc option
would be required if you prefer the examples to go into
${prefix}/share/doc/avr-libc, as opposed to
${prefix}/share/doc/avr-libc-${version}.
If you can, please give it a try. I've already merged it into the 1.4
branch. If all goes well, I'll simply roll avr-libc-1.4.2 out of
that.
Sorry for the hassle, and all the best for the upcoming New Year!
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
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
As Henrik Brix Andersen wrote:
The avr-libc-1.4.1/doc/examples/ directory is not included in
avr-libc-user-manual-1.4.1.tar.bz2, it seems - this is why those
files are not installed under Gentoo Linux.
Is this intended from upstream - or is it a mistake?
Sorry for not sending out a warning about the new layout yesterday.
However, I don't feel very well, and we also were about to leave for a
quick visit to a nearby restaurant, so my announcement here was a
bit terse. I also forgot to prepare and upload a binary release,
doing it right now.
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. As it bothered me the docs got more and more bloated by demo
source code included verbatim there (with no easy way for the users to
get it onto their disks), I decided to no longer use \include
statements in doxygen but rather leave pointers to the demo source.
For the HTML version, these pointers are back references into the
tree, so the idea is that you eventually install the docs at the same
level the examples directory has been installed. In the default
layout (i.e. if you run a ./configure ... --enable-doc and install
everything), that looks like:
${prefix} -- share -- doc -- avr-libc -+- avr-libc-user-manual
|
+- examples -+- demo
|
+- largedemo
|
+- stdiodemo
|
+- twitest
(The manual directory might have the version number appended, but that
doesn't matter for the back references.)
If you don't build the manual yourself (--disable-doc, the default),
the avr-libc-user-manual directory top right in the diagram will be
missing. You can simply fetch the offical manual then, and are
somewhat expected to install it into the same location. If you can't
do that for some reason (e.g. since your package system would be upset
about mixing different packages), on Unix systems, it should be easy
to work around that by symlinking the examples directory
appropriately.
For the printed (i.e. LaTeX) version, the reference only consists of a
description where the demo sources can be found on disk.
I hope that clarifies things a bit.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
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
As Henrik Brix Andersen 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... Sorry for that, that would be a bug. I start getting an idea how that happens... I think I've put it into the generic install-local target, but only inside a doc/ subdirectory, and nothing descends into these directories at all in the --disable-doc case. Too bad. I wonder how to handle that... ideally, I'd like to have the demos installed regardless of whether the remaining docs are built or not. Package maintainers, please manually copy over all *.[ch] files from the examples area for the time being. I don't have the energy anymore to fix that tonight. If someone feels reasonably comfortable with all that automake stuff, patches are welcome. ;-) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] 1.4.1 is done.
As Eric Weddington wrote: Don't forget to add a Savannah News item for this. The last one you did was for 1.2.5. I wouldn't mind if someone else were doing that... I'm tired now. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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] race condition in sleep_mode()
Andreas Kaiser [EMAIL PROTECTED] wrote: Why split SEI and SLEEP in two, if the code only works correctly if they are adjacent instructions at the machine level? This is not true. For many applications, it is simply viable to have interrupts enabled all the time, and then just execute a SLEEP instruction when no more work can be done at some point, as they probably just don't care whether some interrupt is still handled before the sleep, or awakes the device from sleep. In that case, it's not required at all that the SEI and SLEEP instructions are adjacent. This typical case is normally handled by the sleep_mode() macro. The example just demonstrates the manual method where *any* sequence of instructions is determined by the C programmer, and where it was deemed crucial by the programmer that the SLEEP instruction will really be entered before any interrupt could get a chance to hit before (IOW, your situation). In my opinion, it would violate POLA to suddenly have an SEI implied by sleep_cpu(). If people really think this should be a single macro, then the name should reflect this, like enable_interrupts_and_sleep() (but I'd prefer the name to start with sleep_). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #4611] sleep.h sleep_mode() not interrupt safe
Follow-up Comment #1, patch #4611 (project avr-libc): I just committed your patch to CVS, with the sleep() macro name changed into sleep_cpu() (so it still starts with the word sleep but cannot be confused with the Posix function sleep()), and without the sleep_if() macro. There has been some discussion in avr-gcc-list, namely http://lists.gnu.org/archive/html/avr-gcc-list/2005-12/msg00088.html convinced me to rather add some explanation and an example about how to use the other macros to get the effect of an atomic test-and-sleep functionality. ___ Reply to this item at: http://savannah.nongnu.org/patch/?func=detailitemitem_id=4611 ___ 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 #4611] sleep.h sleep_mode() not interrupt safe
Update of patch #4611 (project avr-libc): Status:None = Done Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/patch/?func=detailitemitem_id=4611 ___ 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: [avr-gcc-list] race condition in sleep_mode()
[EMAIL PROTECTED] (Joerg Wunsch) wrote: ... commit that part to the avr-libc version. However, I will adopt the implementation of sleep_enable() and sleep_disable(), as well as sleep() (renamed to sleep_cpu() or something like that, to avoid the confusion with the common Posix function sleep(3)), and add some example on top that explains how to use these in a more complex scenario, based on the suggested pseudo-algorithm you gave. I just committed that to CVS. As I intend to roll the change into the 1.4 branch ASAP (in order to get everything ready for avr-libc 1.4.1), you might want to have a look at what is there now. I've updated the documentation preview at http://www.sax.de/~joerg/avr-libc-user-manual/ http://www.sax.de/~joerg/avr-libc-user-manual/group__avr__sleep.html Please have a look the example and explanation on top are what you had in mind, too. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #15161] util/delay.h misses inline keyword (regression)
Update of bug #15161 (project avr-libc): Status:None = Fixed Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks for notifying us, and sending a fix! Suggested fix applied to all of CVS HEAD, as well as the 1.2 and 1.4 branches. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=15161 ___ 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] Poll: Who uses itoa() co with base != {2, 8, 10, 16}?
As Bjarne Laursen wrote: Agree, why not also get the radix out of the parameter list and into the function name like: char * itoa_2(int /value/, char */string/); char * itoa_16(int /value/, char */string/); Doesn't make sense as these functions are all the same. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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] Poll: Who uses itoa() co with base != {2, 8, 10, 16}?
As Alexei Chetroi wrote: I join this opinion. So do I. Please stop now. I already stopped the poll, and it's not necessary to see yet another 352 developers stating that same opinion. I've got it already. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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
Additional Item Attachment, patch #3729 (project avr-libc): File name: itoa-20051120.tar.gz Size:35 KB Dmitry\'s updated patch file, he\'s got troubles sending attachments http://savannah.nongnu.org/patch/download.php?item_id=3729item_file_id=5496 ___ Reply to this item at: http://savannah.nongnu.org/patch/?func=detailitemitem_id=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] Re: avr-libc-1.4.0 released
As Joerg Wunsch wrote: Sorry, no web page updates yet, so the publically visible documentation is still the 1.2.5 one. Hopefully, I'll get around doing that by tomorrow. Done. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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] Poll: Who uses itoa() co with base != {2, 8, 10, 16}?
As Russell Shaw wrote: I never noticed, because i always write my own minimal versions of things. http://lists.nongnu.org/archive/html/avr-gcc-list/2002-07/msg00063.html Btw., in that case, I think even the logic behind -ffunction-sections and -gc-unused-sections would fail: your foo() recursively called itself, so I guess the linker would recognize this as the symbol foo (and thus the section) being used, and thus not being gc-able -- even though nobody would really call foo() from outside. Situations like these are one of the reasons why I think it would be better to leave it to a human (i.e. the developer) to rather design the entire system in a way where he knows that only those parts of the program that belong into it will really be linked, instead of (to exaggerate quite a bit) hacking together whatever he just feels like, and then hoping the tools will eventually sort his mess out. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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] Poll: Who uses itoa() cowith base != {2, 8, 10, 16}?
As Jörgen Birkler wrote:
Can it be automated by the compiler?
I'm thinking something like:
inline itoa(int i,char* p,int base)
{
if (some_magic_gcc_macro_is_constant_parameter(base))
{
if (base==2)
{
itoa_base2(i,p);
}
else if (base == 10)
{
itoa_base10(i,p);
}
}
else {
itoa_full(i,p);
}
}
I'll keep that idea in mind. It might really be possible to do it,
but of course, this will all fail (and then pull in the full and slow
version) if the base value is not a compile-time constant even in
situations where base is one out of {2, 8, 10, 16}, so the fast
version would be sufficient.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #4627] spec file fixup for 1.2 branch
Update of patch #4627 (project avr-libc): Status:None = Done Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Follow-up Comment #1: Patch applied, thanks. The de-versionization patch for configure.in has not been applied, see patch #4626. I suppose that snippet was added inadvertently here as well. ___ Reply to this item at: http://savannah.nongnu.org/patch/?func=detailitemitem_id=4627 ___ 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] avr-libc-1.4.0 released
It's finally done! I just released avr-libc 1.4.0, the first member of our new stable line named 1.4. Source files and documentation: http://savannah.nongnu.org/download/avr-libc/avr-libc-1.4.0.tar.bz2 http://savannah.nongnu.org/download/avr-libc/avr-libc-user-manual-1.4.0.pdf.bz2 http://savannah.nongnu.org/download/avr-libc/avr-libc-user-manual-1.4.0.tar.bz2 http://savannah.nongnu.org/download/avr-libc/avr-libc-user-manual-1.4.0.ps.bz2 http://savannah.nongnu.org/download/avr-libc/avr-libc-manpages-1.4.0.tar.bz2 Binary release: http://savannah.nongnu.org/download/avr/avr-libc-bin-1.4.0.zip (Supposedly. It's not yet been transferred from the upload directory to the download area by time of this writing.) Sorry, no web page updates yet, so the publically visible documentation is still the 1.2.5 one. Hopefully, I'll get around doing that by tomorrow. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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): Assigned to:None = joerg_wunsch ___ Reply to this item at: http://savannah.nongnu.org/patch/?func=detailitemitem_id=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
Re: [avr-libc-dev] Testpackage gets better
As Peeter Vois wrote: Today is good day, yet another release of preview: Thanks. Changes: + this will dload and build simulavr only if the simulavr is not available in path. The path gets modified to have newly built simulavr + now, if avr-gcc is not present in path, a message is shown and script exits That's OK. Minor thing: if you omit the function from function t(), it's going to become compatible with a generic Posix-shell (not just bash or ksh). Regarding the copyright issue: it might be worth asking Ted Roth if he would be willing to re-release that old simulavr code under a BSD license. I guess he wouldn't care at all. Contact me offline if you want to do that, so I can get you his current email address. Regarding the chunk-wise loading into simulavr: it's probably what you are supposed to do, yes. OTOH, did you remember you can pass a binary to execute on the command-line? All we need now is a documentation to write more testcases... -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] avr-libc and atmega324
As Uwe Fechner wrote: Thanks for the hint. May I use avr-libc-cvs with older binutils and gcc (2.15 and 3.4.3 Debian packages patched for atmega324) or it is necessary to use binutils 2.16 and gcc-3.4.4? GCC 3.4.3 vs. 3.4.4 probably makes not much of a difference. binutils 2.16 has support for some of the recent AVRs added by default (CAN128, tiny13/2313, megaX8). Does anybody else on this list knows the differences between gcc-3.4.4 and gcc-3.4.3 ISTR at least one major ``pessimisation'' issue has been fixed that affects the AVR target. or between binutils 2.15 and 2.16 regarding the avr port? See above. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #4622] unify doc file location in rpms
Update of patch #4622 (project avr-libc): Status:None = Done Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/patch/?func=detailitemitem_id=4622 ___ 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] eliminating version from avr-libc-user-manual filename
As Galen Seitz wrote:
... In order to simplify the rpm spec file, I would like to
eliminate the version number from the user manual filename, ie:
if test $versioned_doc = yes; then
DOC_INST_DIR='${DESTDIR}${datadir}/doc/avr-libc-$(VERSION)'
else
DOC_INST_DIR='${DESTDIR}${datadir}/doc/avr-libc'
fi
AVR_LIBC_USER_MANUAL=avr-libc-user-manual
Does anyone have a problem with this?
Certainly not me, I've never been all that fond of the versioned
documentation anyway, and generally disable it in the FreeBSD builds.
It's been Ted Roth back then who said this way would match the Linux
RPM conventions, and so as long as I could turn it off, I'm happy as
well.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #3925] Dallas iButton 8-bit CRC
Update of patch #3925 (project avr-libc): Status:None = Done Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Follow-up Comment #1: Implemented as inline asm. ___ Reply to this item at: http://savannah.nongnu.org/patch/?func=detailitemitem_id=3925 ___ 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] Atmega2560
As david wrote: Next step is interrupts - I believe I have to modify the file gcrt1.S in avr-libc and maybe something else there to get a interrupt vector table big enough for the atmega2560. If you pick the latest avr-libc from CVS, it's got support for ATmega640/1280/1281 which should have the same interrupt vector table (except that maybe you need to account for yet another byte of jump length, I'm not sure). p.s.: Please don't append full quotes below your message, it looks silly. Use standard Internet quoting style, like above. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] ToDo for avr-libc-1.4?
As Uwe Fechner wrote: is there a list of known issues for current cvs-head, that have to be fixed before the release of avr-libc-1.4.0? Yes, this list is currently empty. ;-) The only remaining things I'd like to do (but which I don't consider to be show-stoppers) is to walk the list of submitted patches, and see what can be applied without risking to break something. Anatoly jumped in as well, and is looking at them right now (it appears). I just succeeded in compiling avr-libc-head, it is much easier than compiling the 2.x branch. Yep, the new auto* tools are much easier in that respect, in particular since that old multilib hack is gone now. Is the way, I configure it ok? [...] Yes, that's the way to do it. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] -O3 ?
As Bernd Trog wrote: I'm seeing quite a few -O3 flags when building from HEAD. Is this intentional? It was intentional, yes, it has only been used on avr3 and avr5 MCUs (i.e. on those with more than 16 KB of ROM). I killed that holy cow now. I never really thought it makes sense at all, as -Os often yields speedier code anyway, and most people appear to be more concerned about code size than speed. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] avr-libc 1.2.6 has been released
As Dmitry K. wrote: Certainly, I welcome fast release of the bug-fixed version. But I am surprised and get vexed by such haste concerning a bug #14852 (pow() with negative x). Unlike others, it is the extremely serious mistake which result can be destruction of the program. As there is a patch together with a set of tests. It is, I think, impossible to have active maintainer for every file of Avr-libc. As stated many times, we don't have an active maintainer for the entire fplib. Unless someone really steps forward to take this job (including taking full responsibility for it, i.e. he needs to do everything up to the final commit, and he needs to respond as timely as possible for a hobby job to any problems arising), as I said, I'm rather willing to rewrite a floating-point library in C, and ship the current fplib as an add-on ``use at your own risk''. You're right, I should perhaps have mentioned on top of the NEWS file that fplib is already in that ``use at your own risk'' state right now (i.e. I consider it severely broken in many respects). I simply don't have the time to maintain it, including all test cases that are required for such maintenance. That's why I basically ignore any open fplib bug myself. Nobody else seems to have the time and energy to handle them either. When I offered you the job, you regretted that you don't want to handle CVS. While I appreciate all your patches, when *I* am the person to commit them to CVS, sorry, I first have to make absolutely sure everything is OK. Typically, for each of your patches, this costs all the spare-time of one evening for one or at most two patches -- not because your patches are of poor quality, but because the issue is quite complex, and whoever is committing stuff to CVS takes full responsibility for what he's doing, so I have to completely understand what you've been doing. They way fplib is hacke^H^H^H^H^Hwritten doesn't really make this kind of understanding faster. I've tried to fix fplib bugs in the past, but quite often found myself to just open another hole by plugging one of them, due to its design (which is arguably quite efficient yet drastically increases matenance overhead). I'm already wondering whether we should rather have a full set of dejagnu (or whatever) regression tests before touching *anything* in fplib again. But then, I didn't want to invest the time for such a testsuite before rolling 1.4.0 (because it would delay it indefinately), let alone yet another bugfix release in the 1.2 line. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] odd man pages when building docs from cvs source tarball
As Joerg Wunsch wrote: _home_galens_src_avr-libc-1.3.0.20051105_doc_examples_.3 ... I can see them here, too. This appears to be a doxygen bug. That kind of files already gave me major headaches with my FreeBSD port, ... Yay, I found the reason! These junk man pages are obviously for directory entries, so I tried to disable the SHOW_DIRECTORIES feature. We don't really use that feature anyway. In order for it to be useful, it would require to put \file explanations on top of each source file that is meant to appear in the documentation. However, as this would rather document avr-libc's source tree, which is not deemed to be of any importance to avr-libc's end users, we don't have any references to the generated docs for directories. I committed the change. For avr-libc-1_2-branch, I cannot merge that fix because their doxygen.config.in doesn't have the SHOW_DIRECTORIES statement at all, as it is supposed to be applicable for an older version of doxygen, and our policy says no tools upgrade must be enforced within a branch. Unfortunately, newer versions of doxygen default that option to YES, so for 1.2.x, you still have to remove the junk manually if you care (or use an older version of doxygen). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [patch #4608] rpm spec file update
Update of patch #4608 (project avr-libc): Status:None = Done Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/patch/?func=detailitemitem_id=4608 ___ 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] problem docs from cvs source tarball
As Galen Seitz wrote: make distcheck DISTCHECK_CONFIGURE_FLAGS=--build=`./config.guess` --host=avr Btw., these ought to be the default DISTCHECK_CONFIGURE_FLAGS. This generates the file avr-libc-1.3.0.20051105.tar.bz2. When I try a build that includes docs, the build fails. make[3]: *** No rule to make target `doxygen.config.in', needed by `doxygen.config'. Stop. I think this file simply needs to be added to doc/api/Makefile.am (probably as EXTRA_DIST). For whatever reason, the old auto tools didn't need this, and always included doxygen.config.in into the tarball, but the new tools don't. OK, committed -- thanks for noticing it! -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #14945] atof() does not convert corectly 0.0
Update of bug #14945 (project avr-libc): Status:None = Invalid Open/Closed:Open = Closed ___ Follow-up Comment #1: I reported a bug that is not realy a bug. This was only my bad interpretaiton of floating point format. Please remove bug #14945. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=14945 ___ 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: [bug #14945] atof() does not convert corectly 0.0
As Rok Markovic wrote: I reported a bug that is not realy a bug. This was only my bad interpretaiton of floating point format. Please remove bug #14945. Thanks for notifying us, I closed the bug report. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #14104] sscanf returns number of matches instead of number of assignments
Update of bug #14104 (project avr-libc): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Fixed in both, HEAD of CVS and the 1.2 branch. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=14104 ___ 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] pow(x,y) broken for x0
As Dmitry K. wrote: I can not send a patch to Savannah. Result is: Duplicate post: this form was already submitted; You might open a bug tracker on their support page. So I have attach a patch in this mail: pow(x,y) with negative x is corrected. Tests are included in tarball. It is added the isfinite() function, it is used in tests. Spasibo. Ja posylal patch to web form. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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 #5, bug #14855 (project avr-libc): This rather looks like a libgcc bug to me then. libgcc should not supply anything that is supplied by avr-libc. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=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
[avr-libc-dev] [bug #14327] wdt_disable() missing a cli
Update of bug #14327 (project avr-libc): Status:None = Fixed Assigned to: arcanum = joerg_wunsch Open/Closed:Open = Closed ___ Follow-up Comment #3: All done. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=14327 ___ 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] Great Header File Reorg done.
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. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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
Update of bug #14855 (project avr-libc): Priority: 5 - Normal = 7 - High ___ Follow-up Comment #2: My first idea was to force all fplib functions into a single .text.fplib subsection, so the linker will link them closely together. Björn, do you think that would work? ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=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] Is it needed to use '_U()'?
As Dmitry K. wrote: Is it any reason to use '_U()'? I can only guess about the idea here. For some architectures and/or object formats, global symbols used to be prefixed by an underscore, mainly in order to avoid the ambiguity between a global symbol and a register name, so you can safely use e.g. r1 as a function or variable name inside your C program, and the assembler won't confuse that with a register r1. For avr-as, this is not needed as the register operands can be distinguished from global symbols (i.e. memory operands) based on the opcode. (In GAS, you can even omit the r and write a simple 1 to denote register r1.) Thus, there's no need for the underscore prefix. Yet, when creating avr-libc, someone (I assume either Denis or Marek) decided to be on the safe side, and use a prefix macro so should the policy ever change, only one place needs to be changed. I don't think that policy will ever change ;-) (as even for other architectures, it's usually not needed anymore since the register distinction is done otherwise, like by prefixing registers with a %), so from my point of view, that macro can be dropped. Perhaps Marek can enlighten us here... -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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
As Peeter Vois wrote: Could you draw an outline of how the pieces are working together? I was thinking on avrice, that as much I know SHOULD have gdb interface that serves the device over TCP/IP using gdb serial protocol. Yes, it does. If this is so, then there is needed basically minimal hardware for testing (device, ice tool and power supply if not USB powered). I hope that if the new device has JTAG debugging support, then the tests can be done. Alas, that will only help for those devices with JTAG support, and AVaRICE first needs to be taught to handle these devices... Maybe AVaRICE can be taught to hande debugWire some day, that would also cover the newer ATtinys, albeit activating dW looks anything else than an automatable process. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] What is the necessity of _FFS() ?
As Dmitry K. wrote: What is the reason of '_FFS' appearance in the last Avr-libc CVS? ffs() is a function, and should remain a function. It violates the principle of least astonishment (POLA) to suddenly have a macro by that name that does magic things on its arguments -- among them, evaluating its argument at least twice. Think about people who'd innocently do something like ... i = ffs(getsomevalue()); ... or even worse: i = ffs(rand()); (where rand() clearly returns a different value for each call). Sure, you could always work around that by #undef'ing ffs in that case, but see above: POLA. Any other known implementation of ffs() doesn't behave that way, so anybody who sees in the documentation that we do implement ffs() has a good right to assume we implement it the same way as anybody else. I've then asked Anatoly what's the purpose of the macro implementation at all, and he passed me your opinion on about having something like a counterpart to _BV(). While I don't think _FFS has the same importance as _BV (mainly since Atmel went the way to have all values that would traditionally be expressed as a bit mask only around as a bit number, so you only need the bit number - bit mask computation), I accepted that the counterpart of _BV might be a good idea, even though it's an off-by-one counterpart (_BV starts numbering bits at 0, _FFS starts numbering bits at one, in line with the ffs() function). Naming convention demands that all function-like macros that have side effects (like evaluating their argument more than once) are written in all upper-case letters (*), so that made FFS. In order to not pollute the application namespace even more, I then also prepended the same underscore we've already got in _BV. (*) Historical exceptions are getc and putc, but for them, it has always been clearly stated they might be implemented as macros that evaluate their argument more than once (even though they aren't in our case, as our stdio does no buffering). As for the purpose of have a bit mask - bit number computation that works on constant expressions though, I then decided it doesn't make sense to have this `automagic' fallback to ffs(). After all, the programmer reasonably ought to know whether his argument is compile-time constant or not. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #12941] Table of Signal Names in Interrupts and Signals is wrong/incomplete
Update of bug #12941 (project avr-libc): Status:None = Fixed Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Follow-up Comment #1: avr/iotn2313.h accidentally did not follow the standard avr-libc style for naming interrupt vectors but invented a scheme of its own. This has been fixed, now the file lists both names for interrupt vectors: those complying with the traditional avr-libc style, as well as those that have always been present just for the ATtiny2313. Note that in future versions of avr-libc, we intend to slowly migrate to yet another different style that is however closer to the datasheet (and Atmel XML files). ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12941 ___ 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: snprintf bug ?
As Russell Strong wrote: Am I doing something illegal? Do snprintf pointers need to be static? No, and no. Can you provide a full, compilable example that demonstrates the problem? -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] ATtiny25/45/85
As Patrick Blanchard wrote: a how-to reference for this process, specific for avr, would be appreciated. my mind reader radar is out of order at the moment and my noob confusion meter is at an all time high. Sorry, no how-to available. If you are maintaining avr-libc, you are basically supposed to know what you're doing (e.g. by reviewing the ChangeLog and CVS logs for those actions where someone did the job before you), as you are responsible for your actions anyway. If you are not maintaining avr-libc, well, rather use what we already did for you. If you plan to use the latest-and-greatest stuff straight from CVS, you first need to make sure you're be able to compile everything (binutils, GCC, avr-libc) yourself. If you know that you can actually do that, drop me a note, and I'll send you my cumulative new devices patches for binutils and GCC, so you can rebuild them with new device support. Then, upgrade your tree to the HEAD of avr-libc's CVS, and recmopile that. This will give you support for ATtiny45 (and much more). If you don't wanto to go through all this -- sorry, you gotta wait until whatever distribution is available for your operating system has been upgraded. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Makefile Procyon AVRlib vs AVR-libc and ANSI C
As Patrick Blanchard wrote: I am working through pstang's avrlib programs on Debian testing and have a few questions: Nope! Please don't post in multiple forums simultaneously. Please read http://www.catb.org/~esr/faqs/smart-questions.html if you don't know why. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #14616] definition of sei() in interrupts.h is faulty
As anonymous wrote:
FYI: I had started with code like
{
uint8_t temp = SREG;
asm volatile (cli : :);
volatile_declared_uint16_t_var_in_memory = value;
SREG = temp;
}
Here gcc had reordered it such that it would read
{
uint8_t temp = SREG;
asm volatile (cli : :);
SREG = temp;
volatile_declared_uint16_t_var_in_memory = value;
}
This looks like a bug to me. After all, the entire purpose of
declaring the asm statement `volatile' was to tell the compiler that
it must *not* move it elsewhere. As SREG itself is also a volatile
object, this looks like a genuine bug to me.
Can you try discussing that with the GCC folks?
Also, the inline asm cookbook suggests that declaring the critical
variable volatile instead of forcing the compiler to treat *any*
variable as volatile would be the preferrable way. After all, when
Harald Kipp wrote that, he must have taken that logic from somewhere,
so it rather appears to me that GCC has moved away from something that
used to be at leasted established practice -- and a useful one, it
seems.
Sure, we can hack up sei() to force all variables becoming volatile by
the clobber attribute memory, but I'd rather prefer if GCC would
accept the current behaviour as buggy, and fix it, as the former would
also lose optimization on those variables the application programmer
wasn't even interested at all.
GCC's documentation says:
The `volatile' keyword indicates that the instruction has important
side-effects. GCC will not delete a volatile `asm' if it is reachable.
(The instruction can still be deleted if GCC can prove that
control-flow will never reach the location of the instruction.) In
addition, GCC will not reschedule instructions across a volatile `asm'
instruction.
(Btw., I cannot find any documentation for the memory constraint.)
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #14616] definition of sei() in interrupts.h is faulty
As Russell Shaw wrote: Linux code has rmb() and wmb() for read memory barrier and write memory barrier, to solve that reordering problem. Something might be learned from finding how those macros are defined. They end up in a spaghetti of header files, but if my brain can trace that right, they simply end up in an __asm__ volatile(::memory) unless the underlying CPU offers a better instruction to implement this. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #12735] No support for AT94K devices in sleep.h
Update of bug #12735 (project avr-libc): Status:None = Fixed Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12735 ___ 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-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes
As Wojtek Kaniewski wrote: What about the SIG_ prefix? If we'll move to something else than SIGNAL(), I think that it should be dropped or somehow hidden from the users. Very good point. I've been thinking about adding a second set of vector names anyway. Our names are completely self-invented. In the long run, I'd rather like to migrate the names as they appear in the Atmel XML files, which incidentally also match those IAR is using. So e.g., SIG_INTERRUPT0 would get an alias named INT0_vect. Besides of being closer to the datasheet and XML specs, it provides for a rather easy option to write source code that is portable between IAR and GCC (as the remainder can be encapsulated in header files, now that IAR includes the C99 _Pragma() operator). As Royce Pereira wrote: In SDCC (mcs51 open source C compiler) one can name their ISR as anything, and then set an attribute to specify it as an ISR for a specific source. void zerocrossover(void) interrupt EXT0 Can this be done with AVR-GCC and what would be the problems implementing this? Not easily. It would require massive changes in both, GCC and avr-libc, and I don't see any obvious advantage that would justify the effort required to do this. As Russell Shaw wrote: You could also use INTERRUPT_(). That's too confusing, I'd say. As Wojtek Kaniewski wrote: [about AVR generic IO abstraction headers] My only concern is to not pollute the include/avr subdirectory itself too much. I'd prefer those functions to be in util/* than avr/generic/*. I could live with that. Eric, does that match your intentions as well? -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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 #12739] Gcc assumes that target libc provides ffs function
As Björn Haase wrote: I think now that It would be best to integrate support in libgcc rather than avr-libc. Since it's not too much work I think that this might happen soon. :-). OK, so do you want me to close that bug report? -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] RFD: more avr-libc API changes
As E. Weddington wrote: If so, what to do with timer_enable_int() and enable_external_int(), should I start a compat/deprecated.h for these? - We should define the compat/* include directory as for compatability includes only. I would take this as meaning compatability with other compilers (i.e. IAR, etc.), and backwards compatability (i.e. deprecated items that are semi-removed). I agree. So then, compat/deprecated.h ought to be OK. I'm no longer so sure about compat/twi.h. Given that we've settled for a util/ subdir, I'd rather move twi.h there, and leave stubs in compat/ and avr/. - We should define the avr/* include directory as for includes that are specific to the AVR hardware. For example avr/boot.h and avr/sleep.h Yep. - As a consequence, a universal UART header would go into the avr/* tree because it is still specific to the AVR hardware. IMHO, it would be avr/uart.h (or perhaps avr/usart.h). If one sees how avr/sleep.h has become a universal SLEEP header, then you can see how the universal UART header fits in here. I'm not that happy about that... I'd rather collect them elsewhere, but I agree, they're AVR-specific. Would people find it annoying to add another subdir level? So then, all generic IO headers could e.g. go into avr/generic/, the include statement would then be #include avr/generic/uart.h supposedly providing a generic uniform UART view for as many as possible AVRs. - I think it would be best to go ahead and deprecate timer_enable_int() and enable_external_int(). I agree that the naming wasn't very well thought out, perhaps. OK, compat/deprecated.h? - I have a possible replacement for the external interrupt header. ..., and I would suggest naming the header avr/extint.h. Or avr/generic/extint.h if we could agree on the above. - Going along with the theme, it would be good to eventually have an avr/timer.h header that deals with timers. Again, I have some possible candidates as a starting point. Fine. Be a bit careful about the name, we once already had an avr/timer.h, so old source code floating in the Internet could expect something else there. Again, no deal with the additional subd... :-) - Our previous offline discussion of having a util/* tree would be good for utility headers, i.e. headers that are nice, but not necessary, and that is not related to the AVR hardware. ACK. As Wojtek Kaniewski wrote: - I think your idea of avr/deprecated.h is a great idea! We could put all of those outdated macros in it: sbi(), cbi(), outp(), inp(), etc. ad naseum. :-) That would be great. I wouldn't have to explain my friends what does PORTD=~_BV(4); mean (-; Except you'd need to explain them what cbi means as it's not a C standard, and could mean anything else beyond occasionally generating a CBI instruction. ;-) Is there any policy for supporting some additional hardware? In general, avr-libc wants to keep out of the hardware business. BTW, util/... would be a good place for avr/crc16.h too. ACK. As E. Weddington wrote: If naming consistency is important, then we should probably do something about fdevopen() and fdev_*() too. All fdev functions except fdevopen() use underscores. Good point. Half point. To compare it to my original complaint about the interrupt helpers, we didn't name one fdevopen() and the other one setup_stream_fdev(). I found the underscores in the new names to improve readability, yet I wouldn't want to rename fdevopen() as it's an established interface. (fdevopen() has once been chosen as an analogy to fopen().) Is there any policy for supporting some additional hardware? This gets complicated. One the one hand, avr-libc is supposed to provide a C library only, and we have extended it to support some of the on-board peripherals. I think we could, and should, do more to support the on-board peripherals. But that should be the extent of the avr-libc project. I think the only on-board peripheral we've got support for is the EEPROM, and well, that did cause us enough grief already. Support for the LPM and SPM stuff could hardly be considered a peripheral... Perhaps the watchdog could be considered a peripheral, yes. On the other hand, I abhor reinventing the wheel and there should be a place for *exactly* what you describe: libraries to interface to common external peripherals, that have been vetted. I think this is worth a separate project. However, to run this will require a number of more volunteers to actively participate, as I see all those currently involved to be staturated with what they've got. BTW, util/... would be a good place for avr/crc16.h too. Very good point. crc16.h has nothing to do with AVR hardware, but it is a very useful utility. Likewise for avr/parity.h, and probably also avr/delay.h. That would leave the following user-visible headers in the avr/ subdir: boot.h eeprom.h interrupt.h io.h pgmspace.h (signal.h) sleep.h wdt.h -- cheers, Jorg
Re: [avr-libc-dev] Succesful install despite errors again for gcc?
As Patrick Blanchard wrote: Sorry to be a pain, but I wanted to check if it is normal to get these errors at the end of the gcc installation... ../../gcc/config/avr/libgcc.S: Assembler messages: ../../gcc/config/avr/libgcc.S:72: Error: suffix or operands invalid for `clr' ../../gcc/config/avr/libgcc.S:72: Error: no such instruction: `clear result' ../../gcc/config/avr/libgcc.S:74: Error: no such instruction: `sbrc r24,0' Nope, this rather sounds like you've got no avr-binutils installed (or in the path), so your host system's assembler is being used rather than avr-as. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Suggested ISR function
As James A.R. Koehler wrote: I'd vote for depreciating both SIGNAL and INTERRUPT in favour of ISR. OK. Indeed, I'd go further and suggest that it intrinsically be the given the attribute of '__naked__' as, for the life of me, I can't see why it is useful to have r0 and r1 set every time an interrupt occurs. Ouch, nope. By default, an ISR must save everything that is destroyed by it, and restore whatever the compiler needs to work. As r0 and r1 could be in use by a MUL (or SPM/LPM) instruction, and the compiler currently uses them as __zero_reg__ and __temp_reg__, we cannot by default drop saving them. What could be done is to make the compiler smarter about detecting whether the ISR is really going to clobber/required these registers, but again, that takes a GCC developer to do it. (That is, you, or you over there, right?) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] instructions for installation - pitfall
As Patrick Blanchard wrote: This install has been crazy, until I recognized that $HOME for usr and root are quite different...this is why my installation $PATH has been so inconsistent. The installation path isn't supposed to depend on $HOME. Of course, if only one of your users has the correct $PATH setting, that's a driver error then. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #13557] small typo in avr-libc-user-manual-1.2.3
Update of bug #13557 (project avr-libc): Status:None = Fixed Assigned to:None = joerg_wunsch Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=13557 ___ 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] Savannah's files are destroyed.
As E. Weddington wrote: Today I have check a few of files from bugs and patches in Avr-libc. All of them gzipped tars are destroyed: only length is true. Is the CVS ok? Yes, CVS is OK. I've recently observed something similar with an older attachment, see the audit-trail of: https://savannah.nongnu.org/patch/index.php?func=detailitemitem_id=4087 I've opened a support tracker at: https://savannah.gnu.org/support/index.php?func=detailitemitem_id=104642 -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-gcc-list] Re: [avr-libc-dev] Please have a look at avr-libc patch #3750
As Bernard Fouche wrote: Errm, you'd still need to supply a dummy implementation for malloc() anyway when using the floating-point versions. ... Now why not have an alloca(3) in libc? Sure it is not the best way to manage dynamic memory but vfprintf/scanf are typicall applications where it is acceptable. And a functionning alloca() is always handy. I was going to tell the same remark about alloca() as Björn did. Anyway, that won't help much here. Instead of using alloca(), I could use an automatic variable then as well, as the size of the buffer is fixed. The only point in using malloc() was that it has minimal protection against stack-heap collisions, and 40 bytes seemed to be too heavy for me to allocate them off stack immediately. If the malloc() failes, the floating-point format in question is simply skipped, but the application would not crash. As malloc() was `in' there (from fdevopen()) anyway, it came in handy. Of course, if there's consensus among the users that this is not needed, and an additional 40 bytes on the stack are no big deal for the floating-point versions, we could easily drop that completely, and always allocate the buffer on the stack. As Björn Haase wrote: We *are* already having a working alloca. It's within gcc. Only thing that you need is an appropriate function declaration. That sounds like a good idea. As Bernard Fouche wrote: . The get backend function can now return -2 to indicate an end-of-file condition, in addition to -1 for an error condition. This will affect the internal state that can be queried using the standard feof() and ferror() functions. The documentation says #define EOF (-1) which is more usual I think. Nope, EOF is the user-visible EOF/error indication. The above is talking about the internal backend function. Their -1 or -2 return code will subsequently translated into the __SERR or __SEOF flags inside struct __file, which can then be queried using the standardn feof() or ferror() functions. I agree there'd better be macros for this, but how to name them? #define _FDEV_ERR (-1) #define _FDEV_EOF (-2) Sounds OK? . A new macro fdev_setup_stream() is provided to setup a user-supplied stream without the need to call fdevopen(), ... In the example code using fdev_setup_stream(), I would put the macro call outside of a body function. fdev_setup_stream() works like a function, so it needs to be called inside a function body. But you're right, the initializer macro you've been been proposing also has some merit, so I'll add that one, too. As Dmitry K. wrote: I disagree. I don't want to poison our interface spec with non-protoype function declarations. After all, this is the year of 2005, and non-prototype function decl's have been deprecated in 1989. I agree with your remark. Nevertheless, it is possible to avoid an old C-code rewriting. It is needed to place into 'stdio.h' 2 definitions, old: extern FILE *fdevopen(int (*__put)(char), int (*__get)(void), int __opts); and new: extern FILE * new_fdevopen (int (*__put)(char, FILE*), int (*__get)(FILE*), int __opts); That gets me an idea. How about the following: #ifdef __STDIO_FDEVOPEN_COMPAT_12 /* discontinued version */ extern FILE *fdevopen(int (*__put)(char), int (*__get)(void), int __opts); #else /* version of avr-libc 1.4 and above */ extern FILE *fdevopen(int (*__put)(char, FILE*), int (*__get)(FILE*)); #endif As you can see, I'd also dropped the unused __opts. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
