Memory Overhead, Oh My!

[Mac 67]

Just playing around and I noticed that the first occurrence of a pinMode() instruction costs 172 bytes of program memory and 10 more bytes for each additional occurrence (I'm using MSP430G2231). Then the first occurrence of a digitalWrite() instruction costs 50 bytes of memory and 10 more bytes for each additional occurrence. Using a P1DIR = 0xFF instruction to set all port 1 pins to outputs costs only 4 bytes. So, after eliminating the pinMode() instructions in favor of a P1DIR= instruction I noticed that the first occurrence of a digitalWrite() instruction now costs 94 bytes of memory and 10 more bytes for each additional occurrence.

 

May I ask if this behavior has something to do with library code being linked into the program at the first occurrence of these instructions? I'd love to know how this stuff works while we have so much expertise hanging around (and before this thing explodes into thousands of users). May I also ask if there's any way to improve this seemingly excessive memory usage?

 

TIA. Cheerful regards, Mike

[energia 485]

The bulk of the first 172 bytes are due to a bunch of lookup arrays that being linked in. These arrays take care of the pin to part mapping, pin to bit mask, etc. The rest of it is the function itself. These arrays and the function itself are only linked once and hence you only see a small increment on each additional call to the function.

 

Unfortunately abstraction and ease of use comes at a (memory) price. There is most definitely room for improvement but comparing memory usage to similar platforms (viewtopic.php?f=38&t=2752#p20722) Energia is not that bad at all.

 

Hope this helps.

 

Robert

[Mac 67]

Ahh, of course. That makes perfect sense... One of the PinMode parameters could be a variable and not always a constant, and so you don't always have a way to resolve the parameter to a constant at compile time. In that case you must use run time code (tables) to resolve the pin parameter into the constant you need for working pinMode() output code. But how about those pinMode() instructions that do use a constant pin parameter? If your sketch only used constant parameters, wouldn't it be nice if the compiler could generate the nice four word output code for each of those instructions? If that were the case, a set of eight pinMode() instructions would only cost 32 bytes of memory instead of 242 bytes (ouch!).

 

Thank you for taking time to answer my 'dumb' questions, Robert. I really appreciate it. You're helping me to understand the real cost of "abstraction and ease-of-use" for these Arduino style development systems. I think I need to focus more on "the big picture" and benefits and much less on some of the objectionable aspects (grin).

 

Cheerful regards, Mike

[rockets4kids 204]

Welcome to Arduino. ;-)

 

BTW, the cycle count to execute them is the real killer.

 

That's the price you have to pay for simplicity.

[energia 485]

It would be possible to make some decisions at compile time. Rickta59 did a great job with his C++ templates for a different project. Rick and myself discussed yesterday if we could do some of these optimizations in Energia. The downside is that it would make Energia a lot faster. This sounds odd but in reality some of the Arduino code relies on the "slowness" for code to work correctly. It is thus wise to stay as close to the Arduino slowness as possible to ensure maximum compatibility.

[websterling 12]

It is thus wise to stay as close to the Arduino slowness as possible to ensure maximum compatibility.

 

Do we really need to maximize compatibility with the Arduino? If there's something that's MSP430 specific that offers an improvement to Energia, then maintaining Arduino compatibility shouldn't hold Energia back from incorporating the improvement. Energia should be Arduino-like, rather than Arduino compatible.

 

This doesn't have to be "No Microprocessor Left Behind."

[Automate 69]

Maybe a compiler directive where the user could specify Arduino compatibility or MSP430 optimized.