c: gcc/avr gleiche/ungleiche varianten of string declarartion

[Apollo M. (Firma: @home) (majortom)]

hi,
variante 1 und variante 2 sollten eigentlich gleichen code erzeugen ... 
tun sie aber nicht bzgl. ram allocation, bei variante 2 liegt die string 
copy im ram, wie kann ich das vermeiden?

mt

variante 1:
PROGMEM const char unit0[] = "uSv/h";
PROGMEM const char unit1[] = "uR/h";
PROGMEM const char unit2[] = "mR/h";
PROGMEM PGM_P const unitTable[] = {unit0, unit1, unit2};

variante 2:
enum {UNIT_uSv, UNIT_uR, UNIT_mR};
PROGMEM PGM_P const unitTable[] = {
  [UNIT_uSv] = "uSv/h",
  [UNIT_uR] = "uR/h",
  [UNIT_mR] = "mR/h",
};

[Walter T. (nicolas)]

Die Strings müssen mit PSTR auch ins Flash. So liegen nur die Zeiger auf 
die Strings dort.

[Thomas W. (goaty)]

Das ist ein Array von Pointern?
Vielleicht vor jedes Element noch progmem schreiben oder in etwas 
anderes als Array von Pointen ändern.

[Apollo M. (Firma: @home) (majortom)]

... so weiter rumgesucht

laut https://ewiki.e-dschungel.de/software/avr-gcc
geht nur variante1?!

das PSTR macro kann hier nicht verwendet werden.

... ich will aber die blonde variant2 und bekomm sie nicht, gemein!


mt

[Johann L. (gjlayde)]

Variante 2 ist mit progmem nicht darstellbar.

PSTR ist an der Stelle syntaktisch nicht möglich.

Was geht:

Variante A

#include <avr/pgmspace.h>

const char unitTable[][6] PROGMEM =
{
  "uSv/h", "uR/h", "mR/h"
};

Allerdings ist das dann kein Array von const char*.  Für ein Array von 
const char* braucht man Strings in progmem wie in deiner Variante 1 oder 
man verwendet __flash mit Compound Literals:

Variante B

#define FSTR(X) (const __flash char[]) { X }

const __flash char* const __flash unitTable[] =
{
  FSTR ("uSv/h"), FSTR ("uR/h"), FSTR ("mR/h")
};

progmem ist ein Attribut und bezieht sich immer auf das definierte 
Objekt.  __flash ist ein Qualifier (wie z.B. const oder volatile) und 
kann sich auch auf ein Pointer-Target beziehen.  Mit __flash geht 
natürlich auch das Analogon von Variante A:

Variante C

const __flash char unitTable[][6] =
{
  "uSv/h", "uR/h", "mR/h"
};

Nachteil der Varianten A und C ist, dass man die Maximallänge der 
beteiligten Strings kennen muss, und dass man Verschnitt hat, wenn viele 
Strings unterschiedlicher Längen auftreten.  Außerdem muss mit der 
Stringlänge multipliziert werden, was teuer ist, wenn der µC keine MUL 
Instruktion kennt.

Bei Variante B hat man hingegen Verschnitt durch die zusätzlich zu 
speichernden String-Adressen, und man hat eine Indirektion mehr.  Dafür 
braucht es nur eine einfache Multiplikation mit 2:

char get_first_B (const __flash char* const __flash strings[], uint8_t index)
{
    return strings[index][0];
}

char get_first_C (const __flash char strings[][6], uint8_t index)
{
    return strings[index][0];
}

compiliert zu:

get_first_B:
  mov r30,r22
  ldi r31,0
  lsl r30
  rol r31
  add r30,r24
  adc r31,r25
  lpm r0,Z+
  lpm r31,Z
  mov r30,r0
  lpm r24,Z
  ret

get_first_C:
  ldi r18,lo8(6)
  mul r22,r18
  add r24,r0
  adc r25,r1
  clr __zero_reg__
  movw r30,r24
  lpm r24,Z
  ret

Vorteil von __flash ist, dass man die hässlichen pgm_read_xxx nicht mehr 
braucht und dass es einfacher ist, an Situationen anzupassen, in denen 
__flash nicht verfügbar oder ungünstig ist:

#if !defined(__FLASH) || defined (__AVR_PM_BASE_ADDRESS__)
#define __flash // empty
#endif

Nachteil ist, dass es nicht in C++ verfügbar ist (kann man wahlweise 
auch als Nachteil von C++ ansehen ;-))

[mh (Gast)]

Johann L. schrieb:
> Nachteil ist, dass es nicht in C++ verfügbar ist (kann man wahlweise
> auch als Nachteil von C++ ansehen ;-))

Braucht man es in C++ außer wenn man C Code direkt übernehmen will?