Re: [avr-gcc-list] avr-gcc making really bad inlining decisions.

Bill Westfield wrote: > Hmm. So I looked at the various command-line parameters other than > -fno-inline-small-functions. Maybe, rather than trial & error, it's better to debug the (wrong) inline decision made? A quick glance at the compiler options yields -fdump-ipa-cgraph and -fdump-ipa-inli

Re: [avr-gcc-list] Error: Instruction sbrc not recognised

Vandana Bhasin wrote: > Assembler messages: > /opt/tinyos-2.1.2/tos/platforms/micaz/chips/at45db/HplAt45dbIOP.nc:150: > Error: no such instruction: `sbrc %cl,7' > /opt/tinyos-2.1.2/tos/platforms/micaz/chips/at45db/HplAt45dbIOP.nc:151: > Error: no such instruction: `sbi 18,3' Sounds like your com

Re: [avr-gcc-list] AVR tool chain on Solaris

Andreas Höschler wrote: > We download http://ftp.gnu.org/gnu/binutils/binutils-2.20.1.tar.gz: > We download http://www.smartsoft.de/Downloads/binutils-2.20.1-patches.tar.gz Note that with recent GNU tools, you don't need any patches in order to get started. If you look at the list of your patch

Re: [avr-gcc-list] hard to find the correct include files at compile time

Joern Rennecke wrote: > This seems to indicate that you are using an older toolchain, or at > least the gcc component you use is older. But that's not his problem, anyway. ;) -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating

Re: [avr-gcc-list] hard to find the correct include files at compile time

Senthil Kumar Selvaraj wrote: > No. This is what I'm seeing > > ~/avr/install/bin/avr-gcc -v inc.c > > #include "..." search starts here: > #include <...> search starts here: > /home/saaadhu/avr/install/lib/gcc/avr/5.0.0/include > /home/saaadhu/avr/install/lib/gcc/avr/5.0.0/include-fixed >

Re: [avr-gcc-list] compilation results with avr-gcc 4.8.3

As Christian Schmidt wrote: > Is it fair to conclude that the ~ > operator, applied to an unsigned char, does produce an int as output > instead of the input type? Yes, this is exactly what the C standard promotion rules require. Well, to be exact, they *require* it behaves "as if" it were promo

Re: [avr-gcc-list] config.status: error: cannot find input file: `avr/lib/avr25/ata5272/Makefile.in'

"Sivanupandi, Pitchumani" wrote: > Could you check your copy of gen-avr-lib-tree.sh file for ata5272? > Before configure, run ./bootstrap and check generated > avr/lib/avr25/Makefile.am. I have a compiled tree sitting around here which obviously successfully compiled the crt files for ata5272:

Re: [avr-gcc-list] What does "error: expected expression before '/' token" really mean?

Bob Paddock wrote: > "error: expected expression before '/' token" You could try running only the preprocessing step (-E), and have a look at the output. > -DLOGO_TEXT_POSITION_X=SCRN_LEFT+1U > -DLOGO_TEXT_POSITION_Y=SCRN_TOP+20U > -DALARM_SET_POINT_MAX=15*1 Quote these, like: -DLOGO_TEXT_POS

Re: [avr-gcc-list] String array in ROM gives error in spite of following example code.

Royce Pereira wrote: > Even the libc documentation, which was once the bible of avr-gcc on > this is not accurate. The sample code just does not work. Apparently, nobody noticed before. Please, file a bug report to the avr-libc project, so we can fix that. The question here (as always) is whet

Re: [avr-gcc-list] avr-libc does not have support for ATxmega16a4u or ATxmega32a4u

Erik Walthinsen wrote: > On 02/16/2014 12:48 PM, Joerg Wunsch wrote: >> As far as avr-libc is concerned, that's not necessary, since it's BSD-style >> licensed. > No, but for gcc and binutils getting the patches upstream does require > FSF paperwork. I think a

Re: [avr-gcc-list] avr-libc does not have support for ATxmega16a4u or ATxmega32a4u

Erik Walthinsen wrote: > I'll gladly file the assignment paperwork with the the FSF to be able to > get this stuff done myself, it somebody will let me. As far as avr-libc is concerned, that's not necessary, since it's BSD-style licensed. Yes, I'm guilty of doing too little avr-libc work in th

Re: [avr-gcc-list] avr-libc does not have support for ATxmega16a4u or ATxmega32a4u

David Fernandez wrote: > Anybody knows if there is a script to create the io files for these two > processors? or if there is some procedure to create them? Should be possible, but it's more than the IO header files. Some #ifdefs need to be extended, too. Alas, since the day when Anitha Boyap

Re: [avr-gcc-list] Is it possible to do a combined gcc build that includes the avr-lib?

David Fernandez wrote: > Does anybody know if it is possible to do a combined gcc build including > the avr-lib, similar to what can be done for newlib (where I can symlink > newlib and libgloss inside gcc sources)? Curious: what would you expect from that, as opposed to do what everyone else

Re: [avr-gcc-list] different behavior on port A and port C

dfx wrote: > The same program, on port C generates the square wave only on pins 0, 1, > 6, 7 while the others remain fixed. The other pins are assigned to JTAG by default. Either turn off the JTAG fuse (but then, you could not use JTAG for programming anymore either), or dynamically disable it

Re: [avr-gcc-list] [RFC] Device specific linker scripts

"Dhakshinamoorthy, Soundararajan" wrote: > As discussed below, I thought the outcome of the discussion was that it makes not much sense? >> >MEMORY >> >{ >> > text (rx) : ORIGIN = 0, LENGTH = 62K >> > boot (rx) : ORIGIN = 62K, LENGTH = 2K >> > data (rw!x) : ORIGIN = 0x800100, LENG

Re: [avr-gcc-list] Building avr-gcc - problems with directories

Volker Kuhlmann wrote: > [...] Thanks for your avr-man script, but it has > parts of the man path hard-coded so I had to patch it up. It also fails > to distinguish between docdir and mandir and uses the docdir path for > the location of the man pages - not useful in my case. Consider > introduci

Re: [avr-gcc-list] Building avr-gcc - problems with directories

Volker Kuhlmann wrote: > I am trying to package up an AVR tool chain again, but am unable to get > avr-gcc to run its own assembler instead of the host one. You have to include $PREFIX/bin into your PATH. > ../gcc-4.8.1/configure \ > -v \ > --prefix=/usr/avr \ > --exec-prefix=

Re: [avr-gcc-list] PICIE0/1 incorrect define in iom165a.h?

Senthil Kumar Selvaraj wrote: > Thanks for the report. I've filed a bug in the avr-libc bug tracker > (https://savannah.nongnu.org/bugs/index.php?39779) as well as our > internal tracker. Nobody ever contributed the ATmega165A to the official avr-libc tree. Thus I have to close the bug report a

Re: [avr-gcc-list] PICIE0/1 incorrect define in iom165a.h?

Jim Brain wrote: > I'm not sure what other issues there might be, but PCIE0 is bit 4 and > PCIE1 is bit 5 on 165a/pa, while it's 6 and 7 on 165 (and I think > 165p). So they are not binary compatible? Ouch. Sethil, thanks for the bug report. -- cheers, Joerg .-.-. --... ...-

Re: [avr-gcc-list] Debugging with gdb7.5

"Schwichtenberg, Knut" wrote: > BTW: Does it make sense to have all PROGMEM variables as the first > components to be set in the flash or shouldn't they be moved per > default to the end of the text segment? The librarie's *_P() functions take only 16-bit pointers, so they are limited to the fir

Re: [avr-gcc-list] problems with debugging, wrong output in assembler window from ddd

"Klaus Rudolph" wrote: > Why I got an address in ram space? I think this is a bug with recent GDB versions. Some things have been changed inside GDB, and as a consequence, it now interprets any non-0 address input as RAM addresses for the AVR target. I once tried to dig into it, but didn't find

Re: [avr-gcc-list] clarification on gcc

Parthasaradhi Nayani wrote: > What are the differences between GCC and AVR-GCC None. "AVR-GCC" is the common name given to a GCC version that has been configured as a cross-compiler for the AVR target. So it *is* GCC. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://

Re: [avr-gcc-list] How to use pgmspace.h in a library source without warning?

Georg-Johann Lay wrote: > That's not a good approach. Reading avr/io.h, the solution reads > > #define __COMPILING_AVR_LIBC__ Yes, we introduced that in order to be able to compile the standard library itself. It hasn't been documented since we then had to also document the actual things that

Re: [avr-gcc-list] [Q] When compiling I'm getting an error witth -mmcu

"m...@spectrix.com" wrote: > as: unrecognized option '-mmcu=3Datmega328p' Sounds like it were picking the wrong (i.e., the host system's) assembler. Try reducing $PATH to the bare minimum required. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joe

Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry

Ruud Vlaming wrote: > I think this is a nice feature, and i see no harm. At some projects > i also put code in the vector table to save space. Well, personally, I think it's a micro optimization that is only needed in some rare cases, when one really cares for the last 50 bytes of flash. (What'

Re: [avr-gcc-list] AVR-GCC-list Digest, Vol 97, Issue 4

Gerrit Bosch wrote: >> If there's enough demand, it would perhaps also be possible to add a >> commandline option for it (through the -x "extended options" feature), >> but so far, nobody seemed to care much about it. > It would be exiting for me to do this, but may be I am not the best > for th

Re: [avr-gcc-list] AVR-GCC-list Digest, Vol 97, Issue 2

Gerrit Bosch wrote: > Last question, can VTG be set only from AVR Studio, not with Avrdude > or something else running on a Mac? VTG can also be set through AVRDUDE, but only from "terminal mode" (option -t). As the startup will probe for a valid AVR ISP connection, if you don't have a target c

Re: [avr-gcc-list] AVR-GCC-list Digest, Vol 97, Issue 1

Gerrit Bosch wrote: > A logic analyser showed that the signals from the m2560 and the > tiny85 were different. The tiny85 produced something like spikes. Is the ATtiny85 located in an STK600 socket board, or off-board? If the latter, perhaps your ISP lines are too long, or perhaps you forgot to

Re: [avr-gcc-list] stk600

Gerrit Bosch wrote: > Connecting to the device fails, see below. What should I do?? Connect it correctly. ;-) > avrdude: stk500v2_program_enable(): bad AVRISPmkII connection status: MOSI > fail This "MOSI fail" comes directly from the STK600's firmware, so you have to convince the STK600. Do

Re: [avr-gcc-list] Question about GDB and debugging

Pink Boy wrote: > I was wondering if avr-gdb is usuable for debugging, with the t= > hought of trying to get it to work with codelite. AVR-GDB is usable. You need a so-called proxy process that links the ICE to GDB, this one is calle AVaRICE. The latest release of AVaRICE doesn't support the J

Re: [avr-gcc-list] Porting Atmel patches

"Weddington, Eric" wrote: > Gah, that last sentence should read: So, *those* files would have to > be submitted to avr-libc *by Atmel*. If they've already got a BSD-style copyright when they are shipping as part of the Atmel toolchain (I didn't look whether they do), this copyright statement its

Re: [avr-gcc-list] Porting Atmel patches

"Weddington, Eric" wrote: > Sure, it's now easier to add devices. But device support also needs > the I/O header file in avr-libc, and no one else can submit that > except Atmel. I think anyone can submit it ;) (because it could be created even based on the datasheet), but that doesn't matter mu

Re: [avr-gcc-list] Porting Atmel patches

>The FSF only allows changes of 10 lines or less in a patch, if there >is no copyright assignment on file. I thought with the recent changes, adding a new AVR device is merely going to be a one-liner (a change to avr-devices.c)? -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL

Re: [avr-gcc-list] Porting Atmel patches

Georg-Johann Lay wrote: > Notice you must have passed the paperwork. Well, don't you think that adding support for a new AVR device would consist a simple change that doesn't require the full paperwork? I think it's always a good idea for a potential contributor to file the paperwork, but for a

Re: [avr-gcc-list] External 256K FLASH - memory pointer

Parthasaradhi Nayani wrote: > I have an external FLASH (serial) of size 256K. I would like t= > o create a memory section for this memory and have pointers (more than 16 b= > its) to this memory. What's the point? A pointer is just a 32-bit (or perhaps 24-bit, in recent AVR-GCC versions) number

Re: [avr-gcc-list] EF_AVR_LINKRELAX_PREPARED bit in e_flags

In article you write: >Rarely do one set of modules, compiled with one set of >compiler flags, get linked to another set of modules, compiled with a >different, incompatible set of compiler flags. As Johann already pointed out, avr-libc is compiled with default C flags (i.e. none of those -m or

Re: [avr-gcc-list] EF_AVR_LINKRELAX_PREPARED bit in e_flags

In article <5046e9de.2060...@gjlay.de> you write: >If you introduce a compatibility check then any usage of libgcc or >AVR-Libc will trigger a diagnose because these libraries are build >with the default ABI and none of these options is a multilib option. Which, in turn, I think would be a really

Re: [avr-gcc-list] EF_AVR_LINKRELAX_PREPARED bit in e_flags

Hi Vidya, > I am trying to introduce a new series for Tiny core. As I see 0xx > series is used for Mega and 1xx series is used for XMega now. If I > have to have 200 series for Tiny, I need to move the > EF_AVR_LINKRELAX_PREPARED to a different position. > I know this will cause binary incompatib

Re: [avr-gcc-list] Undefined reference to "setup"

Georg-Johann Lay wrote: > You use a function called setup that is implemented nowhere. Or, the linker has not been given the object file where it has been implemented in. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: J

Re: [avr-gcc-list] When does the Stack Frame Pointer (Y) get setup?

Bob Paddock wrote: > Did I miss anything in the documentation that would tell me not to > use auto variables in .initX sections after .init2 that sets the > stack? If you declare the function being "naked", you cannot expect the compiler to allocate a stack frame. -- cheers, J"org

Re: [avr-gcc-list] When does the Stack Frame Pointer (Y) get setup?

Bob Paddock wrote: > When does the Stack Frame Pointer (Y) get setup? There's a "stack pointer", which is set up early (on modern AVRs, it's already set up by the hardware). There's a frame pointer (Y), which is set up upon each entry of a function which needs it. Not all functions need a stac

Re: [avr-gcc-list] Speeding [u]ltoa by 35%

Georg-Johann Lay wrote: > Here is a commented version with an average time reduction > of ~45% for the signed version. Can you submit it as a patch report? > If the maintainers don't like the C code, they can use the > sanity check from the original post to get a pure assembler > implementation

Re: [avr-gcc-list] Speeding [u]ltoa by 35%

In article <4fe0237c.9020...@gjlay.de> you write: >* Speed gain 34%..39% see [1] and [2] for detail analysis > >* Code size is same as old implementation Sounds appealing! -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW1

Re: [avr-gcc-list] Link Time Optimization vs __builtin_unreachable() and .signature?

Bob Paddock wrote: > Added __used__ in and avr-objdump -s -j .signature > is working again: (Btw., use rather than the backslash, that makes your projects more portable. MS-DOS understands the forward slash since the days of version 3.x. It's only command.com and cmd.exe that don't understan

Re: [avr-gcc-list] winavr/avrtest: permanent trouble with CVS access

Georg-Johann Lay wrote: > Even more confusing, there is an avrtest SVN in winavr, but that > repository contains other files than the CVS repo and is not linked > from anywhere: > > http://winavr.svn.sourceforge.net/viewvc/winavr/trunk/avrtest/ As a public followup (after some private consultat

Re: [avr-gcc-list] Check whether two macros are equal to each other

Georg-Johann Lay wrote: > As I already wrote, the right C-level condition is > > if (&LED1_DDR == &LED2_DDR) > > You don't want to /read/ from the ports. Sure, yes. I should have read your previous posting more thoroughly. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL h

Re: [avr-gcc-list] Check whether two macros are equal to each other

Georg-Johann Lay wrote: >> Could anyone explain this to me? Is there any way around this >> (still using macros)? > With macros? No way here. Well: no way *at the preprocessor level*. However, moving the comparison to the *compiler level* could work. The values of e.g. DDRD and DDRB are expres

Re: [avr-gcc-list] Bug in GCC 4.8

Kshitij Kumar Singh wrote: > PS, I am kinda confused as to which mail list should I post this > (avr-gcc or the gcc bugs). Sorry if this is the wrong list. Since you are using a 4.8 snapshot, I think even the GCC developers list would be OK. But wait a little, maybe Johann also has an idea, as

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

Georg-Johann Lay wrote: > Well, if a Linux programmer comes over and expects anything, ... That's not my point. My point is that the chosen name bears *neither* any relationship to what a "signal" in a microcontroller environment is (that would be a hardware signal, attaching to an IO pin), *no

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

Georg-Johann Lay wrote: > One hack would be that "interrupt" overrides/is stronger than "signal" > and likewise for OS_task/OS_main. I don't like it much, in particular since the name "signal" does not mean anything to the casual embedded programmer, and it's something fairly different than a "

Re: [avr-gcc-list] avr-ld: Do linker stubs need --relax?

Georg-Johann Lay wrote: > The question "Is using linker stubs supported without --relax at > all?" came up recently, namely in > http://sourceware.org/PR14058#c4 > AFAIR correct handling/generation of stubs needs --relax, but I > cannot find it documented in binutils nor together with -mrelax >

Re: [avr-gcc-list] 'relocation truncated to fit' diagnosis ideas?

Jim Brain wrote: >> *which* relocations are truncated? > It moved around, depending on how much code I compiled in. The last > batch were EEPROM routine references. That basically rules out the -lm issue. >> What are your compiler commandline options? I hope you didn't use the >> silly -msho

Re: [avr-gcc-list] 'relocation truncated to fit' diagnosis ideas?

In article you write: > That's why I believe it's more > appropriate to post it on a site from where it can be downloaded as per > demand. It cannot be downloaded from there unless you first subscribe. (Anonymous guests don't get access to the attachments there.) > Besides, it increases the

Re: [avr-gcc-list] __builtin_avr_delay_cycles expects an integer constant.

In article <4fa2315c.2090...@gjlay.de> you write: >As the error message requestst an /integer/ constant: >Does the error disappear if you avoid float constants? The (compile-time) floating-point calculation is part of the _delay_ms/_delay_us functions anyway (for rounding etc.), but it's supposed

Re: [avr-gcc-list] 'relocation truncated to fit' diagnosis ideas?

Jim Brain wrote: > I got further, but after copying back in all the code I had pulled > out, it still complains about R_AVR_13_PCREL errors. *which* relocations are truncated? What are your compiler commandline options? I hope you didn't use the silly -mshort-calls option. This option would b

Re: [avr-gcc-list] __builtin_avr_delay_cycles expects an integer constant.

Victor Aprea wrote: > I'm using AVR-GCC 4.5.3 on Ubuntu 12.04. Which avr-libc version is that? -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) __

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

"Weddington, Eric" wrote: > Only if we can deprecate the old names, otherwise we're going to > have the GCC maintainers ask us how many attribute names do we need! > ;-) We should at least maintain them for some period still, in order to decouple GCC's release process from avr-libc's. In other

Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK

Georg-Johann Lay wrote: > I just don't see a trick how to add "signal" only if NO_INTERRUPT > is not specified. Neither do I. > The compiler could be changed to handle it, of course. > But I am no fan of trying to support mutually exclusive/contradicting > things... I wonder whether we should

Re: [avr-gcc-list] Want to place __func__ in program memory

Wim Lewis wrote: > I had thought that __FUNCTION__ and __PRETTY_FUNCTION__ acted like > string literals and could be used this way, but I just tested and they > seem to act like __func__. __FUNCTION__ just predates the (C99) standardized __func__ but is otherwise the same. Thus, it's not surpri

Re: [avr-gcc-list] AVR Macro Reference

John Krautkramer wrote: > Studying the WinAVR & AVR Libc docs, I come across many references like: > > #define UDR UDR0 Keep in mind that this is only a compatibility layer: some (older) devices have a name like UDR (since they've only got one UART anyway), while in newer devices, the regis

Re: [avr-gcc-list] Link question

(Please suscribe to the list to not miss replies.) Kári Davíðsson wrote: > I can compile my application and link in this library without errors, > but then .init8 and .fini8 sections are stripped out of the final > executable, e.g. No, they are not "stripped", they simply never made it there, b

Re: [avr-gcc-list] gcc 4.7 changes

Ruud Vlaming wrote: > On http://gcc.gnu.org/gcc-4.7/changes.html > i saw some very interesting changes listed > regarding the AVR. Well, Georg-Johann Lay was very active in pushing many things into AVR-GCC lately. A big "Thanks!" to him! -- cheers, J"org .-.-. --... ...--

Re: [avr-gcc-list] int (*256) optimization problem in avr-gcc 4.5.3

=?ISO-8859-2?Q?Pawe=B3_Stawicki?= wrote: > I switched to gcc-avr 4.3.5 and my problems are gone now :) Then please tell your package vendor about the bug, because it's one of the more severe bugs. He might either patch it (backporting the patch from GCC 4.6.x is simple), or just remove the AVR-

Re: [avr-gcc-list] int (*256) optimization problem in avr-gcc 4.5.3

=?ISO-8859-2?Q?Pawe=B3_Stawicki?= wrote: > I found a issue in the optimization part of gcc-avr. If I run your code through my compiler, I get the following assembler output: ..global _Z1fv .type _Z1fv, @function _Z1fv: push r28 push r29 /* prologue: function */ /* fram

Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re "naked."

"William \"Chops\" Westfield" wrote: > int main(void) __attribute__ ((naked)) __attribute__ ((section (".init9"))); Instead of trying to force main into being naked, I think it would be better to use the OS_main attribute. Btw., please subscribe to the list. You might miss replies otherwise. -

Re: [avr-gcc-list] avr-objdump not including source from main() ?

Bill Westfield wrote: > Ok. By default the code is compiled with "-g", which is giving me > the described behavior. I get that same behavior with "-gstabs"... Perhaps, stabs support is slowly falling apart. We probably have to re-check how complete DWARF-2 support is meanwhile, and whether it

Re: [avr-gcc-list] avr-objdump not including source from main() ?

j...@uriah.heep.sax.de (Joerg Wunsch) wrote: > By the time objdump runs, it doesn't know anymore about any input > sections, it's only got the main output sections (.text, .data, > .bss). Since you're talking about a bootloader: if that bootloader is *not* living in sect

Re: [avr-gcc-list] avr-objdump not including source from main() ?

Bill Westfield wrote: > well, based on my experiences so far, I was expecting an answer of > the form "that's this issue here, even though the description > doesn't sound anything alike", or "you fool! objdump was never > intended to disassemble the .init9 subsection!" By the time objdump runs,

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

Volker Kuhlmann wrote: > Your analysis tool is correct in not having uintX_t predefined. K&R > quite clearly says that they are defined in a lib header file. Note that "R" in the K&R meanwhile died, and I doubt he contributed much to the C99 standard. "K&R", in terms of standardizing C, usually

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

As Georg-Johann Lay wrote: > There's absolutely no rationale for using mode attribute as sizeof(long) > is defined by the implementation and won't change at will. https://savannah.nongnu.org/patch/?3782 introduced the mode attributes. -- cheers, J"org .-.-. --... ...-- -.. .

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

As David Brown wrote: > But where is the harm in having uint32_t typedef'ed as: > unsigned long int __attribute__ ((__mode__(__SI__))) > > Is there any hidden cost or disadvantage here that I (and others) are > not aware of? No, it could be done. I just don't think it's a cool idea to wor

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

"Paul McClean" wrote: > Can anyone explain why the GCC instructions are used in place of the > typical definition? Because the mode names are GCC's equivalent for specifying a particular number of bits. > Could it be expressed as: > unsigned long __attribute__ ((__mode__ (__SI__))) > with both

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

"Paul McClean" wrote: > I recently discovered that the int32_t and uint32_t typedefs in stdint.h > are incorrect (at least on my target - AT90CAN128). j@uriah 173% cat > sizeof.c #include unsigned int sizeof_uint32_t(void) { return sizeof(uint32_t); } unsigned int sizeof_int32_t(void) { r

Re: [avr-gcc-list] Possibly wrong code generated using _BV macro

Omar Choudary wrote: > Sorry for writing too early. In that case, it makes sense to either write the value directly: MCUCR = _BV(JTD); MCUCR = _BV(JTD); (usually, you are expected to know the entire contents of that register at this point ;-), or use a temporary variable rather than |= dir

Re: [avr-gcc-list] error with optimized boolean logic in gcc

Sean D'Epagnier wrote: > The instruction in avr.md which generates this is *sbi, only > enabled with optimizations. I think this is a new optimization > added, but 0x20 needs to be subtracted from the memory location. Let's see what Johann might say about it. One thing to keep in mind is that

Re: [avr-gcc-list] [avr-libc-dev] [bug #28837] using PSTR with c++ produces warnings

As Georg-Johann Lay wrote: > > ./configure --disable/enable-shared/static > > Don't do that. I thought this was referring to the way the prerequisite libraries (gmp, gpc, mpfr) are configured. But upon re-reading, it's not quite clear what Volker was really about to say here. -- cheers, J"o

Re: [avr-gcc-list] [avr-libc-dev] [bug #28837] using PSTR with c++ produces warnings

As Volker Kuhlmann wrote: > I've been trying for 3 days now (incl half a weekend) to get 4.6.2 to > compile and I have to say build instructions are shockingly bad. What > worked for 4.3.3 just wasted 3 days for me. If you look into the correct (out of the many ;) config.log files, you'll see the

Re: [avr-gcc-list] [avr-as]: How to assembler a 24-bit integer?

In article <4eafc016.1040...@web.de> you write: >For now, the reccommendation, I could give you is, to try to place all >of your "data type" constant tables in the first 64k of memory by use of >an appropriate linker script. As long as they reside within the first >64k, a 16 bit pointer will do

Re: [avr-gcc-list] [avr-as]: How to assembler a 24-bit integer?

Georg-Johann Lay wrote: > Now the question is: How to write down a 24-bit symbol? > > .global pc > .data > .type pc, @object > .size pc, 3 > pc: > .word c > .byte hlo8(c) ??? error from as How about extendin

Re: [avr-gcc-list] Trouble compiling avr-gcc > 4.4.4 on Mac OS X Leopard with gcc-4.2 (Solved)

Bingo wrote: > You have to remember that Codesourcery is/was payed by ARM to > develop and maintain arm-gcc. So afaik. a lot of the patches hasn't > found their way into the official "tree". Yes, but that's no reason to not separate the "stock" GCC source tree from the unapproved/unintegrated p

Re: [avr-gcc-list] Trouble compiling avr-gcc > 4.4.4 on Mac OS X Leopard with gcc-4.2 (Solved)

As Jens Bauer wrote: > Do you know if there's a reason for this, or is it just because "it > doesn't fit in logically" ? It is far too AVR-specific to go into a generic toolchain as GNU binutils are. In order for being acceptable there, it would have to be designed in a much more generic way, so

Re: [avr-gcc-list] Trouble compiling avr-gcc > 4.4.4 on Mac OS X Leopard with gcc-4.2 (Solved)

"Jens Bauer" wrote: > I'll take a look at the Codesourcery toolchain anyway, it might > contain some good hints and tips. :) I took a look at the Codesourcery code. The issue there is that all you get is a large blurb of hacked up sourcecode, while Michael Fischer separates his (sparse) patches

Re: [avr-gcc-list] Trouble compiling avr-gcc > 4.4.4 on Mac OS X Leopard with gcc-4.2 (Solved)

"Jens Bauer" wrote: > I used the same build of Yagarto as you mentioned. > Are you building on a PPC Mac ? Nope, I don't have it. > I get duplicate symbols (___gmpz_abs). I cannot find any ___gmpz_abs in GMP 4.3.2 which I am using. > Same as this: >

Re: [avr-gcc-list] Trouble compiling avr-gcc > 4.4.4 on Mac OS X Leopard with gcc-4.2 (Solved)

"Jens Bauer" wrote: > I thought that I would 'get help' from building a Yagarto toolchain > (as it builds gcc-4.6.0 for ARM), but Yagarto (currently) fails on > my system; this is because it for some reason reverts to using > gcc-4.0 instead of gcc-4.2! -I'll try see if I can find the fix and > r

Re: [avr-gcc-list] AVR GDB testsuite

As Boyapati, Anitha wrote: > >Does the attached patch fix this issue? > Yes it does :-) Thanks for testing, committed. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't ha

Re: [avr-gcc-list] AVR GDB testsuite

As Weddington, Eric wrote: > Curious: Has anyone tried to run the avr-libc testsuite using the > 'avrtest' simulator program (that's stored in the WinAVR repo)? That cannot work. The testsuite, as it is now, heavily relies on the existing simulavr code, it won't even work with simulavrxx. That

Re: [avr-gcc-list] AVR GDB testsuite

As Weddington, Eric wrote: > Except that you might recall that avrtest was adapted from the > original core of simulavr. That's what made me wonder if it might > work... I didn't know that. However, I'd be surprised if the rather esoteric feature of terminating with a "coredump" has been retaine

Re: [avr-gcc-list] AVR GDB testsuite

"Boyapati, Anitha" wrote: > ../../src/adc.c: In function 'adc_intr_cb': > ../../src/adc.c:270: error: cast from pointer to integer of different size Does the attached patch fix this issue? > The above error comes from sources checked out from trunk of > simulavr project. (Is 0.1.2.6 the best ve

Re: [avr-gcc-list] AVR GDB testsuite

"Boyapati, Anitha" wrote: > I know that avr-gdb can be run using simulavr as backend Someone (Georg-Johann?) recently told that the simulator that is built into GDB 7.x might also be worth a try. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/

Re: [avr-gcc-list] ATmega32A

Peter Bozzay wrote: > "The differential input channels are not tested for devices in PDIP > Package. This feature is only guaranteed to work for devices in TQFP > and QFN/MLF Packages." But that doesn't mean anything were different at the chip level. It's still the same die that is built into t

Re: [avr-gcc-list] Toolchain not showing up with xmega support

"David L. Martin" wrote: > Atmel just seems to run hot/cold with the Linux support, that lowers > my confidence. However, GCC is essentially the very same compiler on both, Linux and Windows (as well as any other OS GCC supports), so Xmega patches that are used to build the Windows toolchain sho

Re: [avr-gcc-list] avr-gcc 4.3.3 : enum definition/use order has side effects on -fshort-enums

Bernard Fouché wrote: > In the first case, the enumeration is referenced before the > enumeration definition: 'xyz' is sizeof(int) bytes wide Sure: the compiler has no chance to tell it better in that case, as it hasn't seen the enum definition. Thus, its only chance is to assume the enum takes

Re: [avr-gcc-list] Trouble with: relocation truncated to fit: R_AVR_13_PCREL

"Weddington, Eric" wrote: >> I've already consulted Jörg about that, and that the hackish >> "overwrite" of stuff from libgcc by avr-libc does not always work >> as intended. > Do we know why that is the case, why it's not working for certain > cases? Because it does work in other cases. It wo

Re: [avr-gcc-list] Trouble with: relocation truncated to fit:R_AVR_13_PCREL

"Boyapati, Anitha" wrote: > 1. Why can't rcall/rjmp be used against external symbols? They can, and they (usually) do. > If the value falls outside the legal range, linker relaxation can > handle it. No. Linker relaxations can only work the other way: replace longer jumps/calls by smaller one

Re: [avr-gcc-list] avr-gdb use

Levente Kovacs wrote: > On Sun, 22 May 2011 22:20:17 +0200 (MET DST) > j...@uriah.heep.sax.de (Joerg Wunsch) wrote: > >> There's currently no symbolic method for that (ideas what/how to add >> the respective debugging information to the symbol table are welcome), >

Re: [avr-gcc-list] avr-gdb use

Levente Kovacs wrote: > I'd like to read the following things: > > * IO block of the device There's currently no symbolic method for that (ideas what/how to add the respective debugging information to the symbol table are welcome), so you have to examine them manually, like: x/bx 0x800039 prin

Re: [avr-gcc-list] 'Procyon AVRlib - C-Language Function Library for Atmel AVR Processors' translation

Bohdan Zograf wrote: Privet Bohdan, > What I'm asking for is > your written permission Sorry, you're asking the wrong people here. avr-gcc-list is a list to discuss things around the AVR port of GCC (commonly called AVR-GCC), but we are *not* the author(s) of Procyon AVRlib. To the best of m

Re: [avr-gcc-list] Fixing PR44643 vs. PSTR macro

As Boyapati, Anitha wrote: > I don't see a follow-up of this message (or have I missed it?). Was > the patch committed to trunk? At least, it appears I can compile trunk for the AVR again. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/

Re: [avr-gcc-list] Fixing PR44643 vs. PSTR macro

Georg-Johann Lay wrote: > Ok. But let me add that without changing PSTR as indicated and with > PR44643 fixed as proposed, building avr-libc 1.6.8 resp. 1.7.1 will > abort because avr-gcc errors on PSTR usage. It has been reported that recent versions already break on compiling avr-libc anyway (

Re: [avr-gcc-list] Fixing PR44643 vs. PSTR macro

Georg-Johann Lay wrote: > This means that at least PSTR in avr-libc from include/avr/pgmspace.h > must be changed. > > The current avr-libc implementation of PSTR, however, reads > > #define PSTR(s) (__extension__({static char __c[] PROGMEM = (s); > &__c[0];})) > > Which should read instead >

  1   2   3   4   5   6   7   8   9   >