AtMega168 zu wenig RAM ?

Ich wollte jetzt nicht den riesen Klotz Programmcode posten .

Aber der stimmt auch sicherlich .

Das Problem habe ich in mühesamer Arbeit eingekreist und letztendlich 
muss es genau dieses Problem  sein .

Vor allem auch die Tatsache das er ab einem gewissen Punkt alle 
Variablen durcheinanderschmeißt lässt darauf schließen das er mit dem 
RAM überfordert ist .

Du kannst Dir mal die SRAM-Belegung ausgeben lassen (e.g. UART).

int availableMemory()
{
  int size = 1024;
  byte *buf;
  while ((buf = (byte *) malloc(--size)) == NULL);
  free(buf);
  return size;
}

Dann siehst Du ja ob das der Bottleneck ist.

Wenn Du die Vermutung hast dass es am Speicher(mangel) liegt: Schaufel 
doch mal was frei davon. 'LCD' hört sich in dem Zusammenhang noch dem 
Klassiker 'zu viele Strings im SRAM' an..

HTH

g457 schrieb:
> Wenn Du die Vermutung hast dass es am Speicher(mangel) liegt: Schaufel
>
> doch mal was frei davon. 'LCD' hört sich in dem Zusammenhang noch dem
>
> Klassiker 'zu viele Strings im SRAM' an..

Im SRAM liegen in der Tat ziemlich viele Strings  :S .

Allerdings bin ich davon ausgegangen, das wenn ich im SRAM generell noch 
genug Platz habe es kein Problem geben dürfte .

Kann mich da jemand aufklären warum es mit zu vielen Strings zum Problem 
kommt ?

Jup, da ist progmem

(e.g. 
http://www.rn-wissen.de/index.php/Avr-gcc#String_im_Flash_belassen)

Dein Freund.

Alternativ tausche mal Deine LCD.lib gegen die von Peter Fleury aus,

http://homepage.hispeed.ch/peterfleury/lcdlibrary.zip

Die ist recht effizient.

> Kann mich da jemand aufklären warum es mit zu vielen Strings zum Problem
> kommt ?

'zu viele' -> 'zu wenig Platz' - ganz einfach ;-))

Das Schöne an dieser Stelle ist die Tatsache, dass man die 
unveränderlichen Daten (dazu zählen immergleiche Strings für die Ausgabe 
auf LCDs i.d.R.) recht einfach in den Programmspeicher verlagern kann 
[1] [2]

HTH

[1] im Programmspeicher liegen sie so auch schon, aber sie werden noch 
in den SRAM geladen, und der geht bei der Gelegenheit gerne aus
[2] http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_flashstrings

Ok also wenn ich meine Strings etwa so im Flash definiere :

1

extern const char text1[] PROGMEM;

2

const char text1[] = "Hallo";

und dann quasi in einer Funktion etwa so :

1

lcd_write(text1);

aufrufe dürfte es doch passen oder übersehe ich da etwas .


Habe die Geschichte mit ProgMem blöderweise noch nie wirklich gemacht

> Habe die Geschichte mit ProgMem blöderweise noch nie wirklich gemacht

Naja, heute ist Sonntag der 17.4., ein schöner Tag damit anzufangen ;-)

Falls jemand hier auch Nachhilfe braucht.
Ich habe hier was wirklich gutes gefunden .
Schön erklärt :

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=38003

Ok der Einfachheit halber habe ich jetzt meine lcd Routinen 
folgendermaßen geändert z.B

1

lcd_write(PSTR("Hallo"));

hier bekomme ich nun leider den Fehler :

1032: warning: only initialized variables can be placed into program 
memory area

Der Fehler ist wohl auch nicht ganz unbekannt und wohl ein Bug im 
Compiler.

Hat da zufällig jemand einen Workaround für mich bei der ich die 
praktisch einfache PSTR Routine beibehalten kann ?

Für diejenigen die das Problem auch haben :

Using the new version (gcc-4.2.2, avr-libc-1.6.1) I've done some 
checking and found a solution, or work around, I'm not sure which one.

PSTR is defined as (pgmspace.h):

Code:
# define PSTR(s) (__extension__({static char __c[] PROGMEM = (s); 
&__c[0];}))
If I change the definition to

Code:
# define PSTR(s) (__extension__({static prog_char __c[] = (s); 
&__c[0];}))
g++ is happy as well. I'm not sure if this is a g++ issue or if g++ just 
got a little more standards compliant and it is an avr-libc issue.



Somit sind alle meine Probleme auch mein eigentliches gelöst :-)