Go Down

Topic: Running out of memory. (Read 1 time) previous topic - next topic

econjack

@Whandall: I don't understand your comment. I just compiled with 1.6.5 and my program is 2234 bytes and yours is 2254. Also, when I try to run yours, I get no output. I'm not sure what the problem is, as I just compiled it. If yours run, what IDE are you using?

Whandall

I had to change the print function to make it print (edited the post, sorry).

I'm talking about the ram usage. Your strings reside in RAM, not in PROGMEM.
Your code only places the array of pointers (to RAM strings) into PROGMEM
(and creates a bunch of warnings).

My ide is 1.6.5
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

nickgammon

Thanks Nick, and thanks for the clear explanation on your website. I can now start to understand what's going on, rather than poking and hoping (there's a BASIC gag in there for you).
Peeking and poking, eh?
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

oqibidipo

What I need is an equivalent of print(F that works with variable strings. Any ideas?
Code: [Select]
lcd.print(reinterpret_cast<const __FlashStringHelper *>(pgm_read_word(...)))
Feel free to create a macro for it. :)

nickgammon

What I need is an equivalent of print(F that works with variable strings. Any ideas?
PROGMEM isn't variable, so I don't understand your question. Variables go into RAM.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

oqibidipo

I understand it as "piece of PROGMEM selected based on the value of a variable".

nickgammon

#21
Jan 13, 2016, 01:50 am Last Edit: Jan 13, 2016, 01:51 am by Nick Gammon
Here's the problem. I've got a large bunch of strings in PROGMEM. No problem. They're called at random, and output to 1602 display. Each string is less than 16 characters long, but after about ~4 iterations, my SRAM is full and it resets.
I tried your code (without the LCD stuff) and it ran without resetting. I added an iteration counter:

Code: [Select]
6850 Thou test 1test 2test 3
6851 Thou test 1test 2test 3
6852 Thou test 1test 2test 3
6853 Thou test 1test 2test 3
6854 Thou test 1test 2test 3
6855 Thou test 1test 2test 3
6856 Thou test 1test 2test 3


As you can see, the PROGMEM part is not consuming RAM and failing after 4 iterations.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

Doz71

Hi Nick,

Thanks for all your input on this. I ran a similar test ,ditched the push button routine, just  outputting the phrase to the lcd, and a similar iteration counter, output of millis  and report of free memory out to the serial interface, as fast as it would go...  and it resets every 4 or 5 iterations. I scratched my head. I cussed. It appears I wasn't running out of memory at all.

I changed the ATMEGA328 on the board. It works without flaw. Damn! It was a duff micro all along.

Even so, it's been a fascinating journey, and I've learned a lot from your website.

Thank you.

aarg

I changed the ATMEGA328 on the board. It works without flaw. Damn! It was a duff micro all along.
... or a cold solder joint.
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

Doz71

... or a cold solder joint.
Unlikely, as the micro sits in a socket, and this one's as firm as a church tied to a hedge with a piece of string. Been running for hours now.

Whandall

Would an armed(8s?) but unfed watchdog not show similar behaviour?
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

Doz71

Indeed it would. Once the watchdog timer had failed to be reset, a reset would be performed.

The watchdog isn't set though! ;)

Go Up