Go Down

Topic: SRAM and storing strings (Read 4 times) previous topic - next topic


Why must strings be stored in sram? You can put variables in the flash with PROGMEM... F() is sort of doing the same thing.


So you're saying I cannot concatenate or use Flash strings using String class .. I'll guess I can just do it for my own private and modified version of String class.
I think you're not being very helpful. See post above by Marek080 - that was very helpful and actually resolved my original problem.

Sorry. I'm not feeling good today. The String class was developed to make string processing easy - constructing a string from data read from the serial port, for instance. I would guess that no one thought that adding a Flash-compatible constructor or concatenation operator was necessary. Of course, if you want to clutter up your SRAM with Strings made from Flash data, you are free to do so.

I know how to do all the stuff that the String class does, using string functions, so I've never felt the need to use the String class, especially after looking at how the concatenation operator works.

Your mileage may vary.


Without the F() syntax, "hello" would be stored in your SRAM. But you don't have a lot of SRAM, so using the F() stores the string in the flash (program) memory, of which you have a lot. Projects that need a lot of strings will benefit from storing strings in flash, as it will free up ram for things like variables. But a flash string cannot be modified.


+1 -> Exactly!
I actually ran out of SRAM space before moving to Flash strings.
But I didn't want to rewrite my entire Firmware because of that, as I am already using the String class heavily.
When you build strings on the fly, which are composed of constant/literal parts and dynamic values, the String class is very handy.
But moving to F() macro, broke the existing code.
Yes, I can re-write the whole code, but I would prefer to use the same Facade (String interface) instead of changing the implementation.


The String Object class makes it easier (for some, not me) to write string manipulation code without knowing what is going on in memory.
What do you think happens when you concatenate two strings? Not caring is for people who have excess RAM. How can that concatenation be done in read-only flash? Are you going to write a function for "you can't get there from here"?

I'm not the least bit surprised when String users have memory problems. They don't C so well.

I find it harder to express logic in English than in Code.
Sometimes an example says more than many times as many words.

Nick Gammon

Here's the problem with the String library: It makes it easy to write a program that doesn't work.

What I mean by that is, the nice simple String handling initially simplifies things (eg. concatenation). So you use it all over the place. And then you get into full-scale testing. Like, running your program for more than 5 minutes. Then it crashes. Then you go onto the forum. Then people tell you to stop using the String class.

So basically it has just wasted your time. Because now you have to throw it away. You would have saved more time in the long run by not using it in the first place.

It's not a bug per se in the library. It's just that all that concatenation tends to fragment the rather small amount of memory you have on the chip.

Go Up