mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Erfahrungsaustausch LPC21xx ARM Controller


Autor: Axel Stab (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe uC-Gemeinde,

ich suche noch Leute, die sich auch mit den ARM7 Controllern von
Philips beschäftigen. Das ist eine sehr interessante Familie, denn
damit ist der ARM (nach AT91 von Atmel) nun endlich aus dem
Handy/Consumerbereich (verbreitetster Prozessor der Welt!) nun endlich
auch zu uns in die Industriewelt (general purpose)  herabgestiegen.
Preislich etwa wie der Mega128 gelegen ist das ein richtiger 32Bit
Rechner. Interessant für alle, die keine Lust mehr auf Speicher- oder
Performance-Knauserei haben.

Für Bastler gibt's auch den GNU-Compiler für lau, ab Oktober soll eine
Lowcost-IDE von Imagecraft kommen. Ich verwende momentan uVision3 mit
ULINK JTAG-Debugger von Keil. Das ist auch der GNU drunter, ist aber
erstmal bequemer und gut bezahlbar (300€).

Ich stecke noch relativ am Anfang eines größeren Projektes, aber es
läuft schon einiges. Es geht u.a. um Kommandointerpreter und
PWM-Steuerungen. Auch TCP/IP wäre interessant. Da Appnotes usw. noch
recht dünn gesäht sind, möchte ich mich im beidseitigen Interesse ganz
gern Austauschen, wenn mal wieder irgendwo "ein Bit (bzw. eine
Synapse) klemmt".

Viele Grüße

Axel

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mich interessiert auch die CPU. Aber ich kann die Performance der
CPU/Minimum Instruction Cycle schwer einschätzen. So wie ich es sehe
ist es ein gebondeter Controller (Also eigentlich ein ASIC) der schon
Performance durch den Zugriff aufs interne RAM/FLASH verliert.
Also gar nicht mit der maximalen Frequenz von 60MHz arbeitet.
Des weiteren sagte man mir der erzeugte Code sei sehr grossgegenüber
anderen MCUs (z.B. C167 oder M16C) - Kann mir hierzu jemand was sagen
??? Wer arbeitet mit dieser MCU ???

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich probiere auch grad damit herum.

Das mit dem GNU-ARM wie im Wiki beschrieben, kann man vergessen, wenn
man kein UNIX/Linux Experte ist. Allenfalls weiß ich jetzt, wie man
.tar.gz auspacken kann (die Reihenfolge der Schalterzeichen muß
eingehalten werden!), aber sonst läuft absolut nix.


Ich habe mir daher die Keil Testversion runtergeladen, da ist alles
easy in einem Rutsch installiert und läuft super.

Mit Speicher knausern mußte ich noch nie (außer beim AT90S2313).

Aber ich habe jetzt eine Anwendung, wo ich viele Berechnungen spürbar
schneller als auf dem 8051 benötige. Da kommt eigentlich nur der
LPC2106 in Frage.


Im Thumb-Mode erzeugt der Keil 16Bit-Code und das ist garnicht so
groß.
Außerdem kann er clever adressieren, das Argument steht nicht im
Befehl, sondern nur der Offset zum Wert.
Benötigt man also den gleichen Wert mehrmals im Programm, muß dieser
nur einmal angelegt werden und alle Befehle damit zeigen dann auf diese
Stelle. Ist also effizienter als wenn der Wert jedem Befehl direkt
folgen muß.
Ich habs gerade mal ausprobiert, ich habe an 2 Stellen den Wert
0x77777777L verwendet und im Hex-File steht er nur einmal drin. Also
clever mal eben 4 Bytes Flash gespart und keinen "großen Code"
erzeugt.


Das er nicht mit 60MHz arbeiten kann, ist mir neu.
Nur bei einem Interrupt muß er 4 Zyklen warten, da ja dann die Pipeline
ungültig ist.
Soll aber mit einem Trick zu umgehen sein, indem man den
Interrupthandler im SRAM ausführt (geht, da Von Neumann).


Daß da drin mehrere Chips gebondet sind, glaube ich nicht, bei dem
kleinen Gehäuse und dem Preis.


Peter

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

der LPC21xx kann idealerweise mit 60MIPS laufen. Das Lesen aus dem
Flash dauert insgesamt 4 Takte. Da der Flashspeicher aber 128 Bit breit
angebunden ist liefert die Leseeinheit einen Befahl je Takt. Das
allerdings nur wenn keine Sprünge usw. vorkommen. Zusätzlich kommt dann
noch die 3-stufige Pipeline des ARM7-Kern's dazu.

Mit ungeschickter Programmierung kann man den Controller aber bestimmt
unter 10MIPS drücken.

Eine Interrupt-Verzögerung von 3 Takten hat man immer da die Pipeline
neu gefüllt werden muß. Die 4 Takte vom Flash lesen kann man, wie Peter
geschrieben hat, durch verlagern der ISR in den SRAM vermeiden.

Matthias

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mich auch mal am "GNU-Gebastel" versucht und ein "kleines"
Package zusammengestellt, das hoffentlich alle nuetzlichen Tools bis
auf den Debugger enthaelt. Das Package benoetigt kein cygwin hat aber
noch keinen Installer. Ob der Thumb-Mode funktioniert weiss ich nicht,
aber "ARM7-normal" uebersetzt der enthaltene GCC C-Compiler 3.4.0
problemlos (der neuere GCC C-Compiler 3.4.1 hat wohl Probleme mit dem
Thumb-mode)
Ein paar kleine Beispiele fuer LPC2106 liegen bei, die auf dem Olimex
LPC2106-Prototyp-board getestet wurden. Bei weiterem Interesse:
http://www.siwawi.arubi.uni-kl.de/avr_projects/#winarm
Feedback willkommen. Das Projekt ist etwas eingeschlafen, weil mir im
Moment keine gute Anwendung fuer den ARM einfaellt, die nicht auch ein
AVR uebernehmen kann. Die Teile sind auch nicht grade fuer
"Amateurlöter" geeignet.

Wer unbedingt auf schnellen Programmzugriff wert legt, hat die
Moeglichkeit, den Flash-Inhalt beim Startup ins RAM zu kopieren,
zumindest so gelesen, nie ausprobiert.

Martin

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Das Projekt ist etwas eingeschlafen, weil mir im Moment keine gute
Anwendung fuer den ARM einfaellt, die nicht auch ein AVR uebernehmen
kann."

Das möchte ich gerne aufgreifen: hat schon jemand ein konkretes Projekt
für den Prozessor geplant oder realisiert ?
@Axel: was hast Du mit dem Teil vor ?

Mein Interesse für den Prozessor wird durch die kleine Gehäuseform (48
oder 64 Pins) gebremst. Wenn man eine Anwendung hat, die mit den
wenigen Beinchen auskommt, ist es ein schönes, schnelles Teil. Aber
Trauer hat man meines Erachtens, wenn man ext. Daten schnell einlesen,
verarbeiten und ausgeben muß oder die IO-Funktionen nicht ausreichen.
Paralleles IO/Datenbus ist ja nicht (hinreichend) verfügbar.
Die Taktfrequenz als einziges Kriterium hilft nicht viel. Andere µPs
(H8S, M32C, XC167,..) laufen auch mit 33 - 40 MHz und haben mehr
Funktionalität.
Sich mit dem ARM-Kern zu beschäftigen, ist aber sicherlich eine
sinnvolle Sache.

Gruß Michael

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"... und haben mehr Funktionalität."

Also für mich hat der schon viel zu viel Funktionalität, ich bin noch
lange nicht durch alles durchgestiegen.

Schade, daß es kein komplettes LPC2106 Datenbuch gibt, ich habe
inzwischen schon einen riesen Wust an Ausdrucken rumliegen (user
manual, technical reference manual, vectored interrupt controller
...).

Meine Aufgabe ist es, 2 analoge Signale zu generieren, dazu will ich 2
12Bit DAC anschließen, also 12 Bit Daten + 2 Strobe, gesteuert wird das
Ganze über I2C, macht also zusammen 16 Leitungen, d.h. 16 sind immer
noch frei.


Ich hab mal nen Timerinterrupt aufgesetzt, der nur einen Wert
hochzählt. Bis 60 Zyklen läuft er, ab 50 Zyklen verliert er
Interrupts.
Ich weiß jetzt nicht, wo die >50 Zyklen verloren gehen, finde das aber
etwas sehr viel.

D.h. 1µs Timerinterrupt ist gerade so möglich, also schätze ich 2µs in
meiner Anwendung. Ist dann immerhin noch 15* schneller als die alte
8051 Lösung (30µs).

Der Hauptvorteil ist natürlich, daß ich keinen externen SRAM, Latch,
Flash, Adreßdecoder mehr brauche, nur noch die 2 DACs.

Muß jetzt erstmal nen DAC raussuchen, der die 2µs Settling Time auch
schafft, die alten hatten nur 25µs.



Peter

Autor: Axel Stab (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

ich habe meine PWM-Drehfelderzeugung im Testbetrieb, die Keil-Tools
sind brauchbar. Habe mehrere Sachen konkret vor, u.a. eine USB auf CAN
Brücke, leicht zugeschnitten auf Trinamic-Motorsteuerungen, mit dessen
Vetrieb und Kundenanpassung ich ja größtenteils meine Brötchen
verdiene. Klar, keine Paradeanwendung, weil man z.B. noch den FT232BM
extern braucht. Aber das ist ja auch nur ein Anfang. Übrigens ist von
ST ein kleiner ARM auch mit USB (und auch Ethernet-MAC) angekündigt.

Auch mich befällt gelegentlich die Ingenieurskrankheit, und so sieht
dann auch ein erstes Design aus, siehe www.embeddedgateway.com:
Schnelles CPU-Board mit 2xCAN, 2xUART, RS-485, 2xSPI, 6PWMs, I2C
undundund...keine Lust zum Bestücken der 27 Jumper. Hab's gerade
eingesehen und eine wirklich smarte Platine gemacht, passt auch in ein
kleines Gehäuse. Raus gucken nur USB und ein Sub-D Stecker, der
CAN/RS-485 plus noch ein paar I/Os bzw. SPI rausführt. JTAG über
Lötpads. Huckepack kann eine Platine mit zwei Schrittmotortreibern auf
gesteckt werden. Dafür gibt's auch konkret nachgefragte
Kundenprojekte. Neben der CAN-Brücke für das TMCL-Protokoll (s.
axelstab.de/download) gibts ein kleines Projekt zur präzisen Messung
von Drehzahl und Beschleunigung mittels Reflexlichtschranke.
Schulmässige Angelegenheit zum Testen des Input captures. Eine Anfrage
zur CAN-Brücke mit zirkularer Interpolation gibt's auch
(schnell&Fließkomma mit viel sin/cos, stressig auf AVR).

Dann zwei Motorprojekte, einmal zwei Phasen Stepperansteuerung, einmal
Dreiphasenerzeugung (soll bis zur Elecronica laufen).
Für alle Projekte will ich einen ASCII-Kommandointerpreter realisieren,
der später mal IEC1131-angelehnt sein soll. Ich will mir nicht die
10tausendste Kommandosprache ausdenken, sondern im wesentlichen mit
Zuweisungen arbeiten ("v1=1000" für "Motor 1 auf 1000 Touren").
Eine spätere Implementierung der genormten Industrie-Sprache "ST",
was praktisch ein abgespecktes Pascal ist, ist angedacht.

Desweiteren liegt schon lange eine Kundenanfrage für ein HMI mit
QWERTZ-Tastatur und LCD herum. Marktpotential ist da, bislang werden
komplette PCs als HMI für spezielle Maschinen mitverkauft! Habe auch
schon die Schaltung fertig und die Platine angefagen. Das HMI soll über
SPI mit der smarten ARM-Platine verbunden werden. Auch hier sollen
letztlich Motoren gesteuert werden, auch über CAN. Für das Projekt wird
letztlich wohl der LPC2292 mit externem Speicher erforderlich sein, ein
AT91 könnte es auch sein.

Also gibt einiges zu tun. Wenn auch kein berauschendes Budget vorhanden
ist, dann doch zumindest die Gewissheit, dass die o.g. Projekte nicht in
der Schublade landen. Ach ja, dann gibts da auch noch CANopen, aber dazu
ggf. später mehr. Der AVR direkt an einem Mikroschritttreiber pfeift
übrigens recht schnell auf dem letzten Loch, der fehlende boolsche
Prozessor bremst enorm, wenn man schenlles Bitgefummel braucht. Bei
Positionieraufgaben braucht man viel 32Bit Werte, zumindest ICC und GCC
erzeugen dabei sehr viel Code. Mal sehen wie sich der ARM da schlägt.
Fürs Bitgefummel muss zur Not ein CLPD dran.

So, genug geblubbert!

Viele Grüße aus Berlin

Axel

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"So, genug geblubbert!"

Na ist doch interessant. Motoransteuerung wäre auch meine Idee gewesen,
den 21xx einzusetzen; aber als 'slave-device' nutzt man nur einen
geringen Teil der Leistung.

Der LPC2292 ist ein guter Tipp; das Teil gefällt mir wesentlich besser
und werde ich mir mal näher ansehen. Nach einer detailierteren
Beschreibung muß man leider unnötig suchen, um sie dann im Handbuch vom
2119 zu finden. Aber die ext. Speicherschnittstelle und das 144-Pin
Gehäuse lassen die Prozessorleistung doch besser ausnutzen, z.B. um
(nebenbei) ein Grafikdisplay zügig anzusteuern.

GNU-CC wird sicherlich guten Code erzeugen und 32-Bit breite Register
haben noch nie geschadet, zumal die Operationen zumeist nicht länger
dauern als bei 8 Bit. Das Bitgefummel wird man aber vermutlich doch in
Assembler machen müssen.

Grüße zurück.

Michael

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

@peter

IIRC ist standardmäßig der schnelle (128 But breite) Zugriff auf das
interne Flash (MAM) nicht aktiviert. Daher könnten einige deiner
ermittelten 50 Zyklen kommen.

Matthias

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch einige Testergebnisse:

Die meisten Befehle dauern 2 Zyklen, einen Portpin zu setzen dauert
also 6 Zyklen(= 3 Befehle), d.h. das kann der AT89C51RD2 genauso
schnell.

Erst durch die PLL *3 ist der LPC dann etwas schneller, also so doll
ist das ja gerade nicht.

3* schneller ist er dann aber auch nur im SRAM, da ja im Flash noch die
Flashzugriffszeit dazukommt (in meinem Test war es dann effektiv 2,1*).

Laut Users Manual kann man MAMTIM auf 3 setzen (voreingestellt im Keil
war 4). Allerdings läßt sich das nicht mit dem Debugger simulieren. Der
Debugger gibt grundsätzlich alle Zeiten mit MAMTIM = 1 an, das geht aber
nur bis 20MHz, also ohne PLL.


Aber ich hoffe ja, daß er wenigstens bei den floating Point
Berechnungen ordentlich schneller ist, wegen der 32
Bit-Registerbreite.


Im Gegensatz zu anderen MCs führt er Interrupts direkt hintereinander
aus.
Also wenn die Interrupts zu heftig kommen, bleibt das Main komplett
stehen.
8051 oder AVR machen da ja wenigstens immer noch einen Befehl des Main
dazwischen.


Was ich noch nicht kapiert habe, sind die Interruptprioritäten.
Kann also wirklich, wie beim 8051 ein Interrupt höherer Priorität einen
mit niedrigerer Priorität unterbrechen.

Also kann ein non vectored IRQ durch einen vectored IRQ und ein
vectored IRQ durch einen FIQ unterbrochen werden ?

Und wenn doch nicht, wie kann man das dann in Software simulieren ?


Ich muß auf alle Fälle mit dem FIQ jeden anderen Interrupt unterbrechen
können oder ich kann das Ganze gleich in die Tonne kloppen.


Hier mal die Zahlen für meinen Testinterrupt:

Interrupteintritt:                            12 Zyklen
Interruptvector anspringen, 2 Register retten: 6 Zyklen
Timerflag zurücksetzen:                        6 Zyklen
Wert hochzählen:                               9 Zyklen
Interrupt verlassen:                          11 Zyklen
                                            = 46 Zyklen
bei MAMTIM = 1

Damit ist klar, warum bei 50 Zyklen und MAMTIM = 4 alles zu spät ist.


Ich werde mal meine Einschätzung für meine Anwendung auf 5µs minimalen
Timerinterrupt nach oben korrigieren.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S.:

Bin also ziemlich ernüchtert, hatte irgendwie wesentlich mehr
erwartet.

Vielleicht probier ich doch mal so einen 100MHz 8051-er aus der Silicon
Laboratories C8051Fxxx family aus.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich beantworte mal meine Frage selber:

Der LPC2106 hat nicht 18, nicht 16 und nicht 3 Interruptprioritäten
sondern gerademal 2, reicht also genau für meine Anwendung.

Das ergibt sich ja auch aus dem Statuswort, da gibt es nur 2 Bits
dafür.
Eins wird gesetzt beim Eintritt in einen IRQ und verbietet damit
weitere IRQs.
Und beide werden gesetzt beim Eintritt in einen FIQ und verbieten damit
weitere FIQs und IRQs.

Das User Manual ist da also etwas irre führend.


Bei komplexen Anwendungen können 2 Interruptprioritäten aber schnell
mal zu knapp werden. Deshalb haben ja die neueren 8051-er fast
ausnahmslos 4 Interruptprioritäten. Und ich habe auch schon einmal 3
davon benutzen müssen.


Peter

Autor: olegk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,
wie wäre es denn mit dem VIC ?
Hast Du schon mal in 's Datenblatt geschaut? :)
Gruß,
oleg

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Oleg,

ohne den VIC zu programmieren, hätte ich es doch garnicht ausprobieren
können.

Wie gesagt, es gibt ja nur diese 2 Bits (I und F), die die Priorität
regeln.
Man kann natürlich im Interrupt einige Interrupts disablen und das I
Bit manuell wieder setzen, aber das ist dann eben "von hinten durch
die Brust ins Auge".


Peter

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

der ARM7 Kern. hat halt nur zwei INT-Prioritäten. Ist so und nicht zu
ändern.

Matthias

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich das alles so lese, bin ich doch überrascht. Auch ich hätte
erwartet, daß die meisten Befehle aus dem internen Flash in einem Takt
bei 60 MHz abgearbeitet werden; auf den 128-bit breiten Zugriff wird ja
extra hingewiesen. Und daß nur zwei Interruptprioritäten zur Verfügung
stehen ist in der 32-bit Klasse ein bißchen mager.
Bei den Datenbüchern steht letztlich sehr viel zwischen den Zeilen.

Andererseits glaube ich nicht, daß die neueren C8051Fxxx in der
Gesamtleistung besser abschneiden, von Bitmanipulationen mal abgesehen.
Die können mit ihrem Flash (dt.: Flaschenhals) auch keine zu schnellen
Sprünge machen. Die Zugriffszeit des internen Flash-ROM ist ein
generelles Problem. Den schnellsten Prozessor mit Flash, den ich bisher
gefunden habe, ist ein SH2-Prozessor (SH7144F50), der bei 50 MHz sein
internes Flash in einem Takt lesen kann. Das sind < 20ns Zugriffszeit.
Wo gäbe es so ein Bauteil zu kaufen ?

Bei den Taktfrequenzen wird ein internes Cache-RAM sinnvoll; die
neueren Coldfire z.B. haben es. So hoch die Taktfrequenzen der
Prozessoren auch sein mögen, die Leistung steigt nicht mehr
proportional (beim PC ja genau so) und erst die reale Anwendung zeigt,
wie hoch die Leistung tatsächlich ist.
Daher würde mich auch noch interessieren, wie schnell die Verarbeitung
von 'float' auf dem LPC21xx ist.

Gruß Michael

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.