Speicher-Adressen-Marco - suche Hilfe

[Timo B. (Firma: MicroForge) (timob)]

Hallo Leute,

ich versuche grade die CANOpen Lib MicroCanOpen zu kompilieren und stoße 
dabei auf eine Art Macro, was ich nicht verstehe:

/**************************************************************************
DEFINES: MEMORY TYPES USED
**************************************************************************/

// CONST Object Dictionary Data
#define MEM_CONST const code
// Process data and frequently used variables
#define MEM_NEAR data
// Seldomly used variables
#define MEM_FAR xdata

Später im Code wird das dann wieder verwendet:

// process image from user_xxxx.c
extern BYTE MEM_NEAR gProcImg[];

oder auch

BYTE MCOHW_PushMessage 
  (
  CAN_MSG MEM_FAR *pTransmitBuf // Data structure with message to be send
  );

wobei es hier zu einem Compilerfehler kommt:

Error  1  expected ';', ',' or ')' before '*' token  I:\Can-Bus\AVR_Testimplementierung\CANOpen_Test\CANOpen_Test\mcohw.h  130  19  CANOpen_Test

Da ich nirgends Informationen zu dieser Notation finde, frage ich euch, 
ob ihr wisst, was das bedeutet.

Meine Vermutung ist, dass MEM_NEAR im SRAM des Prozessors gespeichert 
werden soll und MEM_NEAR im externen Speicher und MEM_CONST im Flash. 
Aber wie könnte das implementiert sein? Was sollte ich beim AVR tun?

Ich verwende ATMEL Studio 6 und versuche auf einem Mega2560 zu 
kompilieren.

Vielen Dank und viele Grüße
Timo

[Karl H. (kbuchegg)]

Timo Birnschein schrieb:

> Meine Vermutung ist, dass MEM_NEAR im SRAM des Prozessors gespeichert
> werden soll und MEM_NEAR im externen Speicher und MEM_CONST im Flash.

Die Vermutung ist naheliegend.

> Aber wie könnte das implementiert sein?

Durch unterschiedliche Attributierungen. Genau die Dinge, die in den 
#define vereinbart wurden

> Was sollte ich beim AVR tun?

Du hast keine UNterscheidung zwischen verschiedenen RAM-Typen, also 
fällt das schon mal weg

#define MEM_NEAR
#define MEM_FAR


Schwieriger wird mit
// CONST Object Dictionary Data
#define MEM_CONST const code

Die Code-Sektion ist dein Flash.
Jetzt gibt es 2 Möglichkeiten:
* alte Methode mittels PROGMEM.
  Dann musst du allerdings die Code-Teile umschreiben, die auf
  das Flash zugreifen und auf die Verwendung der pgm_read_xxx Methoden
  umstellen.
* mit einem neuen gcc gibt es aber auch die Möglichkeit mit
  _flash die Dinge in den Flash zu legen.
  Das Durchsehen des Codes bleibt dir aber wahrscheinlich nicht
  erspart um sicher zu gehen, dass du die Attributierung nicht 
verlierst.


Mit der 2.ten Methode hab ich noch keine Erfahrung, was da alles an 
Fallen lauert. Johann L. weiß da mehr drüber.

[Oliver S. (oliverso)]

Solche Dinge werden in der Doku zu dem Compiler beschrieben, für den der 
Sourcecode gedacht ist.

Ich habe die ganz starke Vermutung, daß du versuchst, den Code mit einem 
anderen C-Compiler zu übersetzen, als dem, für den der Code geschrieben 
wurde. Das wird nix.

Also besorg dir die Doku zu dem Original-Compiler, und versuche zu 
verstehen, was das soll. Und dann musst du das in etwas umsetzten, das 
dein Compiler versteht.

Oliver

[Oliver S. (oliverso)]

Karl Heinz Buchegger schrieb:
>> Was sollte ich beim AVR tun?
>
> Du hast keine UNterscheidung zwischen verschiedenen RAM-Typen, also
> fällt das schon mal weg

Na ja, das kommt auf dem AVR an. Wenn das einer mit externem Ram ist, 
kann man die Daten da auch verteilen.

Oliver

[Johann L. (gjlayde)]

Timo Birnschein schrieb:
> // CONST Object Dictionary Data
> #define MEM_CONST const code
> // Process data and frequently used variables
> #define MEM_NEAR data
> // Seldomly used variables
> #define MEM_FAR xdata
>
> Was sollte ich beim AVR tun?

Die einfachste Lösung ist die Defines leer auszuführen, also

#define MEM_CONST const
#define MEM_NEAR /* empty */
#define MEM_FAR  /* empty */

Offenbar verwendet der Code nich-standard Qualifier code, data, und 
xdata.

Eine besserer Ansatz wäre damit die Makros so zu lassen wie sie sind und

#define code   /* empty */
#define data   /* empty */
#define xdata  /* empty */

#define MEM_CONST const code
#define MEM_NEAR data
#define MEM_FAR xdata

oder auch "global" per Kommandozeile, da daß man den Code nicht anfassen 
muss:

avr-gcc ... -Dcode= -Ddata= -Dxdata=

Daß statische read-only Daten bei AVR üblicherweise im Falsh abgelegt 
werden ist lediglich eine Optimierung — allerdings eine, die aufgrund 
des sehr begrenzten SRAM bei vielen Anwendungen essenziell ist.

Mit avr-gcc 4.7 und neuer gibt es den Address-Space Qualifier __flash 
gemäß der Embedded-C Erweiterung ISO/IEC TR 18037.  Damit könnte das 
dann auch so aussehen:

#define code   __flash

Damit werden die "code"-Daten ins Flash gelegt und die richtigen 
Zugriffe erzeugt.  Im Gegensatz dazu landen die Daten mit einem reinen 
"const" zwar in der read-only Section .rodata, diese muss bei AVRs aber 
im RAM liegen.

Für avr-gcc bis 4.6 muss man mehr ändern um Daten im Flash abzulegen und 
richtig zuzugreifen, d.h. die Ablage der Daten muss per Attribut progmen 
(aka. PROGMEM, ein Makro auf dieses Attribute) händisch erfolgen und 
ebenso auch der Zugriff über die pgm_read_xxx Makros aus avr/pgmspace.h 
der der AVR-Libc.

[Bronco (Gast)]

Timo Birnschein schrieb:

> // Process data and frequently used variables
> #define MEM_NEAR data
> // Seldomly used variables
> #define MEM_FAR xdata

Ich mag jetzt ganz falsch liegen, aber "xdata" erinnert mich an 8051.
Bei diesem mußte zwischen zwei RAM-Bereichen (die ersten 256 Byte und 
dann alle Byte dahinter) unterschieden werden.
Falls Deine Lib für einen 8051 gemeint ist und Du einen AVR verwendest, 
wage ich zu behaupten, daß Du das wegmachen darfst:

> // Process data and frequently used variables
> #define MEM_NEAR 
> // Seldomly used variables
> #define MEM_FAR

[Timo B. (Firma: MicroForge) (timob)]

Erstmal vielen Dank für die vielen hilfreichen Antworten!

Ja, ich versuche das natürlich mit einem anderen Compiler zu kompilieren 
- ich will es ja zum AVR-GCC portieren / erstmal kompiliert bekommen und 
da es angeblich in reinem ANSI C geschrieben sein sollte, war ich etwas 
überrascht über diese Fehlermeldungen.

Ich werde eure gesammelten Vorschläge alle ausprobieren!

Vielen Dank und viele Grüße
Timo


ps. was ich aber hier eigenlich versuche ist eine funktionsfähige 
CAN-Lib für den AVR zu finden. Vielleicht hat da jemand spontan was?