Re: Compilation with clang

ation I know only have to teach clang the value of __tmp_reg__ (and maybe also a few other constants) to get it compiling :-) Kind regards, Marian On Fri, 15 Oct 2021 09:49:30 +0200 David Brown wrote: On 13/10/2021 18:05, Marian Buschsieweke wrote: Hi together, parts of the avrlibc headers are

Re: Compilation with clang

On 13/10/2021 18:05, Marian Buschsieweke wrote: > Hi together, > > parts of the avrlibc headers are not compatible with clang. (The use case is > not to compile avrlibc itself with clang, but rather an application using > a vanilla GCC compiled avrlibc.) However, the issues are not always trivial

[bug #50270] Article "Problems with reordering code" misleading

Follow-up Comment #8, bug #50270 (project avr-libc): I've been involved in a couple of discussions about this page in the manual. I must admit that it annoys me a little that nothing has been done to update the page. It means people have been getting the same limited and slightly inaccurate info

Re: [avr-libc-dev] const struct in program memory

On 17/06/2019 09:38, avr-libc-devel wrote: You certainly can use PROGMEM (or the newer __flash) on structs in program memory.  But you need to use the right methods to access the data.  Can you post a short sample code that you tried but which did not work? typedef struct {     uint16_t

Re: [avr-libc-dev] const struct in program memory

You certainly can use PROGMEM (or the newer __flash) on structs in program memory. But you need to use the right methods to access the data. Can you post a short sample code that you tried but which did not work? On 17/06/2019 07:08, avr-libc-devel wrote: Hello friends. Tell me, please, c

Re: [avr-libc-dev] Implementing the vprintf "%*s" and "%.*s" formats

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems reasonable to me. It is probably not a heavily used feature in printf, but it is part of the standards and its absence could be surprising to people. David On 17/10/17 22:10, Paul "LeoNerd" Evans wrote: > I often find it useful to be able

Re: [avr-libc-dev] Erroneous definition of _MemoryBarrier() in cpufunc.h

7;ll have to contact > package maintainers of my OS, to mark a more recent version as stable... > > Cheers > Ralf > > [1] > https://github.com/vancegroup-mirrors/avr-libc/commit/6323351b344996a4a8c849ae5e2f6c2b10ae5cc0 > > > On 01/22/2017 10:28 AM, David Brown wrote: >>

Re: [avr-libc-dev] Erroneous definition of _MemoryBarrier() in cpufunc.h

Hi, I am not involved in avr-libc development at all, but I've done my bit of gcc inline assembly. And you are correct - you need the empty string for the memory barrier. mvh., David On 21/01/17 17:54, Ralf Ramsauer wrote: Hi, you define _MemoryBarrier() inside avr/cpufunc.h as follows:

Re: [avr-libc-dev] Working octal code (FYI)

On 16/12/16 09:56, Dale Whitfield wrote: > Hi George, > >> (Am I annoying everyone by using this mailing list as my personal >> coding blog?) >> > > No. But I speak for myself. > > Some of us are interested and reading but don't have time to comment or > to work through the code. > > Your effor

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

On 26/06/16 17:15, Georg-Johann Lay wrote: There are quite some standard insns for atomics known to gcc, cf. "atomic_" insns in http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html This can avoid overhead of function calls. But I still don't see the great advantage of using stdatomic ov

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

On 24/06/16 22:59, Jacob Moroni wrote: Also, on a somewhat related note, I think there may be a bug in the header, specifically, in the “__iRestore” function which is called to restore the interrupt state after the atomic block is finished. There’s currently a memory barrier after SREG is r

Re: [avr-libc-dev] User-manual/optimization.html

On 19/06/15 17:13, Georg-Johann Lay wrote: > Am 06/18/2015 um 02:58 PM schrieb David Brown: >> Hi, >> >> In the user manual: >> >> <http://www.nongnu.org/avr-libc/user-manual/optimization.html> >> >> there is a discussion about the unexpec

[avr-libc-dev] User-manual/optimization.html

he code is optimal and correct, with no unnecessary memory operations (as you would need by making "val" volatile). Could the documentation and web page be updated to include this solution, for the benefit of others who find it (not just avr-libc users)? --

Re: [avr-libc-dev] libsupc++ work

On 25/03/14 09:26, Jeremy Bennett wrote: > On 24/03/14 21:49, David Brown wrote: >> On 24/03/14 19:56, Jeremy Bennett wrote: >>> On 21/03/14 14:47, Joerg Wunsch wrote: >>>> As Jeremy Bennett wrote: >>>> >>>>> We're working on the AVR

Re: [avr-libc-dev] libsupc++ work

On 24/03/14 19:56, Jeremy Bennett wrote: On 21/03/14 14:47, Joerg Wunsch wrote: As Jeremy Bennett wrote: We're working on the AVR GNU tool chain for Atmel - you may have seen the various patches submitted to the FSF by my colleague Joern Rennecke over the last year. I'm very happy to hear th

Re: [avr-libc-dev] [patch #7909] Adding __volatile__ to __asm__ within pgmspace header

lication code. And while you are right that pgm_read and other related macros and calls are often used in bootloaders (though they are not necessary), their main usage is for reading static data and tables. But as you say, we will hear what others here have to say. mvh., David On Mon, D

Re: [avr-libc-dev] [patch #7909] Adding __volatile__ to __asm__ within pgmspace header

On 31/12/12 06:54, Alex Crawford wrote: URL: Summary: Adding __volatile__ to __asm__ within pgmspace header Project: AVR C Runtime Library Submitted by: crawford Submitted on: Mon 31 Dec 201

Re: [avr-libc-dev] [patch #7830] avr-libc headers are very outdated

On 15/08/2012 09:28, Joerg Wunsch wrote: As David Brown wrote: Of course, the ideal situation is that there are no patches - but gcc development does not tend to work like that! To be fair, Georg-Johann has been *very* eager recently to integrate all the outstanding AVR-GCC patches

Re: [avr-libc-dev] [patch #7830] avr-libc headers are very outdated

work like that! mvh., David Hope that helps. Eric Weddington -Original Message- From: John Voltz [mailto:john.vo...@gmail.com] Sent: Tuesday, August 14, 2012 9:12 AM To: Weddington, Eric Cc: David Brown; avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [patch #7830] avr-libc h

Re: [avr-libc-dev] [patch #7830] avr-libc headers are very outdated

On 14/08/2012 16:43, Weddington, Eric wrote: -Original Message- From: John Voltz [mailto:john.vo...@gmail.com] Sent: Tuesday, August 14, 2012 8:38 AM To: Weddington, Eric Cc: avr-libc-dev@nongnu.org Subject: Re: [patch #7830] avr-libc headers are very outdated Eric, I have also submi

Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline...

On 24/07/12 21:22, Joerg Wunsch wrote: As Georg-Johann Lay wrote: C89 is a subset thereof, and the problem is also present with -std=c90. ANSI C89 and ISO C90 are synonyms. However, GCC itself does not have a feature to compile to MISRA (AFAIK) so it makes it difficult to fully comply. (

Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline...

On 24/07/2012 16:30, Weddington, Eric wrote: -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of David Brown Sent: Tuesday, July 24, 2012 1:40 AM To: avr-libc-dev@nongnu.org

Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline...

On 23/07/12 21:00, Joerg Wunsch wrote: > As Weddington, Eric wrote: > >> I would hate to say, "We have to use C99 for some avr-libc modules >> (atomic.h), but we guarantee C89 compliance for other avr-libc >> modules (delay.h)". We really should be consistent across the whole >> project. Which mea

Re: [avr-libc-dev] Some question regarding FP-math

On 07/01/2012 09:25 AM, Dmitry wrote: 18.06.2012 18:53, Dr. Alexander Klein: [...] 1. Most if not all transcendental functions are implemented as power series approximations, but no hints are given as to their properties of approximation. Are the polynomials or maybe their derivatives optimal in

Re: [avr-libc-dev] [bug #35467] Not sure this the right plce to submit this but...

On 09/02/2012 09:39, Vidya Praveen wrote: On 2/9/2012 1:46 PM, David Brown wrote: On 08/02/2012 20:17, Vidya Praveen wrote: Hi Things change in the compiler and there are often cases which are not covered due to several reasons. it's not uncommon to see something that works in a ea

Re: [avr-libc-dev] [bug #35467] Not sure this the right plce to submit this but...

other than testing the code correction when I get a new chip, I am going to let it rest Dave - Original Message - From: "Joerg Wunsch" mailto:j...@uriah.heep.sax.de>> To: "David Brown" mailto:da...@westcontrol.com>> Cc: "Da

Re: [avr-libc-dev] [bug #35467] Not sure this the right plce to submit this but...

small part that has been changed. mvh., David Anyway, I have already spent way too much time tracking this down so other than testing the code correction when I get a new chip, I am going to let it rest Dave - Original Message - From: "Joerg Wunsch" To: "D

Re: [avr-libc-dev] [bug #35467] Not sure this the right plce to submit this but...

On 07/02/2012 16:50, David DeHaven wrote: URL: Summary: Not sure this the right plce to submit this but... Project: AVR C Runtime Library Submitted by: dehaveda Submitted on: Tue 07 Feb 2012

Re: [avr-libc-dev] Progmem types compatibility

On 10/01/2012 10:31, Georg-Johann Lay wrote: Joerg Wunsch wrote: As Jan Waclawek wrote: I agree that having typedefs for the named address space implementation might be a good thing. They should probably start I am really not sure. There is no read use of such a type, it's just because some

Re: [avr-libc-dev] Progmem types compatibility

On 10/01/2012 09:08, Joerg Wunsch wrote: As Jan Waclawek wrote: Just want to remark that these issues had been discussed already in the thread stemming from http://lists.nongnu.org/archive/html/avr-libc-dev/2011-09/msg00025.html ... And the outcome was that the macro solution is not really su

Re: [avr-libc-dev] Progmem types compatibility

On 10/01/2012 08:13, Joerg Wunsch wrote: As Dmitry wrote: IMHO, there is no bases for such abort (in case of C source and known GCC version, i.e.<= 4.6). It is sufficient to put warning: prog_char s[] = "123"; ==> warning: 'prog_char' is deprecated and continue building. If you

Re: [avr-libc-dev] Progmem types compatibility

On 09/01/2012 23:42, Joerg Wunsch wrote: As David Brown wrote: Being able to attach the "progmem" attribute to the type is a useful feature - or it would be, if it were safe to use. The main reason, as I see it, is the same with all type information - it helps improve the safe

Re: [avr-libc-dev] Progmem types compatibility

On 07/01/2012 14:23, Georg-Johann Lay wrote: Dmitry schrieb: Hi! There are a bit of worses with deprecation of prog types in 1.8.0. First, look the possibility of usage progmem attribute with a typedef depending on GCC version and source language:

Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()

On 01/11/2011 15:14, Joerg Wunsch wrote: As David Brown wrote: That might be okay. However, why not do this: #if defined(__DOXYGEN__) #define __attribute__(discard) #endif I don't know whether doxygen's preprocessing stage will really work correctly with that. Otherwise, it mig

Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()

On 01/11/2011 13:45, Joerg Wunsch wrote: As David Brown wrote: It is even more ironic that there are already standard definitions in stdint.h precisely to support tools other than avr-gcc, namely doxygen. OK, so what's wrong with writing #if defined(__DOXYGEN__) || defined(LINT)

Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__(mode)

On 01/11/2011 13:10, Georg-Johann Lay wrote: David Brown a écrit: While I agree with your principle here, I think there is good reason for changing the typedefs in this case - and nothing to lose. People use different tools with their code, such as static error checkers, documentation

Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()

On 01/11/2011 11:28, Joerg Wunsch wrote: As Volker Kuhlmann wrote: I had already posted my solution. To recap, the problem is parsing typedef int int8_t __attribute__((__mode__(__QI__))); typedef int int16_t __attribute__((__mode__ (__HI__))); typedef int int32_t __attribute__((__mode

Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()

On 31/10/2011 22:29, Georg-Johann Lay wrote: Bob Paddock schrieb: All this appears to be specific only to some proprietary lint that unlike gcc doesn't even run everywhere, so not a relevant argument IMHO. It is one of the most common Lints in commercial environments. But why clutter avr-lib

Re: [avr-libc-dev] [bug #34423] util/crc16.h: with -Os option inline functions are called causing registers value loss

On 28/09/2011 22:33, Karol Grzybowski wrote: URL: Summary: util/crc16.h: with -Os option inline functions are called causing registers value loss Project: AVR C Runtime Library Submitted by: karol_grzybo

Re: [avr-libc-dev] PSTR() and duplicate strings

On 05/04/2011 20:30, Benoît Ryder wrote: Thanks for these answers, it is now completely clear for me. Indeed, I checked only the (ROM) size of the final binary, forgetting about .data. There is a "-fmerge-all-constants" flag - it is possible that this will give you the merging you want (though

Re: [avr-libc-dev] PSTR() and duplicate strings

On 04/04/2011 23:11, Benoît Ryder wrote: Hi, I have a question about the use of PSTR(), optimizations and objects located in program space. With optimizations enabled the compiler detect several occurrences of identical constant strings to store them only once in the binary. However, when using

Re: FW: [avr-libc-dev] Patches for 1.7.1?

On 25/03/2011 09:36, Ruud Vlaming wrote: On Friday 25 March 2011, Per Arnold Blaasmo wrote: I tried to send this message to the mailing list, but it only got to the persons on the CC. I hate mailinglists. In the old days we had news servers for discussions. Much easier! And you had the possibi

Re: [avr-libc-dev] Feature wishlisht

On 25/02/2011 23:00, Joerg Wunsch wrote: As Weddington, Eric wrote: On the other hand, I don't like it as an option. -mint8 already breaks avr-libc. Not really. -mint8 doesn't work with the non-mint8 avr-libc binary distributions (so people who'd like to use it have to roll their own or stay

Re: [avr-libc-dev] adding wrapper functions for new and delete operators

On 05/02/2011 07:47, Bradley Jarvis wrote: Hi I use avr-gcc for c++ code (have so for years) and wanted to use new and delete, particularly for libraries that I have written for and used in an x86 environment which I didn't want to have to convert. So I wrote the following wrapper functions, plea

[avr-libc-dev] Re: How many bits wide is __data_load_end?

On 02/10/2010 15:43, Bob Paddock wrote: On Sat, Oct 2, 2010 at 8:24 AM, Simone Zamboni wrote: By the way, a note for me: Bob, how much time does the XMEGA take to verify all the code (roughly)? Reading all the flash data seems to take a few seconds. I will have to measure the time. I'd gues

Re: [avr-libc-dev] Re: bug #22163 (atomic not working as expected inC++)

On 09/06/2010 22:52, Joerg Wunsch wrote: As David Brown wrote: Eric suggested making "some_temp_variable" volatile, which is the traditional way to enforce ordering in C programming. Strictly speaking, you don't have to make it volatile - it's enough to make sure it is in

Re: [avr-libc-dev] Re: bug #22163 (atomic not working as expected inC++)

Joerg Wunsch wrote: As Stu Bell wrote: Before the rant below, let me make sure: I interpret this command to mean that there is no way for the AVR GCC compiler writers to tell the optimizer, "Thou Shalt Not Reorder Code Around This Boundary". Even more, there is no way for any mechanism (even #p

[avr-libc-dev] Re: bug #22163 (atomic not working as expected in C++)

On 09/06/2010 10:23, Joerg Wunsch wrote: https://savannah.nongnu.org/bugs/?22163 The bug looks serious enough to me so I'd like to include David's alternative C++ implementation. Did anyone else test this? Any objections? It's been a while since I wrote that code! Looking back at it, there

Re: [avr-libc-dev] New pgm_read_ptr() macro?

On 03/06/2010 14:55, Jan Waclawek wrote: I would also like very much to finally add the FAR macros that Carlos put together a long time ago, or something very similar. I don't remember if there was ever any issues with them that need to get resolved, or if there is basic agreement that these shou

Re: [avr-libc-dev] New pgm_read_ptr() macro?

-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of David Brown Sent: Thursday, June 03, 2010 9:03 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] New pgm_read_ptr() macro? Hi, Are there any opinions about whether a macr

Re: [avr-libc-dev] New pgm_read_ptr() macro?

Hi, Are there any opinions about whether a macro such as the one I gave below should be part of avrlibc? It's not as clear-cut as Dean's pgm_read_ptr() macro, which follows the existing patterns in the headers. Macros like mine are more like template programming than the fixed-size macros,

Re: [avr-libc-dev] New pgm_read_ptr() macro?

On 01/06/2010 13:34, Dean Camera wrote: Hi, I've been pondering the addition of a new "pgm_read_ptr()" macro to to fill a gap (in my eyes) in the current API. Currently, to read out pointers stored in PROGMEM space, one has to use pgm_read_word() and cast the result to the desired pointer. This

[avr-libc-dev] Re: volatie with winavr2010 ?

Sorry for the extra noise in this list, since the thread is off-topic, but I never like to leave a mistake as the last word in a thread... On 30/05/2010 20:15, Jose Torres wrote: Leiu: Use: volatile *static* uint8_t first_edge = 'A'; Otherwise the compiler will allocate the variable on the cal

Re: [avr-libc-dev] Re: avr-libc 1.6.8 [was: duplicating avr-libcfromwinavr]

Weddington, Eric wrote: -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of David Brown Sent: Thursday, February 11, 2010 3:12 PM To: avr-libc-dev@nongnu.org Subject: [avr

[avr-libc-dev] Re: avr-libc 1.6.8 [was: duplicating avr-libc fromwinavr]

Weddington, Eric wrote: -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of Joerg Wunsch Sent: Thursday, February 11, 2010 9:04 AM To: avr-libc-dev@nongnu.org Subject: Re:

[avr-libc-dev] [bug #28756] Bug in AVR libc 1.6.7 (power.h for 8-bit AVR)

Follow-up Comment #7, bug #28756 (project avr-libc): I have tested out Joerg's snippet with -mmcu=atmega128rfa1 -W -Wall, using WinAVR. With WinAVR-20090313, you get an error ("clock_div_1" undeclared, and a warning implicit declaration of function "clock_prescale_set"). This particular avr is

[avr-libc-dev] Re: [bug #28108] bug with winavr20090313

Hi Brn, This is a closer but it is still not enough to be able to help you. We need a code /snippet/ - cut down the code to the minimal necessary so that we can compile the code and see the problem. Your code below won't compile because it is missing some defines, and it has lots more code

Re: [avr-libc-dev] [bug #28108] bug with winavr20090313

vr release. If you remove yourself from this mailing list, join on again with a real email address, post a brief summary of the problem you are having (not just a link to avrfreaks) and a code snippet, then we will be able to tell you if there is a workaround or other fix that will help you.

Re: [avr-libc-dev] Re: eeprom_read_byte and clr ret_hi

Wouter van Gulik wrote: David Brown schreef: Wouter van Gulik wrote: David Brown schreef: Weddington, Eric wrote: -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of

[avr-libc-dev] Re: eeprom_read_byte and clr ret_hi

Weddington, Eric wrote: -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of David Brown Sent: Monday, November 23, 2009 3:25 AM To: avr-libc-dev@nongnu.org Subject: [avr

[avr-libc-dev] Re: eeprom_read_byte and clr ret_hi

Weddington, Eric wrote: -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009 12:21 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr

Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc - C++

Mike Perks wrote: David, There are some people who believe C++ is evil, and sneaks in all sorts of inefficiencies and code bloat behind your back. It is certainly very easy to write bloated C++ code with class hierarchies so complex they defy understanding, and each class does nothing except pa

Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality toavr-libc - C++

Weddington, Eric wrote: -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of David Brown Sent: Monday, September 21, 2009 1:40 AM To: avr-libc-dev@nongnu.org Subject: Re

Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc - C++

Ruddick Lawrence wrote: This conversation is continued from the avrfreaks forum posting here: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=84072. Basically, we were talking about how best to create a maintained version of the functionality in the Procyon AVRlib, and whether t

[avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality to avr-libc

Joerg Wunsch wrote: As David Brown wrote: One thing I'd like to suggest is that the "library" be divided into separate areas. In particular, I'd like to see a "stable" area and a "staging" or "experimental" area. I don't mind that,

[avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc

Weddington, Eric wrote: -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of David Brown Sent: Friday, September 18, 2009 1:20 AM To: avr-libc-dev@nongnu.org Subject: Re

Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc

Joerg Wunsch wrote: As Ron Kreymborg wrote: I now have a little more spare time, so would be willing to join as a volunteer for this library. As Frédéric Nadeau wrote: I started such a project at the beginning of the year. Please check at: http://code.google.com/p/avr-drv/ [...] I'm wil

[avr-libc-dev] Re: Inline assembler and compiler optimization

Weddington, Eric wrote: -Original Message- From: avr-libc-dev-bounces+eweddington=cso.atmel@nongnu.org [mailto:avr-libc-dev-bounces+eweddington=cso.atmel@nongnu. org] On Behalf Of David Brown Sent: Tuesday, March 17, 2009 4:19 PM To: avr-libc-dev@nongnu.org Subject: [avr

[avr-libc-dev] Re: Inline assembler and compiler optimization

I tried to send this earlier from another account, but it doesn't seem to have made it to the list. Sorry if it turns up twice. Weddington, Eric wrote: As Weddington, Eric wrote: Anyway, it might make sense to provide an additional macro like __memory_barrier() that expands to __asm__ _

[avr-libc-dev] Re: Add lib per devide.

Weddington, Eric wrote: -Original Message- From: avr-libc-dev-bounces+eweddington=cso.atmel@nongnu.org [mailto:avr-libc-dev-bounces+eweddington=cso.atmel@nongnu. org] On Behalf Of David Brown Sent: Tuesday, December 23, 2008 9:24 AM To: avr-libc-dev@nongnu.org Subject: [avr

[avr-libc-dev] Re: Add lib per devide.

Weddington, Eric wrote: -Original Message- From: avr-libc-dev-bounces+eweddington=cso.atmel@nongnu.org [mailto:avr-libc-dev-bounces+eweddington=cso.atmel@nongnu. org] On Behalf Of Anatoly Sokolov Sent: Monday, December 22, 2008 12:05 AM To: Bob Paddock; avr-libc-dev@nongnu.or

[avr-libc-dev] Re: Open Source license for embedded systems

ome reason. (Not that it's hard to find with google, of course.) If the developers here reach an agreement on how they would like copyright notices to be used, could it be added to the FAQ? After all, license questions *are* frequently asked (or they should be!). mvh

[avr-libc-dev] Re: Open Source license for embedded systems

e full avr-libc copyright notice would look very dominant and out-of-place in anything but an extensive technical document. Would something like that be of interest to the avr-libc developers? mvh., David Brown Norway. ___ AVR-libc-dev mailing lis

Re: [avr-libc-dev] pgm_read_byte_far & Interrupts

Joerg Wunsch wrote: As Moritz Struebe wrote: - To make those functions reentrant they would have to loop the read functions until RAMZ_before = RAMPZ_after and the write functions would have to loop until until the corresponding bits get cleared. Right? I don't quite follow you on that. Why

Re: [avr-libc-dev] [patch #6418] Yet another delay routines

wrong "Reply To" button earlier and sent the message only to you. mvh., David David Brown wrote: Carlos Lamas wrote: Problem 2. The proposed solution is to check the constant parameter passed against an inline assembler constraint in an empty dummy asm() instruction. This a

Re: [avr-libc-dev] [RFC] New eeprom.h

Shaun Jackman wrote: On Fri, Feb 29, 2008 at 12:43 PM, Rick Altherr <[EMAIL PROTECTED]> wrote: Many linkers will coalesce copies of the same function from multiple object files. I'm not familiar with binutils enough to know if it does or not. In the standard use of avr-libc with gcc and bi

Re: [avr-libc-dev] Question on IO header policy

Weddington, Eric wrote: Hi All, The avr-libc project has had a policy where all register names and bit names in a device IO header file are derived directly from the Atmel device datasheet. We then updated that policy to state that those names are derived directly from the Atmel device XML files

[avr-libc-dev] [bug #22163] Everytime ATOMIC_BLOCK(ATOMIC_RESTORESTATE) compiler generates warning - unused variable 'sreg_save'

Follow-up Comment #4, bug #22163 (project avr-libc): I've just tried this code section, and there is a good reason for the "unused variable 'sreg_save'" warning - looking at the generated assembly, the variable *is* unused. In other words, the SREG is not restored after the block, as it is in th

Re: [avr-libc-dev] C++ Interrupts

Markus Lampert wrote: Hey Ron, I don't think this will work because the this pointer isn't setup. If you try to access any member variables of your interrupt class you'll end up in neverwhere. That's a good point - the class function may be defined as: void CTimer0::TIMER0_OVF_vect(void) b

Re: [avr-libc-dev] [RFC] New eeprom.h

Weddington, Eric wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of David Brown Sent: Wednesday, January 16, 2008 10:01 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [RFC] New eeprom.h Weddington, Eric wrote: No, no - I

Re: [avr-libc-dev] [RFC] New eeprom.h

Weddington, Eric wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of David Brown Sent: Wednesday, January 16, 2008 3:57 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [RFC] New eeprom.h In general, I agree with you - static

Re: [avr-libc-dev] [RFC] New eeprom.h

Anton Erasmus wrote: On 15 Jan 2008 at 20:05, Weddington, Eric wrote: I have not seen the eeprom.h file, so my comments might be totally inapropriate. Wouldn't it be better to use static inline functions in stead of macros ? One gets the same advantages of macros, but without many of the dan

Re: [avr-libc-dev] Linux -> avr-libc - License issue?

Stu Bell wrote: Hi all, I have started looking at porting the relatively simple byteorder routines from Linux to avr-libc as requested in AVRFreaks. The question I have is that all Linux code is covered by the GPLv2, while (I believe) avr-libc is covered by the LGPL. avr-libc uses a BSD lice

Re: [avr-libc-dev] avr-lib-c-extentions library

Weddington, Eric wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of David Brown Sent: Thursday, January 03, 2008 1:30 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] avr-lib-c-extentions library Weddington, Eric wrote: . same

Re: [avr-libc-dev] avr-lib-c-extentions library

Weddington, Eric wrote: . same license as avr-libc to improve re-usability in closed source projects (that's the major distinction from Procyon AVRlib) I'm open to having the LGPL license on such a library project. (Definitely not the GPL, though.) I can be persuaded to either the BSD or LGP

Re: [avr-libc-dev] Wishlist: place static bool in GPIO registers

Stu Bell wrote: -Original Message- From: Weddington, Eric [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 1:13 PM . . . BIT_receive_132 = 1; BIT_recv_error = 0; if (BIT_buffer_status == 1) {} Thanks! Note that "true" and "false" are already defined in and any implemen

Re: [avr-libc-dev] New release?

Weddington, Eric wrote: Simultaneously quality of a code concedes not only to branches 3.3 and 3.4, but even concedes to a branch 4.1. For example, Avr-libc's sscanf("1.2345","%e",&x) takes 3886 bytes of flash and 140 bytes of stack with 4.2.2. Above branch (4.1.2) uses only 3802 bytes of fl

Re: [avr-libc-dev] New release?

Dmitry K. wrote: On Thursday 29 November 2007 02:16, Anatoly Sokolov wrote: [...] I suggest to set up the minimal required version of GCC as 4.2. It will allow: 1. To remove check of new devices which are already supported in the GCC 4.2 from 'configure.ac' file. 2. To remove avr25 divices fro

[avr-libc-dev] Single page stack suggestion

This is just an idea, inspired by my examination of assembly listing code recently. When a stack frame is needed on the AVR, there is a substantial amount of code needed to safely decrement the stack pointer in the prologue (and increment it in the epilogue) - a total of 19 words overhead. Th

Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?

Eric Weddington wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Joerg Wunsch Sent: Tuesday, March 06, 2007 8:02 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5? As David Brown wrote: Size is the

Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?

Dmitry K. wrote: On Saturday 03 March 2007 07:57, Eric Weddington wrote: Today, there is a bit of functions (memset, memcpy and memcpy_P), which are in 2 variants: compact and speed. This acceleration is very effective: a few of progmem words give 10..30% speed increase. I plan to expand this fu

Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main ratherthanjumping to it

Marek Michalkiewicz wrote: On Tue, Feb 13, 2007 at 02:36:54PM -0700, Eric Weddington wrote: I agree completely: -mcall-prologues is still desired if it produces smaller code. OK, you may be right it still makes sense on the very small devices (I don't have a strong opinion, just a suggestion)

Re: [avr-libc-dev] Volatile not working?

Ned Konz wrote: Ron wrote: Hi Folks. I would have thought that with -Os the code below should work. static volatile char* Ptr; . . static Send(char* p) { if (p) { while (Ptr != NULL) {;} Ptr = p; UDR1 = *Ptr++; } } . . SIGNAL(SIG_UART1_TRANS) { if (*Ptr

Re: [avr-libc-dev] [RFC] Patch adding support for atmega2560-2561

- Original Message - From: "Björn Haase" <[EMAIL PROTECTED]> < snip for compactness > > The method for adding support for the larger devices is the following. The > function's code is now splitted into two parts for the avr6 devices. A small > part consisting of one single jump stub per

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

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