mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LPC2000 verwenden JA/NEIN ?


Autor: mathias giacomuzzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: dose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn es um die Geschwindigkeit geht dann nehme einen ARM 9 der LPC2148
ist "nur" ein ARM7.

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
- 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

Autor: Mathias G. (mgiaco)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Mathias G. (mgiaco)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
VPB-Teiler eingestellt? Die Peripherie taktet nach Reset erst einmal mit
1/4 des Prozessortaktes.

Autor: mathias giacomuzzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: mathias giacomuzzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@ 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

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: LPC user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da "der Rowley Compiler" ein gccarm ist, halte ich das für eher
unwahrscheinlich.

Möglicherweise linkst Du mit den falschen (nicht-float-)Libraries.

Autor: LPC user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: LPC user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich nehme alles mit dem schieben zurück. Das Problem damit sitzt vor dem
Computer

Autor: mathias giacomuzzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: mathias giacomuzzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas:

Habe kürzlich auch festgestellt, daß der Keil Simulator die
Einstellungen des MAM ignoriert.

Also, keine Laufzeitmessungen im Simulator :-(

Gruß

Dietmar

Autor: faleio (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.