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
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.
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
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.
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.
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
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.
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
...
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...
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.
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...
