Instanz von class/struct im Flash ablegen

[Spiffman G. (spiffman)]

Hallo,

ich arbeite gerade an einer Uart-Schnittstelle.
Meine Strings habe ich wie folgt in mein Programm gepackt:

const char f_str_0[] PROGMEM = "/?";
const char f_str_1[] PROGMEM = "HELP";
....
const char * const all[] PROGMEM = { f_str_0, f_str_1, ...};

So kann ich über "all" iterieren und alle unterstützten Befehle 
ausgeben.
Je nach Befehl möchte ich eine andere Funktion anspringen.
Alle Funktionen sind zur Compile-Zeit bekannt.
Aktuell habe ich es so gelöst:

//Return PIN-Control
if( !compare( 4)) {        //Das ist der Index im Array "all"
  AllIO.ReturnControl();   //Diese Funktion möchte ich anspringen
  uart_puts_P( ">>OK\n\r");
  return;
}

Das ist natürlich sehr unschön! Da dachte ich machst dir eine Klasse, 
die den String und einen Funktionspointer im Flash enthält.
Dann mach ich mir ein const-Array aller Klasseninstanzen und schupps 
kann ich einfach neue Befehle hinzufügen.
Leider reichen meine C++Kentnisse nicht aus! :-(
Versucht habe ich das:

struct PROGMEM UartCommand0P
{
  const char * const _ptr_text;
  const uint8_t (*FunctionToCall)();
};

const UartCommand0P b = { "1", nullptr};

Hier landet der String aber im RAM. :(

const UartCommand0P c = { PSTR("blaasdfadsfasdf"), nullptr};

So hätte ich es intuitiv gemacht, jedoch bekomme ich folgenden 
compile-Error:
"statement-expressions are not allowed outside functions nor in 
template-argument lists"

Könnt ihr mir vielleicht sagen, ich ich alles in den Flash packen kann?
Danke für eure Hilfe!

[Johann L. (gjlayde)]

1) PROGMEM wird nur für Variablen unterstützt, nicht für Typen.

2) In C++ können nur POD (pretty old data) per PROGMEM ins Flash gelegt 
werden.  Nicht-POD liegen immer im RAM (falls sie nicht wegoptimiert 
wurden).

[Rolf M. (rmagnus)]

Johann L. schrieb:
> 1) PROGMEM wird nur für Variablen unterstützt, nicht für Typen.

Typen gibt es nach dem Compile-Vorgang nicht mehr. Einen Typ kann man 
nicht speichern, was aber auch nirgends versucht wurde.

> 2) In C++ können nur POD (pretty old data)

Eigentlich "plain old data".

> per PROGMEM ins Flash gelegt werden.  Nicht-POD liegen immer im RAM (falls
> sie nicht wegoptimiert wurden).

Und was sollte daran nicht POD sein?

Spiffman G. schrieb:
> struct PROGMEM UartCommand0P
> {
>   const char * const _ptr_text;
>   const uint8_t (*FunctionToCall)();
> };
>
> const UartCommand0P b = { "1", nullptr};

Das Problem dürfte eher PSTR sein, das in C++ nicht funktioniert.

[Johann L. (gjlayde)]

Rolf Magnus schrieb:
> Johann L. schrieb:
>> 1) PROGMEM wird nur für Variablen unterstützt, nicht für Typen.
>
> Typen gibt es nach dem Compile-Vorgang nicht mehr.

Und was soll uns das jetzt sagen?

In der Definition des struct-Typs UartCommand0P steht ein progmem, und 
das wird nicht unterstützt.  Daß der Compiler an der Stelle keinen 
Fehler wirft, bedeutet nicht, daß es unterstützt wird.

Wenn überhaupt gehört das progmem zu den entsprechenden Objekten, etwa b 
oder c.


> Einen Typ kann man nicht speichern, was aber auch nirgends
> versucht wurde.

Dennoch klebt ein progmem dran.

>> 2) In C++ können nur POD (pretty old data)
>
> Eigentlich "plain old data".

> Und was sollte daran nicht POD sein?

Regel 2) gilt unabhängig davon, ab sie im Beispiel verwendet wird.  Ich 
hab lediglich 2 Regeln genannt, die jedes C bzw. C++ Programm 
betreffen.

>> const UartCommand0P b = { "1", nullptr};
>
> Das Problem dürfte eher PSTR sein, das in C++ nicht funktioniert.

In C geht das auch nicht da PSTR nicht in einer Funktion steht. 
Zumindest lässt die Fehlermeldung darauf schießen, daß das 
nicht-compilierbare Codegeschnippsel nicht in einer Funktion steht.

[Rolf M. (rmagnus)]

Johann L. schrieb:
> Rolf Magnus schrieb:
>> Johann L. schrieb:
>>> 1) PROGMEM wird nur für Variablen unterstützt, nicht für Typen.
>>
>> Typen gibt es nach dem Compile-Vorgang nicht mehr.
>
> Und was soll uns das jetzt sagen?
> In der Definition des struct-Typs UartCommand0P steht ein progmem, und
> das wird nicht unterstützt.  Daß der Compiler an der Stelle keinen
> Fehler wirft, bedeutet nicht, daß es unterstützt wird.

Ah, da hatte ich dich wohl falsch verstanden. Sorry für die Verwirrung.

>>> 2) In C++ können nur POD (pretty old data)
>>
>> Eigentlich "plain old data".
>
>> Und was sollte daran nicht POD sein?
>
> Regel 2) gilt unabhängig davon, ab sie im Beispiel verwendet wird.  Ich
> hab lediglich 2 Regeln genannt, die jedes C bzw. C++ Programm
> betreffen.

Ich sehe nichts im Ursprungsposting, das darauf hindeutet, daß die 
Struktur kein POD sein könnte. Aber du hast natürlich recht, daß man da 
nicht sicher sein kann, wenn nur einzelne Codefragmente gezeigt werden, 
die vermutlich auch noch extra für das Posting geschrieben wurden statt 
dem echten Code.

> In C geht das auch nicht da PSTR nicht in einer Funktion steht.

Ah, wußte gar nicht mehr, daß das nur in Funktionen geht.