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

[Joerg Wunsch]

Ken Lauffenburger <[EMAIL PROTECTED]> wrote:

> I recently built the avr-gcc toolchain on my Gentoo AMD-64 system.
> I used the following command to build it:

> crossdev --target avr

Whatever that command does -- but it appears to me therein lies the
rub, so better contact the author of that command about it.

Does Gentoo no longer have portage compilations for the AVR toolchain?
It used to have well-maintained once by the time Henrik Brix Andersen
was in charge of maintaining them.

-- 
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: [avr-gcc-list] Standard IO - function fwrite

[Joerg Wunsch]

Marjan Fojkar <[EMAIL PROTECTED]> wrote:

> I expected that if one byte is successfully written then the
> function returns 1 if byte is not written then it returns 0.

This is how it works.

> In case of error it returns e.g. EOF.

No, it returns a `short write count' (less than requested), i.e.  it
could only be zero in your case since you only request one object.

This is exactly how the C standard requires it.

Of course, this all depends whether your backend put() function can
actually return an error indication.

-- 
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

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

[Ken Lauffenburger]

Hello,

I'm a newbie to this list, so please forgive me if this is an elementary
problem.

I recently built the avr-gcc toolchain on my Gentoo AMD-64 system.  I
used the following command to build it:


crossdev --target avr


It seemed to work fine.  However to test the installation I downloaded
two different projects from the avrfreaks site and tried to build them.
I ran into the same issue with both of them:


avr-gcc (GCC) 3.4.6 (Gentoo 3.4.6, ssp-3.4.5-1.0, pie-8.7.9)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Linking: main.elf
avr-gcc -mmcu=atmega169 -I. -g -DF_CPU=100UL -Os -funsigned-char 
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes 
-Wa,-adhlns=main.o  -std=gnu99 -Wundef -MMD -MP -MF .dep/main.elf.d main.o 
timer0.o BCD.o usart.o ADC.o RTC.o bfeeprom.o dataflash.o button.o 
LCD_functions.o LCD_driver.o vcard.o sound.o test.o --output main.elf 
-Wl,-Map=main.map,--cref -lm
/usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr5.x: No 
such file or directory


So apparently avr-ld can't locate the ldscripts/avr5.x file.

Checking out the subdirectory tree where avr-gcc tools are stored, I
find the following:


mercury:~> cd /usr/lib/gcc/avr
mercury:/usr/lib/gcc/avr> ls -ltra
total 0
drwxr-xr-x 6 root root 408 Jun  4 22:33 3.4.6
drwxr-xr-x 4 root root 112 Jun  4 22:33 ..
drwxr-xr-x 3 root root  72 Jun  4 22:33 .
mercury:/usr/lib/gcc/avr> find . -type d
.
./3.4.6
./3.4.6/avr3
./3.4.6/avr4
./3.4.6/avr5
./3.4.6/include
mercury:/usr/lib/gcc/avr> ls -ltra ./3.4.6
total 196
-rw-r--r-- 1 root root   7676 Jun  4 22:33 vanilla.specs
-rw-r--r-- 1 root root   7676 Jun  4 22:33 specs
-rw-r--r-- 1 root root   3348 Jun  4 22:33 libgcov.a
-rw-r--r-- 1 root root 145838 Jun  4 22:33 libgcc.a
-rw-r--r-- 1 root root   7682 Jun  4 22:33 hardenednossp.specs
-rw-r--r-- 1 root root   7678 Jun  4 22:33 hardenednopiessp.specs
-rw-r--r-- 1 root root   7682 Jun  4 22:33 hardenednopie.specs
-rw-r--r-- 1 root root   7686 Jun  4 22:33 hardened.specs
drwxr-xr-x 2 root root336 Jun  4 22:33 include
drwxr-xr-x 2 root root104 Jun  4 22:33 avr5
drwxr-xr-x 2 root root104 Jun  4 22:33 avr4
drwxr-xr-x 2 root root104 Jun  4 22:33 avr3
drwxr-xr-x 3 root root 72 Jun  4 22:33 ..
drwxr-xr-x 6 root root408 Jun  4 22:33 .
mercury:/usr/lib/gcc/avr> ls -ltra ./3.4.6/avr5
total 144
-rw-r--r-- 1 root root   3348 Jun  4 22:33 libgcov.a
-rw-r--r-- 1 root root 142820 Jun  4 22:33 libgcc.a
drwxr-xr-x 6 root root408 Jun  4 22:33 ..
drwxr-xr-x 2 root root104 Jun  4 22:33 .
mercury:/usr/lib/gcc/avr> which avr-ld
/usr/bin/avr-ld
mercury:/usr/lib/gcc/avr> l /usr/bin/avr-ld
lrwxrwxrwx 1 root root 23 Jun  4 22:29 /usr/bin/avr-ld -> 
/usr/libexec/gcc/avr/ld
mercury:/usr/lib/gcc/avr> l /usr/libexec/gcc/avr/
total 0
lrwxrwxrwx 1 root root  54 Jun  4 22:29 strip -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/strip
lrwxrwxrwx 1 root root  56 Jun  4 22:29 strings -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/strings
lrwxrwxrwx 1 root root  53 Jun  4 22:29 size -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/size
lrwxrwxrwx 1 root root  56 Jun  4 22:29 readelf -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/readelf
lrwxrwxrwx 1 root root  55 Jun  4 22:29 ranlib -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/ranlib
lrwxrwxrwx 1 root root  56 Jun  4 22:29 objdump -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/objdump
lrwxrwxrwx 1 root root  56 Jun  4 22:29 objcopy -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/objcopy
lrwxrwxrwx 1 root root  51 Jun  4 22:29 nm -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/nm
lrwxrwxrwx 1 root root  51 Jun  4 22:29 ld -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/ld
lrwxrwxrwx 1 root root  56 Jun  4 22:29 c++filt -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/c++filt
lrwxrwxrwx 1 root root  51 Jun  4 22:29 as -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/as
lrwxrwxrwx 1 root root  51 Jun  4 22:29 ar -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/ar
lrwxrwxrwx 1 root root  58 Jun  4 22:29 addr2line -> 
/usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.16.1/addr2line
drwxr-xr-x 4 root root 112 Jun  4 22:29 ..
drwxr-xr-x 2 root root  96 Jun  4 22:33 3.4.6
drwxr-xr-x 3 root root 392 Jun  4 22:33 .
mercury:~> cd /usr/x86_64-pc-linux-gnu/avr/lib/
mercury:/usr/x86_64-pc-linux-gnu/avr/lib> l
total 0
lrwxrwxrwx 1 root root  42 Jun  4 22:29 libopcodes.so -> 
/usr/lib/binutils/avr/2.16.1/libopcodes.so
lrwxrwxrwx 1 root root  42 Jun  4 22:29 libopcodes.la -> 
/usr/lib/binutils/avr/2.16.1/libopcodes.la
lrwxrwxrwx 1 root root  41 Jun  4 22:29 libopcodes.a -> 
/usr/lib/binutils/avr/2.16.1/libopcodes.a
lrwxrwxrwx 1 root root  49 Jun  4 22:29 libopcodes-2.16.1.so -> 
/usr/lib/binutils/avr/2.16.1/libopcodes-2.16.1.so
lrwxrwxrwx 1 root root  40 Ju

RE: [avr-gcc-list] Mega2561 compilation problem

[Eric Weddington]

What versions of the compiler are you using, for both AtmanAVR and WinAVR?

I'm sure that the WinAVR package has more up-to-date patches to the compiler
than AtmanAVR...

Eric 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Parthasaradhi Nayani
> Sent: Wednesday, June 06, 2007 8:28 AM
> To: Stu Bell; avr-gcc-list@nongnu.org
> Subject: RE: [avr-gcc-list] Mega2561 compilation problem
> 
> Hello Stu Bell,
> Thanks for your suggestions, but the code compiled using 
> atman AVR is the same code we compiled using WinAvr. 
> Surprisingly the code compiled using WinAvr resets the 
> controller whereas code from Atman does not. We are not using 
> any special SP initialization etc. We are using the default 
> startup files of WinAvr. Thank you.
> 
> Regards
> Nayani
> 
> 
> Stu Bell <[EMAIL PROTECTED]> wrote:
> 
>   Your usage of stack will go up with the 2561, since a 
> subroutine return address is now 3 bytes instead of 2.  Be 
> sure that you properly account for that in any stack 
> initialization that you do, and in all code that may use RAM.
>   Best regards, 
>   Stu Bell 
>   DataPlay (DPHI, Inc.) 
>   
> 
> 
>   From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> On Behalf Of Parthasaradhi Nayani
>   Sent: Wednesday, June 06, 2007 6:07 AM
>   To: avr-gcc-list@nongnu.org
>   Subject: [avr-gcc-list] Mega2561 compilation problem
>
>   Hello all,
>   We were using a Mega128 in one of our boards and we had 
> to shift to Mega2561 as the requirement for program memory 
> increased with advanced functional demands. We used Atman AVR 
> demo and the code worked without a hitch. However when we use 
> new (latest) WinAvr, the controller is resetting at one point 
> or the other. We are using many sprintf_P functions to save 
> RAM memory. Any clues, suggestions in helping us solve the 
> problem will be highly appreciated. Thank you.
>   
>   Regards
>   Nayani P
> 
>   
> 
> 
>   Be a better Heartthrob. Get better relationship answers 
>  /_ylc=X3oDMTI5MGx2aThyBF9TAzIxMTU1MDAzNTIEX3MDMzk2NTQ1MTAzBHNl
> YwNCQUJwaWxsYXJfTklfMzYwBHNsawNQcm9kdWN0X3F1ZXN0aW9uX3BhZ2U-?l
> ink=list&sid=396545433> from someone who knows.
>   Yahoo! Answers - Check it out. 
> 
> 
> 
> 
> 8:00? 8:25? 8:40? Find a flick 
>  >  in no time
> with theYahoo! Search movie showtime shortcut. 
>  
> 



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

Re: [avr-gcc-list] Standard IO - function fwrite

[Marjan Fojkar]

Has anyone used function fwrite? I think it does not return right
value.  It should return number of objects successfully written but
in my case it returns written character.


Joerg Wunsch wrote:
As your object has a size of 1, both values are the same.  What did
you expect?
  
I expected that if one byte is successfully written then the function 
returns 1 if byte is not written then it returns 0. In case of error it 
returns e.g. EOF.
In my case the function "behaves" like function putc (writting one 
object of size 1). I didn't try to use it with more that one object at 
once so i can say what it returns in other cases.



Marjan


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

RE: [avr-gcc-list] Mega2561 compilation problem

[Parthasaradhi Nayani]

Hello Stu Bell,
Thanks for your suggestions, but the code compiled using atman AVR is the same 
code we compiled using WinAvr. Surprisingly the code compiled using WinAvr 
resets the controller whereas code from Atman does not. We are not using any 
special SP initialization etc. We are using the default startup files of 
WinAvr. Thank you.

Regards
Nayani


Stu Bell <[EMAIL PROTECTED]> wrote:v\:* {behavior:url(#default#VML);} 
o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape 
{behavior:url(#default#VML);} st1\:*{behavior:url(#default#ieooui) }
   Your usage of stack will go up with the 2561, since a subroutine return 
address is now 3 bytes instead of 2.  Be sure that you properly account for 
that in any stack initialization that you do, and in all code that may use RAM.
Best regards, 
  Stu Bell 
 DataPlay (DPHI, Inc.) 
  
  
-
  
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Parthasaradhi 
Nayani
 Sent: Wednesday, June 06, 2007 6:07 AM
 To: avr-gcc-list@nongnu.org
 Subject: [avr-gcc-list] Mega2561 compilation problem
  
   
  Hello all,
 We were using a Mega128 in one of our boards and we had to shift to Mega2561 
as the requirement for program memory increased with advanced functional 
demands. We used Atman AVR demo and the code worked without a hitch. However 
when we use new (latest) WinAvr, the controller is resetting at one point or 
the other. We are using many sprintf_P functions to save RAM memory. Any clues, 
suggestions in helping us solve the problem will be highly appreciated. Thank 
you.
 
 Regards
 Nayani P


-
  
  Be a better Heartthrob. Get better relationship answers from someone who 
knows.
 Yahoo! Answers - Check it out. 
  
  

 
-
8:00? 8:25? 8:40?  Find a flick in no time
 with theYahoo! Search movie showtime shortcut.___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: [avr-gcc-list] Mega2561 compilation problem

[Stu Bell]

Your usage of stack will go up with the 2561, since a subroutine return
address is now 3 bytes instead of 2.  Be sure that you properly account
for that in any stack initialization that you do, and in all code that
may use RAM.

Best regards, 

Stu Bell 
DataPlay (DPHI, Inc.) 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Parthasaradhi Nayani
Sent: Wednesday, June 06, 2007 6:07 AM
To: avr-gcc-list@nongnu.org
Subject: [avr-gcc-list] Mega2561 compilation problem

 

Hello all,
We were using a Mega128 in one of our boards and we had to shift to
Mega2561 as the requirement for program memory increased with advanced
functional demands. We used Atman AVR demo and the code worked without a
hitch. However when we use new (latest) WinAvr, the controller is
resetting at one point or the other. We are using many sprintf_P
functions to save RAM memory. Any clues, suggestions in helping us solve
the problem will be highly appreciated. Thank you.

Regards
Nayani P

  

  _  

Be a better Heartthrob. Get better relationship answers
 from
someone who knows.
Yahoo! Answers - Check it out. 

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

Re: [avr-gcc-list] Mega2561 compilation problem

[Francesco Sacchi]

Parthasaradhi Nayani ha scritto:

Hello all,
We were using a Mega128 in one of our boards and we had to shift to 
Mega2561 as the requirement for program memory increased with advanced 
functional demands. We used Atman AVR demo and the code worked without a 
hitch. However when we use new (latest) WinAvr, the controller is 
resetting at one point or the other. We are using many sprintf_P 
functions to save RAM memory. Any clues, suggestions in helping us solve 
the problem will be highly appreciated. Thank you.




Have you checked watchdog timeout?
--
 _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
  |\ http://www.develer.com/


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

[avr-gcc-list] Mega2561 compilation problem

[Parthasaradhi Nayani]

Hello all,
We were using a Mega128 in one of our boards and we had to shift to Mega2561 as 
the requirement for program memory increased with advanced functional demands. 
We used Atman AVR demo and the code worked without a hitch. However when we use 
new (latest) WinAvr, the controller is resetting at one point or the other. We 
are using many sprintf_P functions to save RAM memory. Any clues, suggestions 
in helping us solve the problem will be highly appreciated. Thank you.

Regards
Nayani P


   
-
Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers - Check it out. ___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: [avr-gcc-list] Standard IO - function fwrite

[Joerg Wunsch]

Marjan Fojkar <[EMAIL PROTECTED]> wrote:

> Has anyone used function fwrite? I think it does not return right
> value.  It should return number of objects successfully written but
> in my case it returns written character.

As your object has a size of 1, both values are the same.  What did
you expect?

-- 
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