Struct mit String im Flash Zugriff

Christian schrieb:

> Ist das normal, sollte man die Warnung deaktivieren?

Nein, auf keinen Fall.
An welcher Stelle kommt denn die Warnung?

Ich denke, dass du sie an dieser Stelle wirklich ignorieren kannst.

Im Prinzip würde man diese Funktionen wohl heutzutage gleich auf dem
__flash address space aufsetzen.  Wenn man das aber macht, compiliert
der historisch gewachsene Code nicht mehr.  Hmm, naja, vielleicht
compiliert er ja noch, bringt aber dann eine Warnung (halt umgekehrt)?
Braucht dann eben nur einen hinreichend neuen Compiler (damit __flash
unterstützt wird), aber das sollte ja kein Problem mehr sein.

An sich wäre das eine API-Änderung, damit müsste man das Resultat
eigentlich dann avr-libc 2.0 nennen.  Bin ich aber nicht völlig
abgeneigt, das zu tun. ;)

Christian schrieb:
> FSTR ("\0")

Wat is dat?

Willst du hier einen NULL-Pointer? Dann schreib NULL oder 0!
Willst du einen leeren String? Dann schreib "" (oder halt FSTR(""))

Christian schrieb:
> Der Code funktioniert, nur was mich stört das folgende Meldung bekomme:
> Warnung  conversion from address space '__flash' to address space
> 'generic' [-Waddr-space-convert]
>
> Ist das normal, sollte man die Warnung deaktivieren?

Ja, die Warnung würd ich nur sporadisch verwenden.

Die Warnung hab ich seinerzeit zusammen mit Address-Space (AS) __flash 
et al. eingeführt um bei Portierung von PROGMEM + pgm_xxx --> __flash 
behilflich zu sein.

Problem ist jedoch, dass z.B. die Lib-Funktionen alle ohne 
AS-Qualifier geschrieben sind und Literale wie in PSTR keine 
AS-Qualifier haben (dürfen).  Daher gibt es auch kein AS-Äquivalent zu 
PSTR.

Somit ist es kaum möglich, Code zu schreiben, der AS verwenden und diese 
Warnung nicht produziert.  Grund ist auch, dass es in GCC keine 
einfache Möglichkeit gibt, zwischen expliziten Casts und einem 
impliziten Casts zu unterscheiden.

Solche Fragen sind übrigens einfacher zu beantworten, wenn der gezeigte 
"Code" compilierbar ist: Es fehlen Deklarationen von FSTR, uint8_t, 
strcmp_P, ...

Eric B. schrieb:
> Willst du hier einen NULL-Pointer?

Der hätte an dieser Stelle übrigens deutlich mehr Sinn, und dann
die Auswertung mit

1

    if(CommandStruct[i].cmdString == NULL) {

2

      break;

3

    }

Das spart eine Dereferenzierung aus dem Flash.

Christian schrieb:
> @Eric und Johann:
> #define FSTR(X) ((const __flash char[]) { X } )

Ich habe mich eher auf das "\0" bezogen. Das macht gar kein Sinn.

Jörg W. schrieb:

> An sich wäre das eine API-Änderung, damit müsste man das Resultat
> eigentlich dann avr-libc 2.0 nennen.  Bin ich aber nicht völlig
> abgeneigt, das zu tun. ;)

Wäre vernünftig.
Es gibt ja auch noch die Funktion strcmp_PF. Ursprünglich dachte ich, 
die wären die richtigen, bis ich bemerkte, dass das F für 'far' steht 
und nicht für 'flash'

Gut wäre es schon, denn wenn bei einem normalen strcmp die Warnung 
kommt, dann ist sie schwerwiegend, bei einem strcmp_P jedoch nicht. 
Ausser die Reihenfolge der Argumente ist genau falsch herum. Dann ist 
sie wieder schwerwiegend. D.h. hier verliert man kräftig an 
Typsicherheit, wenn man die Warnung einfach ignoriert. Und auf diese 
Warnung würde ich ehrlich gesagt auf keinen Fall verzichten wollen.

Übrigens krieg ich bei meinem mit dem Studio 6.2 mitgeliefertem Compielr 
keine Warnung.

Jörg W. schrieb:
> Im Prinzip würde man diese Funktionen wohl heutzutage gleich auf dem
> __flash address space aufsetzen.  Wenn man das aber macht, compiliert
> der historisch gewachsene Code nicht mehr.  Hmm, naja, vielleicht
> compiliert er ja noch, bringt aber dann eine Warnung (halt umgekehrt)?
> Braucht dann eben nur einen hinreichend neuen Compiler (damit __flash
> unterstützt wird), aber das sollte ja kein Problem mehr sein.
>
> An sich wäre das eine API-Änderung, damit müsste man das Resultat
> eigentlich dann avr-libc 2.0 nennen.  Bin ich aber nicht völlig
> abgeneigt, das zu tun. ;)

IMO bringt es keinen nennenswerten Mehrwert, zumal die alten Prototypen 
weiter bestehen werden und die Funktionen den gleichen Code erzeugen, 
d.h. lediglich Aliases auf bestehenden Code wären.

Und willst du Versionen für die bis zu 8 Spaces (generic, memx, flash, 
flash1 ... flash5) implementieren?

Johann L. schrieb:
> Und willst du Versionen für die bis zu 8 Spaces (generic, memx, flash,
> flash1 ... flash5) implementieren?

Nö, ich wollte keine neuen Funktionen implementieren.  Die bisherigen
*_P()-Deklaration dagegen haben ja rein gar nichts, was einen darauf
hinweisen würde, dass man da einen falschen Zeiger übergibt:

1

  const char fmt[] = "%d";

2

3

  printf_P(fmt);

Dass es kein Äquivalent zu PSTR() gibt, ist allerdings in der Tat 
schade.

Jörg W. schrieb:
> Johann L. schrieb:
>> Und willst du Versionen für die bis zu 8 Spaces (generic, memx, flash,
>> flash1 ... flash5) implementieren?
>
> Nö, ich wollte keine neuen Funktionen implementieren.  Die bisherigen
> *_P()-Deklaration dagegen haben ja rein gar nichts, was einen darauf
> hinweisen würde, dass man da einen falschen Zeiger übergibt:
>
>

1

const char fmt[] = "%d";

2

> 

3

>   printf_P(fmt);

Wird aber trotzdem recht ätzend, das müsste ja auch für C99 etc. 
funktionieren, die AS sind aber nur in GNU-C verfügbar.

Außerdem ist das löd mit altem, funktionierendem Code der PROGMEM etc. 
verwendet.  Generell find ich blöd, wenn funktionierender Code Probleme 
bekommt, nur weil neuer Code neue Gimmicks verwendet / verwenden könnte.


> Dass es kein Äquivalent zu PSTR() gibt, ist allerdings in der Tat
> schade.

hmmm, folgendes scheint zu gehen, ganz analog zu PSTR:

1

#define XSTR(X) ({ static const __flash char __s[] = X; __s;})

2

3

extern int strcmp_F (const char*, const __flash char*);

4

5

int afoo (const char *s)

6

{

7

    return strcmp_F (s, XSTR ("Hallo"));

8

}

9

10

char cfoo (int i)

11

{

12

    return XSTR ("Hallo")[i];

13

}

14

15

const __flash char* pfoo (int i)

16

{

17

    return & XSTR ("Hallo")[i];

18

}

Johann L. schrieb:

> Wird aber trotzdem recht ätzend, das müsste ja auch für C99 etc.
> funktionieren, die AS sind aber nur in GNU-C verfügbar.

Eigentlich auch schade.  Ich weiß, AS ist kein expliziter Bestandteil
des Standards, aber zumindest ein Standardvorschlag.

Man kann ja mit _FLASH intern arbeiten und dieses nur dann auf
__flash setzen, wenn klar ist, dass es funktionieren wird.  Dann
kann man auch noch einen Kombatibilitätsknopf für alten Code
einführen.

> Außerdem ist das löd mit altem, funktionierendem Code der PROGMEM etc.
> verwendet.

Wobei wir ja mit den früheren Definitionen für prog_char etc. ohnehin
so hinreichend in die braune Masse gegriffen haben, dass es darauf
nun auch nicht mehr ankommt. ;-)

>> Dass es kein Äquivalent zu PSTR() gibt, ist allerdings in der Tat
>> schade.
>
> hmmm, folgendes scheint zu gehen, ganz analog zu PSTR:

Danke!