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
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 ???
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
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
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
"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
"... 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
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
"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
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
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
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
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
Hallo Peter, wie wäre es denn mit dem VIC ? Hast Du schon mal in 's Datenblatt geschaut? :) Gruß, oleg
@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
Hi der ARM7 Kern. hat halt nur zwei INT-Prioritäten. Ist so und nicht zu ändern. Matthias
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
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.