Hallo zusammen,
ich versuch ein Menü auf dem LCD Display vom MSP430 darzustellen. Dazu
wollte ich das Ganze per doppelt verkettete Liste realisieren.
Ich hab alles unter C normal in einer kleinen Konsolenanwendung getestet
und nun wollte ich alles auf den uC übertragen und merkte dabei, dass da
irgendetwas nciht stimmt.
Als ich mir dann die liste mit der Quickwatch angeguckt habe, sah das so
aus, wie ein Speicherüberlauf o.Ä.
Der Controller ist ein FG4618.
Den Screenshot seht ihr im Anhang. Man erkennt deutlich, wie die
Speicheradresse mittendrin wieder bei 0x00 anfängt.
Links daneben seht ihr im Code, wie die Liste aufgebaut ist.
Gibt es vielleicht irgendeine Möglichkeit dem Controller zu sagen, dass
er die Liste irgendwo speichern soll, wo mehr Platz ist (Ich erinnere
mich nur grob an die Stichworte Code-, Daten-, und Stack-Segment. Das
Daten Segment müsste doch genug Platz haben - oder nicht?).
Vielen Dank für eure geduldige Hilfe :-)
EDIT: Wenn ich die auskommentierten Knoten wieder mit einschalte, dann
fängt der Controller schon früher an zu spinnen...
>Gibt es vielleicht irgendeine Möglichkeit dem Controller zu sagen, dass>er die Liste irgendwo speichern soll, wo mehr Platz ist
je nach Compiler vielleicht dieses?
#pragma abs_address:<0x????> (ICC-Compiler)
Wir verwenden übrigens die IAR Embedded Workbench IDE.
Wo müsste ich diesen Hinweis für den Compiler denn platzieren?
An die Funktion zum erstellen eines Knotens?
An die Struktur (struct) des Knotens?
Der Controller hat übrigens 8kb RAM. Das kann doch nicht schon voll
sein... Wie kann ich meine Liste dahin verlagern?
Hier mal ein Abdruck solch eines Problems. Die Vorinitvariablen (können
auch Strings sein) sollen vom Linker/Locater in des Flash-Segment A des
MSP430F149 gelegt werden:
Wenn Du Variablen als const deklarierst, landen sie beim MSP430 im
Flash-ROM, von dem es deutlich mehr gibt als RAM. Dein Menü dürfte eine
konstante Struktur haben, also solltest Du es komplett ins Flash-ROM
packen können.
Wenn ich ein "const" vor die Definition der struct stelle, kommt eine
Warnung, dass das "bedeutungslos" wäre.
Wenn ich das const vor die Listendeklaration stelle, gibt es auch
Fehler.
Ist ja auch logisch, denn eigentlich ändert sich dadrin immer
irgendetwas bis die Liste komplett aufgebaut ist.
Roland Moch schrieb:> Wenn ich ein "const" vor die Definition der struct stelle, kommt eine> Warnung, dass das "bedeutungslos" wäre.
Das dürfte ein typedef sein, also eine Typdeklaration. Typen an sich
sind aber nicht const.
> Ist ja auch logisch, denn eigentlich ändert sich dadrin immer> irgendetwas bis die Liste komplett aufgebaut ist.
Das ist die hohe Kunst der Initialisierung. Oder soll das Menü wirklich
erst zur Laufzeit zusammengebastelt werden?
Aber selbst dann können die einzelnen Elemente des Menüs bis auf die
Zeiger const sein.
Wie gesagt, alles eine Frage der Initialisierung.
Ja, der Titel könnte const sein, aber das wird schwierig mit der
Initialisierung.
Du hast recht, eigentlich muss das Menü nicht zur Laufzeit aufgebaut
werden, dann ist ein Array doch vielleicht besser geeignet, oder?
Zwei Arrays: Eins mit dem Menütitel, ein anderes mit einem Opcode und
dann reicht eine Int-Variable für den Index des aktuellen Menüs.
Ist zwar nicht mehr so elegant, aber darum geht es bei Microcontrollern
im Gegensatz zu den Hochsprachen auf den PCs auch nicht, oder?
Was meinst du?
Ich würde die Strings aus dem Befehl extrahieren, in const einhüllen und
diese dann durch eine Routine auslesen und anzeigen lassen.
Mal schnell als Beispiel:
Roland Moch schrieb:> Zwei Arrays: Eins mit dem Menütitel, ein anderes mit einem Opcode und> dann reicht eine Int-Variable für den Index des aktuellen Menüs.
Wozu zwei? Man kann doch auch Strukturen in ein array packen.
Z.B.
1
typedefstruct{
2
constintprev;
3
constintnext;
4
constintlist;
5
constchar*title;
6
constcharopcode;
7
}node_t;
8
9
constnode_tmenu[]={
10
{3,1,0,"a",0x01},
11
{0,2,0,"b",0x02},
12
{1,3,0,"c",0x03},
13
{2,0,0,"d",0x04},
14
// ...
15
};
prev, next, list sind dann halt keine Pointer, sondern Arrayindizes. Vom
Prinzip her also fast dasselbe wie Deine verkettete Liste, nur halt
nicht dynamisch zur Laufzeit erzeugt sondern statisch zur Compilezeit.
Memory.jpg
(240 KB)
