AVR Freaks

Is your current program having issues? Are you now trying to have it run as slow as possible....all of this monitoring/overhead will take a huge toll.

I associate the use of the term  "managed pointers" with .Net environments. After a bit of reading it seems to boil down to something very similar to references in C++. So, for all that I can see, not applicable to the OQ (original question). I read this: https://www.infoq.com/news/2015/... .

I can't see how this applies to the OQ. A smart pointer in C++ is a (automatic allocated) container for a pointer to a dynamically allocated object. In short, it will guarantee that the object gets freed when the container goes out of scope. This is what is often referred to as "RAII". Although the acronym is read out as Resource Allocation Is Initialization, it is mostly about this guarantee of de-allocation which 1) guarantees that the destructor will run and 2) that there will be no memory leak (so the slight connection to the OQ is that it applies to allocations schemes like the C++ one - which does not sport reference counting and garbage collection built into the heap management system).

On small uC's (such as AVR) it is veryunusual to use malloc. All memory allocation is usually static, or on the stack for functions.

If there is not enough memory, then switch to a bigger device.

Alternatively, if the application allows, You can declare a (relatively) big array to hold temporary data and re-use that array for differnt data at different times and places in your program.

The easiest and best way to handle memory fragmentation on small uC's it to not fragment thememory at all.

uC's dont run programs for a few hours, but run continously for their whole lifetime ( 20 years or so...).

On Harvard archtitecture chips it is often neccessary to tell the compiler to store static data ONLY in flash.

An often made mistake is to declare (static or not) strings, which permanently occupy valuable ram space.

Adding to clawsons comment above, and using his example code snippet.

Given the address 0x1234 there is no easy/practical way to know that the pointer p points to it.

1) You need to do an exhaustive search of all of memory to find all pointers pointing to that address, and

2) For each memory location so investigated you also need to know it that location actually is a pointer.

The information needed for the second point more or less equates to having type information for each used memory location in the memory.

Now, for a static variable that might be possible if your build included debugging info, which is seldom for production code. Also, debugging info is never propagated all the way to the flash ROM of an AVR. So right there the possibility falls over on it's nose.

Similar for an automatically allocated variable (e.g. a function-local variable), only that it gets somewhat more complicated because of the possibility that the function might recursively call itself. Again, it falls over on it's nose.

For dynamically allocated object (i.e. allocated with malloc() ) it is literally impossible in the general case. E.g. you could have a pointer pointing to a dynamically allocated pointer pointing to a dynamically allocated pointer pointing to... (You get the picture.. Falling over.. Nose.. ).

The solution to this kind of problem is to implement a quite different approach. Let the pointer be a "heavy-wheight" object that not only holds the basic pointer (i.e. a memory address) but also some tag clearly indicating that it is a pointer (and then you might as well include what type of object it potentially points to. Then let all other types of dynamically allocated objects (e.g. structs) also have an embedded tag indicating the objects type. Now you can pick such an object and then search through all objects that are pointers and see if the first object is pointed to by any (or several) of the pointers you find. This, or something similar, is what e.g. the Java run-time and the .Net framework does. This also allows for objects that no longer are pointed to by any pointer to be discarded in a controlled way. Such a discarding algorithm could e.g. be run when memory becomes scarse, or periodically when there is low load on the system, to free up memory. One problem still prevails, and that is fragmented memory, but this problem can also be solved with the information present. Objects can be moved around to "tidy up the memory" and when an object is moved all pointers pointing to it can also be located and corrected. Since objects that are moved might be pointers pointing to other objects this process can easily become costly in CPU time. And you can see that it is costly in memory  consumption. The "tidying-up" process is called "Garbage Collection".

C is a language designed to be highly efficient both when it comes to CPU time and memory consumption. Therefore no such scheme is generated for C programs. C pointers are as light weight as they can be. When a C program is running any pointer is just a simple address (referring to some point in memory). Nothing more.

C pointers are sometimes illustrated as arrows, e.g. drawn on a paper, but while generally good that allegory does not hold all the way. On that piece of paper you can clearly see where the arrow starts. Not so for (C) pointers.

Think of them more as road signs. Now, imagine yourself standing in a town into which many roads lead. Trying to see what points to a certain memory location is akin to standing in that town and ask "What road-signs point to here?" (actually even worse, because when you do an exhaustive search over all of the road network you immediately can identify everything that serves as a road sign - but as noted above, this information is not present for pointer in memory in a C running program.)

Yes. So what. Clearly, the question here was in the context of "C"? 

.NET Micro Framework

http://netmf.github.io/

...

The Microsoft® .NET Micro Framework combines the reliability and efficiency of managed code with the premier development tools of Microsoft Visual Studio® to deliver exceptional productivity for developing embedded applications on small devices. The Microsoft .NET Micro Framework SDK supports development of code, including device I/O, in the C# language using a subset of the .NET libraries, and is fully integrated with the Microsoft Visual Studio® development environment.

...

NETMF went legacy that lead to the birth of TinyCLR OS.

TinyCLR OS

http://www.tinyclr.com/

Microchip

Developer Help

Avoid Memory Allocation Catastrophe

http://microchipdeveloper.com/c:avoid-memory-allocation-catastrophe

...

(last paragraph)

Don’t fall for the seeming ease and expandability of “dynamic memory allocation” in embedded systems. Do the hard work. Define the performance envelope of your application. Figure out, beforehand, how to fail gracefully – degrading performance along the way if necessary. If you invite catastrophe, it will come.

via https://plus.google.com/+MicrochipTech/posts/XZFtRsVFa54