Re: [avr-gcc-list] avr-gcc making really bad inlining decisions.
Bill Westfield wes...@gmail.com 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-inline where the description looks like it could shed some light on that. Perhaps Johann will read this, and can get you some deeper insight ... -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Error: Instruction sbrc not recognised
Vandana Bhasin vandana.bhasi...@gmail.com 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 compiler is calling the host's assembler, rather than the AVR specific one. I remember tinyOS uses a fairly tweaked build environment, so you probably have to ask in a group specific to tinyOS about that. (Better subscribe to the list to not miss replies.) -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] hard to find the correct include files at compile time
Joern Rennecke joern.renne...@embecosm.com 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 system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] hard to find the correct include files at compile time
Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com wrote: No. This is what I'm seeing ~/avr/install/bin/avr-gcc -v inc.c snip #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 /home/saaadhu/avr/install/lib/gcc/avr/5.0.0/../../../../avr/sys-include /home/saaadhu/avr/install/lib/gcc/avr/5.0.0/../../../../avr/include End of search list. For two installations (host GCC, and AVR-GCC) which are somewhat comparable (both are prefixed to /usr/local, but differ in some other configure options), it looks like this: AVR-GCC: ignoring nonexistent directory /usr/local/lib/gcc/avr/4.8.3/../../../../avr/sys-include #include ... search starts here: #include ... search starts here: /usr/local/lib/gcc/avr/4.8.3/include /usr/local/lib/gcc/avr/4.8.3/include-fixed /usr/local/lib/gcc/avr/4.8.3/../../../../avr/include End of search list. host GCC: #include ... search starts here: #include ... search starts here: /usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd10.0/4.7.4/include /usr/local/include /usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd10.0/4.7.4/include-fixed /usr/include End of search list. The avr part (before the version number) vs. the x86_64-portbld-freebsd10.0 are what always distinguishes both installations. (Ivaylo, better subscribe to the list in order to not miss replies.) -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] String array in ROM gives error in spite of following example code.
Royce Pereira royc...@gmail.com 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 whether you really want both, the strings itself as well as the pointers (table of it) in flash. The table is quite small, and could as well be kept in RAM unless you are very thight on RAM. As the compiler now understands the __flash qualifier, using that would make it a lot easier. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-libc does not have support for ATxmega16a4u or ATxmega32a4u
David Fernandez dfernan...@solarflare.com 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 Boyapati has left the Atmel team that handles the AVR tools, there has not been much contribution back from Atmel to avr-libc. Instead, they maintain their own set of patches (until it will eventually become unmaintainable ...). I seem to have problems with avarice, connecting avr-gdb to target and it might be that I have to generate the right stuff out of the right libc io file using one of the avarice scripts... I don't think that's going to help much. I've seen your message to the AVaRICE list, but didn't have the time to analyze your traces. Ping me again in case I might forget about it. (Independently, it might make sense to file an official bug report.) -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Is it possible to do a combined gcc build that includes the avr-lib?
David Fernandez dfernan...@solarflare.com 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 does, and compile the library once the compiler is done? AFAICT, the newlib thing is a little different: for architectures where GCC needs a target library itself (e.g. for stdio), you have to create a bootstrap GCC, then compile the library, and then re-iterate over the GCC build to continue with those parts that could not be done before. But for the AVR target, that's not necessary. (I know it the way above from ARM targets.) -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] different behavior on port A and port C
dfx d...@dfx.it 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 at run-time with the JTD bit. (Please subscribe to the list to not miss replies.) -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Building avr-gcc - problems with directories
Volker Kuhlmann list0...@paradise.net.nz 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=/usr/avr \ --bindir=/usr/avr/bin \ --libdir=/usr/avr/lib64 \ --libexecdir=/usr/avr/lib64 \ --mandir=/usr/avr/share/man \ --infodir=/usr/avr/share/info \ Just keep it as --prefix=/usr/avr, and let it decide about the rest by itself. So prefix is /usr/avr. I figure /usr will never work for a cross compiler because it clashes with the host's compiler's lib and include. /usr does work. All those things that are really different for the cross compilation environment are installed unter a different name. The only clashes I know of are related to documentation files and perhaps internationalization (message catalogs). Of course, your binutils should have been configured and installed using the same prefix as your AVR-GCC. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] problems with debugging, wrong output in assembler window from ddd
Klaus Rudolph lts-rudo...@gmx.de 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 an obvious and quick fix. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] clarification on gcc
Parthasaradhi Nayani partha_nay...@yahoo.com 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://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR-GCC-list Digest, Vol 97, Issue 4
Gerrit Bosch gerrit.bo...@ideeinbeeld.nl 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 the job. Where to start? Savannah? Yes, you need to start with a fresh SVN checkout. The instructions for this are written on Savannah. Just have a look how other programmer implementations (like the JTAGICE mkII) handle the extended options. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] stk600
Gerrit Bosch rtnger...@gmail.com 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 you have anything else attached to the SPI lines, or are they only used for programming? -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR-GCC-list Digest, Vol 97, Issue 1
Gerrit Bosch gerrit.bo...@ideeinbeeld.nl 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 add bypass capacitors to the Vcc line? Not being an expert I read at the AVRDUDE man-page about the -B parameter. A value of 0.1e-120 solved the problem. Really 0.1E-120? That would be strange. :) For a standard 1-MHz-clocked AVR, -B10 normally ought to be a fairly conservative setting. For historical reasons, the ISP clock is given as the period time in microseconds, so -B10 corresponds to 100 kHz. The requirement is to be below 1/4 of the CPU clock, so for a default CPU clock of 1 MHz, your ISP frequency must be below 250 kHz (including all possible tolerances). -B4 might be at risk, but -B5 is guaranteed to satisfy this condition. -B10 has shown to improve the tolerance against all kind of poor cabling etc., at the cost of some programming speed of course. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Porting Atmel patches
Weddington, Eric eric.wedding...@atmel.com 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 much anyway, because avr-libc doesn't insist on a copyright assignment. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] External 256K FLASH - memory pointer
Parthasaradhi Nayani partha_nay...@yahoo.com 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. Normally, the point of using a pointer is that the compiler arranges for you to dereference the pointer automatically, but this memory being external, not accessible by normal CPU instructions, this cannot work anyway. Consequently, you can use the respective integer numbers by itself (perhaps through some kind of typedef that hints them being memory addresses). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] EF_AVR_LINKRELAX_PREPARED bit in e_flags
In article f4adc872c7afbe49a9cede5c75191c2734ab6...@dvrmbx02.corp.atmel.com 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 -f options beyond -mmcu is applied). Now, if you look into the Internet, the compile-time options there are full of -f and -m stuff (including, but not limited to, the Mfile template, the WinAVR Makefile template, and Atmel Studio generated code). Consequently, there's a clash between any these object modules, and avr-libc itself. As most projects link against avr-libc, they are always at risk. If we start including those compiler flags, where does it end? How many should we include and check for? Only those that affect the ABI. Johann mentioned them. Of course, it would have been nice if people wouldn't have started using these ABI-incompatibility options in the first place, but they do. Yes, I'm partially guilty for spreading them around :) by not thoroughly thinking about what has once been distributed with Mfile. I feel quite sorry for that. We might perhaps concentrate on the more severe of those flags (-mint8 [cough, cough] and -fshort-enums immediately come to mind, as they affect the size of certain objects). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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 good idea. ;-) I always thought specifying that -ffoobar nonsense is a poor idea from the beginning: char, signed char, and unsigned char must never be mixed in portable code anyway, so the code should work the same regardless of any -f option. (For small integer numbers rather than printable characters, using C99 uint8_t/int8_t is much preferrable.) Short enums should be declared by the respective attribute rather than implying them by a compiler option. Structure packing is a no-op on the AVR as it only requires an 8-bit alignment for everything anyway. So yes, I think encoding them in the object format, and make the linker warn about mixing differently encoded object modules is a nice idea. Of course, object files produced without any of the -f options should have the respective bits cleard (indicating the default behaviour), so any old object file that has been compiled using the default behaviour would not be marked incompatible with a future object module. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] When does the Stack Frame Pointer (Y) get setup?
Bob Paddock graceindustr...@gmail.com 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 stack frame. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] When does the Stack Frame Pointer (Y) get setup?
Bob Paddock graceindustr...@gmail.com 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, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] winavr/avrtest: permanent trouble with CVS access
Georg-Johann Lay a...@gjlay.de 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 consultations between Eric, Johann and me), the old WinAVR CVS repository has now officially been moved to the SVN repository which can be viewed under the above URL. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Check whether two macros are equal to each other
Georg-Johann Lay a...@gjlay.de 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 expressions that can be compared
by the compiler. As the resulting comparison is constant at
compile-time, with optimization enabled, those code portions that can
never be reached (due to the compile-time constant comparisons) are
optimized away.
So, turn your
#if LED1_DDR == LED2_DDR
into
if (LED1_DDR == LED2_DDR) {
// ...
} else {
// both DDRs are not 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-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Check whether two macros are equal to each other
Georg-Johann Lay a...@gjlay.de 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, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Bug in GCC 4.8
Kshitij Kumar Singh kksing...@gmail.com 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 he's the currently most (only?) active AVR-GCC developer anyway. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 'relocation truncated to fit' diagnosis ideas?
Jim Brain br...@jbrain.com 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 -mshort-calls option. This option would better not exist at all. *hangs head in shame* Yes, I did. Sheesh, I wish this option had not invented at all. I'm tempted to open a GCC PR requesting its immediate removal. After removal, compilation is back to normal. Good to know. In my (somewhat lame) defense, I believe I copied this Makefile from a Tiny2313 project (it started life on a Tiny), and was trying to keep code size at a bare minimum. It wouldn't have changed a bit. As the ATtiny2313 does not have long jumps/calls anyway, code generation for it always uses RJMP/RCALL. Only on devices with more than 8 KiB of flash, the code generation uses JMP/CALL. The way to shorten the jumps and calls afterwards is not to force the compiler not issuing them in the first place (now, you ought to know why this is not the correct way, Jim ;-), but to use the -mrelax option. (Yes, Jan, I know it has its own set of issues.)+ That lets the linker decide which jumps or calls are real candidates for being shortened. You are not alone. Even AVR Studio offers that nonsensical option (while leaving out more important things). Another common nonsensical option is to apply -fpack-struct: as the AVR has no alignment requirements beyond a single byte, structs on the AVR are always packed as tight as possible. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] __builtin_avr_delay_cycles expects an integer constant.
Victor Aprea victor.ap...@wickeddevice.com wrote: I'm using AVR-GCC 4.5.3 on Ubuntu 12.04. Which avr-libc version is that? -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 'relocation truncated to fit' diagnosis ideas?
Jim Brain br...@jbrain.com 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 better not exist at all. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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 to be optimized away. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 'relocation truncated to fit' diagnosis ideas?
In article PC195201205031414050399c9808594@TEST-VISTA 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 chances the OP's problem being helped by those avrfreaks.net users who are not subscribed here. With all due respect, but you overestimate the people who are subscribed there, just because *you* love it more than a plain old mailinglist. All the AVR-GCC developers I know of (and there aren't many of them anyway) are subscribed to this mailinglist, and discussing things around AVR-GCC (and its related tools) is the main purpose of the list, so no need to drive anyone away from here. And no, even a 20 or 30 KiB sourcecode attachment is fine, and usually suffices to demonstrate some particular behaviour. (The actual limit imposed by the server is even higher.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK
Weddington, Eric eric.wedding...@atmel.com 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 words: a newer GCC version should be able to work with an older avr-libc one. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-libc: interrupt.h, ISR and ISR_NOBLOCK
Georg-Johann Lay a...@gjlay.de 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 just keep the old interrupt and signal attributes for historical backwards compatibility, and invent new ones, like: __attribute__((isr)) -- this function implements an ISR (needs RETI, must guarantee to completely save state) __attribute__((interruptible)) -- this function is supposed to also have the isr attribute, but it is asked to re-enable interrupts as soon as possible These names would be a lot clearer. The old interrupt attribute would be equivalent to isr, interruptible, while the old signal one is the same as isr (except signal was never supposed to be accompanied by interrupt). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Want to place __func__ in program memory
Wim Lewis w...@.org 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 surprising that __PRETTY_FUNCTION__ works the same way. As this is debugging-only stuff, the way around is probably to just use a CPU with enough RAM for debugging. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR Macro Reference
John Krautkramer krau...@gmail.com 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 registers are always numbered (UDR0). The above define allows to use code that has been written for the older conventions on a newer device. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Link question
(Please suscribe to the list to not miss replies.) Kári Davíðsson k...@6000k.net 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, because the linker had no reason to include those object modules in the first place. If I on the other hand link the application by specifying all of the library object files on the command line, every thing works just fine. Sure, object files specified on the command line are always linked. Object modules within a library are only pulled in to satisfy global references which are undefined at the point where the library is being processed (that's why the position of a library on the command line is important). Presumably, your init/fini object modules don't define any symbol that is being needed by the linker, so they are not considered. What you could do is putting one global symbol into each of your modules (perhaps you've already got some?), and then explicitly tell the linker that just this symbol is global undefined, using the -u option. This will make the linker pull in that entire object module from the library. avr-g++ -g -Os -DF_CPU=1600UL -mmcu=atmega328p myapp.o \ -Wl,-u,symbol1 -Wl,-u,symbol2 \ -L. -lmylib -o myapp (The -Wl option is used to prefix a linker-only option on the compiler command line.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] gcc 4.7 changes
Ruud Vlaming r...@betaresearch.nl 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, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] int (*256) optimization problem in avr-gcc 4.5.3
=?ISO-8859-2?Q?Pawe=B3_Stawicki?= sta...@gmail.com 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-GCC 4.5.x package alltogether. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] int (*256) optimization problem in avr-gcc 4.5.3
=?ISO-8859-2?Q?Pawe=B3_Stawicki?= sta...@gmail.com 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 */ /* frame size = 0 */ /* stack size = 2 */ ..L__stack_usage = 2 call _Z5getchv mov r29,r24 ldi r24,lo8(0) mov r28,r24 call _Z5getchv add r28,r24 adc r29,__zero_reg__ movw r24,r28 /* epilogue start */ pop r29 pop r28 ret .size _Z1fv, .-_Z1fv This is GCC 4.5.1, but with a patch for bug #46779 (which is only fixed in GCC 4.7 and GCC 4.6). I'm not sure whether this would be your bug, too, but I think it's possible. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
William \Chops\ Westfield wes...@mac.com 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. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-objdump not including source from main() ?
Bill Westfield wes...@gmail.com 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 should be made the default for everyone. In particular, the question is whether AVR-GDB really copes with it 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-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-objdump not including source from main() ?
Bill Westfield wes...@gmail.com 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, it doesn't know anymore about any input sections, it's only got the main output sections (.text, .data, .bss). Source code must be trackable by means of linenumber debugging information in order to be included. So if that debugging information is missing, objdump won't be able to correlate the code addresses to source files. You can use avr-objdump -g to analyze stabs line number (and other debugging) information, or avr-objdump -Wl to analyze DWARF-2 line number information. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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 section .text, it's possible objdump -d wouldn't consider it for disassembly (the manual is a bit vague, it talks about sections expected to contain instructions). You can specify sections to disassemble by the -j (or --section) option. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect
Volker Kuhlmann list0...@paradise.net.nz wrote: Your analysis tool is correct in not having uintX_t predefined. KR quite clearly says that they are defined in a lib header file. Note that R in the KR meanwhile died, and I doubt he contributed much to the C99 standard. KR, in terms of standardizing C, usually refers to the pre-ANSI C89 de-facto standard. You've clearly got a completely wrong understanding of the way the C standard works. The standard mandates that the respective identifiers are declared or defined by the respective header file, but it does not make any claims about *how* an implementation defines or declares them. So it's completely sufficient for a static analysis tool to recognize the #include stdlib.h statement, and then assume all those identifiers that are described in the standard are defined with exactly the effect that is described in the standard. Anything else is asking for trouble. To pick a completely different example, how on earth would an analysis tool want to handle the stuff from stdarg.h? The va_arg macro has to invoke some `magic' to get the next argument from the list, which could be located in a CPU register, or on the stack, depending on the target machine and the way the implementation of variadic arguments has been made. The answer is quite simple: as soon as stdarg.h has been included, the tool has to assume that va_arg, used in the way as described by the standard, just does what it is intended to do. I've already quoted the way newer GCC versions provide their own stdint.h. If an analysis tool wants to track each of the declarations there, it will yield none of them, as the header file all resolves them into internal macro names, properly #ifdef'ed. The tool won't have any of those predefined (they are internally defined in GCC, to the appropriate type names), and thus would (incorrectly) treat all these as being undeclared. In fact, if it turns out that already GCC 3.x declares macros like __INT8_TYPE__ etc., I tend to change the avr-libc header file to exactly the same magic as the newer GCC header files have. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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 work around some tool's flaws by tweaking the library. (OK, we already did that for Doxygen. ;-) And I don't think the tool can assume that uint32_t is 32-bit, just because the standard says that this type must be 32-bit if it exists - people write code that doesn't conform to standards. Tools will, I believe, pick up on the size of uint32_t by tracing back to the system header and reading it. That's where we disagree. I think if a particular type name is mandated by the standard, the tool should rely on it being that way, period. It could easily happen the entire declaration is completely hidden (rather than being exposed as in avr-libc's header). For example, GCC 4.5.1 ships with its own stdint header file which has constructs like: #ifdef __INT8_TYPE__ typedef __INT8_TYPE__ int8_t; #endif In that case, the definition of the macro __INT8_TYPE__ cannot be seen by that tool at all, still, int8_t will be defined at compile-time. If a user is so stupid to define uint8_t to be a 32-bit type, the tool won't save their ass either. :-) As Georg-Johann Lay wrote: The standard C does not make *any* claim about the actual number of bits in an `unsigned long' data type, it only specifies a *minimum* number of bits (indirectly, by telling a minimal magnitude value for LONG_MIN, LONG_MAX, and ULONG_MIN, respectively). Thus, an `unsigned The C standard says it is implementation defined. ... but requires minimum values, effectively mandating a minimal number of bits to implement it. The implementation (AVR backend of GCC) say: long is 32 bits or 16 bits if -mint8 is on. Well, -mint8 violates the standard anyway, and I doubt that tool would stand the slightest chance to cope with -mint8 code. As avr-libc is only intended to work together with GCC, avr-libc could use built-in macros: typedef __INT32_TYPE__ int32_t; I've got the impression these macros are a recent addition. Would that also work e.g. on GCC 3.4? I know there are still users of avr-libc working with such old compilers (since the compiler gets a better code density for them). As fas as I know the only reason why avr-libc used mode attribute is to factor out impact of -mint8, ... No, our previous definitions were -mint8 clean, AFAICT. It just looked more elegant to use GCC's mode attributes to ensure certain bit widths, so when someone was proposing that change, we accepted it. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect
Paul McClean p.mccl...@kelvatek.com 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 stdint.h
unsigned int sizeof_uint32_t(void)
{
return sizeof(uint32_t);
}
unsigned int sizeof_int32_t(void)
{
return sizeof(int32_t);
}
^D
j@uriah 174% avr-gcc -mmcu=at90can128 -Os -S sizeof.c
j@uriah 175% cat sizeof.s
.file sizeof.c
sizeof_uint32_t:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
..L__stack_usage = 0
ldi r24,lo8(4)
ldi r25,hi8(4)
/* epilogue start */
ret
.size sizeof_uint32_t, .-sizeof_uint32_t
..global sizeof_int32_t
.type sizeof_int32_t, @function
sizeof_int32_t:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
..L__stack_usage = 0
ldi r24,lo8(4)
ldi r25,hi8(4)
/* epilogue start */
ret
.size sizeof_int32_t, .-sizeof_int32_t
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect
Paul McClean p.mccl...@kelvatek.com 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 the standard C part and the GCC part indicating the same size? The standard C does not make *any* claim about the actual number of bits in an `unsigned long' data type, it only specifies a *minimum* number of bits (indirectly, by telling a minimal magnitude value for LONG_MIN, LONG_MAX, and ULONG_MIN, respectively). Thus, an `unsigned long' datatype could as well have 64 bits, still conforming to the standard. Likewise, an `unsigned int' on many GCC targets is 32 bits long, so why does your tool assume it were 16 bits? Moreover, how would your tool handle Johann's recent GCC addition of a 24-bit integer type? This one can only be expressed by relying on the definition of __int24_t (or __uint24_t) providing the necessary magic to tell this to the compiler. (This would keep my static analysis tool happy). Your tool should IMHO treat system headers (at least those that are specified in the C standard) as `opaque', and trust the standard-mandated definitions to perform exactly what they are required to do, regardless of *how* they are defined. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Possibly wrong code generated using _BV macro
Omar Choudary choudary.o...@gmail.com 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 |= directly on MCUCR: uint8_t tmpval = MCUCR; tmpval |= _BV(JTD); MCUCR = tmpval; MCUCR = tmpval; The |= requests MCUCR to be read and written back each time (due to its volatileness). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] error with optimized boolean logic in gcc
Sean D'Epagnier s...@depagnier.com 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 Xmega devices don't have that offset. I don't know whether Atmel's Xmega changes have already been incorporated into GCC's SVN meanwhile. (Please don't followup to an unrelated thread. In a threaded display, your message appears as being a followup to your 'trouble compiling latest svn' message.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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.
As Johann works on the named address space implementation in GCC, I
think he really wants a true 24-bit data type. The overall goal is to
be able to eventually replace all those workarounds (use only the first
64 KiB, use a 32-bit number instead) by a genuine 24-bit addressing,
so you can write something like:
__farflash const char *stringtable[] = { ... };
and have the compiler insert the correct (ELPM) instruction to access
them when referencing stringtable data.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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 solution: the C compiler complains that it cannot find
one of the shared object files (libmpc.so, IIRC).
The correct file to look into is avr/libgcc/config.log (within the
build directory). libgcc is the first time where the compilation
process wants to invoke the compiler for the target machine;
everything else before that happened using the host system's compiler.
All this happens if you compile the toolchain using some esoteric
--prefix setting, where ${prefix} is not part of your normal
LD_LIBRARY_PATH (or whatever your system uses as its default
equivalent of that). libmpc (which has been recently added as a
prerequisite to GCC) installs a shared library, and the target
compiler wants to use it.
Three possible solutions:
. use a standard --prefix setting where all your binaries and shared
libs are being found automatically by the system
. set LD_LIBRARY_PATH to ${prefix}/lib before compiling GCC
. use --disable-shared when configuring the gmp, mpc, and mpfr
libraries for your new compiler
(In the latter case, make sure that there are no .so libs from
previous attempts sitting around in ${prefix}/lib.)
Based on experience from previous toolchain compilations, it's also
always a good idea to reset PATH to the minimal elements that are
strictly needed for the compilation, like /bin/:/usr/bin, or
/bin:/usr/bin:/usr/local/bin.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] [avr-as]: How to assembler a 24-bit integer?
Georg-Johann Lay a...@gjlay.de 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 extending the assembler to understand a native 24-bit type as well? .global pc .data .type pc, @object .size pc, 3 pc: .word24 c This probably also requires a matching relocation record type in binutils (so the linker could appropriately enter c's address into pc). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Trouble compiling avr-gcc 4.4.4 on Mac OS X Leopard with gcc-4.2 (Solved)
Bingo avr-li...@luna.dyndns.dk 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 patches, as everyone else is doing. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Trouble compiling avr-gcc 4.4.4 on Mac OS X Leopard with gcc-4.2 (Solved)
Jens Bauer j...@bruger.mine.nu 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 from the actual source. So with Codesourcery, you simply get a large black box of code. Comparing it with a regular GCC tree yields many many differences, and it's not completely clear which GCC version they based their work on - presumably simply some SVN snapshot of the day. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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 it at least would become applicable to other similar device families (say, all flash controllers that are supported). The IMHO better way would have been to continue the old shellscript instead, call avr-size as the backend tool, and perform all the relative percentage calculations in the script. That's the way WinAVR started with. You might still find copies of the script floating in the net somewhere (search for avr-sizex). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Trouble compiling avr-gcc 4.4.4 on Mac OS X Leopard with gcc-4.2 (Solved)
Jens Bauer j...@bruger.mine.nu 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: http://gmplib.org/list-archives/gmp-bugs/2010-January/001748.html Try finding out who defines that inline function, and turn it into static inline to avoid the extern inline issue mentioned in the post. As mentioned there, this appears to be an issue with the MacOS compiler you are using. If you cannot resolve it, you could as well build your own version of GCC, and use that one as the Yagarto compiler. Besides, this appears to be only related to one of the GMP tests. You could probably simply ignore it as well, by using make -i to build/install GMP. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Trouble compiling avr-gcc 4.4.4 on Mac OS X Leopard with gcc-4.2 (Solved)
Jens Bauer j...@bruger.mine.nu 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
report that to Michael.
Something must be seriously wrong then.
I just built a Yagarto (20110429) here. The only thing I needed in
addition to Michael's script was the attached patch, because newlib
fails to build all the crt* stuff for ARMv6-M.
Yagarto uses a slightly different approach: they build all the
additional prerequisites into their `addontools' directory.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)--- newlib-1.19.0/libgloss/arm/configure.in~2006-05-10 22:51:40.0
+0200
+++ newlib-1.19.0/libgloss/arm/configure.in 2011-09-30 11:57:29.0
+0200
@@ -11,7 +11,7 @@
*) AC_MSG_ERROR(bad value ${enableval} for newlib-supplied-syscalls
option) ;;
esac], [newlib_may_supply_syscalls=yes])dnl
-if test x$newlib_may_supply_syscalls = xyes; then
+if test x$newlib_may_supply_syscalls = xyes -o x$with_multisubdir =
xthumb/v6m; then
BUILD_CRT0_TRUE='#'
BUILD_CRT0_FALSE=
else
--- newlib-1.19.0/libgloss/arm/configure~ 2008-04-04 23:51:59.0
+0200
+++ newlib-1.19.0/libgloss/arm/configure2011-09-30 11:58:20.0
+0200
@@ -1680,7 +1680,7 @@
newlib_may_supply_syscalls=yes
fi
-if test x$newlib_may_supply_syscalls = xyes; then
+if test x$newlib_may_supply_syscalls = xyes -o x$with_multisubdir =
xthumb/v6m; then
BUILD_CRT0_TRUE='#'
BUILD_CRT0_FALSE=
else
--- newlib-1.19.0/libgloss/arm/Makefile.in.orig 2011-09-30 14:34:11.0
+0200
+++ newlib-1.19.0/libgloss/arm/Makefile.in 2011-09-30 14:38:12.0
+0200
@@ -53,28 +53,47 @@
@BUILD_CRT0_FALSE@CRT0 =
@BUILD_CRT0_FALSE@CRT0_INSTALL =
-LINUX_CRT0= linux-crt0.o
-LINUX_BSP = libgloss-linux.a
-LINUX_OBJS= linux-syscalls0.o linux-syscalls1.o
-LINUX_SCRIPTS = linux.specs
-LINUX_INSTALL = install-linux
-
-REDBOOT_CRT0 = redboot-crt0.o
-REDBOOT_OBJS = redboot-syscalls.o
-REDBOOT_SCRIPTS= redboot.ld redboot.specs
-REDBOOT_INSTALL= install-redboot
-
-RDPMON_CRT0= rdpmon-crt0.o
-RDPMON_BSP = librdpmon.a
-RDPMON_OBJS= syscalls.o libcfunc.o trap.o _exit.o _kill.o
-RDPMON_SCRIPTS = rdpmon.specs
-RDPMON_INSTALL = install-rdpmon
-
-RDIMON_CRT0= rdimon-crt0.o
-RDIMON_BSP = librdimon.a
-RDIMON_OBJS= $(patsubst %,rdimon-%,$(RDPMON_OBJS))
-RDIMON_SCRIPTS = rdimon.specs
-RDIMON_INSTALL = install-rdimon
+@BUILD_CRT0_TRUE@LINUX_CRT0= linux-crt0.o
+@BUILD_CRT0_TRUE@LINUX_BSP = libgloss-linux.a
+@BUILD_CRT0_TRUE@LINUX_OBJS= linux-syscalls0.o linux-syscalls1.o
+@BUILD_CRT0_TRUE@LINUX_SCRIPTS = linux.specs
+@BUILD_CRT0_TRUE@LINUX_INSTALL = install-linux
+@BUILD_CRT0_FALSE@LINUX_CRT0=
+@BUILD_CRT0_FALSE@LINUX_BSP =
+@BUILD_CRT0_FALSE@LINUX_OBJS=
+@BUILD_CRT0_FALSE@LINUX_SCRIPTS =
+@BUILD_CRT0_FALSE@LINUX_INSTALL =
+
+@BUILD_CRT0_TRUE@REDBOOT_CRT0 = redboot-crt0.o
+@BUILD_CRT0_TRUE@REDBOOT_OBJS = redboot-syscalls.o
+@BUILD_CRT0_TRUE@REDBOOT_SCRIPTS = redboot.ld redboot.specs
+@BUILD_CRT0_TRUE@REDBOOT_INSTALL = install-redboot
+@BUILD_CRT0_FALSE@REDBOOT_CRT0 =
+@BUILD_CRT0_FALSE@REDBOOT_OBJS =
+@BUILD_CRT0_FALSE@REDBOOT_SCRIPTS =
+@BUILD_CRT0_FALSE@REDBOOT_INSTALL =
+
+@BUILD_CRT0_TRUE@RDPMON_CRT0 = rdpmon-crt0.o
+@BUILD_CRT0_TRUE@RDPMON_BSP= librdpmon.a
+@BUILD_CRT0_TRUE@RDPMON_OBJS = syscalls.o libcfunc.o trap.o _exit.o _kill.o
+@BUILD_CRT0_TRUE@RDPMON_SCRIPTS= rdpmon.specs
+@BUILD_CRT0_TRUE@RDPMON_INSTALL= install-rdpmon
+@BUILD_CRT0_FALSE@RDPMON_CRT0 =
+@BUILD_CRT0_FALSE@RDPMON_BSP =
+@BUILD_CRT0_FALSE@RDPMON_OBJS =
+@BUILD_CRT0_FALSE@RDPMON_SCRIPTS =
+@BUILD_CRT0_FALSE@RDPMON_INSTALL =
+
+@BUILD_CRT0_TRUE@RDIMON_CRT0 = rdimon-crt0.o
+@BUILD_CRT0_TRUE@RDIMON_BSP= librdimon.a
+@BUILD_CRT0_TRUE@RDIMON_OBJS = $(patsubst %,rdimon-%,$(RDPMON_OBJS))
+@BUILD_CRT0_TRUE@RDIMON_SCRIPTS= rdimon.specs
+@BUILD_CRT0_TRUE@RDIMON_INSTALL= install-rdimon
+@BUILD_CRT0_FALSE@RDIMON_CRT0 =
+@BUILD_CRT0_FALSE@RDIMON_BSP =
+@BUILD_CRT0_FALSE@RDIMON_OBJS =
+@BUILD_CRT0_FALSE@RDIMON_SCRIPTS =
+@BUILD_CRT0_FALSE@RDIMON_INSTALL =
CFLAGS = -g
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR GDB testsuite
Boyapati, Anitha anitha.boyap...@atmel.com 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 version I could get?)
Yes, it is. It's basically unmaintained, except that I keep it alive
as long as avr-libc's testsuite still uses it.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)? Makefile
? Makefile.in
? aclocal.m4
? autom4te.cache
? config.guess
? config.log
? config.status
? config.sub
? configure
? depcomp
? diff
? foo.S
? foo.bin
? foo.elf
? install-sh
? missing
? simulavr-disp.1
? simulavr.1
? simulavr.spec
? doc/Makefile
? doc/Makefile.in
? doc/doxygen.config
? doc/html
? doc/internals
? doc/internals_html
? doc/mdate-sh
? doc/simulavr.info
? doc/stamp-vti
? doc/version.texi
? regress/Makefile
? regress/Makefile.in
? regress/regress.py
? regress/modules/Makefile
? regress/test_opcodes/Makefile
? src/.deps
? src/Makefile
? src/Makefile.in
? src/config-h.in
? src/config.h
? src/simulavr.away
? src/stamp-h1
? src/disp/.deps
? src/disp/Makefile
? src/disp/Makefile.in
? src/disp/simulavr-disp
? src/disp-vcd/.deps
? src/disp-vcd/Makefile
? src/disp-vcd/Makefile.in
? src/disp-vcd/config_parser.c
? src/disp-vcd/config_parser.h
? src/disp-vcd/config_scanner.c
? src/disp-vcd/simulavr-vcd
? src/getopt/.deps
? src/getopt/Makefile
? src/getopt/Makefile.in
? test_asm/Makefile
? test_asm/Makefile.in
? test_asm/test_8515/Makefile
? test_asm/test_8515/Makefile.in
? test_asm/test_8515/test_blink
? test_asm/test_8515/test_blink.bin
? test_asm/test_8515/test_blink.elf
? test_asm/test_8515/test_blink.hex
? test_asm/test_8515/test_blink.lst
? test_asm/test_8515/test_cntr
? test_asm/test_8515/test_cntr.bin
? test_asm/test_8515/test_cntr.elf
? test_asm/test_8515/test_cntr.hex
? test_asm/test_8515/test_cntr.lst
? test_asm/test_8515/test_eeprom
? test_asm/test_8515/test_eeprom.bin
? test_asm/test_8515/test_eeprom.elf
? test_asm/test_8515/test_eeprom.hex
? test_asm/test_8515/test_eeprom.lst
? test_asm/test_8515/test_port
? test_asm/test_8515/test_port.bin
? test_asm/test_8515/test_port.elf
? test_asm/test_8515/test_port.hex
? test_asm/test_8515/test_port.lst
? test_asm/test_8515/test_stack
? test_asm/test_8515/test_stack.bin
? test_asm/test_8515/test_stack.elf
? test_asm/test_8515/test_stack.hex
? test_asm/test_8515/test_stack.lst
? test_asm/test_8515/test_toie0
? test_asm/test_8515/test_toie0.bin
? test_asm/test_8515/test_toie0.elf
? test_asm/test_8515/test_toie0.hex
? test_asm/test_8515/test_toie0.lst
? test_asm/test_8515/test_toie0_2
? test_asm/test_8515/test_toie0_2.bin
? test_asm/test_8515/test_toie0_2.elf
? test_asm/test_8515/test_toie0_2.hex
? test_asm/test_8515/test_toie0_2.lst
? test_asm/test_8515/test_wdr
? test_asm/test_8515/test_wdr.bin
? test_asm/test_8515/test_wdr.elf
? test_asm/test_8515/test_wdr.hex
? test_asm/test_8515/test_wdr.lst
? test_asm/test_8515/test_wdr2
? test_asm/test_8515/test_wdr2.bin
? test_asm/test_8515/test_wdr2.elf
? test_asm/test_8515/test_wdr2.hex
? test_asm/test_8515/test_wdr2.lst
? test_c/.deps
? test_c/Makefile
? test_c/Makefile.in
? test_c/deep_frame
? test_c/deep_frame.bin
? test_c/deep_frame.elf
? test_c/deep_frame.hex
? test_c/deep_frame.lst
? test_c/demo
? test_c/demo.bin
? test_c/demo.elf
? test_c/demo.hex
? test_c/demo.lst
? test_c/demo_kr
? test_c/demo_kr.bin
? test_c/demo_kr.elf
? test_c/demo_kr.hex
? test_c/demo_kr.lst
? test_c/timer
? test_c/timer.bin
? test_c/timer.elf
? test_c/timer.hex
? test_c/timer.lst
Index: src/intvects.h
===
RCS file: /sources/simulavr/simulavr/src/intvects.h,v
retrieving revision 1.8
diff -u -u -r1.8 intvects.h
--- src/intvects.h 16 Mar 2008 21:14:08 - 1.8
+++ src/intvects.h 29 Jun 2011 06:06:35 -
@@ -26,6 +26,8 @@
#ifndef SIM_INTVECTS_H
#define SIM_INTVECTS_H
+#include stddef.h
+
enum _sleep_modes
{
SLEEP_MODE_IDLE,
@@ -83,7 +85,7 @@
an index enumeration. */
#define irq_vect_table_index(vect) \
-( ((unsigned int) (( ((IntVectTable *)(0)) - vect))) / sizeof(IntVect) )
+( offsetof(IntVectTable, vect) / sizeof(IntVect) )
/* No device will have all of these vectors, but must define a structure which
has a slot for each interrupt. If the device doesn't support the___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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 retained, too. The avr-libc testsuite heavily relies on that feature, in order to analyze the simulator state post mortem. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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 doesn't mean it's impossible to adapt it, but it requires manpower to do so. Keeping the old simulavr alive requires almost zero manpower, in contrast. ;-) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] ATmega32A
Peter Bozzay altbp...@gold.uni-miskolc.hu 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 the PDIP device, but due to the much longer traces, nobody wants to guarantee anything when it comes to the preamplified ADC channels (which are only applicable to differential mode). Likewise, ATmegaX8 in SMD cases feature two additional ADC inputs which are unavailable in the PDIP version. Presumably, they are simply not bonded there since the 28-pin PDIP doesn't have enough pins. Still, from the compiler's point of view, nothing changes. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR GDB testsuite
Boyapati, Anitha anitha.boyap...@atmel.com 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, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Toolchain not showing up with xmega support
David L. Martin dlma...@gmail.com 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 should apply without problems also for Linux. The only thing is there's no Atmel-provided Linux toolchain as a binary distribution. OTOH, you could consider that a value: while (most) Windows users never really learn that they are eligible to also compile that stuff from source (with the option to possibly modify the source if they found a bug that really annoys them), you'll eventually know how to do that. ;-) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Trouble with: relocation truncated to fit: R_AVR_13_PCREL
Weddington, Eric eric.wedding...@atmel.com 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 works incidentally. I think, in the past we've got the entire avr-libc within a single section, so chances were better everything has been linked together local enough to meet the RJMP condition. Now, with the per-function sections, chances are better they get far apart in the resulting binary. We should turn them all into long jumps/calls, and have the linker relaxations do their job later on. It's obvious that the desired solution was to have that code integrated into libgcc instead of in avr-libc (which is not the case for reasons we all know). Your proposed solution looks easy to implement, though I'd prefer if we could instead move *all* of avr-libc's functions that duplicate libgcc functionality out into libgcc. Obviously, that requires that all relevant contributors agree to re-license their code under GPL, and to sign the dreaded (and IMHO pretty useless) FSF copyright assignment. Only failing that, I'd like to see yet another hack ⦠-- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-gcc 4.3.3 : enum definition/use order has side effects on -fshort-enums
Bernard Fouché bernard.fou...@kuantic.com 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 a full `int'. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-gdb use
Levente Kovacs leventel...@gmail.com 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), Well, I'd add a table of the addresses, and you could use the syntax like this: x/bx __PORTA Ideally even print PORTA Anyway, the big question is how to add this to the symbol table from just including the low-level header file (avr/io.h), or possibly even by linking against a separate object file which is going to add the debugging symbols. In the meanwhile I figured out lots of things, and my target is reached: a RTOS. And I'm happy. Glad to hear, 73! -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
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, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Fixing PR44643 vs. PSTR macro
Georg-Johann Lay a...@gjlay.de 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 (with an ICE). So it doesn't matter whether GCC aborts with a valid complaint rather than an ICE. Alas, the GCC trunk is currently broken for compiling for the AVR target (see bug #48395), so I could not test-compile my suggested fix for avr-libc with a current compiler. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Relocation types in AVR GAS
Boyapati, Anitha anitha.boyap...@atmel.com wrote: I am trying to understand relocation types in AVR. To start with, can someone illustrate how R_AVR_16 works in the following case? I can only guess. Don't know whether there's someone with more insight. As I see it, since the address is 16-bit, 'size' is 1. How do we arrive at 'rightshift' and 'bitsize' entries? No idea what rightshift is doing, you might get an idea by comparing against other relocation types. bitsize should be clear: it's a 16-bit relocation. My guess is that bitsize might be different for other relocations even with the same 'size' field; compare that e.g. to the relative branch and jump relocations (R_AVR_7_PCREL and R_AVR_13_PCREL). And how assembler knows to emit R_AVR_16 type? Probably from the instruction it is connected with. Obviously, R_AVR_16 only applies to instructions like STS/LDS etc. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] GCC 4.5.1 wiht AS5 Error
Trampas Stern tram...@gmail.com wrote: /home/tools/hudson/workspace/avr8-gnu-toolchain/src/avr-libc/crt1/gcrt1.S:52: warning: internal error: out of range error avr-gcc-list@nongnu.org That sounds as if you were trying to relocate your bootloader beyond the actual address space of the AT90CAN128. Line 52 in gcrt1.S is the reset vector (containing a jump to the label __init). What's your compiler commandline to link this job? Btw., without subscribing to this mailinglist, I'm afraid you'll miss a number of replies. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] uisp - atmega16 dead after setting high/low fuses
Rieker Flaik rieker_fl...@arcor.de wrote: Maybe I falsely set some Lock-Bits a while ago, I thought Btw., lockbits are always erased upon a chip erase, so that's never going to be a problem when reprogramming a device. In my design I use a external crystal. So I tried to set the fuse-bytes accordingly: The fuse byte values make sense, assuming you are goin to connect an external crystal of at least 1 MHz. What could be the problem? Assuming uisp actually programmed the fuses correctly (Eric already told you it's been out of maintenance for many years now), can you somehow assure the crystal oscillator is actually running, e.g. by probing with an oscilloscope? Failing that, can you locate some external clock source (in the low MHz range), and feed it into XTAL1 to see whether you can resurrect the controller that way? Finally, JTAG might be an option to resurrect the chip(s), as JTAG programs the device using its own clock. For the ATmega16, you could quickly hack one of those cheap JTAG ICE mkI clones together, using another ATmega16. But obviously ;-), this requires a safe method to program ATmega16s first, so that's only a possible fallback once you found your mistake, in order to recover the now dead ATmega16s. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Data section and stack
Salut Sebastien, please, better subscribe to the list in order to not miss replies. Sebastien Chretien s.chret...@enko-creatio.fr wrote: Is there a way to know if stack pointer is entering in data section ? You can read out the stack pointer, and compare it against the symbol _end which is provided by the linker and marks the last allocated SRAM address. While developing, you might monitor the stack usage by initially filling up all SRAM with a known pattern, and then observe the amount of stack that overwrites this pattern, e.g. using JTAG debugging. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] nested macros don't expand
(Please subscribe to the list to see all replies. Many people tend to reply to the list only as it is a closed list anywaa.) George Kvirkvia kvirk...@gmail.com wrote: when I try to use this macro like this: set_port_pin(MOTOR_CONTROL_PIN); I get preprocessor error, saying that set_port_macro expects 2 arguments and I pass only 1 This needs two levels of indirection: #define MOTOR_CONTROL_PIN PORTC,1 #define set_port_pin_(port, pin) (port |= (1pin)) #define set_port_pin(x) set_port_pin_(x) set_port_pin(MOTOR_CONTROL_PIN); -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-libc-1.7.0 fails to compile
As Georg Lay wrote: Thanks, that works. Now using 3.81 instead of 3.80. Yes, Dmitry introduced some pattern derivations that require 3.81. One more question: How does avr-libs determine if a specific target is supported or not? See configure.ac: it tries to test-compile a minimal piece of code, and relies on GCC's exit code to see whether the respective -mmcu option value is acceptable or not. GCC currently has a bug in that it doesn't correctly report an error status if the -mmcu option value is not actually supported (GCC bug #45261); instead, it relies on the assembler to fail. So if your binutils support a device the compiler doesn't support, the decision will be wrong. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-libc-1.7.0 fails to compile
As Georg Lay wrote: Ok, that's fine for me. Just want to understand where the hiccups are If you look into GCC bug #45261, Andrew Pinski already basically posted the fix: replace the one fprintf by an error, and it will work as expected. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-libc-1.7.0 fails to compile
Georg Lay a...@gjlay.de wrote: Building avr-libc-1.7.0 I am running into the error indicated in the attachment. Any ideads? Sounds familar. Update your GNU make. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Specification of AVR ELF format?
Daniel O'Connor dar...@dons.net.au wrote: On 24/09/2010, at 13:59, Wim Lewis wrote: I want to add ELF support to avrdude [...] Which is great! Btw., there's a separate avrdude-dev mailing list for development on AVRDUDE. Can't you just use libbfd, or libelf? Yes, please, use libbfd. It's already a prerequisite for AVaRICE, and for the exact same reason: to load an entire AVR's image from the ELF file. You might get the missing pieces of information including code examples from there (except for the fuse byte offsets, as they are a recent addition, but they should be simple enough to figure them out). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR-newbie need help!
Roger Holmquist ro...@ossgl.com wrote: I assume communication should be performed via the Bootloader? That ought to be possible, yes. I tried this: avrdude -p ATmega169 -c butterfly -P /dev/tty.usbserial -t -v That's basically the way to go. Add three more -v options, and you'll see a trace of the entire communication. There is some lowlevel protocol found in an ATMEL pdf-file, AVR109 and I assume that or part of it is running in the bootloader? Actually, the butterfly protocol is not identical but close to AVR109. AVR109 is the protocol of a standalone programmer that could program different (external) AVRs, while a bootloader can only program a single chip. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Problem with array on the stack
Cory Cross crcr...@mtu.edu wrote: If this is not my fault, I will try and come up with the simplist program demonstrating the problem. Yes, please do: .. make that snippet a fully compilable source file .. add a main() .. show all the commands used to compile and link it The latter is important as the stack is setup before main(), so just compiling your code snippet doesn't yield anything interesting as there is no stack pointer assignment in there. (Actually, there's not even a stack pointer modification at all as your clobberer[] is discarded by the optimizer entirely.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] List of outstanding avr-gcc patches
Johannes Bauer jb@gmx.de wrote: However, I have made the subjective observation that the SNR in web-based fora is usually a lot lower than in mailing lists or the Usenet for that matter - even among non-trolls. That's only because all the newbies asking silly questions went away to the web fora in the past. ;-) Usenet used to have a terrible SNR during its high time (at least in some groups). I also prefer Usenet and mailing lists over web fora personally, I was just arguing that avrfreaks.net sucks big rocks isn't a useful statement, because it exaggerates just on some aspects of its look feel. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR Studio lacks ability to display out-of-scopevariables? (was: Frame pointer location)
Weddington, Eric eric.wedding...@atmel.com wrote: I was referring to automatic variables from your caller(s), i.e. everything where you have to unwind the stack in order to see them. Is there enough DWARF2 info in the generated ELF file to fully support = this feature? I'm not sure about that. Remember, our DWARF-2 support is still accidental (or incidental), it's only a by-product of other GCC platforms moving to DWARF-2, e.g. avr-as' support of --gdwarf-2 is disfunctional, and AVR-GDB cannot usefully handle DWARF-2 at all. The stabs support in AVR-GDB to decode stack frames has once been written by Ted Roth. I don't know whether he also had to tune/enable/tweak anything in GCC for this to work. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR Studio lacks ability to displayout-of-scopevariables? (was: Frame pointer location)
Weddington, Eric eric.wedding...@atmel.com wrote:
I just want to be sure, right now, =
if the required debug information is being generated in the ELF file for =
*any* debugger to take advantage of.
I think it does:
j...@uriah 76% cat foo.c
int
foo(int i)
{
int j = 42 + i;
extern int bar(int);
return bar(j);
}
j...@uriah 77% avr-gcc -gdwarf-2 -O0 -c foo.c
j...@uriah 78% avr-readelf --debug-dump foo.o
[...]
241: Abbrev Number: 3 (DW_TAG_formal_parameter)
42 DW_AT_name: i
44 DW_AT_decl_file : 1
45 DW_AT_decl_line : 2
46 DW_AT_type: 0x5a
4a DW_AT_location: 2 byte block: 8c 3 (DW_OP_breg28: 3)
24d: Abbrev Number: 4 (DW_TAG_variable)
4e DW_AT_name: j
50 DW_AT_decl_file : 1
51 DW_AT_decl_line : 4
52 DW_AT_type: 0x5a
56 DW_AT_location: 2 byte block: 8c 1 (DW_OP_breg28: 1)
[...]
I guess the key point is not so much the DWARF-2 information, but
actually detecting each function's stack frame. Ted implemented a
bunch of heuristics in GCC for this (if I remember it well, it's been
a while ago I've been looking into this last time).
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Frame pointer location
Johannes Bauer jb@gmx.de wrote: When sporadic deadlocks occur in a system, a stacktrace can really help find bugs. Yes, I know. I usually end up in manually inspecting the stack then, as this requires no specific compilation options. As I only have to do it once a year or so, this never bothered me too much (and I could successfully dig up memory corruptions going into IO space that way, which in turn triggered an unexpected interrupt, and other nice gotchas). I think stack unwinding in-system could be useful for other people as well. Well, most people debug using AVR Studio, which has even less ideas about the GCC call stack than AVR-GDB does. AVR Studio even lacks the ability to display out-of-scope variables, yet most people appear to just live with that. I doubt there's a very broad audience for improved stackframes -- as I said, people do care for the amount of code generated, next they do care for the code size, then they compare the generated code size with compiler XYZ, and only then they start comparing other features. :-/ Could you please point me to where I should look/poke around in order to get this resolved? Sorry, I'm not a compiler guy. I don't have any clues about the compiler internals. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Miscompilation with GCC 4.5.1 / diagnosis and possible patch
Owen Taylor otay...@fishsoup.net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45291 Please mark it as for the avr (lowercase letters) target. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] List of outstanding avr-gcc patches
Johannes Bauer jb@gmx.de wrote: Yes, I found that. But it forces you to register with that abysmal website in order to download the file, which I will avoid at all costs. It's probably the worstly designed, butt-ugly and confusing webforum I've ever seen in my entire life. I've seen worse, and at least, the community there is doing fine. It's probably the largest pool of developers using AVRs you can find there. However, even if you register there, nobody forces you to actually use the forum then if you don't like it. Just download Bingo600's patch, and get away again -- the forum won't throw stones after you, or write you emails urging you to come back. ;-) (Btw., if you are annoyed by all the stuff left and right of the forum text, press the Maximize link in the linklist on top. It will give you the forum, and just the forum, nothing else.) If Jörg has compiled the patches, that's strange: On his website there is no reference to them (I looked there first :-)) I maintain them inside the FreeBSD ports tree. I loosely coordinate the patches there with Eric Weddington, so while they are not identical (the FreeBSD ports use some things differently, and I omitted everything that was only there to get AVR-Ada going which I didn't establish a port for yet) they should be not too far away from the Windows AVR toolchain. Bingo600's script is nothing else but a Linux wrapper around the patches from my FreeBSD ports, so Linux users could eventually get the same AVR tools FreeBSD users can get straight from their ports system. It's only a convenience script, usually without any functional changes. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Compiler error creating ISR prologue?
Johannes Bauer jb@gmx.de wrote: This appears to be strange to me. The clr r1 instruction should IMO be placed after the first push r0 instruction. I didn't verify it right now, but I think this is a very old bug that has been fixed in the Xmega patch maybe a year ago. What toolchain are you using? (The Xmega patch is still not integrated into the main GCC tree, AFAICT.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Frame pointer location
Johannes Bauer jb@gmx.de wrote: I've got another question regarding the AVR ISR prologues: Let's say I compile with -fno-omit-frame-pointer. As a side note, I don't think this option has received extended testing in AVR-GCC. People are usually interested in getting the smallest code size possible, so creating a stack frame when it's not really needed (many functions don't need it) is a waste of time and code. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] List of outstanding avr-gcc patches
Johannes Bauer jb@gmx.de wrote: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/ Remember that you're creating them *straight from CVS*, so that's going to be a moving target as soon as I update one of the ports. Please don't try to request larger tarballs there, as it imposes a high load to the CVS server. Remember, this interface is meant as a convenience to the users, not to be abused. wget clients are already not allowed for that reason: one innocent recursive wget attempt could easily knock down the server, as it not only tries to recursively fetch all files, but eventually also *all revisions* individually. If people start abusing that service further, I'm sure someone will throw a block into the system. You could also rsync parts of the FreeBSD CVS tree from public repositories, and then checkout the parts you are interested locally. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] volatile with winavr2010
(Better subscribe to the list, you might miss replies otherwise.) Leiu tvhoa...@gmail.com wrote: Thanks all, But i can't find bug, Here is my full code Result : i can show 'A'! why? Because you're using hyperterm? I've compiled this for an ATmega16, set it up on an STK500, and connected it to my terminal emulator: ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOP... I assume this is what you'd like to see, isn't it? Note that after printing the 'Z', it pauses for one tick, which matches your code (the ISR only resets first_edge to 'A' then, but doesn't print out anything). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] memcpy_P on XMega
Johannes Bauer jb@gmx.de wrote: I suggest on the XMega to set NVM.CMD to zero in the beginning of memcpy or include this in the docs, as it might cost someone else roughly a day in debugging time :-/ Please submit an avr-libc 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-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVRdude for ATMega16
Andi Suhandi andi_messen...@yahoo.com wrote: avrdude: error: selected device is not supported by programmer: m16 So it's not AVRDUDE which doesn't support the ATmega16 but your programmer. The problem here is that AVR910's idea of a device code is completely flawed. The original appnote AVR910 lists device code 0x75 for the ATmega16, meant as the boot code, so the normal code is 0x74. This code doesn't appear in your programmer's device code list, but instead, a number of device codes appear which are not understood by AVRDUDE. The dilemma is, appnote AVR910 has been essentially abandoned by Atmel (at least, the programming protocol/firmware part), and these device codes have not been maintained by any kind of authority further on, so they vastly diverged in the wild. (This doesn't explain though why your programmer obviously doesn't use the rather well-defined ATmega16 code number 0x74.) You have to ask the author of your programmer's firmware about which of these (unknown to AVRDUDE) device codes is meant to apply to the ATmega16. Once you know, let's assume the answer is 0x42, you can run AVRDUDE with avrdude -p atmega16 -P com15 -c avr910 -x devcode=0x42 -b 38400 -U TalkCounter.hex -U eeprom:w:TalkCounter.eep -U lock:w:0xfc:m This will override the device code decision which is normally based on avrdude.conf. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVRdude for ATMega16
Andi Suhandi andi_messen...@yahoo.com wrote: Is it true avrdude not support ATMega16 ? No, of course not. It's been supported for many years now. If you want a more detailed reply, then please give us more details, about error message, about your changes to avrdude.conf, about your exact programmer type etc. Btw., to just change the communication baud rate, no need to edit avrdude.conf, you can do this with the option -b 38400. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] documenting pm() and gs() avr-as operators
Jan Waclawek konf...@efton.sk wrote: I know this is not the best place to mention it, but I don't know *where* is the best place to mention... By filing a bug report + patch to GNU binutils. The better it fits into the project (e.g.: include a ChangeLog snippet), the higher the probability it will go in. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] documenting pm() and gs() avr-as operators
As Jan Waclawek wrote: First, I have no idea what the source of docs is GNU binutils, if you look around, it's easy enough to find: there's a directory named gas (for GNU assembler) which in turn has a subdirectory named doc. There, you can find a file named c-avr.texi, which is supposed to document AVR extensions to the GNU assembler. (and I suspect it is in some arcane language I would have trouble to work with anyway), texinfo, which is nothing terribly hard to guess, since basically, you could just look around how the other entries are formatted. where it is nor how to prepare a patch the high esteemed gnu gurus You are sounding arrogant, sorry. Not much sense in continuing the discussion. If you don't know something, you can simply ask. If you don't want to contribute, that's fine, too, but then don't expect anyone else to spend much more energy into fixing it than you did yourself. There's no God here, there's just people doing their work like you and me are doing. Btw., as a stop-gap measure, we added it to the avr-libc documentation some time ago, as avr-libc is a relatively small project where it is simple enough to add a bit of documentation without pushing it through half a dozen of instances it first. But as Eric mentioned, the bug is really in GNU binutils, they ought to document it. PS. Recently I've posted you personally on another suggestion not fitting anywhere, which came from avrfreaks, a small mod in the MFile template, have you had opportunity to have a look at that? Not really, and I'm a little sorry there is no formal bug tracker available for Mfile, as it isn't really a standalone project of its own. We used to host it in the WinAVR repository, but as Eric is going to transition WinAVR to another project (under the umbrella of Atmel), there's no longer a bug patch tracker around. As such, your suggestion simply sits in my inbox, hoping I'll find enough time and devotion to polish up Mfile again some day, and then going to remember there's still an email from you. I'm not quite satisfied with that situation, but Mfile is just such a minor thing so I'm a little reluctant about pushing it up into a full-blown savannah or sourceforge project of its own. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] documenting pm() and gs() avr-as operators
As Jan Waclawek wrote: Could you please point me at it, I can't find it. I can find a mention of pm in http://www.nongnu.org/avr-libc/user-manual/assembler.html (although not its modifications documented in the as documentation); but I can't find explanation of gs. You're right, the explanation of gs is missing. However, I did find this: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00534.html which says, among others: In order to distinguish relocs where stubs should be generated and relocs where no stubs should be generated, there are now two new ldi-type PM relocs that carry the GS suffix instead of PM. Gas now knows of the directives gs() that has the same functionality as pm(), only that it generates the GS relocs that force the linker to generate stubs. OK, so you found all the documentation that we've got about it. :-/ (Now I even understand what GS stands for generate stubs.) It is sort of Greek to me, though; not really something I would call user documentation (as I said, I do have a faint idea what those things do, but I like things to be straight and solid). Did you understand the pm operator? Basically, it's performing a shift operation by one bit, which is needed since all the code addresses in flash are meant to be in units of 16-bit words, while everything else (including all the GNU tools) think in units of 8-bit bytes. The pm operator works at the linker level, so it can accept relocatable symbols (where the actual address is inserted by the linker after resolving the relocation). That's why it requires the introduction of a relocation code within the object file, so the assembler can transfer that information to the linker. That's also the reason why you cannot perform the bit shift directly in assembly language: neither the ELF file format nor the GNU linker has any method to transfer that bit shifting into the linker, as there is no support for performing arbitrary arithmetics on relocational symbols. (Well, the linker used on the PDP-11, running RSX-11 did have the ability to do that. But that's been 30 years ago. ;-) For machines with = 128 KiB of flash ROM, the gs operator works the same. For larger machines, it tells the linker to perform special actions on the data labelled that way, so the linker can take care to handle addresses beyond the current 128 KiB segment where a trampoline entry is needed. (Disclaimer: that's how *I* understood it. Bjoern might correct me here...) Btw., isn't Bjoern Haase subscribed to this forum? He seems to be the right person to be pestered for the proper docs... Yes, he is, but I'm afraid he might have unsubscribed some time ago. :-( [Mfile] Oh, and we even provided the patch this time! ;-) Okay, not a formal one, but it's just inserting 3 lines anyway. Appreciated, be sure. I'm not quite satisfied with that situation, but Mfile is just such a minor thing so I'm a little reluctant about pushing it up into a full-blown savannah or sourceforge project of its own. I believe it could be simply sticked to avr-libc. I already thought about that as on option, yes. Might be a good compromise, indeed. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Object Memory Layout
Joshua Perry j...@6bit.com wrote: Is there a diagnostic or tool in GCC/G++ to see how it decided to layout an object in memory, with alignment, padding, vtable, etc...? AVR-GCC doesn't apply any padding, as the CPU is an 8-bit CPU. You could start with avr-nm to see the address (and thus, implicitly, the size) of each object. Do you have string literals in your code? -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Avrdude hfuse error message (tiny26) ...
As Royce Pereira wrote: Your link opens a page that says This item is private . Sorry, I don't know why someone did set this bug report to private state. This is normally intended for reporting important security bugs that should not be made public just by reporting the bug. I've set it to public now. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avrdude-5.1 error when installing
med_alpa the.leade...@gmail.com wrote: I have this error : 36: error: conflicting types for 'usleep' pgm.h:107: error: previous declaration of 'usleep' was here. Which version of AVRDUDE is this? I thought I had fixed that in the most recent version. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Inline vs. ? : operator
Weddington, Eric eric.wedding...@atmel.com wrote: It must include a buildable test case that shows the alleged issue. The code shown in the initial posting almost qualifies as such. It should simply extract the define out of the header file, and place it on top of the code: #define PORTA (*(volatile unsigned char *)0x3b) By doing that, the remainder of avr/io.h can be omitted. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] modulo vs. loop (gcc 4.3.x bug)
Szikra Istvan steven.sp...@gmail.com wrote: Maybe we need some kind of -keep-section-together=.bootloader linker option. Sections /are/ kept together. The problem is that your libgcc.a function does not live in the ..bootloader section. There's no simple way the linker could move it there, because if both, the application *and* the bootloader section reference the same symbol, it will only be included once. Changing this will require major structural changes in the linker, I guess, just to solve an arguably fairly rare case. My problem here is caused partly because the tool-chain is not in sync: the compiler is thinking it's being smart, but the linker is not. You're vastly misinterpreting what you see. so how do I tell the compiler to stop messing around, and I know what I'm doing so leave that part of the code alone, or stop recognizing that pattern in the entire project? Well, you'd have to turn off optimizations. ;-) Currently, that can only be done on a per-compilation unit (i.e., per-file) base, I've heard it should be possible in future to do it per-function. You could also try messing around with the optimization settings. I could imagine that this optimization is never activated for -O3. Btw., your test code compiles into: test: /* prologue: function */ /* frame size = 0 */ in r25,59-32 ldi r24,lo8(0) rjmp .L5 ..L6: subi r24,lo8(-(1)) subi r25,lo8(-(-3)) ..L5: cpi r25,lo8(3) brsh .L6 out 56-32,r24 out 53-32,r25 /* epilogue start */ ret with my compiler (GCC 4.3.4, FreeBSD patches, identical to the Bingo600 build script). I think any programmers who writes a loop instead of a modulo or divide by mistake really deserves the result. Compilers recognize patterns, and reorder code on that. The pattern is not necessarily as clear as in your case. Often, such patterns are hidden e.g. inside a C++ template or such. Anyway, I never disagreed it's a pessimization (i.e. a typical case for a missed optimization bug), I only disagreed to qualify it as any kind of serious (in the sense of: wrong code generated) bug. I cannot imagine a case where calling the division function on the AVR would result in really smaller code than the simple loop. I'm surprised about the different result in your compilation, because after all, I think my compiler patches are basically on sync with the latest WinAVR patches (modulo the Ada-related patches, as I don't build the Ada compiler on FreeBSD [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-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
