Re: AVR32 Toolchain Build (was Re: Ok if I hack ADC for AVR32?)

[Martin Guy]

Hi James, I'm adding the list to this post as I think it's of general
(if specialised) interest.

On 20 April 2011 19:51, James Snyder <[hidden email]> wrote:

> On Fri, Apr 15, 2011 at 12:55 PM, Martin Guy <[hidden email]> wrote:
>> On 15 April 2011 18:19, James Snyder <[hidden email]> wrote:
>>> Side question: which avr toolchain are you using
>> The AVR one, gcc-4.3.2
>>
>>> and have you had issues with floating point printf?
>> Floating point? What's that? :D
>> But no, I've had no problems, apart from their stopping distro support
>> and integrating it into the huge AVR32 studio thing.
>
> OK, I did finally get the AS5 patches to build a toolchain, and
> floating point works for me in that version so it appears to have been
> a toolchain issue.  While this one is getting quite a bit more
> complicated than my arm-eabi makefile, I posted an avr32 makefile
> which works for me on OS X and built for me on an Ubuntu box (haven't
> tested the binaries it generates yet):
> https://github.com/jsnyder/avr32-toolchain
>
> Interestingly, unless I'm missing something the avr32 newlib seemed to
> be a lot less sensitive in terms of space savings when I turned on all
> the extra options I use for the arm toolchain beyond what's used for
> the 2 examples of avr32 builds I've found out there.
>
> Building out of trunk I got images like this:
>
> Minimal Space Saving Options on Newlib:
> only: --enable-target-optspace
>  text     data     bss     dec     hex filename
> 119808     1364    1480  122652   1df1c elua_lualong_at32uc3a0128.elf
>
> More Extensive Space Saving Options on Newlib:
> NEWLIB_FLAGS="-ffunction-sections -fdata-sections       \
> -DPREFER_SIZE_OVER_SPEED -D__OPTIMIZE_SIZE__ -g -Os     \
> -fomit-frame-pointer -fno-unroll-loops -D__BUFSIZ__=128 \
> -DSMALL_MEMORY"
> &
> --enable-target-optspace
>  text     data     bss     dec     hex filename
> 119296     1364    1480  122140   1dd1c elua_lualong_at32uc3a0128.elf
>
> One of the things that was interesting me with trying to build the
> toolchain myself was experimenting with stuff like this.  Some of this
> might have some value in the whole stack space & conserving SRAM issue
> as well maybe?  I haven't done any comparisons there.  It might also
> be that since the AVR32 port is younger that it doesn't have as many
> of these options for using fast but space hungry vs simple but slower.
>
>>
>>>  I built a chain using crosstool ng and it seems fine for int but for builds in the recent past I would get "g" whenever trying to print a float.
>> Strange. You could ask on the crosstool-ng mailing list... if you can
>> fix it, the maintainer is very responsive
>
> I'll send a ping in their direction to see if it's something on their
> radar.  If not, I'll try and whip up a test case if I can.  Given I
> now have a working version and a broken version and it likely has
> something to do with printf, perhaps it wouldn't be too hard to figure
> out what's broken :-)

Nice! Built and installed perfectly, just following your instructions.

Default Mizar32 build of git trunk:

122196 bytes with Atmel GCC 4.3.2
120660 bytes with jsnyder GCC 4.4.3

    M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

I suppose I was waiting until I had some confirmation that things
worked on Linux before mentioning it on the list. Sounds like it does
currently.  Feedback is welcome :-)

On Wed, Apr 20, 2011 at 11:28 PM, Martin Guy <[hidden email]> wrote:

> Hi James, I'm adding the list to this post as I think it's of general
> (if specialised) interest.
>
> On 20 April 2011 19:51, James Snyder <[hidden email]> wrote:
>> On Fri, Apr 15, 2011 at 12:55 PM, Martin Guy <[hidden email]> wrote:
>>> On 15 April 2011 18:19, James Snyder <[hidden email]> wrote:
>>>> Side question: which avr toolchain are you using
>>> The AVR one, gcc-4.3.2
>>>
>>>> and have you had issues with floating point printf?
>>> Floating point? What's that? :D
>>> But no, I've had no problems, apart from their stopping distro support
>>> and integrating it into the huge AVR32 studio thing.
>>
>> OK, I did finally get the AS5 patches to build a toolchain, and
>> floating point works for me in that version so it appears to have been
>> a toolchain issue.  While this one is getting quite a bit more
>> complicated than my arm-eabi makefile, I posted an avr32 makefile
>> which works for me on OS X and built for me on an Ubuntu box (haven't
>> tested the binaries it generates yet):
>> https://github.com/jsnyder/avr32-toolchain
>>
>> Interestingly, unless I'm missing something the avr32 newlib seemed to
>> be a lot less sensitive in terms of space savings when I turned on all
>> the extra options I use for the arm toolchain beyond what's used for
>> the 2 examples of avr32 builds I've found out there.
>>
>> Building out of trunk I got images like this:
>>
>> Minimal Space Saving Options on Newlib:
>> only: --enable-target-optspace
>>  text     data     bss     dec     hex filename
>> 119808     1364    1480  122652   1df1c elua_lualong_at32uc3a0128.elf
>>
>> More Extensive Space Saving Options on Newlib:
>> NEWLIB_FLAGS="-ffunction-sections -fdata-sections       \
>> -DPREFER_SIZE_OVER_SPEED -D__OPTIMIZE_SIZE__ -g -Os     \
>> -fomit-frame-pointer -fno-unroll-loops -D__BUFSIZ__=128 \
>> -DSMALL_MEMORY"
>> &
>> --enable-target-optspace
>>  text     data     bss     dec     hex filename
>> 119296     1364    1480  122140   1dd1c elua_lualong_at32uc3a0128.elf
>>
>> One of the things that was interesting me with trying to build the
>> toolchain myself was experimenting with stuff like this.  Some of this
>> might have some value in the whole stack space & conserving SRAM issue
>> as well maybe?  I haven't done any comparisons there.  It might also
>> be that since the AVR32 port is younger that it doesn't have as many
>> of these options for using fast but space hungry vs simple but slower.
>>
>>>
>>>>  I built a chain using crosstool ng and it seems fine for int but for builds in the recent past I would get "g" whenever trying to print a float.
>>> Strange. You could ask on the crosstool-ng mailing list... if you can
>>> fix it, the maintainer is very responsive
>>
>> I'll send a ping in their direction to see if it's something on their
>> radar.  If not, I'll try and whip up a test case if I can.  Given I
>> now have a working version and a broken version and it likely has
>> something to do with printf, perhaps it wouldn't be too hard to figure
>> out what's broken :-)
>
> Nice! Built and installed perfectly, just following your instructions.
>
> Default Mizar32 build of git trunk:
>
> 122196 bytes with Atmel GCC 4.3.2
> 120660 bytes with jsnyder GCC 4.4.3
>
>    M
>

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev