Hallo, Ich wollte eigentlich einen LPC2138 für meine Diplomarbeit verwenden. Als Compiler eventuell den Keil ARM. Aber so wie es aussieht hat der einige Bugs. Und man liest hier ja nichts gutes, ich bin deshalb nicht mehr ganz sicher ob ich jetzt den verwenden soll? Auch stellt sich die Frage ob dieser schnell genug ist. Denn ich muss einen digitalen Regler (eventuell Zustandsregler mit Beobachter) realisieren, deshalb auch der Keil Compiler. Weil laut Keil braucht der GNU V3.31 für float dividieren ==> ca. 9 µSecs, bei 60MHz und der Keil BETA nur 3.11 µSecs. Wenn man diese Operationen viel braucht ist das ein grosser unterschied. Stimmen solche angaben? Der LPC hat ja eben auch keine FPU, deshalb sollte der Compiler schon schnellen Code erzeugen. Gibt es was besseres? Mein Betreuer hat mir eine mpc555 empfohlen, dieser zu lernen ist aber noch um einiges Schwieriger als der LPC denke ich. Wäre aber sicherlich einiges schneller. mfg mathias
Hallo Mathias, ich spiel hier auch gerade mit LPC2148 und Keil rum und bin eigentlich recht zufrieden, bis auf eine Diskrepanz zwischen Simulator und Hardware an einer Stelle. Könnte sein, daß die neu Version des Compilers das Problem löst. Ansonsten entwickle ich auch Vielkanalregelsystem bis in den Bereich von einigen zig kHz und hab bisher noch nie ne Division innerhalb des Reglers gebraucht . Der LPC hat nen MAC drinne der gut funktioniert. Zhomas
- Wenn LPC2000, dann statt LPC213x nach Moeglichkeit einen LPC214x nehmen, dieser ist bis auf die USB-Pins Hardware- und weitestgehend Software(bis auf USB)-kompatibel und viele "LPC2000-Erratas" sind bei den LPC214x behoben. Man kann mit dem LPC213x "Prototypen" und Pins freilassen, die beim 214x fuer USB bestimmt sind. - Die neuen kleinen LPC2000 (210x, x<4) koennen mit bis zu 70MHz betrieben werden. Bieten aber relativ wenig Speicher und integrierte Komponenten (w.r.e auch keinen AD-Wandler). - Bei eine Regler spielt moeglicherweise auch die Geschwindigkeit des internen AD-Wandlers eine Rolle - so dieser verwendet werden soll. Datenblaetter der Alternativen diesbezueglich vergleichen und evtl. Tests durchfuehren. "Allgemeinplatz": Auch der schnellste Core (sei es ARM7, ARM9 oder was auch immer) hilft nichts, wenn die Peripherie nicht "nachkommt". - Die Benchmarkergebnisse fuer GCC von der Keil-Seite sind - na ja - sagen wir: nicht wirklich nachvollziehbar. Es gibt mindestens zwei weitere Web-Seiten mit Vergleichen GNU<->"Kommerziell", die den GNU-Compiler lange nicht so schlecht aussehen lassen (teilweise sogar besser). Archiv der lpc2000 yahoo-Gruppe "abklappern", dort finden sich die Links. Ein Vergleich ist soweit erinnert relativ neutral, der andere von einen Hersteller, der GCC als Compiler "hinter" seiner IDE nutzt, also somit auch "biased". Die Compiler werden von allen Herstellern stetig weiterentwickelt. Abgesehen davon, dass Benchmarks und "MIPS" ohnehin wenig "Naehrwert" haben, veralten die Ergebnisse daher recht schnell (der Vergleich bei Keil ist auch jeden Fall nicht mehr Stand der Dinge). Keil's uVision ist dennoch eine brauchbare Entwicklungsumgebung und der Simulator fuer erste Schritte und Tests recht nuetzlich. Der Keil-eigene Compiler ist uebrigens inzwischen "abgekuendigt" (vgl. keil.com). Keil gehoert nun zu ARM.com und bei neuen uVision-Paketen wird auch der Compiler von ARM selbst mitgeliefert. - Noch ein "Allgemeinplatz": man kann "geschickt" oder "ungeschickt" programmieren und damit sehr stark das Laufzeitverhalten beeinflussen. Beim ARM kann man z.B. Routinen im internen RAM ausfuehren und damit einiges beschleunigen (LPC MAM? - der Flash-Cache ist endlich). Martin Thomas
@ Thomas Danke, ja der beim Regler muss man viel multiplizieren mit float. Das mit dividieren war nur ein Beispiel. MAC ist das eine Hardware multiplizierer? @ Dose Danke. Aber ich denke die sind eine Nummer zu Komplex und zu Schwierig für mich. @ mthomas Danke für den langen Beitrag. Du schreibst wenn LPC dann ... Hört sich so an als wäre es nicht das richtige oder? Ach ja kann mir vielleicht noch jemand sagen was das mit dem Keil aufsich hat. Welches ist der Compiler von ARM selbst ? Ist das der RVDK. Zu den Compilern noch ein paar Fragen. Keil wäre nur darum interessant, weil ich eine zeitbegrenzte Version für wenig Geld bekommen würde. Bei IAR bekommt man das nicht. Es gibt ja nur die IAR-Kickstart 32kB Version ist also was für Studenten :-), wäre das eine gute IDE zum einstieg, und ist da auch sonst nichts eingeschränkt? Problem was tun wenns mit den 32kB knapp wird. Oder WinARM verwenden? Besten Dank mfg mathias g.
Hallo ich habe jetzt das mit den Benchmarks gelesen, der GNU schneidet da ja super ab, dass heisst WinARM wäre doch eine gute Lösung oder? mfg mathias
Solltest Du Student sein, kannst Du versuchen, an eine "educational
license" von Rowley Crossworks zu kommen. Die kostet 100 UKP (150 EUR)
und ist nicht codegrößenbeschränkt.
Crossworks kommt hervorragend mit Parallelport-JTAG-Adaptern
("Wiggler") klar und kann darüber auch ohne Klimmzüge das Flash-Rom
programmieren.
Als Compiler wird gcc 3.4.4 verwendet; das ganze ist in eine recht
praktische IDE mit Projektverwaltung und Debugger verpackt.
http://www.rowley.co.uk/arm/index.htm
In deinem Fall wird weniger der Compiler selbst sondern eher die Floating Point-Bibliothek ausschlaggebend sein; die vom GCC soll nicht sehr berühmt sein, deshalb packen Hersteller wie Rowley meist ihre eigene dazu. Zahlen kann ich aber nicht nennen, habe leider auch noch keine Benchmarks gefunden, du musst wohl einfach ausprobieren welche Geschwindigkeit du erreichen kannst.
Nur ein kurzer Kommentar zu Libraries GCC und ARM compiler. Wir haben bei Tests mit Floating Point tatsaechlich mehrfache Performance gesehen vom ARM compiler gegenueber dem GCC. Die Libraries sind immer noch die Schwachstellen der GCC Implementierung. Rowley benuetzt zwar GCc hat aber eigene Libraries, IAR hat sowieso einen anderen Compiler mit eigenen Libraries und Keil ist inzwischen ARM Real-View basierend. Soweit ich weiss unterstuetzen sowohl die Keil als auch die IAR Evaluierungsversionen der Compiler auch Floating Point, also einfach mal ein paar kleine Tests selbst machen. Wie Rufus schon erwaehnt hat, die andere grosse Schwachstelle der GCC Umgebung ist die Debugger Anbindung, hervorragend geloest bei Rowley, natuerlich auch voll integriert in Keil unf IAR. Solltest Du auch GDB gehen, kanns etwas schwierig werden beim Debuggen und Flashen. Ich will damit keinen Krieg starten, der GCC erzeugt im allgemeinen sehr brauchbaren Code und ich bin heilfroh, dass der Compiler in dieser Qualitaet existiert und anwendbar ist. Gruss, Robert
Servus zusammen, die Evaluierungsversion des Keils funktioniert recht ordentlich. Ich verwende noch die "alte V2.5x". Inzwischen ist eine neue raus. Ich hab zwar auch eine Vollversion gekauft, aber im Moment reicht die Eval-Version noch völlig aus sogar um "echte Anwendungen" zu übersetzen. Ich hab dabei z.B. einen Interrupt mit 50kHz laufen, der auch noch wirklich was ordentliches tut. Danach bleiben immer noch ca. 75% der Prozessorleistung übrig. Was braucht der Mensch mehr ??? Dabei verwende ich so ziemlich alles : Float, printf etc. und es gibt bisher recht wenige Probleme, bis auf die Geschichte mit der 2. SPI (SSP), die mit folgendem Code angesteuert wird: LDR R0,=data_p ; R0 = &data_p LDR R1,[R0] ; R0 = *R0 LDR R0,=0xE0068008 ; SSPDR LDRH R3,[R1],#2 STRH R3,[R0] LDRH R3,[R1],#2 STRH R3,[R0] LDRH R3,[R1],#2 STRH R3,[R0] die Simulation und die Realität klaffen bei der Laufzeitbetrachtung auseinander. (ca. um Faktor 4) Vielleicht hat ja jemand ne Idee was ich dabei verkehrt mache. Braucht evtl. der SSP Zugriff länger als 1 Takt ? die besten Grüße Thomas
VPB-Teiler eingestellt? Die Peripherie taktet nach Reset erst einmal mit 1/4 des Prozessortaktes.
@ Robert könntes du mir mal bitte ein mail schreiben ich möchte da mal noch was fragen, was ich aber nich hier machen möchte. email: mgiacomuzzi(at)ntb.ch Besten Dank an alle, Prozessor ==> versuche es jetzt also mit dem LPC2148 Compiler ==> Crossworks oder IAR oder Keil werde mal schauen was mir besser gefählt. WinARM nehme ich nicht weil ich brauche eine gute Floatingpoint Lib. Ich mal beim progen werden noch einigen Fragen auftauchen. mfg mathias g.
Ach etwas noch Crossworks funktioniert mit Parallelport-JTAG-Adaptern und kann auch das Flash progen. Wie siehts mit IAR und Keil aus ich denke mal die können das auch oder? mfg mathias g.
Hallo A.K., danke für die Info. Das Problem ist, daß der Keil Simulator bei anderen Programmteilen richtig rechnet (Ausführungszeit).... Wobei das evtl. schon der Fehler sein könnte, wenn Keil das VPB Timimg nicht berücksichtigt..... Ich probiers mal aus.. Nochmal vielen Dank und noch viel Spaß Thomas
Das könnte es gewesen sein. Ist zumindest jetzt ne Ecke schneller mit VPBCLOCK = 1/2 CPUCLOCK. Vielen Dank für die Hilfe und noch ein schönes Wochenende. Thomas
>@ mthomas Danke für den langen Beitrag. Du schreibst wenn LPC dann >... Hört sich so an als wäre es nicht das richtige oder? Das will ich damit nicht zum Ausdruck bringen. Kommt halt auf die Anwendung an. War als "falls die Entscheidung auf LPC2k faellt" gemeint. (Rand-)Bemerkungen: - floating-point-routine auf jeden Fall auch selbst mal "benchmarken" (double und single/float). Fuer schnelle Routinen auch fixed-point in Betracht ziehen. nur noch indirekt von Interesse, da nur noch IAR, Keil, Rowley "im Rennen": - openocd funktioniert besser als Macraigors ocdremote, enthaelt einen gdb-server fuer (Insight)-gdb und bietet auch die Moeglichkeit, den internen Flash von LPC2k (in aktueller Version auch AT91SAM7S, STR7) zu programmieren. Dokumentation ist noch recht spaerlich, aber es gibt stetig mehr Information dazu. Da Eclipse gdb-Server ansprechen kann, gibt es eine recht ordentliche freie IDE (vgl. Tutorial von Lynch) - WinARM enthaelt die newlib als "libc". Keil bietet ebenfalls gcc-Support (keine Beschraenkung fuer Compiler, weiterhin aber fuer Simulator/Debugger), allerdings ist das von Keil bereitgestellte gcc-Packet relativ alt. Weiterer Unterschied: das Keil gcc-Packet nutzt uclibc nicht newlib wie gnuarm, devkitpro, codesourcery, WinARM etc. >Ach etwas noch Crossworks funktioniert mit Parallelport-JTAG-Adaptern >und kann auch das Flash progen. Wie siehts mit IAR und Keil aus ich >denke mal die können das auch oder? Keil: nach H-JTAG googeln (RDI-Server fuer Wiggler und -Nachbauten) IAR: nutzt die mitgelieferten Macraigor-Treiber, sollte ueber RDI aber auch mit H-JTAG zurecht kommen. H-JTAG funktioniert mglw. besser mit Nachbauten (H-JTAG noch nicht selbst getestet) Martin Thomas
@Thomas, es gibt 2 Parameter, die fuer die Geschwindigkeit der LPC2000 massgeblich sind: 1. MAMTIM, das reguliert den ZUgriff auf das FLash und es gelten folgende Werte MAMTIM = 3 fuer > 40 MHz, MAMTIM = 2 fuer Frequenzen ueber 20 MHz bis 40 MHz und MAMTIM = 1 fuer bis zu 20 MHz. ZU BEACHTEN, nach Reset ist MAMTIM = 7 und laesst den LPC2000 kriechen wie eine Schnecke. 2. VPBDIV, im Kapitel "System Control Block" . Nach Reset ist der WErt in den zwei Bits von VPBDIV = 00B. Fuer Max. Geschwindigkeit der Peripherals auf 01B setzen oder fuer Peripheral Clock = CPU/2 bitte VPBDIV = 11B setzen. Diese zwei Register zusammen koennen einen Performance Faktor > 3 ausmachen. Gruss, Robert
also ich habe festgestellt das der Rowlley Compiler bei einfachen Rechnungen mit float aussteigt. wenn man dividieren will macht er das nicht, gibt aber auch keinen Fehler aus. auch treten Fehler beim bitweisen schieben auf
Da "der Rowley Compiler" ein gccarm ist, halte ich das für eher unwahrscheinlich. Möglicherweise linkst Du mit den falschen (nicht-float-)Libraries.
unter Propertie ->Project options habe ich Primtf floatin gPoint supported = yes damit sollte er damit umgehen können. hab das Problem jetzt aber einfach umgangen. nur das mit dem schieben ist noch merkwürdig wenn d[0] = 0x88 =0b1000 1000 a=d[0] c= 0x40; =0b0100 0000 b= a & c =0b0000 0000 (b=0x00 0b0000 0000) b=b>>6 sollte b=0x00 ergaben ergibt aber 0x01
ich nehme alles mit dem schieben zurück. Das Problem damit sitzt vor dem Computer
@mthomas Danke also mit H-JTag treiber sollte man mit Keil und parallel J-Tag arbeiten können. Macht das jemand ? Gehts wirklich? Ist sehr wichtig zu wissen. Besten Dank mgiaco.
@ LPC user Habe ich damal ganz vergessen zu Fragen. Das mit dem Rechnen mit Rowley. Stimmt das? Kann das noch jemand bestätigen das es problem im floating point gibt. mfg mathias
@Thomas: Habe kürzlich auch festgestellt, daß der Keil Simulator die Einstellungen des MAM ignoriert. Also, keine Laufzeitmessungen im Simulator :-( Gruß Dietmar
@ mathias giacomuzzi hatte bis jetzt leider keinen erfolg, keil scheint extrem auf usb zu stehen.... uLink ist kein problem und jLink sollte kein problem sein... grüessli
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.