xmega + SDRAM + LIBC > 64K?

[Max (Gast)]

Hallo,

ich bin am überlegen mir ein Experimentierboard für den Atmel xmega128 
zu zulegen + externen RAM (>8MB).

Meine Frage ist jetzt:

Ist es in zwischen möglich mit der LIBC mehr als 64K Ram anzusprechen?
Also das ich z.B. den Heap großer als 64K definieren kann bzw. diesen 
weiter nach hinten zu verlagern.

Es gab ja immer die Einschränkung das AVR-GCC + LIBc nur 16Bit Pointer 
verwenden bzw. den Z-Pointer nicht verwenden, ist das so weit richtig?


Ich habe kürzlich durch Zufall diese Zeile in den LIBC News:

*** Changes in avr-libc-1.6.5:
* Bugs fixed:
  [no-id] malloc() could allocate memory beyond the limits of heap

Heap Limit war doch 64k oder? Wenn jetzt das Limit aufgehoben ist dann 
müsste ich doch 128MB ansprechen können.

Hat schon jemand Erfahrung damit?

mfg Max

[Simon K. (simon)]

Max schrieb:
> Es gab ja immer die Einschränkung das AVR-GCC + LIBc nur 16Bit Pointer
> verwenden bzw. den Z-Pointer nicht verwenden, ist das so weit richtig?

Pointer sind nach wie vor immer noch 16 Bit breit, weshalb man immer 
noch "Workarounds" braucht.
Entweder Z Pointer oder eine DMA dafür missbrauchen.

> Ich habe kürzlich durch Zufall diese Zeile in den LIBC News:
>
> *** Changes in avr-libc-1.6.5:
> * Bugs fixed:
>   [no-id] malloc() could allocate memory beyond the limits of heap

Das heißt nur, dass es ein Bug mit malloc gab, wo man Speicher außerhalb 
des Heaps allokieren konnte.

[Sauger (Gast)]

Hallo,

hier mal ein Ansatz wie sich einige Funktionen der LIBC auf einem xMega 
verbiegen lassen:

#define HiMemExecFunc(Ramp,Func) {\
 \
 uint8_t RampX = *(uint8_t*)_SFR_IO_ADDR(RAMPX);\
 uint8_t RampY = *(uint8_t*)_SFR_IO_ADDR(RAMPY);\
 uint8_t RampZ = *(uint8_t*)_SFR_IO_ADDR(RAMPZ);\
 \
 __asm__ __volatile__\
 ( "out %1,%0"  "\n\t"       \
   "out %2,%0"  "\n\t"       \
   "out %3,%0"  "\n\t"       \
   ::\
      "r" (Ramp),\
      "I" _SFR_IO_ADDR(RAMPX), \
      "I" _SFR_IO_ADDR(RAMPY), \
      "I" _SFR_IO_ADDR(RAMPZ)  \
 );\
 \
 Func;\
 \
 *(uint8_t*)_SFR_IO_ADDR(RAMPX) = RampX;\
 *(uint8_t*)_SFR_IO_ADDR(RAMPY) = RampY;\
 *(uint8_t*)_SFR_IO_ADDR(RAMPZ) = RampZ;\
}

MfG

[Max (Gast)]

OK danke euch zweit

@Sauger die Funktion muss ich mir mal genau angucken danke dir.


An was liegt das eigentlich das der avr-gcc + libc immer noch nicht den 
Z-Pointer "nativ" unterstützen? Wird daran nix mehr weiter entwickelt? 
Die xmegas sind ja nun eine weile auf dem Markt und Atmel ist doch auch 
an der Entwicklung beteiligt kann das nicht richtige verstehen. Atmel 
muss doch sehr daran interessiert sein das dies Funktioniert, den die 
Serie ist ja extra auf C Optimiert.


Also würde sowas auch nicht funktionieren

#define SDRAM_ADDR 0x128000
#define SDRAM(addr) ((uint8_t *) SDRAM_ADDR)[addr]

int_exRam();

SDRAM(0x01) = 0x11;

[Sauger (Gast)]

Moin,

Hier mal ein Auszug meiner himem.h. Arbeitet mit Segment/Offset 
Adressierung,
ist nicht sonderlich gut dokumentiert sollte aber ausreichen.

MfG

[Max (Gast)]

Vielen Dank!


Aber noch mal zur frage warum baut LIBc sowas nicht mit ein?

[Simon K. (simon)]

Weil "LIBc" keine Person ist, sondern eine kleine Gruppe von 
freiwilligen und Hobbyprogrammierern und es bisher noch keiner gemacht 
hat. Lediglich Eric Weddington ist von Atmel für die libc zuständig. 
Mehr weiß ich aber auch nicht.

[Max (Gast)]

Danke noch mal an alle das hat mich ziemlich weit gebracht.

Aber noch eine Frage:
Muss nicht dringend die Globalen Interrupts ausgeschaltet werden? (Das 
welche verwendet werden vorausgesetzt). Weil sonst gibts doch 
Datenchaos.

[Sauger (Gast)]

Moin,

Max schrieb:
> Muss nicht dringend die Globalen Interrupts ausgeschaltet werden? (Das
> welche verwendet werden vorausgesetzt). Weil sonst gibts doch
> Datenchaos.

nicht unbedingt. Schau dir mal einen Interrupthandler im *.lss file an.

MfG

[Max (Gast)]

Supi Danke

Der Z-Pointer wird komplett gesichert und dann wieder zurück gespielt.

Somit ist das ganze nicht so schlimm und der Overhead hält sich auch in 
Grenzen, wenn man nicht immer nur 1Byte liest oder schreibt.


Mit der Art Segmentierung kann man eigentlich gut ein Multitasking 
System bauen.
Auch malloc lässt sich so gut erweitern und solange man nicht mehr als 
64K Speicher  angefordert ist das alles kein Problem, man kann dann nur 
nicht direkt auf den Speicherzugreifen sondern erst die richtige 
Segmentierung wählen.

[Christian M. (fpga-fan)]

Sauger schrieb:
> Moin,
> Hier mal ein Auszug meiner himem.h. Arbeitet mit Segment/Offset
> Adressierung,
> ist nicht sonderlich gut dokumentiert sollte aber ausreichen.
>
> MfG


Hi,

ich habe mir mal den Code oben vom Sauger in meinen 
Xmega128-A1-explained Board hinein geladen und einfach mal versucht es 
zum laufen zu lassen. Die Anfangs- und endadresse habe ich im Code 
angepasst:

Anfangsadresse = 0x800000
Endadresse = 0xFFFFFF

Was die externen 8MB SDRam auf dem Board auch ausmachen.

Der Test läuft mit 19 Bytes gut, ab dem zwanzigsten Byte bekomme ich nur 
noch Müll ausgelesen.

Ich habe das lesen und schreiben mit folgenden Befehlen gemacht:

HiMemWriteByte(0,0,0x31);  //es wird der Buchstabe 1 gesendet
_delay_ms(1000);  //keine chance für timingprobleme
HiMemWriteByte(0,1,0x32);  //zweite Adresse
_delay_ms(1000);  //keine chance für timingprobleme
HiMemWriteByte(0,2,0x33);  //dritte Adresse
_delay_ms(1000);  //keine chance für timingprobleme
und so weiter bis zur 20. Adresse...

und danach:
int temp1 = HiMemReadByte(0,0);  //erste Adresse
_delay_ms(1000);  //keine chance für timingprobleme
int temp2 = HiMemReadByte(0,1);  //erste Adresse
_delay_ms(1000);  //keine chance für timingprobleme
int temp3 = HiMemReadByte(0,2);  //erste Adresse
und so weiter bis zum 20. Byte

Das 20. Byte hatte schon einen falschen Inhalt. Dann habe ich versucht 
als Variableübergabe nicht die Adresse "0" und "1" und "2" usw. 
einzugeben, sondern die echte Adressen 0x800000, 0x800001, 0x800002 usw. 
Auch da das gleiche Spiel nur bis zur 19.ten Adresse.

Was mich noch gar nichts sagt, was hat es mit diesen Segmenten auf sich? 
Ich habe hier immer auf gut Glück mit Segment 0 getestet, aber richtig 
im klaren bin ich mir noch nicht, welche Variablen ich mit HiMemReadByte 
und HiMemWriteByte übergeben soll.

Aus dem Source bin leider ich nicht schlau geworden um das abzuleiten 
...

[Christian M. (fpga-fan)]

Ich habe auch den Verdacht, dass gar nicht der externe SDRam beschrieben 
wird, sondern der interne SRam. Muss ausser dem oben genannten Code noch 
irgendwas berücksichtigt werden? EBI und Sysclock ist initialisiert...

[Johann L. (gjlayde)]

Segment 0 ust doch der normale Speicherbereich.

Du schreibst gerade wild im I/O-Bereich rum...

[Christian M. (fpga-fan)]

Auch so:?

HiMemWriteByte(0,0x800000,0x31);


das ist doch die erste Adresse des externen SDRam's. Zumindest finde ich 
in den Xmega Datenblättern nichts über Segmente.

[Christian M. (fpga-fan)]

Oh, mann, jetzt hab ich es:

HiMemWriteByte(0x80,0x0000,0x31);

Das Segment sind einfach die oberen 8 Bits der 24Bit Adresse, und die 
mittlere Zahl sind nur die restlichen 16 Bit der Adresse...

Tja, eine Doku hätte...