Hallo,
ich versuche bei dem besagten uC mit externen SRAM diesen zu beschreiben
und auszulesen. Die Konfiguration ist soweit in Ordnung.
Aus dem Datenblatt habe ich entnommen, dass die erste Adresse die
0x60000000 ist.
Bei dieser Adresse soll ein Header geschrieben werden, der 32 Byte lang
ist. Dem folgenden die eigentliche Werte, die ich mittels des Headers
später auslesen möchte.
Leider funktionieren meine Funktionen nicht so, wie ich mir das
vorstelle. Deshalb meine Frage an euch, hat jemand auch schon mal sowas
gemacht und könnte mir weiterhelfen?
Momentan habe ich eine Funktion, die den Header in den SRAM bei eine
angegebenen Adresse schreiben soll und eine andere die diesen auslesen
soll. Dabei bediene ich mir eines Makros, dass 32Byte in den interen
Registern des Cortex beschreibt und das ist scheinbar der Knackpunkt...
FSMC_NORSRAMCmd(FSMC_Bank1_NORSRAM1,ENABLE);//entfällt später
33
34
/* Enable FSMC Bank2_PSRAM Bank */
35
FSMC_NORSRAMCmd(FSMC_Bank1_NORSRAM2,ENABLE);
Nach dem zweiten Ausführen der Fkt. "copyInBufferH" bleibt der
Prozessor an dem Marko hängen. In der AddrHead[MessNr] steht immer
die Anfangsadresse des zu beschreibenden RAMs...
Stephan
Wenn immer nur die 32 Bytes kopiert werden und keine grösseren Blöcke,
dann würde ich nicht drauf wetten, dass deine Version viel effizienter
ist als eine, die weniger Register braucht. Denn die Zwischenregister
müssen gesichert werden, was auch Zeit braucht.
A. K. schrieb:
> Wenn immer nur die 32 Bytes kopiert werden und keine grösseren Blöcke,> dann würde ich nicht drauf wetten, dass deine Version viel effizienter> ist als eine, die weniger Register braucht.
Nur die Codegröße unterscheidet sich möglicherweise. Aber warum nicht
einfach memcpy() verwenden?
> Denn die Zwischenregister müssen gesichert werden, was auch Zeit braucht.
Ja, der Teil fehlte mir auch irgendwie :-)
--
Marcus
Marcus Harnisch schrieb:
> Ja, der Teil fehlte mir auch irgendwie :-)
Nicht unbedingt, denn da die Register korrekt als "verwendet"
gekennzeichnet wurden kümmert sich der Compiler selbst darum.
Allerdings werden so aus den 2 LDM/STMs insgesamt 4, sofern das als
eigenständige Funktion implementiert ist. Andernfalls steht diese Aktion
einer effektiven Registeroptimierung im Weg.
A. K. schrieb:
> Nicht unbedingt, denn da die Register korrekt als "verwendet"> gekennzeichnet wurden kümmert sich der Compiler selbst darum.
Irgendwann werde ich mal versuchen, diese kryptische Syntax des GCC
Inline Assemblers zu verstehen. Wenn ich mir die memcpy()
Implementierung bei CodeSourcery anschaue, dann sollte man wirklich
darüber nachdenken...
Und ich dachte schon, der RealView Compiler hätte das durchaus besser
machen können. Erst bei einem doppelten memcpy() mit jeweils vier Worten
wird das von diesem Compiler richtig effizient umgesetzt.
1
voidcopyData32(u32*pSrc,u32*pDest)
2
{
3
memcpy(pDest,pSrc,16);
4
memcpy(pDest+4,pSrc+4,16);
5
}
Aber wenn Zeit nicht das eigentliche Problem ist, dann ist memcpy() in
jedem Fall sinnvoller als Inline Assembler.
--
Marcus
