Hallo, ich Programmiere normalerweise mit 8Bit AVRs oder Mototola HC08, jetzt habe ich weil ich für ein Projekt mehr leistung brauche mal ein Demoboard mit einem LPC21xx bestellt. Jetzt suche ich halt noch einen C compiler der mir das leben nicht ganz so schwer macht. Es gibt ja das WinARM Packet und das GNUArm Packet, was sind da die unterschiede, welchen sollte man vorzugsweise benutzen ohne das man 1/2 Jahr später bei einem neuen Release seinen Code Verändern muss. Bei so einem Comtroller würde ich auch gerne in C++ programmieren, da kann man sich viel verwaltungsaufwand sparen. Der ARM sollte ja eine ähnliche Architektur wie der HC08 haben, also einen Linearen Adressraum wo man mit dem Gleichen Pointer im Ram und im Flash lesen/schreiben kann. Nur wie mache ich das wenn ich beim LPC von einer ungeraden adresse lesen/schreiben muss? beim HC08 kann ich überall im 16bit adressraum lesen und schreiben ohne das es probleme gibt. Wie funktioniert die Interruptverarbeung bei den GCC ARM compilern? Das wird ja bei jedem Controller anders gehandelt. Sebastian
"Das wird ja bei jedem Controller anders gehandelt." Genau das ist das hüpfende Komma !!! z.B. der ARM7 von Philips hat nur 2 Interruptprioritäten. Der ARM7 von ST hat 17 Prioritäten, dafür muß man aber auch erstmal 37 Seiten im Reference-Manual durchackern ! Den ganzen Interruptmist muß man also wohl oder übel selber machen. Ich glaube kaum, daß es einen Interrupt-Wizard gibt, der einem die Arbeit abnimmt. Der Philips hat 32Bit-Timer (keine Counter !), der ST 16Bit-Timer/Counter Auch ADC, CAN, UART usw. sind völlig unterschiedlich ! Kurz und gut, ARM7 sind untereinander so völlig unterschiedlich, wie ich es noch bei keinem andern µC erlebt habe. Die Philips ARM habe ich mit der kostenlosen Keil µVision programmiert, ging auf Anhieb. Das GCC-Geraffel, wie es im Wiki steht, ging garnicht, nach etwa 2 Tagen vergeblichen Installationsversuchen habe ich aufgegeben. Das Philips-CAN ist, gelinde gesagt, sehr gewöhnungsbedürftig, seine SJA1000- oder AT89C51CC01-Erfahrungen kann man getrost über Bord schmeißen. Peter
@Peter hast du den GCC compiler mit der µVision IDE verwendet, oder die µVision mit dem Keil C compiler der ja lt. Keil Page auf 16K objekt code begrenzt ist. http://www.keil.com/demo/eval/arm.htm Sebastian
Wenn ich das richtig gelesen habe, ist nur der Debugger auf 16k begrenzt. Das Umschalten geht in den Einstellungen, dann kriegst Du erstmal tonneweise Fehlermeldungen. Ist aber kein Problem, Du must nur den passenden Startup-Code in Dein Projekt kopieren (die Assembler haben eine unterschiedliche Syntax). Peter
Keil Website unter Limiations: The CARM compiler, assembler, and linker are limited to 16K Bytes of object code. Source code may be of any size. das heisst für mich, das der Compiler in der summe nur object files erzeugt die 16K nicht überschreiten. Und in den Object files steht je für gewöhnlich der Asm Code drin. Ich habe mit jetzt mal die demo von Keil und Iar und GCC-ARM gezogen, mal schauen ob der IAR wiklich so viel besser ist wie auf der IAR.com seite in dem tollen diagramm dargestellt. http://www.iar.com/FilesPublic/EW/002288/Benchmark-EWARM-420.pdf da macht ja der GCC über 200% mehr code als der IAR, und das heisst schon was. Aber das werde ich nach dem selber testen ja sehen ob sich das wirklich so stark auswirkt. Be IAR gibt es übrigends ne 32K demo für den ARM7. Sebastian
> Nur wie mache ich das wenn ich beim LPC von > einer ungeraden adresse lesen/schreiben muss? Sinnvollerweise garnicht. Wenn Du es nicht grad explizit darauf anlegst, dann wird das nicht passieren. Der Compiler legt die Variablen so an, dass dies nicht notwendig ist.
>Es gibt ja das WinARM Packet und das GNUArm Packet, was sind da die >unterschiede, welchen sollte man vorzugsweise benutzen ohne das >man 1/2 Jahr später bei einem neuen Release seinen Code Verändern >muss. Es gibt noch ein paar mehr Packete (z.B. tantos, codesourcery). WinARM hatte ich seinerzeit erst nur fuer den Eigenbedarf zusammengebastelt, um eine zu WinAVR vergleichbares Packet fuer ein LPC2106-Demoboard zu haben. Ein paar Unterschiede (bin bei GNUARM mglw. nicht auf neuestem Stand): - GNUARM wird fuer Unix/Linux- und MS-Windows-"Hosts" bereitgestellt WinARM nur fuer MS-Windows - GNUARM braucht die Cygwin-DLLs, WinARM nicht - GNUARM unterstuetzt in der aktuellen Version mehr Sprachen, WinARM nur C und C++ - GNUARM enthaelt den akutellen insight-gdb, WinARM eine alte Version, die allerdings keine cygwin-DLLs braucht. - die newlib ("glibc fuer embedded") ist bei WinARM so compiliert, dass "reentrant"-Syscalls genutzt werden, bei GNUARM soweit ist weiss fuer "nicht-reentrant"-Syscalls. Grund war urspuenglich, dass die newlib-lpc "reentrant"-Syscalls bereitstellt. - WinARM enhaelt die benoetigten Tools (make, sh) zum "Direktstart" - vergleichbar WinAVR. GNUARM wurde wohl fuer den Betrieb unter cygwin entwickelt, cygwin enhaelt diese Tools schon. - Programmer-Notepad als IDE/Editor bei WinARM enthalten - wieder vergleichbar WinAVR. - die newlib-lpc wird bei WinARM fertig compiliert mitgeliefert. Das sind die von newlib benoetigten Syscalls (fuer malloc etc.) fuer Philips LPCs und etwas "Zubehoer" (relativ leicht an andere ARMs anpassbar). Kein "Geraffel" mehr notwendig. - in WinARM habe ich einige meiner Beispiele dazugepackt (oft nur angepasste Versionen von Beispielen aus dem Netz) - als "Eisbrecher" (makefiles, linker-skripts, startup-code). Im Moment alles LPC2106 und LPC2129-lastig, andere Controller habe ich bisher nicht zum Testen. Die ungetesteten Beispiele fuer ST und AT91SAM7 wollte ich nicht beilegen. Die meisten Beispiele liegen aber auch einzeln auf der "WinARM-Seite". - GNUARM kommt mit einem Installationsprogramm, WinARM nicht. Man muss zur WinARM-"Installation" allerdings nur den Systemsuchpfad erweitern. - WinARM kommt mit Maurers lpc21isp fuer LPC-Flashprogrammierung ueber UART und dem Bray-Terminal. Kann man beides bei Nutzung von GNUARM aber auch selbst leicht nachinstallieren Auch wenn die Auflistung der Unterschiede etwas lang ist, tatsaechlich "merkt" man davon wahrscheinlich beim eigentlichen Entwickeln nur noch wenig. >Bei so einem Comtroller würde ich auch gerne in C++ programmieren, Zumindest mit WinARM hab' ich damit rumgespielt - funktioniert. Leider werden die Binaerdateien bei Nutzung der stdlibc++ (new, delete etc.) recht gross, dazu bisher noch keine Abhilfe gefunden. arm-elf-g++-Beispiele zur "Inspiration" sind auch duenn gesaeht. >Der ARM sollte ja eine ähnliche Architektur wie der HC08 haben, also >einen Linearen Adressraum wo man mit dem Gleichen Pointer im Ram und >im Flash lesen/schreiben kann. Nur wie mache ich das wenn ich beim >LPC von einer ungeraden adresse lesen/schreiben muss? Ja Adressraum ist "linear". Aber Flash-schreiben ist nicht so einfach moeglich und sehr vom Hersteller/Controller abhaengig. Was "ungerade Adressen" betrifft, habe ich zumindest bei den LPCs nicht besonderes bemerkt - einfach Pointer dereferenzieren hat bisher funktioniert. >Wie funktioniert die Interruptverarbeung bei den GCC ARM compilern? >Das wird ja bei jedem Controller anders gehandelt. Jein. Peter Dannegger hat dazu ja schon einiges geschrieben. FIC und SWI scheinen bei ST/AT91/LPC identisch zu funktionieren. IRQ/Vectored-Interrupt wohl nach Peters Erläuterungen nicht. Es gibt auch Texte/Beispiele zu "Nested Interrupts" - aber bisher nie ausprobiert. Alte arm-elf-gcc-Versionen hatten Fehler bei der Generierung von Interrupt-Code (Fkt. mit Attribute "IRQ"/interrupt), das scheint in den aktuelleren Versionen (>=3.4.2) behoben (vgl. gcc-Bugtracker). Einige Entwickler haben sich damit beholfen, die ISRs mit Attribut "nacked" zu versehen und die notwendigen "ISR-Befehle" mittels (inline-)Assembler einzubinden (vgl. FreeRTOS), sollte aber inzwischen nicht mehr notwendig sein. Der Unterschied zum Keil-Compiler scheint, was die Deklaration von ISRs betrifft nur Syntax. Allerdings kann man beim Keil-Compiler (nicht dem gcc von Keil) wohl ARM und Thumb-Code ("Interwork") in einer Quellcodedatei mischen, das ist beim gcc soweit ich weiss nicht moeglich. ISRs sind beim gcc im ARM-Mode zu kompilieren und damit gegebenenfalls in einer "extra Datei". Soweit fuer's Erste - hoffe, es bleibt nicht allzuviel offen. Martin Thomas
Habe jetzt mal das WinArm Paket ausprobiert (gcc 4.0.0) mit dem LPC2106 bzw. LPC2138. Hab jetzt ein Problem mit dem ARM-Thumb-Interwork, welches mit dem GCC 3.3.4 nicht vorhanden war. Sobald ich aus einer ISR eine Funktion aus einem Modul, das im Thumb-Mode kompiliert ist aufrufe, schmiert das ganze System ab. Der Rücksprung aus der ISR geht dann meist schief. Komischerweise passiert das nur, sobald eine Optimierungsstufe aktiv ist, also bei -O0 funzt es. Und auch ohne -thumb-interwork geht es. Weist Du was von diesem Problem, oder stell ich mich so blöd an?
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.