Is it "safe" to use "new" keyword to instantize several sensor objects?

Question

I've read that it is bad practice to use dynamic memory allocations on a microcontroller and I have a pretty good grasp of why.

I am developing a custom PCB around an ATMega2560 and in my situation, I need to create 24 objects for one kind of sensor and 8 more for another.

With a small number of sensors, you might create objects like this:

Ezo_board PH = Ezo_board(99, "PH"); //create a PH circuit object, who's address is 99 and name is "PH"
Ezo_board EC = Ezo_board(100, "EC"); //create an EC circuit object who's address is 100 and name is "EC"

But since I have so many and I want to loop through them I created a pointer array Ezo_board *EC[maxEC];

and in setup function I wrote:

for (uint8_t i = 0; i < maxEC; i++)
 {
 EC[i] = new Ezo_board(i+11) //passing the I2C address which start at 11 and increment

I never delete the Ezo_board objects in the code. Is this a safe way to use dynamic memory allocation or is there a better way to do this while still maintaining ability to loop through the sensors in subsequent code?

• KIIV: Why do you think you need dynamic allocation? It can be Ezo_board boards[] = {{99,"PH"}, {100,"EC"}, };, or if it has ambiguous constructors you'll need ` = {Ezo_board(99, "PH"), Ezo_board(100, "EC"), }`
• MattD: My concern was with hard coding all the sensors in when I may wish to adjust the number of sensors used on a given board. By defining a number of sensors (maxEC), I just need to change a constant.
• KIIV: Well, arduino supports c++11 standard for a while, you can use range based for loop like: for (auto & sensor : sensors) { ... and you don't have to know the size
• MattD: I hadn't heard of range based loops before, I'll look that up!

Answer 1

The danger in using dynamic memory on embedded devices lies in repeated allocation & de-allocation of chunks of memory. The memory allocator splits off a piece of memory for each allocation. When one is returned the de-allocator joins it - or should join it - with an adjacent free chunk, if there is one, to create a larger free chunk instead of two adjacent smaller ones. But that is a big 'if': 1) does the particular memory-manager even try to do that? and 2) in too many instances, it won't even be possible.

The net result is that the memory pool becomes a bunch of small fragments that aren't join-able and aren't large enough to satisfy further requests.

In your scenario, dynamic allocation at the start of the run with no further returns and re-alloacation, there is very little difference between it and static allocation, other than the static allocation would have be done at load-time, just before the run begins.

Either way is fine in that case. If anyone else might ever look over your code, or if someday in the future you might come back to it and wonder whether this application might have created a fragmentation problem, then it's worth leaving a comment to make your intentions clear.

I should add here that when I need dynamic allocation in an embedded system, I write my own memory allocator that never splits free memory. Instead, it simply hands out one buffer from a statically allocated array of fixed size buffers for any request up to that size (and returns a failure code otherwise). Memory is never split or joined, so it never gets fragmented. As long as the demand for buffers is predictable and you allocate enough of them to meet the maximum demand, your system won't fail for running out of memory.

Answer 2

Yes, it is (in common sense) bad practise and you know why and you probabelly also know, why it is not problem in your case.

It is perfectly safe way and I do not see, why you should not do it this way.

I do similar things regularry and I have no problem with it.

I want my code working right and the readibility and maintainability are the more important steps in this way. So I structure my code in such way, that I can understand it easily even after couple of years.

There are many rules, how to make code better and there is some reason after each one. But some goes against others.

I have Arduino for fun and I use the rules as recomendations, but I am the Master of my code. So I sometime take other ways.

If it helps me to see the code better organized, I have not problem to do things my own way.

(In large corporation, where you must share code with many others, the formal rules are more important, as they helps all to be at the same platform. There you are payed to stick to rules.

In home developement I share code mainly with myself and I am not paid. So I have to care mainly only about future me)