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
:
Verschoben durch User
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.
Hallo, hier mal ein Ansatz wie sich einige Funktionen der LIBC auf einem xMega verbiegen lassen:
1 | #define HiMemExecFunc(Ramp,Func) {\
|
2 | \
|
3 | uint8_t RampX = *(uint8_t*)_SFR_IO_ADDR(RAMPX);\
|
4 | uint8_t RampY = *(uint8_t*)_SFR_IO_ADDR(RAMPY);\
|
5 | uint8_t RampZ = *(uint8_t*)_SFR_IO_ADDR(RAMPZ);\
|
6 | \
|
7 | __asm__ __volatile__\
|
8 | ( "out %1,%0" "\n\t" \
|
9 | "out %2,%0" "\n\t" \
|
10 | "out %3,%0" "\n\t" \
|
11 | ::\
|
12 | "r" (Ramp),\
|
13 | "I" _SFR_IO_ADDR(RAMPX), \
|
14 | "I" _SFR_IO_ADDR(RAMPY), \
|
15 | "I" _SFR_IO_ADDR(RAMPZ) \
|
16 | );\
|
17 | \
|
18 | Func;\
|
19 | \
|
20 | *(uint8_t*)_SFR_IO_ADDR(RAMPX) = RampX;\
|
21 | *(uint8_t*)_SFR_IO_ADDR(RAMPY) = RampY;\
|
22 | *(uint8_t*)_SFR_IO_ADDR(RAMPZ) = RampZ;\
|
23 | }
|
MfG
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
1 | #define SDRAM_ADDR 0x128000
|
2 | #define SDRAM(addr) ((uint8_t *) SDRAM_ADDR)[addr]
|
3 | |
4 | int_exRam(); |
5 | |
6 | SDRAM(0x01) = 0x11; |
Moin, Hier mal ein Auszug meiner himem.h. Arbeitet mit Segment/Offset Adressierung, ist nicht sonderlich gut dokumentiert sollte aber ausreichen. MfG
Vielen Dank! Aber noch mal zur frage warum baut LIBc sowas nicht mit ein?
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...
Segment 0 ust doch der normale Speicherbereich. Du schreibst gerade wild im I/O-Bereich rum...
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...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.