Hello everyone, I want to know how to know the current bounds of HEAP while the program is running. Also is HEAP a continuous separate section or is it mixed with other sections like is it sprinkled in between static data? I'm completely new to all this can you give me an in-depth overview? I want to write a new class similar to the String class without the problem of heap fragmentation. Rather than always using C strings which is not as friendly as String, I would like to write a class so that I can have the advantage of String.
Also, how can I write to addresses directly and read from them?
Thanks for all the help! 
Rather than always using C strings which is not as friendly as String, I would like to write a class so that I can have the advantage of String.
C strings are neither friendly or unfriendly. They simply involve a different mindset.
The String class has some nice features. What it does not do well is manage the memory needed to allow a String to grow as needed. Your class must do memory management better than the String class, or ridicule will be heaped on it, too.
Also, how can I write to addresses directly and read from them?
Write what to what address? You can only write directly to a memory location using assembler. The indirect methods, like x = 14; are far easier to use.
I'm completely new to all this
So, what makes you think you can write a class that is better, for some definition of better, than String? You need more than ego for that.
suersaiyangod:
Rather than always using C strings which is not as friendly as String, I would like to write a class so that I can have the advantage of String.
what do you think is the advantage of the String class (in this context)? the operators?
PaulS:
Write what to what address? You can only write directly to a memory location using assembler. The indirect methods, like x = 14; are far easier to use.
So, what makes you think you can write a class that is better, for some definition of better, than String? You need more than ego for that.
Yes directly to memory locations. Yes, of course, I need more than just ego for that but just because I am new to this doesn't mean I can't, after all, everyone is at some point. If I had sounded like I was condescending the current class I apologize and I didn't mean it that way. I have written functions to write Strings to EEPROM and I think that method can be incorporated in the class that I'm writing.
BulldogLowell:
what do you think is the advantage of the String class (in this context)? the operators?
If I had to use a character array then I would need to specify the length of the array during declaring and I may end up needing more space. The String class doesn't have this problem as I can assign any sentence regardless of its size, I hope you get my point. That is the main feature I'm after since there are functions that do the same as operators like strcmp().
My idea for solving the heap fragmentation problem is to move the consecutive addresses away or "pull" them closer to accommodate the new size of the String. I have implemented this method in my function for writing Strings to EEPROM while overwriting a String that is already stored.
link:Arduino is freezing after running function twice - Programming Questions - Arduino Forum
Thanks for your time
why chase rainbows? just learn C strings
why chase rainbows?
Because there is a pot of gold at the end.
Of course, there is also a leprechaun with a baseball bat. 8)
Can you tell some good websites where I can learn it? And my main concern is that I have to specify the length of the character array at the time of declaration which is hard for me to predict.
BulldogLowell:
why chase rainbows?
It's more of a problem that I want to solve, like doing a project.
Thanks.
And my main concern is that I have to specify the length of the character array at the time of declaration which is hard for me to predict.
What are you using Strings for where you can't deal with a reasonable amount of the data at a time?
I'm trying to store the UID of RFID cards as Strings because its a number like "836 637 363 63" because I'm adding up all 4 UID's together and storing it as a String. Since I keep readings different cards it crashes(Arduino). And also I just want to create a class to improve in programming and obviously for the fun.
Thanks
suersaiyangod:
I'm trying to store the UID of RFID cards as Strings because its a number like "836 637 363 63" because I'm adding up all 4 UID's together and storing it as a String.
save them as char arrays.
BulldogLowell:
save them as char arrays.
Yes that's what I am currently doing but I want to know if I can create a class like I have detailed
I'm trying to store the UID of RFID cards as Strings because its a number like "836 637 363 63"
The UID is 4 bytes. The ASCII representation of each byte will be 1 to 3 characters. That is a total of 16 bytes, allowing room for the terminating NULL.
Compare that to what sizeof(String) reports. The size of the String object does NOT include the size of the string that it wraps.
Storing fixed length strings in EEPROM is faster than unwrapping the string from the String and storing that and the length of the wrapped string, AND allows for more rapid stepping through the stored UIDs.
Of course, there is NO reason to store the 4 bytes as a string OR as a String. Complete waste of memory to store up to 16 bytes when 4 will do.
Try again to come up with an example where Strings do something that a string (or other more reasonable data structure) can't do faster/better/cheaper.
Here's an example: I'm reading the Strings stored in the EEPROM, each String can vary in size and obviously I won't know the size of each String. So if I have to read each String from each address I can't specify the length of the character array I'm using to store each character of the String since I will have to read more than one String from the EEPROM and each one will vary in size. If I use Strings instead of character strings then I don't need to specify the size. I want to this advantage. I hope you understand my example. Thanks
I hope you understand my example.
Not really. You can't store a String in EEPROM. You can only store the string that it wraps.
The String class uses malloc() to allocate the memory occupied by the string. If you must store strings in EEPROM (and your example does NOT illustrate that), then you too can use malloc() to allocate memory to write the string to. Just be sure to free() the memory when you are done with it.
suersaiyangod:
Here's an example: I'm reading the Strings stored in the EEPROM, each String can vary in size and obviously I won't know the size of each String. So if I have to read each String from each address I can't specify the length of the character array I'm using to store each character of the String since I will have to read more than one String from the EEPROM and each one will vary in size. If I use Strings instead of character strings then I don't need to specify the size. I want to this advantage. I hope you understand my example. Thanks
Short of re-writing the memory allocation functions provided by the low-level startup code (malloc, free, sbrk, etc.), there is nothing you can do to change the way objects, like String, use memory in any beneficial manner. So, any class you write, will suffer the exact same problems as String. Your base assumption is that there is something the authors of the String class could/should have done to avoid memory fragmentation. There is not. The problems with the String class are, first and foremost, a result of the very limited amount of RAM available on many Arduinos, and the fundamental way memory allocation is done, which is completely outside the String class. It's kinda like deciding the guys that designed your car didn't do a very good job, because it does not accelerate as fast as a Bugatti Veyron. So you're going to re-design your 1.6L 4-cylinder engine to "overcome" this limitation. Basic physics says it just ain't gonna happen.
Now, if you want your EEPROM class to provide the same functionality as String, that is quite do-able, and does not require you to even know how the low-level memory allocation works. That is the beauty of C++ inheritance.
Regards,
Ray L.
Your base assumption is that there is something the authors of the String class could/should have done to avoid memory fragmentation. There is not.
Well, there was one thing. Instead of allocating memory again for every single character being added, most String classes allocate more memory is somewhat larger chunks. Allocating memory to hold the current data plus 10 characters, when the previous allocation was filled, would reduce the number of times malloc(), memcpy(), and free() need to be used.
The tradeoff is that the number of unused elements at the end needs to be managed, but that is not a big deal.
This is not to say that I think the String class is a good idea. I do not. But, there are things that it could do better.
Thanks for all the response guys. Guess I will stick with C strings then.
PaulS:
Well, there was one thing. Instead of allocating memory again for every single character being added, most String classes allocate more memory is somewhat larger chunks. Allocating memory to hold the current data plus 10 characters, when the previous allocation was filled, would reduce the number of times malloc(), memcpy(), and free() need to be used.The tradeoff is that the number of unused elements at the end needs to be managed, but that is not a big deal.
This is not to say that I think the String class is a good idea. I do not. But, there are things that it could do better.
That would reduce the number of malloc/free calls, at the expense of, on average, more wasted memory for each String object. You'd STILL, at some point, end up with fragmented memory, or just plain run out of memory, if you do a lot of random String operations. It may happen later, it may happen sooner, depending on the specific usage pattern. End of the day, you haven't actually "fixed" anything, you've simply changed when/where/how it will eventually fail, and for at least some applications you will have made it worse.
Regards,
Ray L.