Re: [avr-gcc-list] C++ with PSTR

Paul Stoffregen wrote: Maybe some combination of __builtin_types_compatible_p or _built_const_p or typeof? I tried playing with these but could never seem to make a macro that resolves one way if the arg is a string literal and another way if it's a pointer or anything else. Remember, macr

c++ (was: Re: [avr-gcc-list] RE: AVR-GCC-list Digest, Vol 52, Issue 10)

Mohamed Reda wrote: i wish to learn the c++ structure to be able to wright a project using AVR-GCC. Your question isn't exactly clear, but I think you are asking for some getting-started information on writing C++ for AVR's. If you go over to avrfreaks.net and search the gnu forum, you will

Re: [avr-gcc-list] Mac Development for attiny88

Have you been trying the macports and fink stuff? I'm not sure how well either of those is kept up. You might be better off building your own from fresh sources. -dave David Tuzman wrote: Hi, I'm trying to set up AVR development on my Intel-Based MacBook Pro. I've tried various toolchain

Re: [avr-gcc-list] Using delay functions with variable F_CPU clock?

David VanHorn wrote: F_CPU is always evaluated upon each invocation, so if you ever change it within one compilation unit, the next invocation of one of these macros will reflect this. That's compile-time, he's looking for execution-time changes in processor speed. He didn't explicitly say so,

Re: [avr-gcc-list] Syntax: Function pointer hell... newbee lost ! ;-)

Vincent Trouilliez wrote: I am still not quite clear why the map file reports Flash adresses twice that of what the memory pointer of the AVR chip actually holds physically ? The not-very-technical answer: Well, avr-gcc thinks the whole world is byte addressable. But AVR flash is (16 bit) wo

Re: [avr-gcc-list] Sharing code between a bootloader and an application.

dphar...@telus.net wrote: Since bootloaders need to establish communications in order to function, it would seem useful to be able to use some of this functionality by the bootloaded application code. In particular, this is in relation to CAN, where the boot-up code will need to establish a no

Re: [avr-gcc-list] Re: AVR LLVM backend?

Preston Wilson wrote: I'm pretty sure this is not an issue (anymore, at least). I could be wrong. The recently-added PIC port of LLVM would be a good place to start looking. Ummm... are you sure they mean PIC as in a processor from Microchip, or do they mean PIC as in Position Independent Co

Re: [avr-gcc-list] Re: AVR LLVM backend?

Weddington, Eric wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of John Regehr Sent: Thursday, November 13, 2008 9:23 PM To: David Brown Cc: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Re: AVR LLVM backend? I'm pretty sure this is

Re: [avr-gcc-list] Link script question

Dave Hylands wrote: Gu Gre7g, Try this version of mega32.ld I think it does everything you need without having to use any .c files. Yes, better. I didn't know you could stuff data from the linker script. -dave __

Re: [avr-gcc-list] Link script question

Gre7g Luterman wrote: From: Dave N6NZ <[EMAIL PROTECTED]> To: Gre7g Luterman <[EMAIL PROTECTED]> Cc: avr-gcc-list@nongnu.org Sent: Friday, October 10, 2008 11:02:21 AM Subject: Re: [avr-gcc-list] Link script question That would work, of course, but I'd have to designate a cons

Re: [avr-gcc-list] Link script question

Gre7g Luterman wrote: From: Dave N6NZ <[EMAIL PROTECTED]> To: Gre7g Luterman <[EMAIL PROTECTED]> Cc: avr-gcc-list@nongnu.org Sent: Thursday, October 9, 2008 8:56:07 PM Subject: Re: [avr-gcc-list] Link script question I would take very slightly different approach. Make that a sec

Re: [avr-gcc-list] Link script question

I would take very slightly different approach. Make that a section of it's own, and put it in the linker script just after your exported symbol: __user_prog_start = .; *.(.userprog.*) ; then create a simple .S .section .userprog .byte 0xff ; is this the correct directive? I forget .

Re: [avr-gcc-list] how do I pass --defsym to avr-ld?

ntries.o I'm not sure if the command line is okay :-(. Knut -Original Message- From: [EMAIL PROTECTED] g [mailto:[EMAIL PROTECTED] ongnu.org] On Behalf Of Dave N6NZ Sent: Tuesday, September 30, 2008 10:15 PM To: [EMAIL PROTECTED] Cc: AVR-GCC Subject: Re: [avr-gcc-list] how do I

Re: [avr-gcc-list] how do I pass --defsym to avr-ld?

??? badly need a clue here... -dave Dave N6NZ wrote: After making many threats, I'm finally attacking the problem of doing separately compiled libraries in a robust fashion. (I can't bring myself to call them dll's since being flashed they are hardly very dynamic :) I have pat

[avr-gcc-list] how do I pass --defsym to avr-ld?

After making many threats, I'm finally attacking the problem of doing separately compiled libraries in a robust fashion. (I can't bring myself to call them dll's since being flashed they are hardly very dynamic :) I have patched the avr5.x ld script as follows, which is a total of 3 addition

Re: [avr-gcc-list] A few basic doubts regarding installing AVR-GCC on Fedora 9

Eshwaran Vijaya Kumar wrote: @ Dave I did check the Bingo thread. However there seems to be no reference to any GCC beyond 4.2.2. I suppose they are yet to update the scripts to the corresponding versions? Regards Sorry for the distracting comment... I missed the version-specific nature of

Re: [avr-gcc-list] A few basic doubts regarding installing AVR-GCC on Fedora 9

WinAVR and the *nix releases are kept in close sync by Eric and Joerg. Most *nix users follow the "Bingo scripts" found in a sticky thread at avrfreaks.net in the gcc forum. The Bingo scripts are reliable and incorporate all the patches. -dave Eshwaran Vijaya Kumar wrote: Hi Bernard, Tha

Re: [avr-gcc-list] 24 bit Integer

PDP-11 is 16 bit words, byte addressed. DEC-10 was 36 bit words. -dave Steven Michalske wrote: Sorry, I though GCC supported the more of the PDP lines, but its just the PDP-11 with it's 36bit words Steve On Jul 30, 2008, at 8:54 PM, Weddington, Eric wrote: -Original Message

Re: [avr-gcc-list] Eclipse, avarice, JDB usage?

Dennis Clark wrote: I had found this before, but it was so _old_ I'd disregarded it. As I read more it looks like a good jumping off point. It points out places I can get information - Like avarice (in this document) says it can only support hardware break points. DebugWire however only sup

Re: [avr-gcc-list] Eclipse, avarice, JDB usage?

Dennis Clark wrote: dlc wrote: Hi all, No one on AVR-chat appears to use avarice, avr-gcc and Eclipse. All are using AVR studio or nothing at all for debugging. SO, my question to this group is. How? Does anyone have any experience using the following nifty tools all together? avr-gcc ava

Re: [avr-gcc-list] Eclipse, avarice, JDB usage?

dlc wrote: Hi all, No one on AVR-chat appears to use avarice, avr-gcc and Eclipse. All are using AVR studio or nothing at all for debugging. SO, my question to this group is. How? Does anyone have any experience using the following nifty tools all together? avr-gcc avarice Eclipse Ecli

Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

Mark Litwack wrote: On Friday 16 May 2008 04:00:17 pm Dave N6NZ wrote: [...] I could see including both clobbering and non-clobbering flavors of sei()/cli() in avrlibc -- then we can have a whole new and entertaining argument about whether the old names sei()/cli() should have the new or old

Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

John Regehr wrote: Well, isn't the net effect of volatile simply a more fine-grained clobbering lock? Almost but not quite: - volatile says nothing about the atomicity of any given access - volatile does not suppress reordering (except with other volatiles) - volatile has no effect on cach

Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

John Regehr wrote: # define sei() __asm__ __volatile__ ("sei" ::: "memory") # define cli() __asm__ __volatile__ ("cli" ::: "memory") Adding these clobbers is an extremely good idea because they make cli/sei act like proper locks, in two senses. First, they prevent reordering of comput

Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

The result of the atan2 does not impact the bit value written to PORTA, so the compiler is free to re-order it. That's what optimizers do. -dave Thomas D. Dean wrote: I have a code segment which 1. sets a bit in PORTA. 2. calls atan2. 3. clears the same bit in PORTA. The compiler

Re: [avr-gcc-list] prog_mem limitation?

Marc Wetzel wrote: Is this the intended behaviour? What cause is here the trigger? I'm not eaxctly sure why they behave differently, but the latter causes teststring[] to be allocated in the .data section instead of .progmem. Probably because the second case does not have the '

Re: [avr-gcc-list] avr toolchain install problem

I'm thinking its a configuration problem. Have you successfully compiled something else with gcc? Maybe it's not finding some headers or libraries or such. -dave Richard Johns wrote: Thanks Andy. I installed gcc(as well as gcc-4.2) which gave: checking for gcc... gcc checking whether the

Re: [avr-gcc-list] OS X 4.2.2 -- simplest way today?

Rick Mann wrote: On Apr 28, 2008, at 17:14:38, Dave N6NZ wrote: Can someone point me to the simplest way to get the avr-gcc 4.2.2 tool chain running on OS X, with patches that sync up to the "linux sticky thread" in avrfreaks? I got it working using the scripts in the &qu

Re: [avr-gcc-list] OS X 4.2.2 -- simplest way today?

Weddington, Eric wrote: Note on Gentoo: do NOT use crossdev to build your AVR toolchain as that has known problems. Very true. I tell anyone who will listen not to run crossdev. My Gentoo and Slackware systems are working fine. The main point of this exercise is to get my collaborator (a

Re: [avr-gcc-list] OS X 4.2.2 -- simplest way today?

thing is one big .tar.gz file, covering some 2 ports, but if you have the guts to unzip the thing, you should find the patches in /devel/avr-gcc/distfiles, methinks. Not much of a unix coder, can't help more than that, but if you have time and initiative, it might get you there. Steve

[avr-gcc-list] OS X 4.2.2 -- simplest way today?

Hi, Can someone point me to the simplest way to get the avr-gcc 4.2.2 tool chain running on OS X, with patches that sync up to the "linux sticky thread" in avrfreaks? Thanks, Dave ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://list

Re: [avr-gcc-list] Bug? gcc silently assumes mcu model when linking, creating bad executable

Weddington, Eric wrote: As Weddington, Eric wrote: My guess is all this comes from a time when AVR-GCC was created, and there were maybe three or four different AVRs only, so it did make some sense for it to default to one of them (IIRC, it defaults to the AT90S8515). I thought it defaults

Re: [avr-gcc-list] RE: Patch Fix PR35013, PR27192

Well, I don't really feel qualified to comment since I'm unfamiliar with gcc internals, but since nobody else seems to be following your progress, I'll throw in my US$0.02 This seems like a simple fix and I can't think of any other test cases that you haven't already addressed. I say we add i

Re: [avr-gcc-list] RE: Patch Fix PR35013, PR27192

On the face of it this sounds like a good idea, and is simple -- enough so that even I understand what you are trying to do and I don't know the internals of GCC. This may be a dumb question... Is this going to have any impact on PROGMEM variables, or any other calculations done with pointers

Re: [avr-gcc-list] Re: Patch Fix PR35013, PR27192

Andy H wrote: To fix is not simple. The following are ideas only - please add some more 2) We could avoid using gs() and get function address as byte address + byte offset. This would require extra run-time code for function pointer calls (to divide by two). It is useful in that same poi

Re: [avr-gcc-list] [Bug target/35634] New: [avr] result of char promotion comes out of CHAR_MIN/MAX

Dmitry K. wrote: Now I can not understand, why the Standart permits 'undefined behavior' with ordinary overflow, Well, checking for integer overflow can cause a lot of code to be generated on some architectures. That becomes both a space and performance issue. In general, the C standard

Re: [avr-gcc-list] 32m1/c1 64m1/c1 status?

Weddington, Eric wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Dave N6NZ Sent: Saturday, March 01, 2008 10:50 AM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] 32m1/c1 64m1/c1 status? One can presume that those with NDA access

[avr-gcc-list] 32m1/c1 64m1/c1 status?

One can presume that those with NDA access have been getting the avr-gcc tool chain patches ready for the 32m1/c1 64m1/c1 parts that were recently announced. When the day comes that I can get my hands on some real silicon, is everything going to be ready to go, or are there some pieces that wo

Re: [avr-gcc-list] Makefiles, $(AS) $(ASFLAGS) - simple-minded question

Anton Erasmus wrote: On 23 Feb 2008 at 23:12, Dave N6NZ wrote: Anton Erasmus wrote: Normally .S (Upper case S) should be processed by avr-gcc and not by avr-as. .S files are first pre-processed by the normal C processor. I see that now from some other documentation that I found. avr-gcc

Re: [avr-gcc-list] Makefiles, $(AS) $(ASFLAGS) - simple-minded question

Anton Erasmus wrote: Normally .S (Upper case S) should be processed by avr-gcc and not by avr-as. .S files are first pre-processed by the normal C processor. I see that now from some other documentation that I found. avr-gcc have no concept of $(ASFLAGS) or any other make definition. Not q

[avr-gcc-list] Makefiles, $(AS) $(ASFLAGS) - simple-minded question

I'm working on a new generic Makefile for my projects, and am contemplating the most sensible way to define .S handling. The first thought that popped to mind is: (lots of unrelated stuff omitted) AS = avr-as ASFLAGS = -mmcu=$(MCU) %o: %.S $(HEADERS) $(AS) $(ASFLAGS) -o $@ $< (All untes

Re: [avr-gcc-list] testsuite saga continues

Wouter van Gulik wrote: Yes this is exactly what I wanted to point out. The carry is now only used in handwritten assembler (in avr.md). GCC's RTL does not know anything about the carry bit being available when it's set/cleared and when it's clobbered. Is there some limitation in the RTL t

Re: [avr-gcc-list] accessing carry bit

John Regehr wrote: microcontroller compilers support - the ability to write things like "if (CARRY) ..." can be a big win for some code. A killer app for exposing some of the condition code flags to C may be that this facilitates very efficient integer over/under flow detection. Integer ove

Re: AVR Benchmark Test Suite [was: RE: [avr-gcc-list] GCC-AVR Register optimisations]

Weddington, Eric wrote: Hi John, Dave, others, Here are some random thoughts about a benchmark test suite: - GCC has a page on benchmarks: However all of those are geared towards larger processors and host systems. There is a link to a benchmark that focuses

Re: [avr-gcc-list] Tip: handling volatile operands

Dave Hansen wrote: switch (ioport) { case 1: ... case 2: ... case 99: ... } This is (IMHO) a closer abstraction of what you actually want done. But there is no general guarantee that the compiler won't turn a switch into an if..then..else if... chain. It would be an

Re: [Fwd: Re: [avr-gcc-list] GCC-AVR Register optimisations]

Andrew Hutchinson wrote: For speed/size I was think we need to have sanity checks as gcc versions have been known to suddenly dump a bunch of unexpected data in the middle of a linked program. Of course all the functional tests still give correct results and all looks good! Yup. A commo

Re: [Fwd: Re: [avr-gcc-list] GCC-AVR Register optimisations]

was a shotgun blast of issues completely devoid of specifics :) :) Andy -dave Dave N6NZ wrote: Well, after spamming the wrong list with this, I hope I've got the right place now :( -dave Subject: Re: [avr-gcc-l

[Fwd: Re: [avr-gcc-list] GCC-AVR Register optimisations]

Well, after spamming the wrong list with this, I hope I've got the right place now :( -dave --- Begin Message --- Weddington, Eric wrote: - I, and others, are very interested in what you are using to test your proposed changes. I have plans to put together an AVR Benchmark Suite, consisting o

Re: [avr-gcc-list] GCC-AVR Register optimisations

Andrew Hutchinson wrote: Hi all, just spend some days going over gcc-avr and missed optimizations. Which is a huge bunch of work! Thanks! The result is a 1.25% saving in code size for a simple mixed application. Pretty good for such a simple change! Very good! What test cases were you

Re: [avr-gcc-list] rjmp to an absolute address

Well, I should think that you could pick up the symbol for the beginning of the text section that is already defined in the default linker script, whatever that is :) I'm sure somebody here knows what that is off the top of their head. Or it shouldn't take much research to find it. -dave S

[avr-gcc-list] OS X install

OK, a FAQ, I know. I need to install the avr-gcc tool chain on a MacBook, OS X. Can someone please give me a pointer to the current best-known-method for getting the most up-to-date tool chain on a Mac? Thanks, Dave ___ AVR-GCC-list mailing li

Re: [avr-gcc-list] USB

Joerg Wunsch wrote: "Shashank Chintalagiri" <[EMAIL PROTECTED]> wrote: Does anyone know of any chip that will let me interface with USB devices from an ATmega, that is available in DIP packages? I've never seen one. Many amateurs have been soldering things like FTDIs or PDIUSBs before

Re: [avr-gcc-list] Warning message

Royce Pereira wrote: Hi all, What does the following warning mean? warning: comparison is always true due to limited range of data type Here is the context: I have a AVR I'm trying to connect to a DS1307 RTC chip via TWI. To check the integrity of the DS1307 internal ram, I plan to write 4

Re: [avr-gcc-list] RE: confirm 70e8cedc7c9b034344df26628372e8690f48d513

This may be a Vector issue... IIRC my build on Slack 11 when smoothly been a while though. -dave Rory Galvin wrote: hi Folks, Sorry for not getting back sooner. (Memory Slot A on my laptop died, then yahoo cancelled my webmail account for reasons as yet unclear. grrr) Well, Francesco was

Re: [avr-gcc-list] scanf and __fmt string

Second link in google for 'scanf': http://en.wikipedia.org/wiki/Scanf But... if my experience is a guide, you will be sorry you ever heard of scanf. It's not a very robust way to parse input. -dave Roger Furer wrote: Aloha from Honolulu, I'm trying to use scanf in a program and reading ab

Re: [avr-gcc-list] AVR Studio and Hardware: results don't match. Any clue?

did you double check your clock fuses? Perhaps the processor is not running at the frequency that you expect. -dave Leonardo B. Oliveira wrote: Hello everyone, I've measured running time for a program in AVR Studio and also in MICAz sensor node. MICAz is featured w/ the ATmega128 microcontr