XBYTE Makro?

Ich sehe absolut keine Chance auf ein Makro, das dir erlauben würde, den 
gezeigten Code unverändert weiter zu nutzen. Wenn es keine eckigen 
Klammern wären, sondern runde, dann ja.

Hi, Danke für die Antwort.


Ok, dann muss ich das in 2 Funktionen
read und write auslagern, nicht schön, aber sollte funktionieren.

Nachtrag:
Was du aber machen kannst, ist einfach ein Array mit den Namen XBYTE 
anzulegen, und dieses dann per Linker-Option auf die passende Adresse 
(0x8000 ?) zu legen.

Danke nochmal,

kannst du mir die Linker option dafür posten, bin darin nicht so 
vertraut

Christian O. schrieb:
> Ok, dann muss ich das in 2 Funktionen
> read und write auslagern

Wieso das denn jetzt? Ich habe nicht gesagt, dass es grundsätzlich nicht 
per Makro geht. Es geht nur nicht, wenn der Code komplett unverändert 
bleiben soll (mit dem Array würde das aber gehen). Wenn du den Code eh 
ändern willst, dann mache einfach aus den eckigen Klammern runde, und 
schon geht es per simplen Makro.

und wie würde das aussehen?


Gruss Ch.

Array:

1

uint8_t XBYTE[SIZE_OF_EXTERNAL_MEMORY] __attribute__ ((section(".xmem")));

1

-Wl,--section-start=.xmem=0x808000

Makro:

1

#define  XBYTE(adr)  (*((uint8_t*)(adr)))

Ups. Vergiss das mit dem Array gleich wieder. Dumme Idee.
Mit den Indizes haut das ja gar nicht hin.

Wenn man den kompletten XRAM selbst in einem einzigen Objekt (hier: 
Array) verwaltet, reicht eine Deklaration aus:

extern uint8_t XBYTE[];

oder wenn's gefällt auch

extern uint8_t XBYTE[SIZE_OF_EXTERNAL_MEMORY];

Und dann XBYTE per -Wl,--defsym,XBYTE=0x8000 festlegen.

Christian O. schrieb:
> bei Keil gibt es das XBYTE, das dem Compiler sagt, dass ein
> externer Speicherzugriff erfolgt.
>
> Kann man für den AVR dazu ein Makro schreiben?

Wozu?
Beim AVR gibt es keine unterschiedlichen Zugriffe dafür.

Willst Du MMIO ansprechen, mach ne Struct und setze sie auf die Adresse 
des Interfaces.

Christian O. schrieb:
> Dann muß ich den
> Quellcode
> nicht ändern.

einfach durch nichts ersetzen:

1

#define XBYTE

Peter Dannegger schrieb:
> Wozu?

Hat er doch dazu geschrieben, um vorhandenen Code mit möglichst wenigen 
Änderungen portieren zu können.

Peter Dannegger schrieb:
> einfach durch nichts ersetzen:
> #define XBYTE

Was den vorhandenen Code in kompletten Unsinn verwandelt.

Stefan Ernst schrieb:
> Was den vorhandenen Code in kompletten Unsinn verwandelt.

Stimmt, ich hatte das mit den Memory-Specifier verwechselt, da geht das:

1

#define data

2

#define idata

3

#define pdata

4

#define xdata

Man müßte mal wissen, wie das Macro XBYTE definiert ist. Vielleicht 
benutzt es ja xdata.

Peter Dannegger schrieb:
> Man müßte mal wissen, wie das Macro XBYTE definiert ist.

Das ist offenbar kein Makro, sondern eine Art Pseudo-Array, das vom 
Compiler speziell behandelt wird (Index wird direkt als Adresse 
interpretiert).

Wie vermutet:

1

// Original Definition des XBYTE:

2

#define XBYTE ((unsigned char volatile xdata *) 0)

3

4

// Und schon geht es auch beim AVR:

5

#define xdata

Peter Dannegger schrieb:
> // Und schon geht es auch beim AVR:

Kaum, denn XRAM fängt kaum an physikalischer Adresse 0 an.

Johann L. schrieb:
> Kaum, denn XRAM fängt kaum an physikalischer Adresse 0 an.

Das hat ja auch niemand verlangt.

Das Beispiel des TO compiliert jedenfalls so wie gewünscht:

1

int main()

2

{

3

  uint8_t myuint8_tvar;

4

5

  myuint8_tvar = XBYTE[ 0x8001];

6

  22:   80 91 01 80     lds     r24, 0x8001

7

  XBYTE[ 0x8001] = myuint8_tvar;

8

  26:   80 93 01 80     sts     0x8001, r24

9

  2a:   ff cf           rjmp    .-2             ; 0x2a <main+0x8>