Program size.

Created Thu, 26 May 2011 16:49:56 +0000 by hfb3

hfb3

Thu, 26 May 2011 16:49:56 +0000

The compiled programs are way too big. Example. The Blink program for the arduino came in at .9k, but the blink program for the clipKIT 32 came in at 7k. At this rate, I will run out of space on this ClipKIT 32 long before my Arduino UNO does. Any ideas or suggestions?

Harry

cobbj

Thu, 26 May 2011 17:47:32 +0000

Harry -

This thread discusses it a little bit:

http://chipkit.cc/forum/viewtopic.php?f=6&t=8&p=26&hilit=sketch&sid=6e8230c886fd1f8c45b6f09362a282aa#p26

Basically, even though the size of the sketch is bigger, it's not a linear code size function... each library ends up being a little bigger, but subsequent calls to functions in the library will not increase the total sketch size. As an example, try compiling a sketch that does the basics + digital write... see the sketch size, then add 500 more digital write commands, and you'll see it isn't a linear size increase.

--Jeremy

jasonk

Thu, 26 May 2011 18:05:20 +0000

In future releases, we could probably remove some features that aren't likely to get used. For instance, the PIC32 has the capability of executing functions located in data memory. That requires some extra initialization code at startup. I think we can safely remove some of these things to reduce the code-size footprint. Power users could always add it back in if they wish.

hfb3

Thu, 26 May 2011 20:11:31 +0000

Makes sense. I really could not test that theory yet because most of the larger programs I tried to compile failed. Thanks.

WestfW

Fri, 27 May 2011 07:19:24 +0000

Most obvious source of "Bloat" in "blink.pde" is about 1300 bytes of what looks like generalized timer library (RtccOpen, RtccInit, RtccWaitClockOff, RtccSetTimeAndDate (!))

Right now, it looks like the PIC32 builds are NOT using the gcc switches that permit unused functions to be "garbage collected" from the final binary (-ffunction-sections -fdata-sections) This means that the BLINK binary includes code for analogRead and analogWrite even though it never uses those functions. I don't know if this is an oversight, or whether the PIC32 compiler doesn't support this option, or whether there is some other reason that the developers chose to do this. (Hmm. Looks like it works. Adding the switches in platforms.txt (it's very cool to be able to do this, BTW!) cuts the size of Blink by about 2000 bytes. I suspect the Rtcc library isn't compiled that way, though, so all the rtcc function are still there.)

Also keep in mind that even the Uno32 is more like an Arduino MEGA (43 IO pins, 5 timers, etc), so there is more initialization than on the smaller chips. For example, BLINK compiled for a mega2560 is about 50% bigger than BLINK compiled for atmega328.

Finally, I'd expect the low-level bit manipulation that happens during initialization to be significantly larger on a 32bit RISC machine than on an AVR. Marketing aside, an AVR (and most other 8bit micros) can set or clear a bit in a peripheral configuration register in a single 2-byte instruction, and a RISC can't (I think the best it could hope for is about 4 bytes, and more likely 6: 16bit instruction (possibly including bitnumber, but maybe additional operands for bit number) and 16bit address (to be expanded to 32bits) of peripheral. (I don't know MIPS or ARM assembler, other than vaguely.)

jasonk

Fri, 27 May 2011 16:01:03 +0000

Thanks for the thorough investigation. Yes, garbage collection will definitely help and it's something that we can look into making the default. We should also investigate the granularity of the core and library files to see if there are areas that we can improve to prevent unnecessary code from getting linked.

WestfW

Fri, 27 May 2011 16:48:35 +0000

We should also investigate the granularity of the core and library files to see if there are areas that we can improve to prevent unnecessary code from getting linked.

My perception is that the garbage-collection in the avr toolchain works SO well that the arduino team (and other people writing arduino libraries) is getting pretty lax WRT paying attention to the (arduino) core and library files. ("Should I include this obscure function that might be used by 2% of the users? Sure - there's no downside; it won't be in the binaries that don't use it!") The PIC32 specific libraries are a separate matter. Basic timer initialization shouldn't suck in date and time functions.

(IMO, the program size issue, having become somewhat understood, does not really need to actually be "fixed" anytime soon. One of the facts standing in the way of the success of 32bit Arduino clones in general is that even the 32k/16MHz AVR is more computer than many arduino projects need.)

jasonk

Fri, 27 May 2011 17:02:11 +0000

Thanks for the very constructive feedback. It's really useful.