Hallo! Ich brauche für ein Uni - Projekt ein einfaches Board für einen ARM mit > 50MIPS. Ich habe mich mal umgesehen und bin auf die Philips -und Atmel ARM7 gestoßen. Da mit GCC programmiert werden soll, interessiert mich erstmal, welcher Controller besser unterstützt wird bzw. problemloser damit zusammenarbeitet. Die zweite Frage wäre, welche Teile unbedingt auf die Platine müssen. (Abblockkondensatoren, Spannungsversorgung, Quarz...) Die Platine soll möglichst klein sein (max. 1/2 Euro), da sie in einem mobilen Roboter eingesetzt wird. Damit fallen schonmal alle Devboards weg. Zum Fertigen kann ich eine Platinenfräße benutzen.
"ARM mit > 50MIPS." Mit dieser Forderung sind die üblichen Verdächtigen auf ARM7TDMI-Basis wie Philips LPC2xxx und Atmel SAM7 aus dem Rennen, das geben die nicht her (MIPS << MHz). Unterhalb von ARM9, und folglich externem Speicher, solltest Du dann nicht anfangen. Und liegst damit etwas jenseits der hier gängigen Erfahrungen. Und brauchst zu viel Platz. Philips LPC2xxx ist etwas schneller als Atmel SAM7, weil Atmel aus dem Flash heraus nur den langsameren Thumb-Code in voller Geschwindigkeit unterstützt. Der native ARM-Code wird ausgebremst. Dem GCC ist es übrigens komplett egal, ein Plug-and-Play-Lösung ist der eher nicht. Wenn Du die Compiler-Lösung nicht einkaufst, musst Du die Controller-spezifischen Anpassungen selber machen oder aus dem Netz zusammenklauben. Da gibt's für Phlips z.Zt. noch etwas mehr Angebot.
Hallo Luky, schau mal unter www.embeddedartists.com nach. Ich verwende momentan das LPC2132 QuickStartBoard. Das Board beinhaltet für 29 alles was es zum einfachen Einstieg in die LPC-Familie braucht. Da Du ja schreibst, dass ein DevBoard wegen der Größe wegfällt, findest Du, falls das QuickStartBoard noch zu groß wäre, auch den Schaltplan dafür auf der Seite und kannst Dir da evtl. ein paar Ideen holen. Gruß Roland
Wie sieht es eigendlich mit den angeblich zimlich gravierenden Fehlern der LPC2xxx Baureihe in der Praxis aus? Externen Speicher möchte ich nicht verwenden, also muss ein ARM7 reichen.
Wenn ich das hier im Forum richtig mitbekommen habe, sind Fehlerbereinigte Versionen der Chips in Planung. Um zu sehen, ob Dich die bestehenden Fehler betreffen, schau Dir die Eratasheets direkt auf der Seite von Philips zum entsprechenden Controller an. Beim LPC213x wäre das dann beispielsweise unter http://www.semiconductors.philips.com/pip/LPC2132FBD64.html unter dem Punkt "Support & Tools" zu finden.
Errata-Liste genau lesen und verstehen ist Voraussetzung, Funktionen, die man nicht braucht, dürfen ruhig Fehler enthalten, mit anderen kann man leben. Neuere Devices wie 213x haben deutlich weniger Bugs als die alten 210x oder 211x/2x.
@AK Ich habe da aber etwas gelesen. Jemand aus dem Forum hatte so einen Chip von ATMEL und hat glaube ich über die Codedichte gesprochen. Auf der Atmelseite stand dann etwas von 55Mhz und 50MIPS. Die kleinen Versionen sollen angeblich bald überall auf den Markt geworfen werden und die großen haben sogar 500Kb integrierten Speicher. Da braucht man kein ASM mehr. Da kann man gleich mit C anfangen :-)
Laden: 3 Takte Speichern: 2 Takte Sprung/Call: 3 Takte + 1-2 Takte Zugriffszeit Flash ALU: 1 Takt Wenn Du dir jetzt mal realen Allerweltscode ansiehst, dann wird rasch klar, dass die Realität wohl näher als 0,5 MIPS/MHz liegt als an den Angaben von Atmel.
was ich viel erschreckender finde ist die Verwendung einer Platinenfräse .. kann die wirklich so feine Strukturen herstellen, dass man die Leiterbahnen um den Prozessor fräsen kann ???
@Ak: Mehr als 3 Zeilen habe ich über das Teil nicht gelesen. Bedeutet das jetzt, dass eigentlich nur die ALU mit 50MIPS arbeiten kann und der rest getürkt ist(langsamer als ein AVR)? Wie viele Takte benötigen IO Zugriffe dann eigentlich?
Innere Struktur und Pipeline vom ARM7-Core sind geradezu antik, noch identisch mit dem ersten ARM-Prozessor, der vor rund 2 Jahrzehnten entstand. Code und Daten gehen über den gleichen Bus. Cache gibt es ebenfalls keinen. Und so brauchen manche Befehle halt mehrere Takte. Bei AVR können Code- und Daten/IO-Zugriffe parallel stattfinden. Herstellerangaben zu MIPS sind üblicherweise "Werte die garantiert nie überschritten werden". Ungefähr wie die Höchstgeschwindigkeit von Autos, gemessen im freien Fall aus 100m Höhe. Und genauso aussagekräftig wie die von den Compilerherstellern handoptimierten Dhrystones. So habe ich einen Dhrystone gesehen, in dem der IAR-Compiler um Längen vor GCC lag. In der Praxis ist der Codegenerator vom GCC erheblich besser als der von IAR.
Ach ja, um die Verhältnisse klarzustellen. AVR: Laden/Speichern: 2 Takte. Springen: 2 Takte Call: 4 Takte 16-Bit Op: 2 Takte
@AK: Aber wenn man bedenkt, dass dieser neue Arm mit über 50 Mhz läuft und so vielleicht auch 60Mhz erreichen könnte, dann müsste der doch schneller sein als ein ATmega mit 20Mhz, oder? Dein Verhältnis zum AVR sieht gar nicht mehr so schlimm aus. Das mit dem Call hat mich gerade etwas überrascht. Ich dachte, dass der Atmega das in 3 Takten machen kann. Und Rechnen usw. Macht der ja auch in einem Takt :-), was wieder Identisch mit dem Arm wäre. Wenn man jetzt 32 Bit Operationen mit dem AVR durchführen woltle, dann relativiert sich der Geschwindigkeitsvorsprung pro MHz vom Atmel ja auch schon wieder. Wobei eigentlich alle Operationen, die ich mir vorstelle nur 16 Bit benötigen. Sind die IO-Pins bei den Arms dann auch ein 32Bit-Register? Wenn ja, dann werde ich wohl immer zwei Verknüpfungen machen müssen(eine um die Hälfte der Bits zu löschen und eine zum setzen mit Xor) Der ARM von Atmel ist mir nur irgendwie sympatisch, weil er so günstig sein soll und es davon so heftige Typen gibt, die 500Kb ram haben und >90IO Pins, wobei das Löten dann sicher richtig spaßig wird *G* Aber das hörte sich für mich an, als könnte man damit richtig etwas verwalten
Außerdem dachte ich vorher, dass diese 50MIPS bedeuten, dass es dieses Takt-Leistungsproblem bei dem Chip nicht in dieser Form gibt. Kann es sein, dass der Aufbau der AVRs auch die maximale Taktgeschwindigkeit begrenzt?
Natürlich wird die Taktgeschwindigkeit begrenz - aber hauptsächlich durch den FLASH-Programmspeicher, der irgendwann anfangt zu bremsen (indem er nicht mehr richtig arbeitet). Ein AVR-Core könnte sicherlich einige male schneller laufen.
http://www.atmel.com/dyn/resources/prod_documents/6209s.pdf Trotzdem sehen diese Chips schon gewaltig aus. Wenn es für diese Packages noch günstige Sockel geben würde, die so wie ein CPU-Sockel funktionieren und per ISP programmierbar sind(Pins hätte man ja genug), dann wäre das ein absolut perfekter Chip. Abgesehen vom Preis. Ich meine, alles was man braucht hat man Onboard. (USB und Ethernet) und alles andere kann man sich basteln, da man viele IO-Pins frei hat. Es gibt ja diese MP3-Playerprojekte für den AVR. Mit so einem Chip könnte man diese Player um USB erweitern und da man so viel Ram übrig hat könnte man das mit den Festplattenzugriffen sicher verbessern.
Ich habe da gerade etwas in einem anderen Forum gelesen, was sich richtig gut anhört: ___________________________________________________________________ LOL, Schokolade ist gut USB programmierbar ist der aber im Prinzip schon. Die AT91SAM7Sxxx haben einen Bootloader der über USB und seriell funktioniert. Allerdings bin ich noch nicht ganz durchgestiegen. Ich kann bisher immer nur einmal einen Download machen, danach ist das Programm zwar drin, aber ich weiß nicht wie man dann wieder an den Bootloader kommt ohne einen mehrere Sekunden dauernden Ablauf durchzuspielen. Dieses Jahr wird's noch keine Boards geben, und mit dem 7S32 vermutlich gar nicht weil der Preisunterschied einfach zu klein ist und der 7S32 dann dafür aber deutlich weniger bietet. Einziger Vorteil ist das er kleiner ist. Die ersten Boards werden vermutlich ähnlich aussehen wie das da oben von Olimex. Steckmodule im Stil von meinem Mega128 Modul kommen auch noch
"Kann es sein, dass der Aufbau der AVRs auch die maximale Taktgeschwindigkeit begrenzt?" Das Flash begrenzt die Geschwindigkeit. Der Core dürfte mehr können, allerdings verwendet AVR zwecks 5V-tauglichkeit vielleicht auch eine andere Prozesstechnik dafür, als beim USB-AVR mit 48MHz im RAM. "dann müsste der doch schneller sein als ein ATmega mit 20Mhz, oder?" Aber ja doch. Nicht, wenn er bloss mit I/O-Leitungen spielt. Bei Software-SPI (bit banging) wird ein AVR schneller sein als zumindest die meisten LPCs, weil die einen berüchtigt langsamen Peripheriebus haben. Aber lass den AVR mal die in C extrem häufigen (mindestens) 16bit breiten Daten und Zeiger verwursten, rechnen, schieben, ... am besten mit kompletten Stack-Frames dank Daten auf dem Stack, und der ARM rennt davon wie nix (grad die Stack-Frames sind beim AVR eine Katastrophe). Zudem ist grad dann selbst der native ARM-Code ausgesprochen kompakt im Vergleich mit AVR, erst recht Thumb.
Also der LPC213x läuft mit bis zu 60MHz. Die lassen sich duch die integrierte PLL auch aus ner niedrigeren Quarzfrequenz erzeugen (z.B. 15MHz Quarz über PLL mit 4 multiplizieren). Zu den IO-Ports: Der LPC213x hat 2 Ports einer mit 31 und einer mit 16 IO-Lines. Allerdings lassen sich die IOs nicht nur über einen "direkten" Registerzugriff ansprechen, sondern es gibt für jeden IO-Port noch ein Set- und ein Clear-Register (Beispielsweise IO0SET und IO0CLR). Schreibst Du jetzt in IO0SET zum Beispiel 0x000000AA dann werden IO0.1, IO0.3, IO0.5 und IO0.7 gesetzt. die anderen bleiben unverändert. Genauso (nur halt zum löschen) geht das mit dem IO0CLR-Register. Dadurch spart man sich einiges an Auslese- und Logikverknüpfungsaufwand beim schreiben auf die IOs. Gruß Roland
ARM nicht gut, AVR leider zu langsam, ... Was soll man dann bitteschön nehmen wen man etwas Rechenleistung braucht? Mann könnte ja schon fast in versuchung kommen ein eigenes Design zu entwickeln :-( @Sebastian Block: Die Platinenfräse kann Leiterbahnen >0,2mm sauber fertigen.
Da kann ich auch nicht ganz folgen. Das hat hier glaub ich keiner behauptet, oder?
Naja ARM und AVR haben beide Nachteile. Perfekt wäre jetzt ein 32Bit AVR auf 60Mhz mit 120IO-Pins onboard USB und Ethernet g Aber man kann sich ja zwischen AVR und ARM etwas aussuchen. Ich denke dass man beim ARM eher etwas wie Betriebssysteme laufen lassen kann. Wenn es aber um bloßes durchrouten von Signalen geht und um Steuerungsaufgaben wie Lampe an und Lampe aus, dann ist der AVR scheinbar die bessere Lösung, weil die Pins schneller beschaltbar sind.
Habe erst einmal den Beiträgen im Forum gelauscht. Ich setze in einem Projekt den LPC2138 bzw. auch den LPC2148 mit USB-Anschluß ein. Ich muss sagen, die neuen LPCs haben mich überrascht, von einem langsamen Peripheriebus kann ich nicht reden, habe meine CPU von extern 12MHz auf 60MHz hochgefahren und dem Peripheriebus einen zu 1 Teiler gegeben, so dass dieser ebenfalls mit 60MHz läuft. Einen schneller Flash-Zugriff bietet mit Philips einer der wenigen und was die Portsteuerung anbelangt, kann ich nur sagen. Es ist ein 32-bitter aber wie man die Ports nutzen will, wird einem selbst überlassen. So kann man auch 8- oder 16 bitweise auf die Ports zugreifen um das Handling zu erleichtern. Ich nutze zum Beispiel einen 8Bit breiten Port für eine schnelle LVDS Schnittstelle und greife über die im LPC verfügbare Fast IO-Funktionalität zu, so dass für die Portausgabe mehrere MHz zustande bekomme. Zu den MIPS gebe ich keinen Kommenatr ab, da ich meine dass diesen MIPS oft viel zuviel Bedeutung gegeben wird. Für mich sind andere Faktoren viel entscheidender und in den wenigsten Fällen ist es entscheident ob jetzt in der Regel 50,40 oder 30 Mips herauskommen.
Hallo, die Diskussion über MIPS als Performance-Beurteilung nervt. Das Problem ist dass die MIPS immer in der Register-Breite der Prozessors durchgeführt werden. Ein sinnvoller Rückschluss auf die Vergleichbarkeit innerhalb einer Applikation ist jedoch nicht möglich. Besser finde ich den Ansatz allgemein gebräuchliche Programmteile miteinander zu vergleichen. Beispiel ist die Microcontroller- Performance-Comparison auf freetrtos.org. Vergleich man dort die Geschwindigkeiten, sieht man zum einen dass der Unterschied bei Kontrollstrukturen gar nicht so gross ist, dafür bei Arithmetik umso grösser. Durch ein paar eigene MSR-Applikationen, die ich bei ARM und AVR weitestgehend portabel, bzw. vergleichbar gehalten habe, habe ich den Eindruck, dass das Verhältniss LPC2106 zu einen ATmega(16 MHz) etwa den Faktor 10:1 entspricht. Die Erfahrung die ich dabei ebenfalls gemacht habe, ist dass mit zunehmender Komplexizität der Applikation der Unterschied grösser wird. Gruss, Peter
@A.K. zum thema MIPS beim AVR: Ich habe das bis jetzt folgendermaßen verstanden: 1.) Speicheranbindung: Die LPC2k haben einen 128bit breiten Flash-Bus, der laut lpcgroup mit bis zu etwa 25MHz betrieben wird. Dh selbst PLL auf 70 MHz ergibt, daß noch immer locker 32 bit, also 1 ARM und 2 ThumbARM Instruktionen die auf einmal gelesen werden. Der ARM7TDMI hat zwar per Design keinen Cache (wegen der angestrebten geringen Leistungsaufnahme), aber immerhin eine pre fetch Queue. Diese wird nur bei Branches und Jumps vollständig gelöscht, ansonst hat man auf jeden Fall 32 bit zur Verarbeitung zur Verfügung 2.) instruction set: Alle Befehle beim ARM sind 32 bit, im thumb mode 16 bit. Das mit dem Load Value (LDI beim AVR) ist also so eine Sache. Wenn man 32bit pro Befehl hat, dann kann man klarerweise damit keinen 32bit Value direkt laden. Bei MIPS ist man den Weg gegangen zwei Befehle zu machen (LDL und LDH), beim ARM gibt man beim Load eine relative Adresse von +-4kByte im Befehl an, von dem dann die Konstante geladen wird. ALLERDINNGS: Es gibt für 8-Bit immediate Operationen einen eigenen Befehl (PSR, Data Processing Operation), die AND, EOR, SUB, RSB, ADD, ADC, SBC, RSC, TST, TEQ, CMP, CMN, ORR, MOV, BIC, MVN DIREKT mit einem 8-bit Value machen kann. Dh, das Laden eines Registers mit einem 8-bit Value verbraucht lediglich 1 instruction! Und zusätzlich kann beim ARM bei jeder Instruction gleich eine Condition mitgegeben werden. Man kann also das bedingte Laden eines 8-bit immediate values in 1 Taktzyklus erledigen, während das beim AVR min 4 Zyklen braucht.
Das Flash mag aberhunderte von Bits breit sein, der ein- und einzige Bus vom Core hat aber nun einmal nur 32bit Breite, und ab und zu auch mal einen leeren Takt dabei. Und so kommen bei LDR mindestens 3 Takte zustande, egal wie der Speicher organisiert ist. Plus Waitstates. Siehe Beschreibung vom ARM7TDMI-S Core auf www.arm.com. Dass ARM für den gleichen Job weniger Befehle braucht ist klar. Aber hier wurden (sinnlose) MIPS gefordert, nicht (sinnvolle) Performance. Schrott rein Schrott raus, kannst es auch "höheren Blödsinn" nennen.
Das Laden einer 32-Bit-Konstante in ein ARM-Register kann, je nach Konstante, auch mit einem 32-Opcode erfolgen. Ich zitier' mich mal selbst (untersucht wurde der von einem C-Compiler erzeugte ARM-Assembler-Code): Ein harmloses Statement wie IOCLR = 0x00000080; sieht disassembliert so aus: 0x0000058C 0xE3A032CE mov r3, #0xE000000C 0x00000590 0xE283390A add r3, r3, #0x00028000 0x00000594 0xE3A02080 mov r2, #0x00000080 0x00000598 0xE5832000 str r2, [r3] Zunächst rieb ich mir verwundert die Augen; was zum Teufel hat die Addition da verloren? Bei Betrachtung der Adressen und der Operandengröße wurde mir dann aber einiges klar. Jede der vier Instruktionen ist exakt 32 Bit lang - das sind die Operanden aber auch. Also werden die 32-Bit-Operanden "gepackt", um mit in den 32-Bit-Opcode untergebracht zu werden. Der Wert 0xE002800C (das ist das Register IOCLR) lässt sich nicht in einen Opcode packen und muss daher durch eine Addition der in eine Instruktion packbaren Werte 0xE000000C und 0x28000 gebildet werden. Anscheinend gibt es auch keine Möglichkeit, eine Konstante in eine in einem Prozessorregister enthaltene Adresse zu schreiben, daher muss erst die Konstante in ein Register geladen werden (was hier wohl glücklicherweise in einem Rutsch geht) und dies dann indirekt über das andere Register in den Speicher geschrieben werden. Ich hab' mir mal den Spaß gemacht, und mir die Funktion der Instruktion 0xE283390A im ARM7-TDMI Manual näher anzusehen. Das ist die Addition der Konstanten 0x28000 zum Register R3 - der Wert wird durch eine 32-Bit-Rotation des 8-Bit-Wertes 0x0A gewonnen (9*2 mal nach rechts). Diese Operation wird in einem* Takt ausgeführt. Geht's noch komplizierter? Damit hatte ich nicht gerechnet, aber es erscheint nach einiger Überlegung logisch. Nur durch so eine Vorgehensweise kann die Instruktionslänge auf 1 DWORD und so auch die Ausführungszeit auf 1 Takt pro Instruktion** beschränkt bleiben. Nun, das wird wohl der RISC/CISC-Unterschied sein. Das ist natürlich ziemliche Grütze, weil so die Ausführungszeit folgender C-Zeilen unterschiedlich ist: unsigned long Variable; Variable = 0xE000000C; // schnell Variable = 0xE002800C; // langsamer Damit hatte ich nun wirklich nicht gerechnet. *) der LPC2106 hat ein 32 bit breites Speicherinterface, benötigt also nicht wie andere kleine ARM-Varianten zwei 16-Bit-Speicherzugriffe für eine Instruktion. **) jedenfalls bei den hier zitierten. Quelle: http://www.mikrocontroller.net/forum/read-1-142873.html#145955
Ich denke wir sprechen beide von verschiedenen Dingen: > Und so kommen bei LDR mindestens 3 Takte zustande Beim direkten Laden eines 32bit values hast du absolut recht, aber nicht, wenn man den PSR Befehl benützt. Bei dem kann man 8-bit Werte innerhalb eines Taktbefehls an eine beliebige stelle eines Registers laden, modifizieren, etc. (also ANDI pendant) Dieser Data Processing Befehl braucht laut meiner Liste genau 1 fetch cycle (3 nur bei register specified shift oder wenn der PC geschrieben wird). Meine Liste ist aber zugegebenermaßen schon ziemlich alt (SA110). Ich hab 1997 meinen Apple Newton in asm gehackt, beim LPC arbeite ich mit gcc. Ich kann mir aber irgendwie nicht vorstellen, daß der ARM7 von heute langsamer sein soll als der dem 110er zugrundeliegende ARM2 core. Zur höheren Leistung: Viele hier vergessen, daß die 60 (70) MHz der LPC, AT91SAM7, etc lediglich die interne per PLL erzeugte Taktfrequenz ist. Alle externen Komponenten laufen genau mit der Quarzspeed, und keine ns schneller. Die meisten boards haben zB einen 14,x MHz Quarz und den PLL auf x4 eingestellt. Pin toggeln, abfragen, etc geht damit aber auch nur alle 4 Taktzyklen, und damit genauso schnell wie ein mit 14,x MHz betriebener AVR.
Da könnte man doch einen 20Mhz Oszillator benutzen und mit 3 multiplizieren und vielleicht könnte man irgendeinen Quarz auch auf einer Obwerwelle schwingen lassen, so dass man garnicht mehr multiplizieren muss usw. Oder funktionieren die Ausgänge dann garnicht mehr? (Ich habe mich bis jetzt noch garnicht damit auseinandergesetzt)
Wenn ich den PeripheralClock auf CPUClock/1 stelle sollten doch die eingebauten Peripheriekomponenten wie beispielsweise die Timer, Ports, etc. auch mit der selben Geschwindigkeit funktionieren, da die ja alle am PCLK hängen. Oder hab ich da jetzt was falsch verstanden? Bausteine die nicht im Controller integriert sind haben natürlich nur den Takt, der ihnen zugeführt wird. Das ist mir schon klar.
LDR 3 Takte - beliebige Konstanten MOV 1 Takt - 8 Bit, rotiert Freilich liegen die I/O-Adressen so, dass selten weniger als 3 Takte drin sind. Wenn man sie direkt verwendet. Empfehlung: Die Register der Peripherieeinheiten in structs zusammenfassen, statt alle einzeln als (*(...)0x12345678) zu definieren. Das überzeugt zumindest GCC davon, die Adresse einer solchen Peripherieeinheit nur einmal zu laden und alle Register relativ dazu zu adressieren. Wer mehr Zeit hat (IAR), verwendet Bitfelder, weil das zwar schön aussieht, aber ein Maximum an Code erzeugt. Bei den LPC2000-ern leitet sich der I/O-Takt vom Prozessortakt ab, nicht vom Quarztakt. Um mal Zahlen rein zu bringen: LDR dauert beim lpc2129 bei maximalem Peripherietakt 4 Takte länger wenn ein I/O-Port gelesen wird. Also 7 Takte statt 3 Takte.
"als der dem 110er zugrundeliegende ARM2 core." Der Strongarm war eine Eigenentwicklung von DEC, ohne direkten Bezug auf die ARM Cores. Er mag die ARMv2-Architektur der ARM6xx/7xx Cores gehabt haben, die Pipeline indessen war komplett anders, eher Richtung ARM9xx.
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.