Re: [avr-gcc-list] Trick for creating WYSIWYG bitmaps in C [was: how to specifiy a binary constant]

I thought I'd try this bitmap 'trick' via copy&paste of the #defines and code into the file I was working on, this is what I get: Name/name.c:692: error: `sXX__' undeclared here (not in a function) Name/name.c:692: error: initializer element is not constant Name/name.c:692: error: (near init

Re: [avr-gcc-list] CVS or SVN ?!

> I have been advised to use CVS when developing programs, but it seems > awkward to set up the server side. While asking around for help, I have > been suggested to give up CVS and use SVN, "subversion", Here is a comparison of seventeen different version control systems: http://better-scm.berl

Re: [avr-gcc-list] CVS or SVN ?!

On Friday 30 September 2005 04:45 am, Vincent Trouilliez wrote: > I have been advised to use CVS when developing programs, but it seems > awkward to set up the server side. While asking around for help, I have > been suggested to give up CVS and use SVN, "subversion", Here is a comparison of seve

[avr-gcc-list] Special Statistics-Measuring code?

Is it possible to do this with AVR-GCC?: "The project team used a GNU-C compiler to build special statistics-measuring code into the binary executables. A program built with profiling support generates a gmon.out file that contains statistics it gathers while the program is running. The gpr

[avr-gcc-list] How to rebuild AVR-GCC for Windows?

I want to build GCC 3.4.4/Binutils 2.16.1/AVR-LIBC 1.4 as I need to use the Tiny2313, Mega164, and Mega325. Building all of these would be no problem for me on my Linux box at home. Alas the power's-that-be here at work won't let me use Linux; "We are a windows shop here" I was told. :-( At any

Re: [avr-gcc-list] How to rebuild AVR-GCC for Windows?

On Mon, 05 Dec 2005 14:13:48 -0500, Eric Weddington <[EMAIL PROTECTED]> wrote: Bob Paddock wrote: I want to build GCC 3.4.4/Binutils 2.16.1/AVR-LIBC 1.4 as I need to use the Tiny2313, Mega164, and Mega325. Building all of these would be no problem for me on my Linux box at home. Al

Re: [avr-gcc-list] How to rebuild AVR-GCC for Windows?

On Mon, 05 Dec 2005 18:20:59 -0500, Joerg Wunsch <[EMAIL PROTECTED]> wrote: "Bob Paddock" <[EMAIL PROTECTED]> wrote: ... The motivation at the moment is that the Boss wants to start using GCC on his new Mega164 project, so it would be a Good Thing to have a Mega16

Re: [avr-gcc-list] How to rebuild AVR-GCC for Windows?

On Tue, 06 Dec 2005 00:46:18 -0500, Uwe Fechner <[EMAIL PROTECTED]> wrote: I want to build GCC 3.4.4/Binutils 2.16.1/AVR-LIBC 1.4 as I need to use the Tiny2313, Mega164, and Mega325. You could try: http://www.atmanecl.net/EnglishSite/indexEnglish.htm http://www.avrfreaks.org/index.php?name

Re: [avr-gcc-list] How to rebuild AVR-GCC for Windows?

On Tue, 06 Dec 2005 01:47:51 -0500, Erik Christiansen <[EMAIL PROTECTED]> wrote: Have you considered running the windows machine, as asked, but a linux box as well? Been down that road. I had my personal Linux laptop under the desk, that I ran with TightVNC http://www.tightvnc.com/ to do PC

[avr-gcc-list] LIBC 1.2.6 vs 1.4.0 header files, FLASH and EEPROM

AVR-LIBC 1.4.0 has added a couple of new defines for EEPROM and FLASH. Both that I had defined in my own code, leading to redefinition warnings. Here is a code snippet that lets you work around this type of issue. By checking the GCC version you can load the appropriate header files(s) from th

Re: [avr-gcc-list] LIBC 1.2.6 vs 1.4.0 header files, FLASH and EEPROM

On Tue, 06 Dec 2005 14:37:53 -0500, Joerg Wunsch <[EMAIL PROTECTED]> wrote: Why not test for #if __AVR_LIBC_VERSION__ < 10400UL put old code here #endif Any C preprocessor macro that hasn't been defined but is used in a preprocessor expression as shown above automatically evaluates to 0, s

Re: [avr-gcc-list] Cygwin NTFS hard links?

NTFS has always had support for hard links, but Windows has no tools for using them Use 'Junction' to create such links. http://www.sysinternals.com/Utilities/Junction.html I use it with WinAVR to maintain different versions of the compiler. My setup.bat files all point to C:\WinAVR, but if

Re: [avr-gcc-list] (no subject)

You want something more like this: #ifndef _GLOBAL_H_ #define _GLOBAL_H_ (1) #ifdef DEFINE_SPACE_GLOBAL_H #define EXTERN_GLOBAL #else #define EXTERN_GLOBAL extern #endif #if defined(__cplusplus) && __cplusplus extern "C" { #endif EXTERN_GLOBAL u08 RX485_oldbyte3, RX485_oldbyte2, RX485_oldby

Re: [avr-gcc-list] Re: ATmega168 FreeRTOS code

On Wed, 05 Apr 2006 19:24:50 -0400, Uwe Fechner <[EMAIL PROTECTED]> wrote: Just for grins, the internal RC isn't all that stable over temperature Well, this would not be good for my concept reducing power supply current. Micro Crystal Switzerland's Real Time Clock chips generate a 32,768 H

[avr-gcc-list] _delay_us pulling in floating point lib?

I was working toward some precision delays that I needed. I was starting with this function: #include #include "util/delay.h" inline void delay_us( uint8_t delay_u8 ) { uint8_t irq_state_u8 = SREG; __disable_interrupt(); /* Macro to cli */ _delay_us( (double) delay_u8 ); /* Also tried wi

Re: [avr-gcc-list] _delay_us pulling in floating point lib

On Wed, 16 Aug 2006 13:37:11 -0400, Björn Haase <[EMAIL PROTECTED]> wrote: The problem is that the list files shows that floating point library is being used, when comments in delay.h say that should not happen. I realized my mistake about five seconds after hitting "Send". I was passing a v

[avr-gcc-list] Installing WinAVR 20070122 broke older 3.4.5 install?

I installed WinAVR 20070122, into the directory G:\WINAVR411, but now I find that my older 3.4.5 based code will not compile, with the 3.4.5 compiler. I get the error "can't find CC1", even tho cc1.exe is where it has been along in my G:\WinAVR345\libexec\gcc\avr\3.4.5 directory. Path is being

Re: [avr-gcc-list] Installing WinAVR 20070122 broke older 3.4.5 install?

On Wed, 31 Jan 2007 12:16:44 -0500, Eric Weddington <[EMAIL PROTECTED]> wrote: Yes, there are three keys being installed in the registry: HKLM\Software\Free Software Foundation\WinAVR\GCC HKLM\Software\Free Software Foundation\WinAVR\BINUTILS HKLM\Software\Free Software Foundation\WinAVR\G++

Re: [avr-gcc-list] Installing WinAVR 20070122 broke older 3.4.5install?

On Wed, 31 Jan 2007 13:21:59 -0500, Eric Weddington <[EMAIL PROTECTED]> wrote: C:\WinAVR is the "prefix" path that I mentioned, where I install WinAVR when I build it. Yes, it *is* hard-coded into GCC. There's nothing I can do about that. :-/ With GCC all is possible. :-) The solution to

[avr-gcc-list] Wrong excution order in 4.1.1, but not 3.4.5, regression?

I'm seeing something in 4.1.1 that is not making sense. The code produced is clearly the wrong order, in 4.1.1. Code from 3.4.5 is the correct order. Optimization in both cases is set for -Os; I'm using the same source code/Makfile and pointing at different versions of WINAVR, between 4.1.1 an

Re: [avr-gcc-list] Wrong excution order in 4.1.1, but not 3.4.5, regression?

On Monday 19 February 2007 19:34, Eric Weddington wrote: > I can't fully tell what's going on with just the asm snippets you provide. I spent a while trying to get a reproducible version in a few lines, but that kept changing the results. > If you think that this is a GCC bug, then please fill o

Re: [avr-gcc-list] Wrong excution order in 4.1.1, but not 3.4.5, regression?

On Tue, 20 Feb 2007 03:24:49 -0500, David Brown <[EMAIL PROTECTED]> wrote: If you can't post a cut-down version, then at least post a compilable section of your code with the minimal necessary typedef's and other definitions included. To be able to test your code, people will have to be

Re: [avr-gcc-list] Wrong excution order in 4.1.1, but not 3.4.5, regression?

I wrote a lengthy reply from work this morning, but it has never shown up on the list. > When the code is re-written to actually say what you mean, do you still > get a difference? Saying: a_volatile = b_volatile = c; produced exactly the same object code as: b_volatile = c; a_volatile = b

Re: [avr-gcc-list] gcc-avr/avr-libc wiki

On Thu, 01 Mar 2007 16:09:42 -0500, Joerg Wunsch <[EMAIL PROTECTED]> wrote: So you are never supposed to write "it's" there, but always "it is". This also avoids the common misspelling of "its" as "it's" which interestingly native speakers are more often a victim of than foreigners. "The Ap

[avr-gcc-list] Should this code work? 4.1.1

In what many or may not be a continuation of my problems with out-of-order code execution, with 4.1.1, I'd like to know why this code does not work (comments below the code): /* Code for AT90CAN64. */ #include #include void SPI_MasterInit(void); void SPI_MasterInit(void) { /* Enable SPI, M

Re: [avr-gcc-list] Should this code work? 4.1.1

On Friday 02 March 2007 18:42, Francesco Sacchi wrote: > Bob Paddock ha scritto: > > you see that the last rjmp is jumping to the point where shift > > is reinitialized with '1' (r18/r19). > > > > Moving 'uint16_t shift = 1;' out of the for(;;){}

Re: [avr-gcc-list] Should this code work? 4.1.1

On Friday 02 March 2007 21:29, Graham Davies wrote: > Bob Paddock wrote: > < for(;;){} is a endless loop, how is "until execution of that > > block ends in any way." being fulfilled here? > > The block begins with the open brace and ends with the close brace. The

Re: [avr-gcc-list] Should this code work? 4.1.1

On Sunday 04 March 2007 14:21, Gavin Jackson wrote: > Another thing you may want to take a look at is the SPIF > flag on page 174 of the datasheet. It states that: > >From what the datasheet says, your SPIF bit is never cleared > so you'll be overwriting the SPI data register contents before > the

Re: [avr-gcc-list] Endless loop: uchar c; for (c=1; c; c++)

On Tue, 06 Mar 2007 23:12:16 -0500, Dmitry K. <[EMAIL PROTECTED]> wrote: On Wednesday 07 March 2007 13:18, Eric Weddington wrote: Are you use non-pure avr-gcc 4.1.1 ? Below is from the stock WinAVR-20070122 edition, compiled for the CAN64. Going back to your original code, I had to ad

Re: [avr-gcc-list] Endless loop: uchar c; for (c=1; c; c++)

On Tue, 06 Mar 2007 21:31:09 -0500, Dmitry K. <[EMAIL PROTECTED]> wrote: My results for 3.4.5 and 4.1.1 for the follow program, below: Program: ~~~ /* This program is compiled as endless loop: condition `c1 != 0' is not tested. In original (real) program there was an another error

Re: [avr-gcc-list] AVRDude serial access problem under WinXP

On Tue, 20 Mar 2007 18:37:37 -0400, Vrudny, Noah O <[EMAIL PROTECTED]> wrote: AVRDude punts and returns an error "ser_open():failed Access Denied" ... avrdude -p atmega128 -P com2 -c stk500 -U flash:w:test_led.hex I get the "Access Denied" error on my machine as well, if I have the newer s

Re: [avr-gcc-list] Embedding CRC into hex file

On Tue, 27 Mar 2007 11:22:13 -0400, larry barello <[EMAIL PROTECTED]> wrote: Does anyone have the AVR equivalent routine for one of the CRC16 generated with "srecord" they would share? I would like to modify my boot loader to check the application code before running so corrupted downloads

Re: [avr-gcc-list] Embedding CRC into hex file

On Tue, 27 Mar 2007 14:34:27 -0400, larry barello <[EMAIL PROTECTED]> wrote: Srec_cat has CCITT 16 built in. What stopping you? How do you initialize it with all ones? Last I looked it was initialized with all zeros, and I did not see away to initialize it otherwise. If you initialize wit

Re: [avr-gcc-list] New GCC warning - how to silence?

On Sunday 08 April 2007 05:38, Francesco Sacchi wrote: > I made a simple test, I took a large ATMega64 project and recompiled > with -funsigned-char and -fshort-enums. > > The code shrinks only about 200 bytes on an a total size of 59800. > This is only a 0.33% gain. It doesn't definitely worth

Re: [avr-gcc-list] AVR ADC

On Thursday 12 April 2007 22:47, andi wrote: > I want to use ADC in AVR Atmega8 and using the 2.56V internal voltage for > the reference. > It said in datasheet we have to decouple the AREF pin with capacitor, but it > didn't said the value. > Does anyone know the value ? 0.1uF works. Make s

Re: [avr-gcc-list] AVR ADC

On Fri, 13 Apr 2007 12:49:30 -0400, Galen Seitz <[EMAIL PROTECTED]> wrote: Just curious, why didn't you measure the reference and stick a calibration factor in EEPROM? Labor costs of doing that when you are dealing with lots of units, in this case hardware was a cheaper system solution. _

[avr-gcc-list] Read wrong value from array of structures in Flash in 4.1.1?

/* Am I doing something here that is stupidly obvious that I keep overlooking or is this a big in GCC 4.1.1, for the AT90SCAN64? The idea here is to have a table of constants so I can reprogram the CLKPR register on the fly to save power. Values like the baud rate and timer rates need to be cha

Re: [avr-gcc-list] avr-gcc toolchain problem on x86-64 system

On Thursday 07 June 2007 01:07, Joerg Wunsch wrote: > > crossdev --target avr > It used to have well-maintained once by the time Henrik Brix Andersen > was in charge of maintaining them. > Does Gentoo no longer have portage compilations for the AVR toolchain? avr-libc is maintained, as far as I

[avr-gcc-list] I do not understand the parameters to strcpy_P in .LSS File?

I have this program: /* Start Example */ #include /* strcpy_P() */ unsigned char buffer[256]; int main( void ) { (void) strcpy_P( (char *) buffer, "Clock Not Set" ); } /* End Example */ That is producing the .lss and .hex files below. I do not understand why r23/r22 is being loaded with t

[avr-gcc-list] What is the proper cast for reading a table of pointers to functions from Flash?

I'm moving some code from 3.4.5 to 4.1.2 and I'm getting a warning now that I can't figure out the right way of removing. This was happy in 3.4.5: state_function_ptr = (void *) pgm_read_word( &menu_state[current_state_u8].FunctionPointer ); Now generates this warning in 4.1.2: "ISO C forb

Re: [avr-gcc-list] Example programs missing in WinAVR 20070525

On Wednesday 19 September 2007 03:42:31 pm Joerg Wunsch wrote: > If Windows had symlinks, he could place a link between both > locations... XP, and presumably Vista, does have symbolic links, they are called 'Junctions Points'. http://en.wikipedia.org/wiki/NTFS_junction_point --

Re: [avr-gcc-list] Problem with delay loop

On Monday 01 October 2007 09:48:23 am Eric Weddington wrote: > Its an interesting question. I'm not sure what the answer is. Perhaps a > language lawyer on comp.lang.c could explain the reasoning behind the > current standard. http://thread.gmane.org/gmane.linux.kernel/523210 for the Linux view o

Re: [avr-gcc-list] avr-gcc-4 TinyOs

On Monday 15 October 2007 10:57:17 pm Ned Konz wrote: > Like many projects that wanted to extend the C (or C++) language, they > started with GCC. > > They added interface wiring, native state machine constructs, and > probably other things that I don't recall. If you are interested in State Mach

[avr-gcc-list] Paste structure tokens with the preprocessor ##?

Is it valid to paste structure tokens with the preprocessor ## operator? I get one of two errors, depending on if I do "X.##M" or "X##M": 'error: pasting "." and "Accel_mo_setting_x_u16" does not give a valid preprocessing token.' What happend to the text before the dot? or 'EE_PROM' has no m

Re: [avr-gcc-list] Paste structure tokens with the preprocessor ##?

On Thu, 08 Nov 2007 14:23:27 -0500, Joerg Wunsch <[EMAIL PROTECTED]> wrote: Is it valid to paste structure tokens with the preprocessor ## operator? That's not the purpose of that operator. The solution turns out to be just don't use the ## operator at all, and I got the effect that I want

Re: [avr-gcc-list] examples on how to create and use a dynamic array in the EEPROM

On Fri, 16 Nov 2007 04:30:21 -0500, Oven Senmeis <[EMAIL PROTECTED]> wrote: Hello, Would you please give me an example on how to create and use a dynamic array in the EEPROM of AT90CAN128? As far as I know, it’s not possible to use functions like malloc() to allocate space for pointers beca

Re: [avr-gcc-list] Bug35013 - Incomplete check for pm() annotation

On Saturday 16 February 2008 04:47:06 pm Andrew Hutchinson wrote: > Unfortunately it is only linker WARNING and easily missed during > compilation. # -Werror : Make all warnings into errors. CFLAGS += -Werror # -pedantic : Issue all the mandatory diagnostics listed in the C # standard. Some of

[avr-gcc-list] What has changed between WinAVR 20070525rc2 and WinAVR 20080430?

Can anyone tell me what has changed from: avr-gcc (GCC) 4.1.2 (WinAVR 20070525rc2) to?: avr-gcc (WinAVR 20080430) 4.3.0 I recompiled code for a working product using 4.1.2 with 4.3.0 and it no longer works correctly. Fairly complex product so trying to localize the problem would not be all tha

Re: [avr-gcc-list] What has changed between WinAVR 20070525rc2 andWinAVR 20080430?

On Monday 12 May 2008 04:49:33 pm Anatoly Sokolov wrote: > avr-gcc 4.3 don't save all call-used registers in interrupt handler > routine if it do function call, but should. It is in you ISR is function > calls? I'll check the code when I get back to work in the morning, but it should not be call

Re: [avr-gcc-list] What has changed between WinAVR 20070525rc2 andWinAVR 20080430?

On Monday 12 May 2008 04:50:56 pm Stu Bell wrote: > Umm, describe "no longer works correctly". Ok, but don't know that it will help, as it doesn't really help me any even with the unit in my hand. :-) This unit is a type of Panic Alarm. It has a big "Alarm" button on the top of it. The Alarm

Re: [avr-gcc-list] What has changed between WinAVR 20070525rc2 andWinAVR 20080430?

On Monday 12 May 2008 08:13:31 pm Steven Michalske wrote: > a bit off topic, but a bed of nails works great for not having to > have a connector for jtag and allows for ICT in assembly on plain ole > test point pads. The JTAG port in this case is six 18 mil holes on a similar grid spacing, the "

Re: [avr-gcc-list] What has changed between WinAVR 20070525rc2andWinAVR 20080430?

> > FYI, I just released WinAVR 20080512 that contains a patch from Anatoly > that fixes this problem. Code is now running fine with that version. Thank you. I'll have to find the function call I put in the IRQ and didn't mean to... BTW for the next release it might be nice if all of these were

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

> > > Indeed, the compiler spit out a warning on the non-'static' > case: > > main.c: In function 'test': > main.c:294:warning: '__progmem__' attribute ignored > > which whipped by and I missed it before. Add this to your Makefile to enforce a "No Warnings Allowed" policy: # -Werror : Make all w

Re: [avr-gcc-list] What has changed between WinAVR 20070525rc2andWinAVR 20080430?

On 5/13/08, Preston Wilson <[EMAIL PROTECTED]> wrote: > "Bob Paddock" wrote: > >> > >> FYI, I just released WinAVR 20080512 that contains a patch from Anatoly > >> that fixes this problem. > > The other item you noted was code size increase,

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

On 5/13/08, Marc Wetzel <[EMAIL PROTECTED]> wrote: > Bob Paddock schrieb: > Which compiler are you guys using? At which moment? :-) I've been compiling code with avr-gcc 4.1.2 for a CAN64, and a Mega645 with 4.3.0/20080430 and 4.3.0/20080512, while helping a colleague with his

Re: [avr-gcc-list] __checksum

> I have been successfully porting the old code from IAR to AVR GCC except for > the followings: > extern flash unsigned short __checksum; If your 'checksum' is the last thing after your program, the equivalent in avr-gcc is __data_log_end[1]. You appear to be trying to do the same as this code:

Re: [avr-gcc-list] __checksum

> Would seem IAR automatically buries a __checksum in the code > image but avr-gcc does not. The equivalent in avr-gcc is __data_log_end[1], see the code I just posted. The one possible difference is that __checksum is purely the code, .text in avr-gcc, where __data_log_end[1] is .text+.data. _

Re: [avr-gcc-list] What has changed between WinAVR 20070525rc2andWinAVR 20080430?

On Tuesday 13 May 2008 02:36:29 pm Bob Paddock wrote: > > Anatoly Sokolov suggested, in another thread or two on the avr-gcc list, > > using the gcc option "--param inline-call-cost=N" > > Where N is between 1 and 7 > > > > I found that for the one project

Re: [avr-gcc-list] Re: "progmem_far" attribute

On 7/20/08, Andy H <[EMAIL PROTECTED]> wrote: > If we can create "FAR" as unsigned long Should that not be size_t rather than unsigned long? Might not make a difference on the smaller AVR's right now but if we ever need to port the code to a future AVR64 it might. -- http://www.wearablesmarts

Re: [avr-gcc-list] Can someone benchmark this option please

On 7/22/08, Andy H <[EMAIL PROTECTED]> wrote: > I have noted problem where gcc is optimizing if-then-else constructs - with > disastrous results. I inherited a lot of code from the Boss with big if-then-else trees: > Can folks try the following gcc option > > -fno-if-conversion I find no change

Re: [avr-gcc-list] Newbie questions about Procyon AVRlib

On Sun, Sep 28, 2008 at 10:55 AM, Gary French <[EMAIL PROTECTED]> wrote: > a copy is available at: > http://chromiteblue.com/Projects/AVR/avrlib-2006-10-29.zip > (with some random AVR info at the TLD) You have the latest version of PonyProg there as well. Do you know if the issue of the Tiny2313

Re: [avr-gcc-list] Strange issues with 16-bit values

> while(TCNT3<(uint16_t)benc_period*224UL/255); One can never have to many parenthesise when writing something like the above. I did not look at your code so the following may not be relevant. If you are having issues with 16-bit register values, make sure that you are not accessing the same tim

[avr-gcc-list] eeprom.h error: cast from 'const uint8_t*' to 'uint8_t' loses precision in c++

I was starting a new project and wanted to do it in C++, mostly to get the better type checking. I'm aware of the C++ caveats in the FAQ/Manual. However I did not get very far before I ran into an error: g:/winavr-20081205/lib/gcc/../../avr/include/avr/eeprom.h: In function 'uint8_t eeprom_read

Re: [avr-gcc-list] eeprom.h error: cast from 'const uint8_t*' to 'uint8_t' loses precision in c++

> Curious, if you replace that by a cast to uint16_t (which then gets > assigned to a uint8_t register), will it still complain? EEARL = (uint16_t)__p; and EEARL = (uint8_t) (uint16_t)__p; both work without error. ___ AVR-GCC-list mailing li

Re: [avr-gcc-list] Add 'OS_main' and 'OS_task' attributes in avr-gcc 4.2.1

On Mon, Jul 23, 2007 at 2:48 PM, Anatoly Sokolov <[EMAIL PROTECTED]> wrote: > This patch add "OS_main" and 'OS_task' attributes in GCC 4.2.1. Function with > "OS_main" and 'OS_task' attributes do not save any "call-saved" registers. I had hoped that using OS_main would get rid of the call to main

Re: [avr-gcc-list] Most reliable version of avr-gcc?

On Wed, Dec 17, 2008 at 6:37 PM, David Carr wrote: > By reliability, I mean least probability of undetected errors in machine > code generation. IE: The machine code conforms to the source code. "How to verify your compiler for use in IEC 61508 safety-critical applications; A step-by-step guid

Re: [avr-gcc-list] address@hidden ... what is it for ?!

> Older AVRs had the problem, if a the voltage dropped under the limit > during a eeprom write, adr 0 was corrupted as well as the one written. > > But current AVRs -- at least with the brown out detector enabled -- does > not show this bug anymore... If you look at the EEPROM Address Register in

[avr-gcc-list] Tiny88 C++ code optimized out of existence?

I'm trying to bring up a new board that uses a Tiny88. I'm compiling the code as C++ code, using WinAVR 20081205/4.3.2, using -Os. Makefile was produced by MFile. This is the test program, main.cpp: = #if defined(__cplusplus) && __cplusplus extern "C" { #endif #include #include

Re: [avr-gcc-list] Tiny88 C++ code optimized out of existence?

>> for(;;) >> { >> uint8_t byte_u8 = LED2H; // Start LED > > You're initializing the variable inside the loop. I knew I was overlooking the obvious. Thanks. Still not sure why I was getting the warning about byte_u8 not being used, when it was not in the loop, which is how it got in

Re: [avr-gcc-list] Tiny88 C++ code optimized out of existence?

>> Still not sure why I was getting the warning about byte_u8 >> not being used, when it was not in the loop, which >> is how it got in there in the first place, trying to figure >> out where the warning was coming from. >> >> I deleted the .dep directory and OBJs then recompiled, and it went >> aw

[avr-gcc-list] How do we link a IAR Touch Library with GCC?

http://www.atmel.com/products/touch/touchswlib.asp "Atmel Touch Library is a royalty free software library (IAR) for developing touch applications on standard Atmel AVR microcontrollers. Customers can link the library into their firmware in order to provide touch sensing capability to their projec

Re: [avr-gcc-list] How do we link a IAR Touch Library with GCC?

>> http://www.atmel.com/products/touch/touchswlib.asp >> How do we link a IAR binary library with GCC? > You don't. You request a GCC version of the library. There is zero mention of GCC in anything I've seen. Where did I miss it? More importantly where do I file said request?

Re: [avr-gcc-list] How do we link a IAR Touch Library with GCC?

>> There is zero mention of GCC in anything I've seen. > > That doesn't mean it doesn't (or won't) exist. > >> Where did I miss it? More importantly where do I file said >> request? > > Try sending a request to avr AT atmel DOT com. Request sent on: Tue, Jan 27, 2009 at 8:50 AM Response re

[avr-gcc-list] Tiny88 __data_load_end stuck at 256?

I have code that calculates the CRC of Flash at power up, that works fine on the AT90CAN64 part. When I move the CRC function to the Tiny88 it does not work. To me it looks like in the generated code _data_load_end is stuck at 0x0100 (256), but the map and symbol file show reasonable values: proj

[avr-gcc-list] Re: Tiny88 __data_load_end stuck at 256?

On Thu, Feb 5, 2009 at 2:30 PM, Bob Paddock wrote: > I have code that calculates the CRC of Flash at power up, that works > fine on the AT90CAN64 part. > When I move the CRC function to the Tiny88 it does not work. > What is going on here? > > This is with avr-gcc (WinA

[avr-gcc-list] Meaning of "relocation truncated to fit: R_AVR_13_PCREL"?

What does this error mean?: g:/winavr~4/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr25/crttn88.o:(.init9+0x2): relocation truncated to fit: R_AVR_13_PCREL against symbol `exit' defined in .fini9 section in g:/winavr~4/bin/../lib/gcc/avr/4.3.2 \ /avr25\libgcc.a(_exit.o) make[1]: *** [LT_A.elf]

Re: [avr-gcc-list] Re: Newbie question

>> Also enable compiler warnings - at a minimum, use these flags: >> >>        -Wall -Wextra -Wunreachable-code >> >> Then the compiler would have told you of your error here. I always run with the warnings maxed out, due to a "No Warning" policy. However I did have to turn unreachable-code off.

Re: [avr-gcc-list] Re: [patch #6004] "main-as-normal" patches for GCC

> The OS_main and OS_task attributes are mainly used for RTOSes, for the > main() function and task functions respectively. However, OS_main can be > useful in an application's main() function that does not have an RTOS, > as it will reduce the code size slightly. Is there any workable combination

Re: [avr-gcc-list] Newbie question (Solved)

>   Raw_Data[0][Raw_Data_In_Index] = 0xAA; >   Raw_Data[0][Raw_Data_In_Index++] = 0x55; Should the last one be Raw_Data[1]...? -- http://www.wearablesmartsensors.com/ http://www.softwaresafety.net/ http://www.designer-iii.com/ http://www.unusualresearch.com/ _

Re: [avr-gcc-list] Re: C vs. assembly performance

>  In practice, the experienced programmer can do a lot to help > the tools. avr-gcc *does* do a good job with most code - I do > much less re-structuring of my source code for avr-gcc than I do > for most other compilers (I use a lot of compilers for a lot of >different > targets). Something I a

Re: [avr-gcc-list] Re: C vs. assembly performance

> And the first complies with coding standards like gnu and gcc, > and maybe even others like misra etc. MISRA doesn't say a lot about style, that is how pretty the code looks. It is implicit that ugly looking code is bad, and probably buggy. If your code looks like a IOCCC entry, your code woul

Re: [avr-gcc-list] Re: C vs. assembly performance

>> Note that technically no AVR-LibC based project complies >> with MISRA due to rule #3.6 that says any library used, >> including the GCC libraries, must be complaint with MISRA [IEC 61508 >> Part 3].  I tend to follow the MISRA Guidelines anyway as it shows an >> attempt at Due Diligence. > s/c

Re: [avr-gcc-list] Re: C vs. assembly performance

>> Would be nice.  There are probably legal issues with doing that. >> MISRA is one of those things you must buy.  There are not Open >>Source >> versions, as MISRA does not allow the distribution of the >> rules without proper licensing. > > I wasn't aware of that. How disgusting. Yes. Standards

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

Many of the newer AVRs, Tiny88 for example, let you dynamically change the CPU clock frequency. However the AVR-LibC based delays always assume a fixed frequency based on F_CPU. I'll always know what frequency I'm at when I call a delay() function. Is there a way of doing: _delay_us( double __

Re: [avr-gcc-list] WinAVR Release Candidate

> WinAVR Release Candidate 20090306rc1 is now available. I'm watching the install unpack. Why is H8, 68HC11, V850 stuff being installed? -- http://www.wearablesmartsensors.com/ http://www.softwaresafety.net/ http://www.designer-iii.com/ http://www.unusualresearch.com/ __

Re: [avr-gcc-list] WinAVR Release Candidate

>> > WinAVR Release Candidate 20090306rc1 is now available. >> >> I'm watching the install unpack.  Why is H8, 68HC11, V850 stuff >> being installed? > > Could you explain what you mean here? When you run the setup.exe you can watch what it is unpacking. It was listing many non-AVR devices. Now t

Re: [avr-gcc-list] WinAVR Release Candidate

> WinAVR Release Candidate 20090306rc1 is now available. > > > > Please test and report any feedback, good or bad. My Tiny88 code links now, will test on real hardware first thing Monday morning. Thank you. This bug appears to be fixe

Re: [avr-gcc-list] build srecord under mingw

> It isn't done. WinAVR ships with SRecord 1.38 because that is the last > version that did >not require the Boost libraries. Like you, I did not see a > Boost package for MinGW. There is no package. Build from the boost instructions. Goto the Boost Download site linked from http://www.boost.o

Re: [avr-gcc-list] build srecord under mingw

> Get the PDF documentation for Boost if you want them.  The link to them > is hiding in the lower left corner of the download page in the 'news' section. Lower right corner. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org

Re: [avr-gcc-list] Re: build srecord under mingw

ter section years ago. Any reason you prefer it; I'm guessing speed? > P/S: the boost stuff seems pretty huge It is 184 megs of source code. Takes well over 1G when it is all built. > There is another thread on this list about srecord and boost. I'm working > with Bob >Pad

Re: [avr-gcc-list] Re: build srecord under mingw

>>> using the -mno-cygwin >> >> Note that no-cygwin has been removed in current Cygwin installs.  It tells >> you to use MingW when you try to use no-cygwin. > > My cygwin installation seems up to to date. Updated when I installed the > boost pkgs. You have to do a fresh install to lose the no-cygw

Re: [avr-gcc-list] Re: build srecord under mingw

>> I'll try building srecord after all the compiling is done. > > They could be wrong on this but looking over on the minGW list someone said > that "most" apps don't actually need a full build of boost, they just need > the header files included. > > All srecord configure does is check for existen

Re: [avr-gcc-list] Re: Passing a string variable to lcd_puts

On Mon, Mar 30, 2009 at 2:48 PM, David VanHorn wrote: > I thought I must be doing something fairly trivial wrong, this IS > only my second project in C... Dave, I have two recommendations for a beginner at C. 1) Buy yourself a copy of Gimpel Lint, even if you have to pay for it out of your own p

Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling

> I am relatively new, not only to Atmel but also to Embedded system. > typedef struct eventdata >        {       uint8_t unit_add; >                uint8_t card_add; >                uint8_t event_no;               //Event counter >                uint8_t type;           //Event type >          

Re: [avr-gcc-list] regression in size from 4.2.2 to 4.5.0

>> 1) -no-inline-small-function    - 69034 >> 2) --param inline-call-cost=2   - 68964 >> 3) -fno-inline                  - 68816 >> 4) -finline-limit=10            - 68810 >> 5) #2 & #4                      - 68754 6) -finline-limit=3             - >> 68754 (same results for 1,2 and 3) > > I found

Re: [avr-gcc-list] regression in size from 4.2.2 to 4.5.0

>> Is there any way to apply the switches on a per source file basis? > > Yes, it's called "using a Makefile". ;-) Eric, my Makefile builds four concurrent models, in to separate object trees from a single source set, applies configuration parameters to each model, serializes each build, CRC's the

Re: [avr-gcc-list] Re: issues with struct and volatile

On Fri, Jul 24, 2009 at 3:59 AM, David Brown wrote: > The principle is right, the details are wrong. You want: > >uint8_t * volatile tx_tail; > > These things are so very easy to get wrong that I always use typedefs: > >typedef uint8_t * pUint8_t; >volatile pUint8_t tx_tai

Re: [avr-gcc-list] including default eeprom values in flash memory

> Ditto. Declare the variables twice, once with a name that is obvious to > you is EEPROM in the EEPROM space, and again with a name that is obvious > to you is stored in FLASH. Then when/if you wish to restore EEPROM > contents to their initial default values use the PGM modifier to read > from FL

Re: [avr-gcc-list] Rounded integral division in preprocessor

On Fri, Feb 5, 2010 at 1:44 AM, Johannes Bauer wrote: > Dear list, > > I'm trying to do rounded (opposed to truncated) integer division with > avr-gcc with using only preprocessor magic. This proves to be difficult: The > current code I'm using is > > #define __IDIV(x, y)    (long)(((long)x + ((lo

Re: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointer manipulation not interrupt safe in XMega

> There are several places that handle SP adjustment: > > avr.c: output_movhi, expand_prologue, expand_epilogue > avr.md: movhi_sp_r_irq_off, movhi_sp_r_irq_on (both generated in > epilogue/prologue) > libgcc.S: __prologue_saves__, __epilogue_restores__ > > For changes in libgcc.S to take effect, a

  1   2   >