Struct welches im Flash liegt an Funktion übergeben

mhh... hab jetzt schon viel probiert, bekomme es aber nicht hin..
vielleicht kann mir ja jemand unter die Arme greifen.

Gruß Tobias

In neueren Versionen von GCC (z.B. 4.7.2) geht das deutlich entspannter:

1

const __flash struct S { int a, b, c, d; } var; // => ROM

2

3

extern void f(struct S param);

4

extern void g(const struct S __flash *param);

5

6

void h(void)

7

{

8

        f(var); // wird vom ROM zum Stack kopiert

9

        g(&var); // g() greift direkt auf ROM zu

10

}

Bshit schrieb:
> Was n das n für Quatsch? C kennt kein RAM oder ROM.

C ursprünglich nicht, AVRs jedoch schon und die Implementierung von GCC 
auf AVRs mittlerweile auch. Daher kein Quatsch.

> Du spielst hier auf die Harvard Architektur an, oder?

Ja.

Siehe auch hier, insbesondere die universellen Pointer per __memx
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Flash_mit_flash_und_Embedded-C

Stefan Us schrieb:
> Mir ist gerade noch eingefallen, dass man die vier Bytes auch am Stück
> mit memcp_P() kopieren kann.

Man könnte auch die komplette Struktur mittels memcpy_P in einem Rutsch 
vom Flash ins SRAM kopieren. Nur fürs Protokoll, das würde dann 
beispielsweise so aussehen

1

const Filter _50_Hz_TP PROGMEM =  

2

{ {0x00,0x00,0x00,0x0B},

3

  {0x00,0x00,0x00,0x16},

4

  {0x00,0x00,0x00,0x0B},

5

  {0xFF,0x00,0x97,0x7A},

6

  {0x01,0xFF,0x68,0x5A}

7

};

8

9

void write_dsp_hp(Filter* filterFlash)

10

{

11

  Filter filterSRAM;

12

13

  memcpy_P( &filterSRAM, filterFlash, sizeof(FilterSRAM) );

14

15

  Sigma_block_write( DEVICE_ADDR_IC_1, Crossover_HP_1B2_2, Crossover_BYTE, filterSRAM.B2);

16

  Sigma_block_write( DEVICE_ADDR_IC_1, Crossover_HP_1B1_2, Crossover_BYTE, filterSRAM.B1);

17

  Sigma_block_write( DEVICE_ADDR_IC_1, Crossover_HP_1B0_2, Crossover_BYTE, filterSRAM.B0);

18

  Sigma_block_write( DEVICE_ADDR_IC_1, Crossover_HP_1A2_2, Crossover_BYTE, filterSRAM.A2);

19

  Sigma_block_write( DEVICE_ADDR_IC_1, Crossover_HP_1A1_2, Crossover_BYTE, filterSRAM.A1);

20

}

21

22

...

23

  write_dsp_hp(_50_Hz_HP);

24

...

Aber egal wie man es dreht und wendet, es muss einen Kopiervorgang vom 
Flash ins SRAM geben. Die von A.K angesprochene Variante mit dem 'neuen' 
__flash Schlüsselwort ist die deutlich eleganteste Lösung dafür. Zum 
einen macht der Compiler dann den Kopiervorgang, wenn auf die 
tatsächlichen Werte zugegriffen wird und zum anderen kann der Compiler 
auch die Weitergabe von Pointer an Funktionen besser überwachen, da 
__flash anders ins Sprachkonzept von C eingebunden ist als die alte 
PROGMEM Lösung, die die Hauptverantwortung für die korrekte Verwendung 
im Code ausschliesslich an den Programmierer abgetreten hatte. Letzters 
ging dann schon auch mal schief.

Karl Heinz schrieb:
> Man könnte auch die komplette Struktur mittels memcpy_P

Man könnte auch die PROGMEM Krücke in Würde sterben lassen und 
konsequent nur noch __flash verwenden. (Von legacy Projekten mal 
abgesehen).
Und Anfänger auch zur Benutzung dieses auffordern, anstatt ihnen 
Workarounds für den Workaround anzubieten.

le x. schrieb:

> Und Anfänger auch zur Benutzung dieses auffordern, anstatt ihnen
> Workarounds für den Workaround anzubieten.

Mit welchem Teil meines Postings, das die von A.K. angesprochene und von 
dir propagierte Lösung ebenfalls als die deutlichst bessere Variante 
hervorhebt, bist du nicht einverstanden?

Eventuell benutzt er ja noch (so wie ich) eine gcc Version, die __flash 
noch nicht kann. Spätestens dann muss er wissen was da dahinter steckt, 
so wie es nicht schadet, wenn er auch weiss, dass __flash vom Compiler 
eine andere Behandlung erfordert und es daher zb nicht egal ist, wenn er 
es (so wie manchmal bei einem volatile) einfach wegcastet, bzw. das 
__flash nicht ohne einen Laufzeit-Penalty daher kommt und worin dieser 
besteht.

So, jetzt funktioniert es.

Danke für die Hilfe und die Denkanstöße. Das hat mir weitergeholfen.