MSP430FG4618 - Controller voll??

[Roland N. (eroli)]

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

[Paul (Gast)]

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

[Roland N. (eroli)]

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?

[Paul (Gast)]

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:

// Flash-Segment A:
#pragma abs_address:0x1080
unsigned int uiFlashArrayA[64] = 
{ 0x0000, 0x032F, 0xFFFF, 0xFFFF,    
  0x0003, 0x2301, 0xFFFF, 0xFFFF, // BR_PORT1, Messgr.ID/Busadresse, 
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // irgendwas 4x
  0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF  // irgendwas 4x
};
#pragma end_abs_address

Zur Änderung des Speicherplatzes kann man die Strings auch mit const 
unsigned char* deklarieren. Der Locater sucht dann den optimalen Platz.

[Rufus Τ. F. (rufus)]

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.

[Roland N. (eroli)]

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.

[Rufus Τ. F. (rufus)]

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.

[Roland N. (eroli)]

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?

[Paul (Gast)]

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:

const unsigned char Messen_String1 [] = {"gemessen am:"};


NT_String_senden ((unsigned char*)Messen_String1); 


//Funktion
//----------------------------

void NT_String_senden (unsigned char *string)
{
 unsigned char i=0;
  
  
    while((string[i] != '\0')&&(i<31))
    {
  
      SOFT_UART_TXD ((unsigned int) string[i]);
    i++;
    
    }
  SOFT_UART_TXD (0);  
}

[... (Gast)]

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.

typedef struct {
  const int prev;
  const int next;
  const int list;
  const char* title;
  const char opcode;
} node_t ;

const node_t menu[] = {
  {3, 1, 0, "a", 0x01 },
  {0, 2, 0, "b", 0x02 },
  {1, 3, 0, "c", 0x03 },
  {2, 0, 0, "d", 0x04 },
  // ...
};

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.

[Roland N. (eroli)]

Wow, vielen Dank für diese gute Idee. Das hört sich wirklich 
ausgezeichnet an und ist gar nicht so "unelegant" :-)