Memory usage inconsistency

linuxgeek

Well-known member
I'm reposting a version of this cause I think the issue would be well served as a separate post, instead of buried in my other thread.

The inconsistent behavior is that memory usage is accurate if a library is accessed as:
<class>.function();

but not via a pointer
<class>->function();

I created a library to demonstrate the difference between the two. I created a library, StealthMemory, which creates and initializes a byte array of 1024. To start off, I followed the example of access that was in RingBuffer (ADC library) example code (pointer access). I attached the library I created, which comes with the example.

Code:
#include <StealthMemory.h>

//StealthMemory sm;
StealthMemory *sm;

void setup() {
/*this faithfully tracks memory usage in arduino IDE*/
//sm = StealthMemory();
//sm.initialize();

/*this does not track memory usage arduino IDE, reports no extra memory usage*/
sm = new StealthMemory();
sm->initialize();
}

void loop() {
}

I used arduino 1.6.5 and 1.6.8/teensyduino1.28
 

Attachments

  • StealthMemory.zip
    2.1 KB · Views: 110
Arduino's memory usage summary can only report static allocated memory. Local variables and stuff allocated on the heap (malloc or new) aren't known at compile time.
 
Ok, that makes some sense to me. I think that libraries often use "new" and pointer access in their examples, so I'm not sure if novices like me know that I need to be wary of including libraries and following their examples, and tracking memory usage. This was tricky for me, cause it didn't fail outright, instead my Serial output got wonky. I was thinking if it was allocated in setup(), it would be reported.

So, if I only want to create something once and never destroy it, the static method above is the preferred way of doing things.
 
IMO, C++ New and malloc shouldn't be used on embedded processors where timing can be critical and RAM is limited (say, less than 256KB).

And for newbies, stack size is important and often you need to be aware of guidelines.
 
When Arduino officially added the RAM usage (it had been done for some time by Teensy and others), quite a long of debate occurred about the wording. The message was a sort of compromise, to let you know other stuff uses the rest of the memory, but not too long to explain what all that stuff really is.

Maybe someday that window will support links, which could allow more detail, without making the default message too long and complicated? A lot of people could benefit from access to the details, but I do believe the Arduino debts had a good point. The default message can't be too complicated, especially for utter novices.
 
Often, such a message can be a simplistic headline. Then a blank line plus "Detail...".
serves both types of users.
 
When Arduino officially added the RAM usage (it had been done for some time by Teensy and others), quite a long of debate occurred about the wording. The message was a sort of compromise, to let you know other stuff uses the rest of the memory, but not too long to explain what all that stuff really is.

Maybe someday that window will support links, which could allow more detail, without making the default message too long and complicated? A lot of people could benefit from access to the details, but I do believe the Arduino debts had a good point. The default message can't be too complicated, especially for utter novices.

I have noticed they like to keep things simple at the cost of annoying the vast majority of intelligent people that want the extra features. They should just consider adding an expert mode. So you have say classic for the new people that keeps the bells and whistles hidden and then once they learn the basics they can turn on expert mode.
 
I have noticed they like to keep things simple at the cost of annoying the vast majority of intelligent people that want the extra features.
How long did Arduino/AVR lack interrupt driven serial port output? Naive users were befuddled that what we call blocking IO was happening and impacting their other code's timing.
 
How long did Arduino/AVR lack interrupt driven serial port output?

They've always had interrupt-based receive, but transmit was done by polling for a very long time, causing the blocking if you sent more than 2 bytes.

Arduino added transmit interrupts in version 1.0, released November 30, 2011.

I added this to Teensyduino in version 0.6, released September 8, 2009 (supporting Arduino version 0012 to 0017).

Teensy 3.0 had it at initial release in October 2012.

I believe Arduino has just recently added serial transmit buffering for Arduino Due. Someone contributed it on github... Arduino didn't develop themselves.

Arduino Zero appears to still not have transmit interrupts.

Arduino 101 (Intel Curie) uses transmit interrupts, added on github Jun 3, 2015, months before 101's initial release in October 2015. Likewise, I've seen a lot of good effort from Intel's people to support libraries on Arduino 101. Long-term, I expect we'll see this board really develop well.
 
Arduino 101 (Intel Curie) uses transmit interrupts, added on github Jun 3, 2015, months before 101's initial release in October 2015. Likewise, I've seen a lot of good effort from Intel's people to support libraries on Arduino 101. Long-term, I expect we'll see this board really develop well.
Opinion alert...
I'll take a pass on Intel's schizophrenic CurieQuark - with its x86 core that has no floating point and a 2nd core that's not ARM based. This schizophrenia is Intel Marketing driving the ship, paranoid about the sea state shift to ARM.
The ARM world, with lots and lots of manufacturers competing in price/features, is the way it needs to be. Not Intel being an anti-ARM dissident and trying the change the orbit and push non-competitive sole-source. They will have some lemmings that go along.
 
Last edited:
Back
Top