Hallo, es gibt ja eine kostenfreie EVAL Version von Keil, die Codegrößen von bis zu 16kB zulässt. Da ich zumindest in absehbarer Zeit keine größeren Programme plane und ich Keil eigentlich ganz nett finde, wollte ich fragen, ob der Startupcode den Keil automatisch generiert brauchbar ist, oder ob der in der Regel so großer Anpassungen bedarf, dass ich auch gleich selber welchen schreiben könnte? Target sind ARMs, wie im Betreff schon erwähnt. Vor allem auch mal "exotischere" Typen, zu denen noch nicht so viele Beispiele im Netz kursieren. MfG Chris
Ich bin aus dem Starup-Code nie wirklich schlau geworden und es hat mich auch immer gestört, weil ich es nicht verstanden habe. Deshalb hab ich es immer über Board geworfen. sicherlich hat es seinen Sinn für den jenigen der es versteht;) Den Startupcode braucht man, glaube ich, nicht wirklich.
Hallo Chris, ich hab bisher fast aussschließlich mit Keil an ARM Prozessoren gearbeitet und kann bisher nicht über die startup klagen solang dein Target auch unterstützt wird. Die Startup ist nicht für jeden µC gleich da sich die Speicheradressen wie zumbeispiel entryAdresse der Main unterscheiden. Ebenso gilt es für den Stack der sich in den Unterschiedlichen Betriebsmodies also USER/SVC/ISR... unterscheidet. Wenn dir der jeweilige StackSpeicher zu klein ist oder zu groß kannst dies ja auch selbst kurz eintragen. Die ErrorHandler Sprungadresse sind ebenfalls von der Keil Startup schon geschrieben doch im Fall eines Aborts oder Resets sind die Standartroutinen glaub eh immer ein Reset Ansonsten werden ja nur Taktraten und PLL einstellungen vorgenommen. Das kannst entweder in der startup selbst ändern oder einfach wenn in der Main() drin bist ne Initialisierung in C schreiben. Ich hoff das Hilft dir ein wenig weiter. CYA
Chris: Der Keil Startup Code für LPC21xx und LPC22xx paßt komplett auf diese gesamte Bausteinserie und ist ausgereift. Bei den neueren LPC23xx und 24xx hab ich allerdings keine Erfahrung. Die Keil Startup.s in der Demo-Version ist voll in Ordnung und die selbe wie in der Vollversion, enthält alle Grundinitialisierungen, auch die, die man auf Grund der Geschwindigkeit und Änderung der Operation Modes in C nicht so gut bewerkstelligen kann: Initialisierung der Stacks für alle Operation Modes Heap Speicherreservierung (für ARM RealView) Interrupt- und Exception- Vektoren mit Default-Labels (Endlos-Schleifen für die Exceptions, die man bei Bedarf anpassen kann) PLL Initialisierung MAM Setup External Memory Controller Selbst habe ich hinzu gefügt: IRQ Surprise Interrupt Handler mit IRQ Surprise Interrupt Zähler FIQ Surprise Interrupt Handler mit FIQ Surprise Interrupt Zähler Diese Zähler kann man z.B. über UART an Hyperterminal ausgeben oder auf dem CAN-Bus an den CAN-Analyser ins Nutzdatenfeld, um zu sehen, ob der ARM irgendwelche Mätzchen (Unannehmlichkeiten) macht. Und die Unannehmlichkeiten habe ich tatsächlich, bis zu 100000 FIQ Capture Interrupts pro Sekunde (aus hochgenauer Frequenzmessung) und Watchdog Feed, das konnte bisher nicht gelöst werden. Wenn du den Startup-Code selbst erstellen wolltest, nur um den ARM erst mal überhaupt vernünftig ans laufen zu bekommen, wärst du eine Weile nur damit beschäftigt, bis dein ARM überhaupt vernünftig läuft. Die Startup.s selbst zu erweitern, ist natürlich jedem User frei vorbehalten. Ich verwende LPC2129 und 2138, die Dinger laufen mit der Keil Startup völlig reibungslos. Im C-Code nach main() initialisiert man denn das was man für seine Anwendung noch braucht, z.B. I/O-Ports, die Peripherals und Exception Behandlung Funktionen (ganz normale Funktionen, nicht als IRQ o.ä. deklariert). Für die Exceptions Undef, DAbt, PAbt, habe ich einen Sprung von den Vektoren in der Startup.s zu einer C-Funktion installiert und die entsprechende Endlosschleife gelöscht. Die Exceptions behandele ich zunächst noch als schnell initialisierten Watchdog-Reset mit zwei falschen Feed-Befehlen, da ich mit den Exceptions zur Zeit noch nichts konkretes anzufangen weiß. Später in der richtigen Anwendung, sollte natürlich niemals mehr eine Exception auftreten. Mit dem ARM Assembler wird man früher oder später etwas vertraut, spätestens dann, wenn man mal 2 separate unabhängige Programme im ARM installieren muß und die Interruptvektoren an das aktive Programm umleiten muß. Gruß Dietmar
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.