Hallo Leute! Ich habe mich jetzt eine Zeit lang mit dem LPC2138-ARM7 von Philips auseinandergesetzt. Ich habe gehört, dass es von Philips auch ARM9-Prozessoren gibt. Da mich die µC-Technologie grundsätzlich sehr interessiert, dachte ich, dass ARM9 sicher auch sehr interessant ist. Aus diesem Grund möchte ich mich einbißchen damit beschäftigen. Ich verwende den Keil-Compiler und habe gehört, dass dieser seit Neuestem auch ARM9-Prozessoren unterstützen könnte, sollte, müsste. Inwieweit sind die ARM9 besser oder schneller oder leistungsfähiger als ARM7? Haben ARM9 ebensoviele Peripheriefunktionen auf dem Chip oder nicht? Wie sieht es mit der Rechenleistung aus? Inwiefern unterscheidet sich der ARM7 vom ARM9-Core? Danke für eure Antworten, Profis. Schönen Gruß Martin
Grobe Richtung: ARM7 sind eher vollintegriert mit Peripherie/Flash/RAM intern. ARM9 (und höher) peilen eher Systeme mit gösseren Speichermengen an, daher Cache intern und Speicher ganz oder überwiegend extern. Core: ARM9 hat andere Pipeline. Schneller wird's dadurch erst einmal nicht, erleichtert aber höhere Taktfrequenzen. Anonsten gilt wie üblich: Nimm soviel Leistung/Funktionalität wie du benötigst, nicht was du maximal kriegen kannst.
Hallo A.K.! OK! Ich weiß, du hast recht. Für z.B. einfache Projekte nehme ich nach wie vor AVR-8-Bit-Prozessoren. Das letzte Projekt forderte ziemlich viel Rechenleistung und da war die Geschwindigkeit des ARM7-Prozessors gerademal ausreichend. Mit einem AVR von Atmel hätte man die Projektziele ziemlich weit zurückschrauben müssen. ... Dies bedeutet jetzt nicht, dass ich für jedes Projekt einen ARM9 verwenden würde. Es ist ja nicht falsch mal hineinzuschnuppern und bei Bedarf kann man ihn dann verwenden. Sind die ARM9 jetzt eher für kleinere Betriebssysteme optimiert oder läuft auch ein gewöhnliches C-Programm ohne Betriebssystem? Wenn man in die ARM9-Welt einsteigen möchte, welche Typen sind hier empfehlenswert? Es muss ja nicht gleich der größte sein, aber trotzdem sollte er möglichst neu und modern sein. Da ich mich bereits mit dem ARM7 von Philips beschäftigt habe, würde ich es eher begrüßen weiterhin einen Prozessor von Philips zu verwenden. Es sei denn ein ARM9 von Philips hätte so gravierende Nachteile, dass ein ARM9 von z.B. Atmel viel besser wäre. Tschüss. Martin
Ich habe selber keine Erfahrungen mit ARM9, Zielrichtung scheint da jedoch eher Linux&Co zu sein. Allerdings begegnet man bei diesem Thema häufig Atmel (AT91RM9200), beispielsweise http://elmicro.com/de/armeva.html. Philips' LPC3000 ist auch noch sehr "warm". Und da der externe Speicher einigermassen schnell sein muss (lies: viele Pins), darfst du zudem mit BGA-Gehäuse rechnen.
Der an sich schickste Philips-ARM7 LPC2880/2888 wird leider auch in einem völlig unverarbeitbaren Gehäuse (0.5mm-Finepitch-BGA mit 180 Balls) hergestellt. Ansonsten wäre der eine reizvolle Alternative zu manch anderem ARM - ARM7TDMI, max 60 MHz, 8 kByte Cache(!) - 1 MByte Flash (2888) - 64 kByte SRAM - Controller für externes SDRAM - USB-Devicecontroller auch für USB 2.0 high speed (480 MBit/sec) - SD-Card-Controller - Audio D/A und A/D-Wandler (16 Bit, Stereo) - Audio I²S-Interface - interne Versorgungsspannungserzeugung mit DC/DC-Wandler - 10 Bit A/D-Wandler - diverser anderer Pofel Aber leider, leider im 10x10mm großen TFBGA180 untergebracht. http://www.standardics.philips.com/products/lpc2000/pdf/lpc2880.lpc2888.pdf
Nur ist ein ARM7 mit 60MHz auch nicht viel schneller als ein ARM7 mit 60MHz. Und schneller als internes RAM für kritische Routinen ist ein interner Cache auch nicht.
> Nur ist ein ARM7 mit 60MHz auch nicht viel schneller > als ein ARM7 mit 60MHz. Besser hätte ich das auch nicht ausdrücken können. Der interne Cache dürfte einem aber das Kopieren von kritischen Routinen ins RAM ersparen. Ich erwähnte diesen ARM in erster Linie deshalb, weil der auch für ucLinux ausreichendes Flash-ROM und einen bei ARM7 seltenen SDRAM-Controller hat (der einzig andere, der mir einfällt, ist der OKI 67Q4xxx/5xxx)
Hallo! Hei, diesen Kontroller finde ich auch großartig. Stimmt es, dass dieser Kontroller sehr neu ist? Der Keil-Compiler unterstützt ihn jedenfalls nicht. Außerdem habe ich kein richtiges User-Manual gefunden, indem die einzelnen Einheiten samt Register erklärt werden würden. Ich muss mal bei der Firma Keil durchklingeln. Wie funktioniert das eigentlich mit dem Cache? Managed dies der Kontroller selbst oder kann man auf das Cache wie auf ein RAM zugreifen? Gruß, Martin
@Martin: Solltest Du den von mir erwähnten LPC2888 meinen, der ist in der Tat sehr neu. Da er einen ARM7TDMI-Kern verwendet, wird er prinzipiell von jedem Compiler für ARM7 unterstützt - die Headerdatei für die Peripheridefinitionen wird man sich halt selbst erstellen müssen. Den Cache verwaltet der Controller selber, ganz so, wie Cache sonst auch von Prozessoren bzw. deren Cachecontroller verwaltet wird. Der Cache ist für den Programmierer unsichtbar. Da dieser Controller so neu ist, dürften weder Lieferanten noch Preise feststehen. Selbst wenn, aufgrund des völlig unbrauchbaren Gehäuses, das zwingend den Gebrauch von viellagigen Multilayerplatinen vorschreibt, dürfte das Teil leider ziemlich uninteressant bleiben. Nicht nur, daß das ein BGA-Gehäuse ist, nein, das muss auch noch Finepitch-BGA mit 0.5mm Rastermaß sein. So ein Scheiss. Dabei gibt es PQFP-Gehäuse mit 208 Anschlüssen, das hätte ja auch funktioniert ... Vielleicht lernt Philips ja noch dazu. Robert? Das wäre eine Anregung! Nachdem der LPC2103 sogar im PLCC-Gehäuse hergestellt wird ...
Hallo Rufus und A.K. Das Gehaeuse war erst mal vom Spezialkunden vorgeschrieben. Wir pruefen welche Gehaeuse machbar sind. Das LQFP-208 ist ein Riesenfladen, mit 28mm Kantenlaenge und hat so seine eigenen Probleme in einer Serienfertigung. Vielleicht wirds ja ein QFP-176 wenn wir 4 pins identifizieren koennen die etwas weniger wertvoll sind als die anderen 176. Ausserdem koennten wir ja auch ein BGA mit 0.8 mm Raster nehmen, da brauchst auf jeden Fall weniger Lagen in der Platine. Wird aber noch ein paar Wochen dauern! Gruss, Robert
Hi, eine LQFP208 oder QFP176 Version waere sehr schoen. BGA für den Hobbybastler bzw. Kleinserien ist leider noch unerschwinglich. Gruß, Dirk
Hallo Robert, wenn BGA sein muss, dann ist auch 0.8 mm Raster fuer Prototypen eine Plage. 1.00 oder 1.27 mm Raster erlaubt mehr Toleranzen und laschere Designregeln.Aber QFP ist viel besser zu kontrollieren Tschuess
Robert, danke für die Antwort. Vielleicht ließe sich ja -analog zur "Abstimmung" beim LPC2103- ein "wir verzichten auf vier Pins"-Happening zur QFP-176-Ermöglichung veranstalten. Bitte auf jeden Fall eine Alternative zum BGA. Was mich etwas erstaunt, ist der eingebaute 16-Bit-Audio-DAC/ADC; ist so etwas in einem Baustein dieser Art tatsächlich ohne größere Probleme in den Griff zu bekommen? Einem Artikel aus der LPC2000-"News"group auf Yahoo zufolge ist Olimex dabei, eine Platine für den LPC2888 zu entwickeln: > > Does this imply that there will be an Olimex > > board carrying an LPC2888? > > > > Maybe even a header board? > > yes, header board with miniUSB connector, 32MB SDRAM, > 2MB external FLASH and extensions on all LPC2888 ports, > board size is in credit card format > the total 120 pin extensions are on the two edges of > the board and are 20x3 0.1" easy for prototype, everyone > could use this module to develop low cost double side > "mother" board for his applications > > > Is there yet a time frame? > > Philips promise to deliver the first LPC2888s in September, > so the board will be released not earlier than October > this year (unless Philips deliver earlier ;) Mir läuft jedenfalls schon das sprichtwörtliche Wasser im Munde zusammen.
Das Wasser läuft einem im Munde zusammen bei den sehr schön lötbaren STR9-MCUs: http://mcu.st.com/mcu/inchtml.php?fdir=pages&fnam=str9 Ein schneller Arm9 im LQFP80 mit USB und CAN oder im LQFP128 mit Ethernet, USB, CAN. Was will man mehr?
und die STR912 habe noch als Zugabe ein External memory inteface. Ist zwar ein Multiplexbus ( für 16Bit Datenbus ), aber mit 4 x 64MB mehr als ausreichend. Bei Digikey kosten die derzeit 15 EUR ( 256KB Flash ) bzw. 17 EUR ( 512KB Flash ).
@Andreas Der STR9xx ist definitiv kein "schneller ARM9" aber es ist ein ARM9. Also hat er fuer DSP orientierte Anwendungen deutliche Vorteile gegenueber einem ARM7. Ein schneller ARM9 faengt im Bereich 200 MHz an. Ach ja, externer Speicher, ist natuerlich was wert, wenn man den adressieren kann! Allerdings sollte dabei klar sein, mit einem 16-bit Multpiplexed Bus kann man bei Abarbeitung aus einem sagen wir mal <10ns SRAM vielleicht 20-25% der Leistung rauskitzeln im Vergleich zu voller Geschwindigkeit interne Ausfuehrung aus dem SRAM. Damit ist der ARM9 von extern langsamer als ein ARM7 mit non-mux 32-bit breitem Bus. Also fuer unkritische Erweiterungen, die einfach Speicher brauchen laesst sich was damit machen. Aber eine Benutzerfuehrung kann auch aus einem SPI-Flash gemacht werden. Mich wuerde mal interessieren wenn jemand im Forum hier Vergleichsmessungen zwischen einem LPC2000 und dem STR9 machen wuerde, beide vom internen Flash, der LPC bei 60 MHz, der STR9 bei 96 MHz. Da unsere Tests verstaendlicherweisse nicht als Mass genommen werden koennen wuerde mich ein unabhaengiger Test sehr interessieren. Robert
Solche Vergleiche hat Paul Curtis von Rowley in der LPC2000 Yahoo Group angestellt - der STR9x schnitt dabei mit 96MHz schlechter ab als ein LPC2000 mit 60MHz. Er ist dabei zwar nicht näher auf die gemachten Tests eingegangen, aber zumindest als grobe Hausnummer kann das wohl dienen. Trotzdem ist es gut möglich, dass mit einiger Optimierung aus einem STR9 noch mehr herauszuholen ist - die Architektur sollte wohl mehr hergeben. Der Vorteil in Sachen DSP erschliesst sich mir nicht so direkt - erst ein ARM9E(J)-S bringt den erweiterten Befehlssatz der ARMv5TE Architektur mit sich, ARM920T, ARM922T etc. sind vom Befehlssatz identisch mit den ARM7 (ausser ARM7EJ-S, wovon ich allerdings nur die Beschreibung des Cores auf arm.com gesehen habe, keine käuflichen Chips). Der Vorteil des ARM9 an sich liegt in der Harvard Architektur, also getrennten Ports für Daten und Befehle (bringt nur etwas, wenn das Speicherinterface/Caches/TCM genügend Bandbreite besitzen), und in der von drei auf fünf Stufen velängerten Pipeline, womit höhere Frequenzen möglich sind, was die aktuellen STR9 mit ihren 96MHz allerdings nur kaum ausnutzen. Gruss, Dominic
Bezüglich des arg beschnittenen Busses: Der scheint wohl ähnlich wie der externe Bus der LPC23xx auf I/O Anwendungen ausgerichtet zu sein - da ist auch ein gemultiplexter Bus eine Bereicherung gegenüber den GPIO Ports, die bei STR7x oder LPC21xx zur Verfügung stehen. Als Befehlsspeicher ist er definitiv ungeeignet, es sei denn die Anwendung stellt extrem niedrige Anforderungen an die Performance. Gruss, Dominic
wenn man bedenkt, das nocht nicht ein ARM bei der Gemeinde Gut abgeschnitte hat, ist das eine Super Aussage. NXP/Phillips steht anscheinend über allen, bis auf die Tatsache, das ihre ERRATAS nicht weniger werden.
Auch NXPs Erratas werden weniger - für einige der älteren LPCs (2119, 2290, k.a. wie viele noch) gibt es bereits Revision B Chips, für andere wie LPC213x wurde das in Aussicht gestellt (hier, oder in der LPC2000 Yahoo Group, weiss nicht mehr wo). Ausserdem sind Erratas nichts tragisches, solange sie Einschränkungen der Funktionalität rechtzeitig bekannt machen, also bevor du dich für einen bestimmten Chip aufgrund bestimmer Produkteigenschaften entschieden hast. Dass die Leute in diesem Forum skeptischer gegenüber ARM sind liegt wohl daran, dass ein ARM deutlich komplexer und oft auch unhandlicher im (Hobby-)Einsatz ist. Grössere Packages mit mehr und enger beieinander liegenden Pins sind schwieriger in der Verarbeitung als ein DIP. Wenn der AVR dann noch ausreichende Leistung für ein Problem bietet greifen die Leute eben lieber zu dem. Wenn du mal in's Archiv der LPC2000 Group siehst wirst du jede Menge Leute finden, die mit den Chips hochzufrieden sind. Gleiches gilt für Atmels AT91SAM7, dazu allerdings das Forum auf at91.com befragen. Für Aufgaben, die nach noch mehr Performance oder Speicher verlangen, muss dann aber oft ein System mit Caches her - also ARM720t, ARM920t, ARM922t, ARM926EJ-S, etc. Bei höheren Taktraten wird der Unterschied zwischen Core-Clock und Memory-Clock gnadenlos bestraft. Grösserer Speicher wird auch immer langsamer sein, wobei sich langsam nicht zwangsläufig auf Bandbreite bezieht, sondern auch Latenz meint. Für solche Aufgaben gibt es dann Chips wie AT91RM9200, AT91SAM926[0123], EP93xx, S3Cxxxx, LH7xxxx, ... - wer solche Chips in Hobby Projekten einsetzen will kann auf fertige Module zurückgreifen, die uC, Takt, Spannungsregelung, Speicher etc. auf einer Platine vereinen, und die übrigen Signale im 2.54mm Raster zur Verfügung stellen. Gruss, Dominic
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.