25 replies to this topic

[Species8372]

Hi CW2, Species8372:

We'll be posting the source for .NET MF 4.2 RC3 firmware in the next few days. Would one of you like to test it with the latest supported version of GCC, and see how big the compiled firmware comes out?

Chris

Hi Chris,

that'd be the first thing i'd do when i get my hands on this source
Thats very good news. Although i wonder why you didnt write "and see how tiny and really small the compiled firmware comes out".

Species8372

[jcoffman98]

So has anyone had any success building ND+ with lwip with GCC? I managed to get it to build without lwip using gcc 4.5.2 but as soon as I add lwip it becomes to large (48k overflow). Seems like it's still not an option even with later versions of gcc unless I am doing something wrong.

[CW2]

So has anyone had any success building ND+ with lwip with GCC? I managed to get it to build without lwip using gcc 4.5.2 but as soon as I add lwip it becomes to large (48k overflow). Seems like it's still not an option even with later versions of gcc unless I am doing something wrong.

You are not doing anything wrong, there is a problem with C runtime library (aka newlib) size, printf-family functions are significantly bigger than those used by RVCT. I have managed to build Netduino Go GCC firmware which is now about ~10% larger than the official (ARM RVDS output) by recompiling the newlib with some additional options. I have not tried to build neither Netduino nor Netduino Plus firmware with that.

CFLAGS_FOR_TARGET="-ffunction-sections -fdata-sections
-DPREFER_SIZE_OVER_SPEED -D__OPTIMIZE_SIZE__ -Os -fomit-frame-pointer -D__BUFSIZ__=256"

I have also tried uClibc, even went though the Canadian cross using crosstool-NG in an attempt to build custom toolchain, unfortunately I had to abandon that way due to limited resources and because reportedly the newlib can be tweaked to produce output comparable to uClibc.

[jcoffman98]

You are not doing anything wrong, there is a problem with C runtime library (aka newlib) size, printf-family functions are significantly bigger than those used by RVCT. I have managed to build Netduino Go GCC firmware which is now about ~10% larger than the official (ARM RVDS output) by recompiling the newlib with some additional options. I have not tried to build neither Netduino nor Netduino Plus firmware with that.

CFLAGS_FOR_TARGET="-ffunction-sections -fdata-sections
-DPREFER_SIZE_OVER_SPEED -D__OPTIMIZE_SIZE__ -Os -fomit-frame-pointer -D__BUFSIZ__=256"

I have also tried uClibc, even went though the Canadian cross using crosstool-NG in an attempt to build custom toolchain, unfortunately I had to abandon that way due to limited resources and because reportedly the newlib can be tweaked to produce output comparable to uClibc.

Thanks for the reply. I will try recompiling newlib and then the firmware and see where that gets me. I assume that would require me to rebuild the arm toolchain from source?

[CW2]

Thanks for the reply. I will try recompiling newlib and then the firmware and see where that gets me. I assume that would require me to rebuild the arm toolchain from source?

Well, I found out it is rather easy to recompile the whole Yagarto toolchain, because it comes with very handy build scripts, so it is necessary just to modify the one used to build newlib (07-build-newlib.sh). It should be possible to just compile newlib, but you'd need to ensure all the options are correct, so there are binaries built for proper platform, with correct prefix so linker can find them etc.

Althought there might be one way to accommodate bigger firmware in the flash: by rearranging the flash memory layout and removing unused features, if there are any. I am not sure how many features you could remove to free enough space and leave the firmware to be usable, or enough flash blocks in application deployment area that can be moved to code region, but maybe if you are lucky, it can be done.

And, a bonus idea: if you don't mind updating the firmware via Atmel SAM-BA, you can compile version without the bootloader, which will free a few flash blocks at the beginning (14 blocks of 'bootstrap' type).

[jcoffman98]

Well, I found out it is rather easy to recompile the whole Yagarto toolchain, because it comes with very handy build scripts, so it is necessary just to modify the one used to build newlib (07-build-newlib.sh). It should be possible to just compile newlib, but you'd need to ensure all the options are correct, so there are binaries built for proper platform, with correct prefix so linker can find them etc.

Althought there might be one way to accommodate bigger firmware in the flash: by rearranging the flash memory layout and removing unused features, if there are any. I am not sure how many features you could remove to free enough space and leave the firmware to be usable, or enough flash blocks in application deployment area that can be moved to code region, but maybe if you are lucky, it can be done.

And, a bonus idea: if you don't mind updating the firmware via Atmel SAM-BA, you can compile version without the bootloader, which will free a few flash blocks at the beginning (14 blocks of 'bootstrap' type).

You last suggestion is basically what I did to get it working with all the features. I would like to have some in field updating capability so no boot-loader isn't an option for the final product.

I've been using the mentor graphics tool-chain, do they use a different c lib? I haven't looked into building it but they do provide the source. I haven't built a cross compiler in about 10 years I hope its more fun than it used to be

Thanks,

Jeff