Nabble - AVR - gcc

Re: C++ with PSTR

2009-12-06T10:51:01Z

Hi,

On Sun, Dec 6, 2009 at 4:20 AM, darkschine <zhpctw3dash@...> wrote:
>
> This topic is covered all over avr forums in bits and pieces so please keep
> responses to a minimum. The problem is that when using PSTR("String") in a
> cpp file, the compiler generates the warning:
>
> warning: only initialized variables can be placed into program memory area
...snip...

> Does anyone have a proven solution or workaround for this problem? Is there
> anything that can be done to at least suppress the warning without
> suppressing other warnings?

I think I found a way.

I tested this with WinAVR-20080610 (gcc 4.3.0) and with the latest
(WinAVR-20090313 gcc 4.3.2).

My source file, called test.cpp was as follows:

----- Start of test.cpp -----
#include <avr/pgmspace.h>

#if 0
#undef PROGMEM
#define PROGMEM __attribute__(( section(".progmem.data") ))

#undef PSTR
#define PSTR(s) (__extension__({static prog_char __c[] PROGMEM = (s);
&__c[0];}))
#endif

void Log_P( const char *fmt, ... );

void foo( void )
{
Log_P( PSTR( "foo was called\n" ));
}
----- End of test.cpp -----

As shown above, I compiled it with the following command line:

603 >avr-g++ -mmcu=atmega168 -c test.cpp -o test1.o
test.cpp: In function 'void foo()':
test.cpp:15: warning: only initialized variables can be placed into
program memory area

and then ran

604 >avr-objdump --full-contents test1.o

test1.o: file format elf32-avr

Contents of section .text:
0000 df93cf93 cdb7deb7 80e090e0 00d0edb7 ................
0010 feb73196 91838083 0e940000 0f900f90 ..1.............
0020 cf91df91 0895 ......
Contents of section .progmem.data:
0000 666f6f20 77617320 63616c6c 65640a00 foo was called..

I then changed the #if 0 to #if 1 and repeated, replacing test1.o with test2.o

605 >avr-g++ -mmcu=atmega168 -c test.cpp -o test2.o
606 >avr-objdump --full-contents test2.o

test2.o: file format elf32-avr

Contents of section .text:
0000 df93cf93 cdb7deb7 80e090e0 00d0edb7 ................
0010 feb73196 91838083 0e940000 0f900f90 ..1.............
0020 cf91df91 0895 ......
Contents of section .progmem.data:
0000 666f6f20 77617320 63616c6c 65640a00 foo was called..

607 >cmp test1.o test2.o

shows that the two objects are in fact 100% identical, but the 2nd
version has no warning.

--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

C++ with PSTR

2009-12-06T04:20:58Z

This topic is covered all over avr forums in bits and pieces so please keep responses to a minimum. The problem is that when using PSTR("String") in a cpp file, the compiler generates the warning:

warning: only initialized variables can be placed into program memory area

despite the warning, the code operates as desired, however, each occurrence of PSTR() generates the warning and therefore makes it difficult to efficiently analyse the compiler's output

A reported solution to the problem is to redefine PSTR from

# define PSTR(s) (__extension__({static char __c[] PROGMEM = (s); &__c[0];}))
to
# define PSTR(s) (__extension__({static prog_char __c[] = (s); &__c[0];}))

This solution prevents the warning but also causes the program to operate incorrectly

Does anyone have a proven solution or workaround for this problem? Is there anything that can be done to at least suppress the warning without suppressing other warnings?

Re: AVR environment on Solaris 10

2009-12-02T08:13:01Z

Hi Eric,

>> Am I missing an environment variable?
>>
>
> I've been bitten by this several times. IIRC, you're supposed to use
> GNU make 3.81. That should solve the problem.

It did solve the problem! Unbelievable!

Thanks so much,

Andreas

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: AVR environment on Solaris 10

2009-12-02T07:49:39Z

> -----Original Message-----
> From: Andreas Höschler [mailto:ahoesch@...]
> Sent: Wednesday, December 02, 2009 3:08 AM
> To: Weddington, Eric
> Cc: Ruud Vlaming; avr-gcc-list@...
> Subject: Re: [avr-gcc-list] AVR environment on Solaris 10
>
> I now have /usr/local/avr/bin/avr-gcc and it seems to work. However,
> while building the AVR C library (I am following the getting started
> instructions on
> http://www.micahcarrick.com/02-15-2006/installing-gnu-tools-avr-
> gcc.html) I get the following error:
>
> mkdir /usr/local/avr/src
> cd /usr/local/avr/src
> bunzip2 avr-libc-1.6.7.tar.bz2
> gtar xvf avr-libc-1.6.7.tar
> cd avr-libc-1.6.7
> ./configure --build=`./config.guess` --host=avr
> --prefix=/usr/local/avr
> make
>
> ...
> make[4]: Entering directory
> `/usr/local/avr/src/avr-libc-1.6.7/avr/lib/avr2'
> avr-gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../common
> -I../../../include -g -Wall -W -Wstrict-prototypes
> -D__COMPILING_AVR_LIBC__ -mcall-prologues -Os -x assembler-with-cpp
> -Wa,-gstabs -D__COMPILING_AVR_LIBC__ -c -o
> eerd_block_at90s1200.o
> \
> -mmcu= \
> ../../../libc/misc/eerd_block.S
> cc1: error: missing argument to "-mmcu="
> make[4]: *** [eerd_block_at90s1200.o] Error 1
> make[4]: Leaving directory
> `/usr/local/avr/src/avr-libc-1.6.7/avr/lib/avr2'
> make[3]: *** [install-recursive] Error 1
> make[3]: Leaving directory
> `/usr/local/avr/src/avr-libc-1.6.7/avr/lib/avr2'
> make[2]: *** [install-recursive] Error 1
> make[2]: Leaving directory `/usr/local/avr/src/avr-libc-1.6.7/avr/lib'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory `/usr/local/avr/src/avr-libc-1.6.7/avr'
> make: *** [install-recursive] Error 1
>
> Am I missing an environment variable?
>

I've been bitten by this several times. IIRC, you're supposed to use GNU make 3.81. That should solve the problem.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: AVR environment on Solaris 10

2009-12-02T02:12:38Z

Hi all,

> ...
> make[4]: Entering directory
> `/usr/local/avr/src/avr-libc-1.6.7/avr/lib/avr2'
> avr-gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../common
> -I../../../include -g -Wall -W -Wstrict-prototypes
> -D__COMPILING_AVR_LIBC__ -mcall-prologues -Os -x assembler-with-cpp
> -Wa,-gstabs -D__COMPILING_AVR_LIBC__ -c -o eerd_block_at90s1200.o
> \
> -mmcu= \
> ../../../libc/misc/eerd_block.S
> cc1: error: missing argument to "-mmcu="
> make[4]: *** [eerd_block_at90s1200.o] Error 1
> make[4]: Leaving directory
> `/usr/local/avr/src/avr-libc-1.6.7/avr/lib/avr2'
> make[3]: *** [install-recursive] Error 1
> make[3]: Leaving directory
> `/usr/local/avr/src/avr-libc-1.6.7/avr/lib/avr2'
> make[2]: *** [install-recursive] Error 1
> make[2]: Leaving directory `/usr/local/avr/src/avr-libc-1.6.7/avr/lib'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory `/usr/local/avr/src/avr-libc-1.6.7/avr'
> make: *** [install-recursive] Error 1
>
> Am I missing an environment variable?

I manually executed the failing line with -mmcu=atmega8. This worked!
So where do I set the -mmcu value for the whle build process?

Thanks a lot,

Andreas

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: AVR environment on Solaris 10

2009-12-02T02:07:52Z

Hi all,

>> Thank you for trying. This seems not to encouraging.
>> But, at least this tool tests before it runs into unclear
>> errors... ;-)
>>
>
> Andreas just sent me a personal email saying that he finally got the
> toolchain to build.

Well, I got binutils and gcc successfully built with

mkdir /usr/local/avr/
mkdir /usr/local/avr/bin

cd /usr/src
gunzip binutils-2.20.tar.gz
tar xvf binutils-2.20.tar
cd binutils-2.20
./configure --target=avr --prefix=/usr/local/avr
make
make install

cd /usr/src
bunzip2 gcc-4.3.3.tar.bz2
gtar xvf gcc-4.3.3.tar
cd gcc-4.3.3
mkdir objdir
cd objdir
../configure --target=avr --prefix=/usr/local/avr --enable-languages=c
--disable-libssp --disable-shared --disable-libada --disable-libssp
--disable-nls --with-dwarf2 --with-gmp=/usr/local
--with-mpfr=/usr/local --prefix=/usr/local/avr
make
make install

I now have /usr/local/avr/bin/avr-gcc and it seems to work. However,
while building the AVR C library (I am following the getting started
instructions on
http://www.micahcarrick.com/02-15-2006/installing-gnu-tools-avr-
gcc.html) I get the following error:

mkdir /usr/local/avr/src
cd /usr/local/avr/src
bunzip2 avr-libc-1.6.7.tar.bz2
gtar xvf avr-libc-1.6.7.tar
cd avr-libc-1.6.7
./configure --build=`./config.guess` --host=avr --prefix=/usr/local/avr
make

...
make[4]: Entering directory
`/usr/local/avr/src/avr-libc-1.6.7/avr/lib/avr2'
avr-gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../common
-I../../../include -g -Wall -W -Wstrict-prototypes
-D__COMPILING_AVR_LIBC__ -mcall-prologues -Os -x assembler-with-cpp
-Wa,-gstabs -D__COMPILING_AVR_LIBC__ -c -o eerd_block_at90s1200.o
\
-mmcu= \
../../../libc/misc/eerd_block.S
cc1: error: missing argument to "-mmcu="
make[4]: *** [eerd_block_at90s1200.o] Error 1
make[4]: Leaving directory
`/usr/local/avr/src/avr-libc-1.6.7/avr/lib/avr2'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory
`/usr/local/avr/src/avr-libc-1.6.7/avr/lib/avr2'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/usr/local/avr/src/avr-libc-1.6.7/avr/lib'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/usr/local/avr/src/avr-libc-1.6.7/avr'
make: *** [install-recursive] Error 1

Am I missing an environment variable?

Thanks a lot,

Andreas

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: AVR environment on Solaris 10

2009-12-01T14:01:59Z

Andreas just sent me a personal email saying that he finally got the toolchain to build.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: AVR environment on Solaris 10

2009-12-01T13:56:03Z

Hi Anreas,

Thank you for trying. This seems not to encouraging.
But, at least this tool tests before it runs into unclear errors... ;-)

Let me remark, that some of those tools are not specially
needed by my builder, but more for the build process itself,
which may not be as appearent as it may seem. Thus,
as long as you do not have automake for example, you
will have a hard time getting the any avr toolchain
compiled if i remember correctly. The same applies for
libtool and some other guys.

On the other hand, it also can be that my version detection
mechnism does not work correctly on Solaris. Determining
the version of a program is difficult since the way programs
report their version numbers is different per program and (!)
different per operating system.

My advise would be to make sure you update/install
the tools that are to old/missing, since i guess you will
need most of them for a correct build anyway.
(With or without my script!) Since these are all pretty
standard tools, using whatever packet manager is used
for Solaris, this should be not to hard.

After that you can give it an other try. If you think you
do have a particular tool, contrary to what my builder
reports, (automake for example) try typing that on
the commandline, if it reports present, than my script
is not able to detect is somehow, and i must fix that first.

Succes.
Ruud.

On Tuesday 01 December 2009, you wrote:

> Hi Ruud,
>
> > You can give my toolchainbuilder a try. Although it is
> > not tested on Solaris, it runs on gentoo, Ubuntu, macos
> > windows with cygwin, and probably others. It installs
> > all patches, takes care of GMP and MPFR etc. If it runs,
> > please say so, i can add it to the list. If not, send me
> > the log, so i can solve it.
> >
> > It is in my Femto OS distribution.
> > http://sourceforge.net/projects/femtoos/
>
> I gave it a try and got
>
> ===> testing tools
> ERROR: aclocal not present, script cannot continue.
> WARNING: ar version could not be detected. (Needed: >= 2.16.1)
> ERROR: autoconf not present, script cannot continue.
> ERROR: autoheader not present, script cannot continue.
> ERROR: automake not present, script cannot continue.
> WARNING: bison version: 1.875, tool may be too old. (Needed: >= 2.1)
> WARNING: flex version: 2.5.31, tool may be too old. (Needed: >= 2.5.33)
> ERROR: gawk not present, script cannot continue.
> OK: gcc version: 4.2.3
> OK: g++ version: 4.2.3
> WARNING: install version could not be detected. (Needed: >= 5.94)
> ERROR: libtool not present, script cannot continue.
> OK: make version: 3.80
> WARNING: makeinfo version: 4.7, tool may be too old. (Needed: >= 4.8)
> OK: openssl version: 0.9.8
> WARNING: patch version could not be detected. (Needed: >= 2.5.8)
> WARNING: perl version: 5.8.4, tool may be too old. (Needed: >= 5.8.8)
> WARNING: touch version could not be detected. (Needed: >= 5.94)
> OK: wget version: 1.10.2
> ===> Test done.
>
> ===> Results of this script:
> - tools: failure
> - download: skipped
> - patches: skipped
> - bin-utils: skipped
> - gcc: skipped
> - avr-libc: skipped
> - avr-dude: skipped
>
> Seems a bunch of packages are missing! :-(
>
> I wonder what's the best way to proceed. Try to install/upgrade all
> these guys or try to get gcc built manually!? What do you think?
>
> Thanks,
>
> Andreas
>
>
>
>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: AVR environment on Solaris 10

2009-12-01T12:37:01Z

> -----Original Message-----
> From: Andreas Höschler [mailto:ahoesch@...]
> Sent: Tuesday, December 01, 2009 1:28 PM
> To: Weddington, Eric
> Cc: Jonathan Blanchard; avr-gcc-list@...
> Subject: Re: [avr-gcc-list] AVR environment on Solaris 10
>
> Hi all,
>
> >>
> >> The build is still in progess, so no success so far.
> >
> > cd /usr/src
> > gunzip binutils-2.20.tar.gz
> > tar xvf binutils-2.20.tar
> > cd binutils-2.20
> > ./configure --target=avr --prefix=/usr/local/avr
> > make
> > make install
> >
> > cd /usr/src
> > bunzip2 gcc-4.3.3.tar.bz2
> > gtar xvf gcc-4.3.3.tar
> > cd gcc-4.3.3
> > mkdir objdir
> > cd objdir
> > ../configure --target=avr --prefix=/usr/local/avr
> --enable-languages=c
> > make
> > make install
> > Ah, but no failure yet either! ;-)
>
> In the meanwhile I got a failure trying this on Solaris 10:
>
> " -c -o ssp.lo ../../../libssp/ssp.c; \
> then mv -f ".deps/ssp.Tpo" ".deps/ssp.Plo"; else rm -f
> ".deps/ssp.Tpo";
> exit 1; fi
> libtool: compile: /usr/src/gcc-4.3.3/objdir/./gcc/xgcc
> -B/usr/src/gcc-4.3.3/objdir/./gcc/ -B/usr/local/avr/avr/bin/
> -B/usr/local/avr/avr/lib/ -isystem /usr/local/avr/avr/include
> -isystem
> /usr/local/avr/avr/sys-include -DHAVE_CONFIG_H -I. -I../../../libssp
> -I. -Wall -O2 -g -g -O2 -MT ssp.lo -MD -MP -MF .deps/ssp.Tpo -c
> ../../../libssp/ssp.c -o ssp.o
> ../../../libssp/ssp.c: In function '__guard_setup':
> ../../../libssp/ssp.c:70: warning: implicit declaration of function
> 'open'
> ../../../libssp/ssp.c:70: error: 'O_RDONLY' undeclared (first use in
> this function)

Use --disable-libssp in your configure.

These are my configure switches:

--with-gmp=/usr/local \
--with-mpfr=/usr/local \
--prefix=$installdir \
--target=$target \
--enable-languages=$lang \
--with-dwarf2 \
--enable-doc \
--disable-shared \
--disable-libada \
--disable-libssp \
--disable-nls \

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: AVR environment on Solaris 10

2009-12-01T12:27:42Z

Hi all,

>>
>> The build is still in progess, so no success so far.
>
> cd /usr/src
> gunzip binutils-2.20.tar.gz
> tar xvf binutils-2.20.tar
> cd binutils-2.20
> ./configure --target=avr --prefix=/usr/local/avr
> make
> make install
>
> cd /usr/src
> bunzip2 gcc-4.3.3.tar.bz2
> gtar xvf gcc-4.3.3.tar
> cd gcc-4.3.3
> mkdir objdir
> cd objdir
> ../configure --target=avr --prefix=/usr/local/avr --enable-languages=c
> make
> make install
> Ah, but no failure yet either! ;-)

In the meanwhile I got a failure trying this on Solaris 10:

" -c -o ssp.lo ../../../libssp/ssp.c; \
then mv -f ".deps/ssp.Tpo" ".deps/ssp.Plo"; else rm -f ".deps/ssp.Tpo";
exit 1; fi
libtool: compile: /usr/src/gcc-4.3.3/objdir/./gcc/xgcc
-B/usr/src/gcc-4.3.3/objdir/./gcc/ -B/usr/local/avr/avr/bin/
-B/usr/local/avr/avr/lib/ -isystem /usr/local/avr/avr/include -isystem
/usr/local/avr/avr/sys-include -DHAVE_CONFIG_H -I. -I../../../libssp
-I. -Wall -O2 -g -g -O2 -MT ssp.lo -MD -MP -MF .deps/ssp.Tpo -c
../../../libssp/ssp.c -o ssp.o
../../../libssp/ssp.c: In function '__guard_setup':
../../../libssp/ssp.c:70: warning: implicit declaration of function
'open'
../../../libssp/ssp.c:70: error: 'O_RDONLY' undeclared (first use in
this function)
../../../libssp/ssp.c:70: error: (Each undeclared identifier is
reported only once
../../../libssp/ssp.c:70: error: for each function it appears in.)
../../../libssp/ssp.c:73: error: 'ssize_t' undeclared (first use in
this function)
../../../libssp/ssp.c:73: error: expected ';' before 'size'
../../../libssp/ssp.c:75: warning: implicit declaration of function
'close'
../../../libssp/ssp.c:76: error: 'size' undeclared (first use in this
function)
../../../libssp/ssp.c: At top level:
../../../libssp/ssp.c:89: error: expected declaration specifiers or
'...' before 'size_t'
../../../libssp/ssp.c: In function 'fail':
../../../libssp/ssp.c:100: error: 'O_WRONLY' undeclared (first use in
this function)
../../../libssp/ssp.c:104: error: 'size_t' undeclared (first use in
this function)
../../../libssp/ssp.c:104: error: expected ';' before 'progname_len'
../../../libssp/ssp.c:107: error: 'progname_len' undeclared (first use
in this function)
../../../libssp/ssp.c:107: warning: implicit declaration of function
'strlen'
../../../libssp/ssp.c:107: warning: incompatible implicit declaration
of built-in function 'strlen'
../../../libssp/ssp.c:108: error: 'len' undeclared (first use in this
function)
../../../libssp/ssp.c:108: error: 'msg1len' undeclared (first use in
this function)
../../../libssp/ssp.c:109: warning: implicit declaration of function
'alloca'
../../../libssp/ssp.c:109: warning: incompatible implicit declaration
of built-in function 'alloca'
../../../libssp/ssp.c:111: warning: implicit declaration of function
'memcpy'
../../../libssp/ssp.c:111: warning: incompatible implicit declaration
of built-in function 'memcpy'
../../../libssp/ssp.c:119: error: 'ssize_t' undeclared (first use in
this function)
../../../libssp/ssp.c:119: error: expected ';' before 'wrote'
../../../libssp/ssp.c:120: error: 'wrote' undeclared (first use in this
function)
../../../libssp/ssp.c:151: warning: implicit declaration of function
'_exit'
../../../libssp/ssp.c:151: warning: incompatible implicit declaration
of built-in function '_exit'
../../../libssp/ssp.c: In function '__stack_chk_fail':
../../../libssp/ssp.c:161: warning: incompatible implicit declaration
of built-in function 'strlen'
../../../libssp/ssp.c:161: warning: passing argument 2 of 'fail' makes
pointer from integer without a cast
../../../libssp/ssp.c:161: error: too many arguments to function 'fail'
../../../libssp/ssp.c: In function '__chk_fail':
../../../libssp/ssp.c:168: warning: incompatible implicit declaration
of built-in function 'strlen'
../../../libssp/ssp.c:168: warning: passing argument 2 of 'fail' makes
pointer from integer without a cast
../../../libssp/ssp.c:168: error: too many arguments to function 'fail'
make[2]: *** [ssp.lo] Error 1
make[2]: Leaving directory `/usr/share/src/gcc-4.3.3/objdir/avr/libssp'
make[1]: *** [install-target-libssp] Error 2
make[1]: Leaving directory `/usr/share/src/gcc-4.3.3/objdir'
make: *** [install] Error 2

Any idea?

Thanks,

Andreas

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: AVR environment on Solaris 10

2009-12-01T11:01:33Z

> -----Original Message-----
> From: Andreas Höschler [mailto:ahoesch@...]
> Sent: Tuesday, December 01, 2009 11:47 AM
> To: Jonathan Blanchard
> Cc: Weddington, Eric; avr-gcc-list@...
> Subject: Re: [avr-gcc-list] AVR environment on Solaris 10
>
>
> The build is still in progess, so no success so far.

Ah, but no failure yet either! ;-)

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: AVR environment on Solaris 10

2009-12-01T10:46:48Z

Hi Jonathan,

> I can offer some help as I built it before on Solaris 10. It was quite
> a while ago but I think that everything should work.

Thanks a lot for your offer. I modified the build process to

cd /usr/src
gunzip binutils-2.20.tar.gz
tar xvf binutils-2.20.tar
cd binutils-2.20
./configure --target=avr --prefix=/usr/local/avr
make
make install

cd /usr/src
bunzip2 gcc-4.3.3.tar.bz2
gtar xvf gcc-4.3.3.tar
cd gcc-4.3.3
mkdir objdir
cd objdir
../configure --target=avr --prefix=/usr/local/avr --enable-languages=c
make
make install

The build is still in progess, so no success so far. I will let you
know!

Thanks,

Andreas

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: AVR environment on Solaris 10

2009-12-01T09:15:35Z

Hi,

I can offer some help as I built it before on Solaris 10. It was quite
a while ago but I think that everything should work.

Jonathan Blanchard

2009/12/1 Andreas Höschler <ahoesch@...>:

> Hi Eric,
>
>> Normally binutils is built in a separate build directory, not built in its
>> source tree.
>>
>> I don't know for sure if you really need to use the --program-prefix
>> configure switch in binutils and gcc. The build process normally does that
>> on other hosts, but I don't know how it behaves on Solaris.
>>
>> You do need to make sure that after binutils is built, that you put the
>> installation directory (--prefix) in your PATH environment variable.
>> Building gcc and avr-libc will need to know where the just-built AVR
>> assembler and linker are located.
>>
>> You have the gcc configure switch --enable-language=c and it should be
>> --enable-languages=c. Note that "languages" is plural.
>>
>> It would be better to build gcc version 4.3.3, instead of 4.2.3. It's a
>> more recent version and it's being used on other hosts.
>>
>> To get support for other devices, as well as a number of bug fixes, you'll
>> need to patch your binutils and gcc source code using the patches found at
>> the WinAVR project (SourceForge) or using the patches found in the FreeBSD
>> Ports project. These are roughly the same patches. The WinAVR patches only
>> patch binutils 2.19 though, not 2.20.
>>
>> You will need to have the GMP and MPFR library packages on your host in
>> order to properly build GCC. If you don't have these libraries, they are
>> relatively easy to build.
>>
>> I don't know for sure whether any of the above is a cause of your problem,
>> but it might help out.
>
> Thanks for all your comments. I am currently downloading gcc 4.33 and will
> retry with the modified options. I will let you know ...
>
> Thanks a lot,
>
> Andreas
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> AVR-GCC-list@...
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: AVR environment on Solaris 10

2009-12-01T09:02:56Z

On Tuesday 01 December 2009, Andreas Höschler wrote:

> I am trying to setup an AVR development environment
> on my Solaris 10 machine as follows:

You can give my toolchainbuilder a try. Although it is
not tested on Solaris, it runs on gentoo, Ubuntu, macos
windows with cygwin, and probably others. It installs
all patches, takes care of GMP and MPFR etc. If it runs,
please say so, i can add it to the list. If not, send me
the log, so i can solve it.

It is in my Femto OS distribution.
http://sourceforge.net/projects/femtoos/

regards
Ruud.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: AVR environment on Solaris 10

2009-12-01T09:02:48Z

Hi Eric,

> Normally binutils is built in a separate build directory, not built in
> its source tree.
>
> I don't know for sure if you really need to use the --program-prefix
> configure switch in binutils and gcc. The build process normally does
> that on other hosts, but I don't know how it behaves on Solaris.
>
> You do need to make sure that after binutils is built, that you put
> the installation directory (--prefix) in your PATH environment
> variable. Building gcc and avr-libc will need to know where the
> just-built AVR assembler and linker are located.
>
> You have the gcc configure switch --enable-language=c and it should be
> --enable-languages=c. Note that "languages" is plural.
>
> It would be better to build gcc version 4.3.3, instead of 4.2.3. It's
> a more recent version and it's being used on other hosts.
>
> To get support for other devices, as well as a number of bug fixes,
> you'll need to patch your binutils and gcc source code using the
> patches found at the WinAVR project (SourceForge) or using the patches
> found in the FreeBSD Ports project. These are roughly the same
> patches. The WinAVR patches only patch binutils 2.19 though, not 2.20.
>
> You will need to have the GMP and MPFR library packages on your host
> in order to properly build GCC. If you don't have these libraries,
> they are relatively easy to build.
>
> I don't know for sure whether any of the above is a cause of your
> problem, but it might help out.

Thanks for all your comments. I am currently downloading gcc 4.33 and
will retry with the modified options. I will let you know ...

Thanks a lot,

Andreas

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: AVR environment on Solaris 10

2009-12-01T08:47:04Z

Hi Andreas,

Various comments:

Normally binutils is built in a separate build directory, not built in its source tree.

I don't know for sure if you really need to use the --program-prefix configure switch in binutils and gcc. The build process normally does that on other hosts, but I don't know how it behaves on Solaris.

You do need to make sure that after binutils is built, that you put the installation directory (--prefix) in your PATH environment variable. Building gcc and avr-libc will need to know where the just-built AVR assembler and linker are located.

You have the gcc configure switch --enable-language=c and it should be --enable-languages=c. Note that "languages" is plural.

It would be better to build gcc version 4.3.3, instead of 4.2.3. It's a more recent version and it's being used on other hosts.

To get support for other devices, as well as a number of bug fixes, you'll need to patch your binutils and gcc source code using the patches found at the WinAVR project (SourceForge) or using the patches found in the FreeBSD Ports project. These are roughly the same patches. The WinAVR patches only patch binutils 2.19 though, not 2.20.

You will need to have the GMP and MPFR library packages on your host in order to properly build GCC. If you don't have these libraries, they are relatively easy to build.

I don't know for sure whether any of the above is a cause of your problem, but it might help out.

Eric Weddington

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of Andreas Höschler
> Sent: Tuesday, December 01, 2009 9:07 AM
> To: avr-gcc-list@...
> Subject: [avr-gcc-list] AVR environment on Solaris 10
>
> Hi all,
>
> I am trying to setup an AVR development environment on my Solaris 10
> machine as follows:
>
> mkdir /usr/local/avr/
> mkdir /usr/local/avr/bin
>
> cd /usr/src
> gunzip binutils-2.20.tar.gz
> tar xvf binutils-2.20.tar
> cd binutils-2.20
> ./configure --target=avr --prefix=/usr/local/avr
> --program-prefix="avr-"
> make
> make install
>
> cd /usr/src
> gtar xvf gcc-4.2.3.tar
> cd gcc-4.2.3
> mkdir objdir
> cd objdir
> ../configure --target=avr --prefix=/usr/local/avr
> --enable-language=c
> --program-prefix="avr-"
> make
>
> The make of the gcc build leads to the following error:
>
> make[2]: Entering directory
> `/usr/share/src/gcc-4.2.3/objdir/libdecnumber'
> source='../../libdecnumber/decNumber.c' object='decNumber.o'
> libtool=no
> gcc -I../../libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
> -Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long
> -I../../libdecnumber -I. -c ../../libdecnumber/decNumber.c
> source='../../libdecnumber/decContext.c' object='decContext.o'
> libtool=no gcc -I../../libdecnumber -I. -g -O2 -W -Wall
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> -Wold-style-definition -Wmissing-format-attribute -Wcast-qual
> -pedantic
> -Wno-long-long -I../../libdecnumber -I. -c
> ../../libdecnumber/decContext.c
> source='../../libdecnumber/decUtility.c' object='decUtility.o'
> libtool=no gcc -I../../libdecnumber -I. -g -O2 -W -Wall
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> -Wold-style-definition -Wmissing-format-attribute -Wcast-qual
> -pedantic
> -Wno-long-long -I../../libdecnumber -I. -c
> ../../libdecnumber/decUtility.c
> source='../../libdecnumber/decimal32.c' object='decimal32.o'
> libtool=no
> gcc -I../../libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
> -Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long
> -I../../libdecnumber -I. -c ../../libdecnumber/decimal32.c
> source='../../libdecnumber/decimal64.c' object='decimal64.o'
> libtool=no
> gcc -I../../libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
> -Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long
> -I../../libdecnumber -I. -c ../../libdecnumber/decimal64.c
> source='../../libdecnumber/decimal128.c' object='decimal128.o'
> libtool=no gcc -I../../libdecnumber -I. -g -O2 -W -Wall
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> -Wold-style-definition -Wmissing-format-attribute -Wcast-qual
> -pedantic
> -Wno-long-long -I../../libdecnumber -I. -c
> ../../libdecnumber/decimal128.c
> rm -f libdecnumber.a
> ar cru libdecnumber.a decNumber.o decContext.o decUtility.o
> decimal32.o
> decimal64.o decimal128.o
> ranlib libdecnumber.a
> make[2]: Leaving directory
> `/usr/share/src/gcc-4.2.3/objdir/libdecnumber'
> make[2]: Entering directory `/usr/share/src/gcc-4.2.3/objdir/gcc'
> make[2]: *** No rule to make target `all'. Stop.
> make[2]: Leaving directory `/usr/share/src/gcc-4.2.3/objdir/gcc'
> make[1]: *** [all-gcc] Error 2
> make[1]: Leaving directory `/usr/share/src/gcc-4.2.3/objdir'
> make: *** [all] Error 2
>
> I am not sure what to do with that. Any idea what went wrong here?
>
> Hints are greatly appreciated!
>
> Thanks,
>
> Andreas
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> AVR-GCC-list@...
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

AVR environment on Solaris 10

2009-12-01T08:06:57Z

Hi all,

I am trying to setup an AVR development environment on my Solaris 10
machine as follows:

mkdir /usr/local/avr/
mkdir /usr/local/avr/bin

cd /usr/src
gunzip binutils-2.20.tar.gz
tar xvf binutils-2.20.tar
cd binutils-2.20
./configure --target=avr --prefix=/usr/local/avr
--program-prefix="avr-"
make
make install

cd /usr/src
gtar xvf gcc-4.2.3.tar
cd gcc-4.2.3
mkdir objdir
cd objdir
../configure --target=avr --prefix=/usr/local/avr --enable-language=c
--program-prefix="avr-"
make

The make of the gcc build leads to the following error:

make[2]: Entering directory
`/usr/share/src/gcc-4.2.3/objdir/libdecnumber'
source='../../libdecnumber/decNumber.c' object='decNumber.o' libtool=no
gcc -I../../libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long
-I../../libdecnumber -I. -c ../../libdecnumber/decNumber.c
source='../../libdecnumber/decContext.c' object='decContext.o'
libtool=no gcc -I../../libdecnumber -I. -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic
-Wno-long-long -I../../libdecnumber -I. -c
../../libdecnumber/decContext.c
source='../../libdecnumber/decUtility.c' object='decUtility.o'
libtool=no gcc -I../../libdecnumber -I. -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic
-Wno-long-long -I../../libdecnumber -I. -c
../../libdecnumber/decUtility.c
source='../../libdecnumber/decimal32.c' object='decimal32.o' libtool=no
gcc -I../../libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long
-I../../libdecnumber -I. -c ../../libdecnumber/decimal32.c
source='../../libdecnumber/decimal64.c' object='decimal64.o' libtool=no
gcc -I../../libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long
-I../../libdecnumber -I. -c ../../libdecnumber/decimal64.c
source='../../libdecnumber/decimal128.c' object='decimal128.o'
libtool=no gcc -I../../libdecnumber -I. -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic
-Wno-long-long -I../../libdecnumber -I. -c
../../libdecnumber/decimal128.c
rm -f libdecnumber.a
ar cru libdecnumber.a decNumber.o decContext.o decUtility.o decimal32.o
decimal64.o decimal128.o
ranlib libdecnumber.a
make[2]: Leaving directory
`/usr/share/src/gcc-4.2.3/objdir/libdecnumber'
make[2]: Entering directory `/usr/share/src/gcc-4.2.3/objdir/gcc'
make[2]: *** No rule to make target `all'. Stop.
make[2]: Leaving directory `/usr/share/src/gcc-4.2.3/objdir/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/usr/share/src/gcc-4.2.3/objdir'
make: *** [all] Error 2

I am not sure what to do with that. Any idea what went wrong here?

Hints are greatly appreciated!

Thanks,

Andreas

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: Calibrate internal RC oscilator FAQ

2009-11-30T11:34:51Z

max2009tiny <mm@...> wrote:

> 1. when i program and select 4MHz internal RC osc. what OSCAL
> constatnt is loaded by reset if Atmel have more constants from
> factory?

The AVR hardware only loads the default (i.e., 8 MHz) OSCCAL value
itself. It's the responsibility of the developer to maintain the
OSCCAL values of the other frequencies outside (e.g. through an EEPROM
cell), or somehow perform a run-time calibration (against whatever
that could be used as a calibration source, 32 kHz oscillator,
external clock of some kind, ...).

If you don't want to bother with that, use a more modern AVR: they
only have a single (and much better, e.g. regarding the frequency
stability vs. Vcc variations) RC oscillator, and thus also only a
single OSCCAL value which is loaded automatically.

> 2. where in code can change OSCAL and where not

You could change it everywhere you want.

> 3. exist math function to recalc new OSCAL for a correct freq or
> only probing?

There is no (guaranteed) mathematical formula for that.

> If diference between Tiny Mega ... please write simply about this.

I outlined the major difference above: recent AVRs ship with only a
single RC oscillator anymore which has been improved. For example,
with an ATmega128, it was basically unavoidable to recalibrate the RC
oscillator (even the 8 MHz one) if you wanted to use Vcc = 3 V when
the calibration value the device ships with has been obtained for Vcc
= 5 V. Replacing the ATmega128 by an ATmega1281, there's a good
chance you could run an RS-232 communication without recalibrating the
RC oscillator even at Vcc = 3 V (but of course, it's not guaranteed it
will work).

--
cheers, J"org .-.-. --... ...-- -.. . 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@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Calibrate internal RC oscilator FAQ

2009-11-30T01:20:43Z

Hi all,
i read info about internal RC, but dont good understand how it work.
Here is 3 basic question:

1. when i program and select 4MHz internal RC osc. what OSCAL constatnt is loaded by reset if Atmel have more constants from factory?

2. where in code can change OSCAL and where not

3. exist math function to recalc new OSCAL for a correct freq or only probing?

If diference between Tiny Mega ... please write simply about this.
If have more info simply write...

Thanks Max.

RE: assembly-c mix and interrupts

2009-11-30T01:15:31Z

Paul responded off thread

> I experienced this problem with version 4.3.0, I believe provided by an
> older version of Ubuntu. Version 4.3.2 (as provided by Ubuntu 9.04)
> fixed the problem. I assume later versions also work, though I have not
> verified.

I am indeed using 4.3.0

Perhaps this will also solve my string problems :) However, I have already moved strings to program memory where they should have been in the first place. All seems okay now

Thank you for all of your reponses

Re: assembly-c mix and interrupts

2009-11-29T23:35:35Z

> The issue I am trying to draw attention to is that, in my case, the compiler
> is not being conservative so the push/pop of volatile registers must be done
> manually.
>

I experienced this problem with version 4.3.0, I believe provided by an
older version of Ubuntu. Version 4.3.2 (as provided by Ubuntu 9.04)
fixed the problem. I assume later versions also work, though I have not
verified.

Just to be sure, I did a quick test.

// compile with avr-gcc -Wall -mmcu=atmega168 -g -Os -c isr.c
// disassemble with: avr-objdump -d isr.o

#include <avr/io.h>
#include <avr/interrupt.h>

extern void some_random_function(void);

ISR(TIMER0_OVF_vect)
{
some_random_function();
}

This was the result.

isr.o: file format elf32-avr

Disassembly of section .text:

00000000 <__vector_16>:
0: 1f 92 push r1
2: 0f 92 push r0
4: 0f b6 in r0, 0x3f ; 63
6: 0f 92 push r0
8: 11 24 eor r1, r1
a: 2f 93 push r18
c: 3f 93 push r19
e: 4f 93 push r20
10: 5f 93 push r21
12: 6f 93 push r22
14: 7f 93 push r23
16: 8f 93 push r24
18: 9f 93 push r25
1a: af 93 push r26
1c: bf 93 push r27
1e: ef 93 push r30
20: ff 93 push r31
22: 0e 94 00 00 call 0 ; 0x0 <__vector_16>
26: ff 91 pop r31
28: ef 91 pop r30
2a: bf 91 pop r27
2c: af 91 pop r26
2e: 9f 91 pop r25
30: 8f 91 pop r24
32: 7f 91 pop r23
34: 6f 91 pop r22
36: 5f 91 pop r21
38: 4f 91 pop r20
3a: 3f 91 pop r19
3c: 2f 91 pop r18
3e: 0f 90 pop r0
40: 0f be out 0x3f, r0 ; 63
42: 0f 90 pop r0
44: 1f 90 pop r1
46: 18 95 reti

From this simple test, I believe it should be very clear 4.3.2 is
indeed saving all the caller clobbered registers. (also, it appears to
be calling itself because the linker has not yet inserted the actual
address of "some_random_function") It is horribly inefficient, but
looks correct to me.

Maybe you're using version 4.3.0 or something similar? Type "avr-gcc
-v" to see the version.

-Paul

// compile with avr-gcc -Wall -mmcu=atmega168 -g -Os -c isr.c
// disassemble with: avr-objdump -d isr.o

#include <avr/io.h>
#include <avr/interrupt.h>

extern void some_random_function(void);

ISR(TIMER0_OVF_vect)
{
some_random_function();
}

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: assembly-c mix and interrupts

2009-11-29T23:12:33Z

Weddington, Eric wrote:

Many times in the embedded software world, you have to deal with trade-offs.

Sure you could design an ISR that way and do the unit testing the way you describe. And I'm sure that it would make your unit testing easier. The trade-off though is that it makes the ISR very inefficient. It has been said on this mailing list as well as on the AVR Freaks website forums that calling functions in an ISR is a Bad Idea, if you want to keep your ISR short. And you *do* want to keep your ISR as short as possible.

When an ISR calls a function, the compiler has no idea what registers the called function will use. So, to be conservative, the compiler will generate code to push/pop practically all registers, thus causing more code bloat and more time in the ISR prologue. That is your trade-off. If you think that ease of testing is better priority than a short ISR, then by all means go ahead. I know that most embedded software engineers on this list would rather have a short-as-possible ISR instead of that testing scheme. It's all a matter of priorities and trade-offs.

I see your point, I guess it all depends on the application.

The issue I am trying to draw attention to is that, in my case, the compiler is not being conservative so the push/pop of volatile registers must be done manually.

RE: assembly-c mix and interrupts

2009-11-29T22:46:38Z

Many times in the embedded software world, you have to deal with trade-offs.

Sure you could design an ISR that way and do the unit testing the way you describe. And I'm sure that it would make your unit testing easier. The trade-off though is that it makes the ISR very inefficient. It has been said on this mailing list as well as on the AVR Freaks website forums that calling functions in an ISR is a Bad Idea, if you want to keep your ISR short. And you *do* want to keep your ISR as short as possible.

When an ISR calls a function, the compiler has no idea what registers the called function will use. So, to be conservative, the compiler will generate code to push/pop practically all registers, thus causing more code bloat and more time in the ISR prologue. That is your trade-off. If you think that ease of testing is better priority than a short ISR, then by all means go ahead. I know that most embedded software engineers on this list would rather have a short-as-possible ISR instead of that testing scheme. It's all a matter of priorities and trade-offs.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: assembly-c mix and interrupts

2009-11-29T22:11:10Z

What I was trying to say was:

ISR(vector){
interruptHandler();
}

interruptHandler() was blindly destroying volatile registers which ISR should have been preserving since they are the callers responsibility. ISR was not preserving these registers because it was not aware that these registers were currently in use. The attitude of the ISR seems to be that the problem registers should have been stored before the ISR was triggered. The problem registers are used to carry arguments and return values between function calls and the ISR can be triggered at ANY time, so any chance of avoiding this problem is impossible

A solution to the problem would have been:

ISR(vector){
asm("push r18");
.....
asm("push r31");
interruptHandler();
asm("pop r31");
.....
asm("pop r18");
}

or like you said, constrain the ISR to the ISR() macro. But this reduces abstraction and the ability to test the code.

In my opinion, the best algorithm for an interrupt would be:

ISR(vector){
data=getData();
processData(data)
}

then unit testing can be carried out on processData() and getData() leaving little testing required for the interrupt itself

Re: assembly-c mix and interrupts

2009-11-29T21:18:06Z

darkschine <zhpctw3dash@...> wrote:

> my code was actually already written in C and looked something like:
>
> ISR(vector){
> interruptHandler();
> }

Which is less than ideal because the compiler *always* has to preserve
all the registers that could possibly be destroyed by
interruptHandler(). If possible, always write the code directly into
the ISR.

> The compiler does not make sure that all necessary registers are
> saved and restored properly and apparently I am the first to notice
> this.

The chances that this is really the case are about 1E-6. ;-)

As the thread subject is about assembly-C mix, it is much more likely
that your mix is the reason rather than the compiler-generated code
that has been used by millions of AVR-GCC users before.

> I'm starting to wish I wrote the whole thing in assembly! ;)

You should probably have written the whole thing in C instead, as this
completely avoids the class of errors you are currently running into.

--
cheers, J"org .-.-. --... ...-- -.. . 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@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: assembly-c mix and interrupts

2009-11-28T21:56:04Z

David Brown-4 wrote:

So any function generated by the compiler, or compatible functions
written in assembly by hand, can freely use the call-used registers
(SREG, r18-r27, r30-r31) without preserving or restoring them. But if
it wants to use the call-saved registers (r2-r17, r28-r29), it must save
them on entry and restore them on exit.

An interrupt routine must also preserve any call-used registers it
needs, including SREG and r0. It must also preserve the current r1 and
set it to 0 before certain compiler-generated code is executed. If the
interrupt routine is going to call other functions, it must preserve
/all/ the call-used registers, since the other functions may trash them.
On the other hand, it does not need to preserve any of the call-saved
registers, as the called function will preserve these as needed.

Thanks David. This was precisely the issue!
My interrupt routine was calling other functions but not preserving the call-used registers.
my code was actually already written in C and looked something like:

ISR(vector){
interruptHandler();
}

The compiler does not make sure that all necessary registers are saved and restored properly and apparently I am the first to notice this. I guess the ISR preserves the call-used registers it uses, but does not preserve the call-used registers that may be in use prior to the interrupt before transfering control to the ignorant interruptHandler() function.

I wish I could say this was the end of my troubles.

char *test ="test";
writeChar(test[0]);
writeChar(test[1]);
writeChar('x');
waitForInput();

The output on the LCD is "\0\0x"

but put in another function in the same file, the output is "tex" as expected! I'm starting to wish I wrote the whole thing in assembly! ;)

Can anyone suggest a possible cause for this problem?

Re: Volatile bad compiled while

2009-11-27T13:06:02Z

max2009tiny <mm@...> wrote:

> I understand that gcc miss, but if register is clause to change
> storing possition of var and volatile is for "change defining on the
> fly" i dont understand trouble for gcc compile this ok.

I don't pretend to understand enough of the internals of GCC. As I
understood it from a previous discussion, the unability to handle
both, fixed register assignments and volatileness together is tied
deep into the GCC code, and nothing that could easily be changed. So
in short, "volatile" can only be honoured for locations in memory, as
it effectively demands to load/store the data from/to memory
immediately before/after use. This is impossible for a register
variable (obviously).

So whatever you are arguing, you have to find a different solution for
your code.

--
cheers, J"org .-.-. --... ...-- -.. . 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@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: Volatile bad compiled while

2009-11-27T04:43:58Z

max2009tiny wrote:
> Ok thanks i use gcc 4.3.2
> secondary question is if i remove volatile from code
>
> register unsigned char lastrec asm("r8")
>
> then while generate asm efficient but dont work why?
> a0: 88 11 cpse r24, r8
> a2: ff cf rjmp .-2 ; 0xa2 <waitACK+0x2>

My educated guess (since you're not providing a full working example) is
that the interrupt routine that is supposed to change r8 is saving and
restoring its state in the prologue / epilogue. You might need to do a
naked interrupt routine or write it all in assembly.

As others have said, unless you're really desperate to shave off a few
cycles, all the issues that arise from trying to tweak the compiler's
behavior are really not worth it. IMHO, you'd be better of trying some
compiler options like David Brown suggested.

--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"I have not yet begun to procrastinate"

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: Volatile bad compiled while

2009-11-27T04:36:11Z

Thanks David but you miss,
i write code for tiny2313 with 2048 bytes and without use registers and leave optimize work
my code have 3266 bytes +60%
then i make noinline for some functions and code reduce to 2666 bytes.
Secondary count memory variables in code and max counted replace with register previously controlled in lss as not used
globaly changed to register r2-r11 and r18-r20 13 variables and code have now 2048 bytes.

Code works perfectly only while i must rewrite to asm.

David Brown-4 wrote:

max2009tiny wrote:
> OK
> i can't drop register and i use on this code more register vars and all work
> ok exept
> while clause. That generate bad jump -4 .
>
> My query is why not for removing register clause.
> If memory store all code is +2 bytes for read and +2 any once write var and
> this is over memory limit....
>

Here are some hints that might help you out:

You can't use "register volatile" variables - they don't work.

Using "register" variables will sometimes make code larger, since it
hinders the compiler - do some testing here to be sure.

Using __attribute__((noinline)) will also often make the code larger -
the compiler will spend more instructions putting data in the right
registers for the function call than it would by inlining small functions.

Generally speaking, the compiler is better at optimising when you let it
do its job than when you try and force it using hints like "register"
and "noinline".

Make sure you use -combine and -fwhole-program to compile the code.
-fno-split-wide-types is also often helpful.

You can force a "volatile" read of a register using the register's
memory address:

__attribute__ ((noinline)) void waitACK(u08 cmack)
{
while (cmack != *((volatile u08*)(0x0008))) ;
}

Address 0x0008 is the address of the r8 register. This will force a
volatile read as (using an lds instruction), but you will at least spare
the write.

If all else fails, it is sometimes best to use assembly.

mvh.,

David

>
>
>
> David Brown-4 wrote:
>> max2009tiny wrote:
>>> Hi everybody. I make project on Tiny2313 and use
>>>
>>> volatile register unsigned char lastrec asm("r8")
>>>
>>> and lastrec is modified on rs232 rx isr.
>>>
>>> When compile little function
>>> __attribute__ ((noinline)) void waitACK(u08 cmack)
>>> {
>>> while(cmack!=lastrec) ; //wait for reply request
>>> }
>>>
>>
>> Fixing a variable to a register in this way is almost never a good idea.
>> It is /possible/, because there are rare occasions when you want to do
>> so, but such cases are very rare. It is also very easy to break other
>> parts of your program by using register variables like this, due to
>> conflicts with register usage in the library or the compiler. See
>>
>> <http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_regbind>
>>
>> (Note that explicitly recommends /not/ using r8 for this use.)
>>
>>
>>
>> On some versions of gcc, using a "volatile register" variable will give
>> the warning "volatile register variables don't work as you might wish"
>> if -Wall or -Wvolatile-register-var is enabled. For some reason, this
>> warning does not seem to be triggered by avr-gcc while testing.
>> However, the explanation from the manual remains relevant:
>>
>> """
>> -Wvolatile-register-var
>> Warn if a register variable is declared volatile. The volatile
>> modifier does not inhibit all optimizations that may eliminate reads
>> and/or writes to register variables. This warning is enabled by -Wall.
>> """
>>
>>
>> Here are some other comments about global volatile register variables:
>>
>> <http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00657.html>
>> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34351>
>>
>>
>>
>> In summary, you use "register" variables for data that is absolutely
>> speed-critical and used widely throughout your code, and for which
>> dedicating a register makes sense (i.e., almost never). You use
>> "volatile" when you specifically want to limit the compiler's
>> optimisation of the variable. "volatile register" is a conflict of
>> interests, and it does not work as you think it should - the compiler
>> cannot treat it as both a restricted volatile and a highly-optimised
>> register at the same time.
>>
>> Drop the "register", and your code will be fine.
>>
>>
>>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: Volatile bad compiled while

2009-11-27T03:41:41Z

max2009tiny wrote:
> OK
> i can't drop register and i use on this code more register vars and all work
> ok exept
> while clause. That generate bad jump -4 .
>
> My query is why not for removing register clause.
> If memory store all code is +2 bytes for read and +2 any once write var and
> this is over memory limit....
>

Here are some hints that might help you out:

You can't use "register volatile" variables - they don't work.

Using "register" variables will sometimes make code larger, since it
hinders the compiler - do some testing here to be sure.

Using __attribute__((noinline)) will also often make the code larger -
the compiler will spend more instructions putting data in the right
registers for the function call than it would by inlining small functions.

Generally speaking, the compiler is better at optimising when you let it
do its job than when you try and force it using hints like "register"
and "noinline".

Make sure you use -combine and -fwhole-program to compile the code.
-fno-split-wide-types is also often helpful.

You can force a "volatile" read of a register using the register's
memory address:

__attribute__ ((noinline)) void waitACK(u08 cmack)
{
while (cmack != *((volatile u08*)(0x0008))) ;
}

Address 0x0008 is the address of the r8 register. This will force a
volatile read as (using an lds instruction), but you will at least spare
the write.

If all else fails, it is sometimes best to use assembly.

mvh.,

David

>
>
>
> David Brown-4 wrote:
>> max2009tiny wrote:
>>> Hi everybody. I make project on Tiny2313 and use
>>>
>>> volatile register unsigned char lastrec asm("r8")
>>>
>>> and lastrec is modified on rs232 rx isr.
>>>
>>> When compile little function
>>> __attribute__ ((noinline)) void waitACK(u08 cmack)
>>> {
>>> while(cmack!=lastrec) ; //wait for reply request
>>> }
>>>
>>
>> Fixing a variable to a register in this way is almost never a good idea.
>> It is /possible/, because there are rare occasions when you want to do
>> so, but such cases are very rare. It is also very easy to break other
>> parts of your program by using register variables like this, due to
>> conflicts with register usage in the library or the compiler. See
>>
>> <http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_regbind>
>>
>> (Note that explicitly recommends /not/ using r8 for this use.)
>>
>>
>>
>> On some versions of gcc, using a "volatile register" variable will give
>> the warning "volatile register variables don't work as you might wish"
>> if -Wall or -Wvolatile-register-var is enabled. For some reason, this
>> warning does not seem to be triggered by avr-gcc while testing.
>> However, the explanation from the manual remains relevant:
>>
>> """
>> -Wvolatile-register-var
>> Warn if a register variable is declared volatile. The volatile
>> modifier does not inhibit all optimizations that may eliminate reads
>> and/or writes to register variables. This warning is enabled by -Wall.
>> """
>>
>>
>> Here are some other comments about global volatile register variables:
>>
>> <http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00657.html>
>> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34351>
>>
>>
>>
>> In summary, you use "register" variables for data that is absolutely
>> speed-critical and used widely throughout your code, and for which
>> dedicating a register makes sense (i.e., almost never). You use
>> "volatile" when you specifically want to limit the compiler's
>> optimisation of the variable. "volatile register" is a conflict of
>> interests, and it does not work as you think it should - the compiler
>> cannot treat it as both a restricted volatile and a highly-optimised
>> register at the same time.
>>
>> Drop the "register", and your code will be fine.
>>
>>
>>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: Volatile bad compiled while

2009-11-27T02:02:09Z

Ok thanks i use gcc 4.3.2
secondary question is if i remove volatile from code

register unsigned char lastrec asm("r8")

then while generate asm efficient but dont work why?
a0: 88 11 cpse r24, r8
a2: ff cf rjmp .-2 ; 0xa2 <waitACK+0x2>

and without register volatile unsigned char lastrec
make work but big code

ac: 80 91 62 00 lds r24, 0x0062
b0: 98 17 cp r25, r24
b2: e1 f7 brne .-8 ; 0xac <waitACK+0x2>

I understand that gcc miss, but if register is clause to change storing possition of var
and volatile is for "change defining on the fly" i dont understand trouble for gcc compile this ok.

Joerg Wunsch wrote:

max2009tiny <mm@canor-audio.com> wrote:

> Hi everybody. I make project on Tiny2313 and use
>
> volatile register unsigned char lastrec asm("r8")

"volatile register" doesn't work.

There used to be a warning for this, which has been dropped in the
past. GCC 4.4 does have the warning back:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34351

--
cheers, J"org .-.-. --... ...-- -.. . 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: Volatile bad compiled while

2009-11-26T22:19:45Z

max2009tiny <mm@...> wrote:

> Hi everybody. I make project on Tiny2313 and use
>
> volatile register unsigned char lastrec asm("r8")

"volatile register" doesn't work.

There used to be a warning for this, which has been dropped in the
past. GCC 4.4 does have the warning back:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34351

--
cheers, J"org .-.-. --... ...-- -.. . 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@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: Volatile bad compiled while

2009-11-26T06:49:59Z

OK
i can't drop register and i use on this code more register vars and all work ok exept
while clause. That generate bad jump -4 .

My query is why not for removing register clause.
If memory store all code is +2 bytes for read and +2 any once write var and this is over memory limit....

David Brown-4 wrote:

max2009tiny wrote:
> Hi everybody. I make project on Tiny2313 and use
>
> volatile register unsigned char lastrec asm("r8")
>
> and lastrec is modified on rs232 rx isr.
>
> When compile little function
> __attribute__ ((noinline)) void waitACK(u08 cmack)
> {
> while(cmack!=lastrec) ; //wait for reply request
> }
>

Fixing a variable to a register in this way is almost never a good idea.
It is /possible/, because there are rare occasions when you want to do
so, but such cases are very rare. It is also very easy to break other
parts of your program by using register variables like this, due to
conflicts with register usage in the library or the compiler. See

<http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_regbind>

(Note that explicitly recommends /not/ using r8 for this use.)

On some versions of gcc, using a "volatile register" variable will give
the warning "volatile register variables don't work as you might wish"
if -Wall or -Wvolatile-register-var is enabled. For some reason, this
warning does not seem to be triggered by avr-gcc while testing.
However, the explanation from the manual remains relevant:

"""
-Wvolatile-register-var
Warn if a register variable is declared volatile. The volatile
modifier does not inhibit all optimizations that may eliminate reads
and/or writes to register variables. This warning is enabled by -Wall.
"""

Here are some other comments about global volatile register variables:

<http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00657.html>
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34351>

In summary, you use "register" variables for data that is absolutely
speed-critical and used widely throughout your code, and for which
dedicating a register makes sense (i.e., almost never). You use
"volatile" when you specifically want to limit the compiler's
optimisation of the variable. "volatile register" is a conflict of
interests, and it does not work as you think it should - the compiler
cannot treat it as both a restricted volatile and a highly-optimised
register at the same time.

Drop the "register", and your code will be fine.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: Volatile bad compiled while

2009-11-26T04:38:54Z

max2009tiny wrote:

> Hi everybody. I make project on Tiny2313 and use
>
> volatile register unsigned char lastrec asm("r8")
>
> and lastrec is modified on rs232 rx isr.
>
> When compile little function
> __attribute__ ((noinline)) void waitACK(u08 cmack)
> {
> while(cmack!=lastrec) ; //wait for reply request
> }
>

Fixing a variable to a register in this way is almost never a good idea.
It is /possible/, because there are rare occasions when you want to do
so, but such cases are very rare. It is also very easy to break other
parts of your program by using register variables like this, due to
conflicts with register usage in the library or the compiler. See

<http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_regbind>

(Note that explicitly recommends /not/ using r8 for this use.)

On some versions of gcc, using a "volatile register" variable will give
the warning "volatile register variables don't work as you might wish"
if -Wall or -Wvolatile-register-var is enabled. For some reason, this
warning does not seem to be triggered by avr-gcc while testing.
However, the explanation from the manual remains relevant:

"""
-Wvolatile-register-var
Warn if a register variable is declared volatile. The volatile
modifier does not inhibit all optimizations that may eliminate reads
and/or writes to register variables. This warning is enabled by -Wall.
"""

Here are some other comments about global volatile register variables:

<http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00657.html>
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34351>

In summary, you use "register" variables for data that is absolutely
speed-critical and used widely throughout your code, and for which
dedicating a register makes sense (i.e., almost never). You use
"volatile" when you specifically want to limit the compiler's
optimisation of the variable. "volatile register" is a conflict of
interests, and it does not work as you think it should - the compiler
cannot treat it as both a restricted volatile and a highly-optimised
register at the same time.

Drop the "register", and your code will be fine.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Volatile bad compiled while

2009-11-25T06:03:46Z

Hi everybody. I make project on Tiny2313 and use

volatile register unsigned char lastrec asm("r8")

and lastrec is modified on rs232 rx isr.

When compile little function
__attribute__ ((noinline)) void waitACK(u08 cmack)
{
while(cmack!=lastrec) ; //wait for reply request
}

compiler make bad asm
a0: 98 2d mov r25, r8
a2: 98 17 cp r25, r24
a4: e9 f7 brne .-4 ; 0xa2 <waitACK>

To avoid i change while to asm as follow, but i need know why this gcc make. Thanks.

000000a0 <waitACK>:
__attribute__ ((noinline)) void waitACK(u08 cmack)
{
// cmd to wait is in txcmd
// use std ack packet 0x4 0x0 0x2 0xresult 0xtxcmd 0xcksum

asm(" mov r25, r8 ;\n cp r25, r24 ;\n brne .-6 ;");
a0: 98 2d mov r25, r8
a2: 98 17 cp r25, r24
a4: e9 f7 brne .-6 ; 0xa0 <waitACK>

//while(cmack!=lastrec) ; //wait for reply request
}
a6: 08 95 ret