AtMega168 zu wenig RAM ?

[Mike (Gast)]

Ich habe einen relativ komplexen Programmtext, in dem zum Beispiel unter 
anderem auch ein LCD angesteuert wird.

Jetzt habe ich das unerklärliche Problem ,das wenn ich in einer Funktion 
eine weiter Displayausgabe aufrufe mein gesamtes Programm spinnt .

Vor allem betroffen sind hiervon Variablen die im Ram liegen dürften .
Die Funktion in der ich die LCD Ausgabe habe wird im übrigen zur 
Standby-Laufzeit des Programmes nichtmal aufgerufen .

Daher meine Frage .Kann es sein, das der Controller mangels RAM nicht 
mehr korrekt arbeitet ?
Und wenn ja gibt es hier eine Lösung den RAM zu erweitern ? .

Oder weiß zufällig jemand ob es von den Ports her einen AtMega gibt der 
genau wie der 168 ist jedoch mit mehr RAM ?!.

Lieben Dank für die Hilfe im vorraus

[(prx) A. K. (prx)]

Bist du sicher, dass du an der richtigen Stelle suchst? Um das 
einschätzen zu können bringst du ein bischen arg wenig Information.

Ja es gibt einen Kompatiblen mit mehr RAM, den ATmega328.

[Mike (Gast)]

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 .

[der andere Mike (Gast)]

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.

[(prx) A. K. (prx)]

Mike schrieb:

> 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 .

Nö, wenn das RAM nicht reicht, dann äussert sich das entweder in einem 
Linker-Error, oder durch Stack-Überlauf. Letzteres zerlegt aber meist 
nicht das gesamte RAM, sondern ein paar wenige globale/statische Daten 
am hinteren Ende und/oder den Stack mit den lokalen Daten und der 
Rücksprungadresse.

Bischen komplizierter wird es, wenn man dynamische Speicherverwaltung 
per malloc/free verwendet, wovon ich bei Controllern dieser 
Grössenordnung ohnehin abrate.

Wenns nicht zu viel verlangt ist: Womit programmierst du? Ada, Lisp, 
APL, ...? Welches Entwicklungssystem?

Wenn du in C programmierst, dann dürfte der Compiler/Linker ein Mapfile 
auswerfen. Das ist zur Diagnose der RAM-Situation sehr hilfreich.

[g457 (Gast)]

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

[Mike (Gast)]

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 ?

[der andere Mike (Gast)]

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.

[g457 (Gast)]

> 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

[Mike (Gast)]

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

extern const char text1[] PROGMEM;
const char text1[] = "Hallo";

und dann quasi in einer Funktion etwa so :

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

[der andere Mike (Gast)]

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

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

[Mike (Gast)]

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

[Mike (Gast)]

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

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 ?

[Mike (Gast)]

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 :-)