Würde mich über Rückmeldungen freuen. Wer Lust und Zeit hat könnte auch
mal einige Performancemessungen machen z.B.
10k per malloc() anfordern, diese mit memset() füllen, zurücklesen und
mit free() wieder freigeben, um den unterscheid zwischen 32/64MHz
ClkPer2 zu sehen. Ich habe leider keine Messtechnik.
MfG
Nabend,
Reader schrieb:> * Für diese Funktionen stehen 48K zur Verfügung, da gcc und die> * libc von einem 16-Bit Adressraum ausgehen.
dann jubel dem AVR-gcc und der libc mal 8M unter die er für dich
verwaltet.
MfG
Reader schrieb:> wozu sollen die 48k gut sein ? Das Xplain hat 8MB SDRAM !
Das ist schon richtig. Nur leider lassen sich die 8 MB mit AVR-GCC nicht
so einfach, elegant ansprechen.
Als "Anleitung" wie man generell (und in einer hoffentlich erträglichen
Geschwindigkeit) mit dem DRAM des XPlain arbeiten kann, ist das
Codefragment eine "Offenbarung".
Dank an Sauger.
Werner
durch rumspielen mit den Prescalern
CLK_PSADIV_1_gc | CLK_PSBCDIV_1_2_gc
ist zwischen 32/64MHz ClkPer2 ein Faktor 2 erkennbar. Wenn jemand das
ganze mal an einen Oskar hängen könnte um reelle Zeiten (ms) zu
ermitteln wäre ich dankbar.
MfG
@Sauger
>dann jubel dem AVR-gcc und der libc mal 8M unter die er für dich>verwaltet.
Aus diesem Grund nutze ich Assembler, damit lassen sich die 8MB
ansprechen.
@Werner B:
>Als "Anleitung" wie man generell (und in einer hoffentlich erträglichen>Geschwindigkeit) mit dem DRAM des XPlain arbeiten kann, ist das>Codefragment eine "Offenbarung".
Meine Meinung: Ganz oder gar nicht.
Hat meiner Meinung nach in der Codesammlung nichts zu suchen, da völlig
unbrauchbar.
Moin,
Reader schrieb:> Aus diesem Grund nutze ich Assembler, damit lassen sich die 8MB> ansprechen.
Ja, und deswegen auch:
"48KB SDRam für gcc mit 64MHz auf einem Atmel Xplain"
Das Beispiel zeigt wie man das EBI das xMega128A1 auf dem Xplain
initialisiert und den System Takt über die PLL auf 32/64MHz setzen kann.
Durch die Linkeroptionen:
"-Wl,-section-start=.data=0x804000" und
"-Wl,-defsym=__heap_end=0x80ffff"
werden dann 48K der 8M dem gcc zugeschlagen. Der Rest lässt sich auch
weiterhin nutzen egal ob C oder Assembler, man muss ihn nur selber
verwalten.
MfG
P.S.
0x9000 Byte füllen und zurücklesen (mit obiger Testschleife) dauern bei
64MHz ClkPer2 20ms bei 32Mhz 27ms
Reader schrieb:> @Sauger>>>dann jubel dem AVR-gcc und der libc mal 8M unter die er für dich>>verwaltet.>> Aus diesem Grund nutze ich Assembler, damit lassen sich die 8MB> ansprechen.
Wo ist der Sinn? Auch mit dem AVR-GCC lassen sich 8MB ansprechen. Nur
kann der Linker wegen der 16Bit Pointer unter C nicht die ganzen 8MB
verwalten.
In Assembler kann man den Speicher gar nicht verwalten lassen, also ist
die hier gezeigte Lösung der Mittelweg zwischen "gar keine automatische
Verwaltung" (Assembler) und "vollautomatische Verwaltung" (mit einem
gepimpten C Compiler, der das unterstützt, wozu AVR-GCC aber nicht
gehört.).
Moin,
mal ein Selbstgespräch:
mit:
"-Wl,-section-start=.noinit=0x804000" und
"-Wl,--defsym=__heap_end=0x80ffff
bleiben statische Variablen im internen SRam, malloc()/free() gehen ins
SDRam.
MfG
Malzeit,
Dominik,
lasse dich nicht von "EBI_MRDLY_0CLK_gc" blenden. "_0CLK" ist schon
CLK_PR2 / 2
... das ganze aus dem Kopf, werde es mir aber nochmal (beim nächsten
Sauwetter) anschauen.
MfG
Sauger schrieb:> lasse dich nicht von "EBI_MRDLY_0CLK_gc" blenden. "_0CLK" ist schon> CLK_PR2 / 2
Hallo Sauger,
Warum ist das schon CLK_PER2 / 2? Hängt das mit dem CAS = 2 zusammen
(kenn mich mit SDRAM [noch] nicht so gut aus? Bei den
Registerbeschreibungen steht im AVR XMEGA A Datenblatt immer
1
... in number of Peripheral 2x clock (CLK_PER2) cycles ...
Daher bin ich davon ausgegangen, dass sich die Registerwerte auf
CLK_PER2 beziehen. Auch in Abbildung "Figure 33-44. Single write" sieht
man NOPs die nur einen CLK_PER2-Zyklus lang sind. Die Anzahl der NOPs
entspricht dem Wert in Register ??DLY . EBI_??DLY_0CLK_gc ist als 0
definiert. Allerdings steht in den Fußnoten zu den diversen
Timing-Diagrammen immer
1
... The number of NOPs is equal to WRDLY[1:0] + 1 ...
Also dürfte für WRDLY eine Ausnahme gelten...
Soll ich eventuell einen regulären Beitrag im µC Forum öffnen?
lg,
Dominik
PS: Ich will dich jetzt aber nicht von diversen Freizeitaktivitäten bei
idealem Sommerwetter abhalten ;-)
Nabend,
Dominik schrieb:> ... in number of Peripheral 2x clock (CLK_PER2) cycles ...
der xMega braucht 2 Takte für sich (besser das EBI)
... aus dem Kopf,
habe hier als Betreuer jede Menge kleine (WUKIS) rumlaufen, die sich
nicht entscheiden können wer lieber Cowboy / Indianer ist. Nach der
Fütterung liegen fast alle in ihren Zelten / Tipis, aber die Nacht ist
noch nicht zu Ende.
MfG
@Dominik:
Meiner Meinuing nach siehst du das schon richtig so. Ich benutze den
selben SDRAM (nicht XPLAIN) und nutze folgende Werte laut Datenblatt für
64MHz CLK_PER2:
EBI.INITDLY=6400;// max. 16383, min. 100us, 1/64MHz*6400=100us
Auch beim Refresh und Initdelay sehe ich hier im Forum immer wieder
inkorrekte Einstellungen. Zb. REFRESH = 0xFF00; was soll das bringen
wenn Refresh nur 10Bit breit ist, also bis 1023 gehen kann.
Die Row/ColCycDly findet man auch im Datenblatt des SDRAMs, als Tabelle
in Angabe EBI Takte. Andere Angaben sind wieder in Zeit gemacht und man
muß das in Takte umrechnen, wie Zb. Refresh und InitDelay.
Gruß Hagen
PS: allerdings läuft es auch mit Angabe von ???_0CLK_gc in allen Felder
bis auf EBI_ROWCYCDLY_1CLK_gc.
Hallo,
danke für den Code, glaube das wird mir sehr weiterhelfen.
Habe bisher noch nie Linker-Optionen verwendet. Kannst du mir sagen, wo
ich
"-Wl,-section-start=.data=0x804000" und
"-Wl,-defsym=__heap_end=0x80ffff"
eintragen soll?
Verwende einen ATXMEGA128128A1.
MfG
Sebastian
Hallo noch mal,
habe nun herausgefunden, dass man die Linker-Optionen in AVR Studio
direkt eintragen kann.
Aber wohin mit dem Code? Er soll ja vor der main aufgerufen werden.
Würde mich freuen, wenn ihr mir weiterhelft.
MfG
Sebastian
Sebastian schrieb:> Hallo noch mal,>> habe nun herausgefunden, dass man die Linker-Optionen in AVR Studio> direkt eintragen kann.> Aber wohin mit dem Code? Er soll ja vor der main aufgerufen werden.>> Würde mich freuen, wenn ihr mir weiterhelft.>> MfG> Sebastian
Möglicherweise in Section .init3
Siehe
http://www.nongnu.org/avr-libc/user-manual/mem__sections.html
Janz einfach. Den obigen Code setzt Du z.B. in die Datei die Deine
main() enthält. Anhand dieser Zeile
void _attribute_ ((naked, section(".init3"))) XplainMemAndClk(void)
erkennt der Compiler was Sache ist und setzt diesen Teil im compilierten
Code an die richtige Stelle.
Hallo nochmal,
leider klappt das alles doch nicht so ganz wie erhofft. Das obige
Beispiel funktioniert.
Nun habe ich mit den Linkeroptionen
"-Wl,-Tdata=0x804000,--defsym=__heap_end=0x80ffff" .data, .bss und den
heap in den externen RAM gelegt. Die main() sieht so aus:
int main (void)
{
unsigned int i;
static unsigned int c [15000];
initSerialPortE0(9600);
sei();
for (i = 0; i < 15000; i++)
{
c[i] = i;
}
for (i = 0; i < 15000; i++)
{
usartSendE0(c[i] >> 8);
usartSendE0(c[i]);
}
for (;;)
{}
}
Das Programm scheint immer wieder neu zu starten und gibt manchmal ca
1500 Bytes aus, manchmal auch nicht.
Wäre nett, wenn ihr mir noch mal weiterhelfen könntet.
MfG
Sebastian
Hallo,
das Problem war wohl die Initialisierung des EBI, das bei meiner
Hardware so nicht funktioniert hat. Habe nun aus der Atmel Appnote
AVR1312 die Initialisierung übernommen. Musste sie nur umbauen, sodass
es keine Funktionsaufrufe gibt (der Stackpointer ist ja noch nicht
initialisiert).
Das Ergebnis findet sich im Anhang.
MfG
Sebastian
