Hallo, ich habe einen CORTEX M0. Dieser hat ein SRAm welches mit vollem Systemtakt laufen kann und ein Flash welches langsamer ist. ich würde gerne folgendes bei zeitkritischen Routinen machen um meine Performance zu verbessern. -> Beim Systemstart werden Funktionen vom Flash ins SRAM geschrieben (ca. 4kB für "schnellen" Code verfügbar) -> Die zeitkritischen Funktionen werden dann von dort ausgeführt. Ich will/kann nichts mit den Boots PINs machen. ich suche eine universelle Lösung und eine Anleitung wie so was geht. Erstens braucht es ein Skript um am Systemstart vom Flash ins SRAM zu kopieren bevor irgendwas vom C-Code ausgeführt wird. Zweitens muss der Linker so eingestellt werden das er die Funktionen im SRAM erwartet. Wer hat so was schon mal gemacht und kann Tips/Infos geben wie es genau geht? IDE ist MDK-ARM (habe dort leider keine Beispiele gefunden)
Kann jetzt meine Versuche momentan nicht finden, aber meine Vorlage war damals das: http://siwawi.bauing.uni-kl.de/avr_projects/arm_projects/#gcc_ramfunc
>ich würde gerne folgendes bei zeitkritischen Routinen machen um meine >Performance zu verbessern. Ich würde gleich einen schnelleren Controller nehmen und mir das rumgekrampfe sparen.
Hallo Holger, danke für den (konstruktiven) Beitrag. Den Geldbeutel aufmachen kann jeder. Entwickeln und sich wo reinarbeiten nur wenige. Ich bin an Lösungen zu einem gegeben Thema mit einer gegeben Randbedingung interessiert. Die Maschine bleibt und hat mit 48MHz Cortex M0 genug Dampf für die Aufgabe sofern die Ausführung aus dem flash geschieht. Theoretisch kann auf Basis des Assembler-Codes unter Berücksichtigung der 3-stufigen Pipeline, den Sprüngen und aktuellen Messergebnissen darauf geschlossen werden das der Boost mit Ausführung aus SRAM zum Ziel führt. Jetzt bin ich an der Realisierung interessiert. hp-freund hat einen Weg aufgezeigt für eien etwas ältere Maschine. Folgendes habe ich momentan im Sinn nachdem ich mich weiter eingelesen habe (ungetestet): Mit einem sog. scatter-file die "Execution Region" des Programmes definieren und die zeitkritischen Routinen in einer eigenen C-Datei kompilieren. Beschrieben wie auf: http://www.keil.com/support/man/docs/armlink/armlink_BABDJCAA.htm Jetzt ist nur noch die Frage an welcher Stelle das Kompilat im Flash abgelegt wird. Wie groß es ist und dann kann ich es mit memcopy rüberschieben bevor mein Code beginnt der die Funktionen im SRAM aufruft. Das ganze voretilhafterweise vollautomatissch d.h. über Symbole statt absolute Größen
Stichwort: fastrun sieh dir mal die fastfunc.* und die LPC2129-ROM.ld an. Es wird einfach eine Section hinter der .data Section angelegt. In diese kommen die Funktionen und werden wie die Variablen in den RAM kopiert. Ist keine Hexerei ;-)
>Die Maschine bleibt und hat mit 48MHz Cortex >M0 genug Dampf für die Aufgabe sofern die Ausführung aus dem flash >geschieht. Fein. >Theoretisch kann auf Basis des Assembler-Codes unter >Berücksichtigung der 3-stufigen Pipeline, den Sprüngen und aktuellen >Messergebnissen darauf geschlossen werden das der Boost mit Ausführung >aus SRAM zum Ziel führt. Jaja, mach mal. Und praktisch hat ein M4 mit 168MHz genug Dampf das ohne rumgfrickel direkt aus dem Flash zu erledigen. Aber was rede ich. Mach halt.
holger schrieb: > Jaja, mach mal. > > Und praktisch hat ein M4 mit 168MHz genug Dampf das ohne > rumgfrickel direkt aus dem Flash zu erledigen. > > Aber was rede ich. Mach halt. Dann kannst du ja die Mehrkosten dafür ohne Probleme übernehmen? Speedy Gonzales schrieb: > Den Geldbeutel aufmachen kann jeder. > Entwickeln und sich wo reinarbeiten nur wenige. > > Ich bin an Lösungen zu einem gegeben Thema mit einer gegeben > Randbedingung interessiert. Die Maschine bleibt und hat mit 48MHz Cortex > M0 genug Dampf für die Aufgabe sofern die Ausführung aus dem flash > geschieht. So ist es gesagt! Wenn es nicht passt, muss man sich dazu nicht äußern. Es gibt auch andere, die an Lösungen dafür interessiert sind.
holger schrieb: > Und praktisch hat ein M4 mit 168MHz genug Dampf das ohne > rumgfrickel direkt aus dem Flash zu erledigen. Manche hier posten nicht als Bastler, sondern für die Firma, so dass Stückpreise durchaus eine Rolle spielen können.
z.B. so:
1 | #define FASTRUN __attribute__ ((long_call, section (".data")))
|
2 | |
3 | FASTRUN
|
4 | void SysTick_Handler(void) |
5 | {
|
6 | ....
|
7 | }
|
Welche Section das ist, ist eigentlich egal. Es muss nur eine sein deren Inhalt beim Systemstart vom Flash in den Ram kopiert wird.
Speedy Gonzales schrieb: > ich habe einen CORTEX M0. > Dieser hat ein SRAm welches mit vollem Systemtakt laufen kann und ein > Flash welches langsamer ist. Welcher Typ ist denn das? Die meisten Cortexe können auch aus dem Flash mit maximalem Takt laufen. Nur bei Sprüngen kann manchmal ein Wait nötig sein. Sei also nicht traurig, wenn der Zeitgewinn nur sehr gering ausfällt.
Ein uraltes Beispiel für einen µC, der ext. EPROM mit 8 Bit Busbreite
aber (begrenztes) SRAM für den Stack hatte.
static void h8s_schiebe_4094x(uchar wert) // Startadresse im ROM
{
..... // auszuführender Code
}
static void h8s_schiebe_4094y(){} // zur Bestimmung der Codegröße
void h8s_schiebe_4094(uchar wert) // nach außen sichtbare Funktion
{
static char init=0;
static short (*f)(uchar);
if(!init) {
H8S_DDR6 |= 0x0c; // port6 richtung als ausgang bit 0+1
init = 1;
f = load_i_ram((char *)h8s_schiebe_4094x,(char *)h8s_schiebe_4094y);
}
f(wert);
}
Mit f = load_i_ram() wird der schnell auszuführende Code in einen
reservierten RAM-Bereich kopiert (heap z.B.), die neue Startadresse
zurückgeliefert und nachfolgend über f(wert) aufgerufen.
Falls im RAM kein Platz mehr frei ist, wird die Startadresse im ROM
zurückgeliefert. Je nachdem, ob der µC 2k oder 8k RAM hatte, passten
alle Routinen hinein oder auch nicht.
Es gibt bezüglich absoluter und rel. Adressierung Einschränkungen, die
vom jeweiligen Compiler abhängen.
m.n. schrieb: > } > static void h8s_schiebe_4094y(){} // zur Bestimmung der Codegröße Der Trick funktioniert jedoch nur, wenn der Linker nicht umsortiert oder unbenutzte Funktionen gleich ganz rausschmeißt.
Steffen Rose schrieb: > Der Trick funktioniert jedoch nur, wenn der Linker nicht umsortiert oder > unbenutzte Funktionen gleich ganz rausschmeißt. Das ist alles bekannt, weshalb ich auf Einschränkungen hingewiesen habe. Wer soetwas programmiert wird wissen, wie er es kontollieren muß.
m.n. schrieb: > Wer soetwas programmiert wird wissen, wie er es kontollieren muß. Ohne den Fragesteller zu kennen würde ich aber meinen, dass er nicht so tief drin steckt.
Steffen Rose schrieb: > Ohne den Fragesteller zu kennen würde ich aber meinen, dass er nicht so > tief drin steckt. Dann geben wir ihm doch die Gelegenheit, noch etwas dazuzulernen. Sollte er weitere Fragen haben, wirst Du ihm sicherlich zu einem Deiner zahlreichen Lösungsvorschläge Rede und Antwort stehen.
Dein Beispiel fand ich gut, da es zeigt, wie man das Problem in Fällen löst, bei denen einem der Linker nicht unterstützt. Warum Du ein Problem damit hast, dass ich auf zusätzliche Gefahren aufmerksam mache, verstehe ich nicht. m.n. schrieb: > Dann geben wir ihm doch die Gelegenheit, noch etwas dazuzulernen. Dann missverstehe ich dieses Forum. Klar aus Fehlern lernt man - vermutlich sogar besser als wenn man die Lösung vorgesetzt bekommt. Aber muss man deswegen unsere Mitleser auflaufen lassen?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.