mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM Board minimal


Autor: Luky (Gast)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

Autor: Roland Schmidlin (rschmidlin)
Datum:

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

Autor: Luky (Gast)
Datum:

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

Autor: Roland Schmidlin (rschmidlin)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

Autor: Freak5 (Gast)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

Autor: Sebastian Block (Gast)
Datum:

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

Autor: Freak5 (Gast)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, um die Verhältnisse klarzustellen. AVR:

Laden/Speichern: 2 Takte.
Springen:        2 Takte
Call:            4 Takte
16-Bit Op:       2 Takte

Autor: Freak5 (Gast)
Datum:

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

Autor: Freak5 (Gast)
Datum:

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

Autor: Christoph Wagner (christoph)
Datum:

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

Autor: Freak5 (Gast)
Datum:

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

Autor: Freak5 (Gast)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

Autor: Roland Schmidlin (rschmidlin)
Datum:

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

Autor: Luky (Gast)
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
> ARM nicht gut

?

Autor: Roland Schmidlin (rschmidlin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da kann ich auch nicht ganz folgen. Das hat hier glaub ich keiner
behauptet, oder?

Autor: Freak5 (Gast)
Datum:

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

Autor: LPCler (Gast)
Datum:

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

Autor: Peter Mahler (Gast)
Datum:

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

Autor: Mark Struberg (struberg)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

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

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

Autor: Mark Struberg (struberg)
Datum:

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

Autor: Freak5 (Gast)
Datum:

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

Autor: Roland Schmidlin (rschmidlin)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

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.