www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LPC-P2148 oder AT91SAM7S64 ?


Autor: Pascal Lenzner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Welches ARM7-Entwicklungssystem aus dem Shop würdet ihr bevorzugen, das
für den LPC-P2148 oder den AT91SAM7S64? Ersteres hat zwar etwas mehr
Speicher, jedoch gefällt mir der Atmel-Prozessor irgendwie besser, aber
dieses "irgendwie" ist eher ein Gefühl :-), vielleicht kann mir ja
jemand von euch helfen!

Ciao...

Pascal

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt drauf an, was Du vorhast.

Philips hat den Vorteil, daß die jetzt massiv einsteigen und die
Derivatezahl enorm hoch drücken, dafür sind die Atmel nicht so
fehlerbehaftet und außerdem gibt es die schicken "X"-Varianten (bald
hier erhältlich), die Ethernet, CAN sowie Hardware-Verschlüsselung auf
einem Chip vereinen.

Ich habe mich jedenfalls für die Atmels entschieden.
Olimex bringt angeblich noch dieses Jahr ein "X"-Board, welches es
dann hoffentlich auch hier im Shop geben wird.

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin seinerzeit mit LPC2106 eingestiegen (mit Olimex Board, aus dem
Shop), dann LPC2129 (ebenfalls Olimex) und LPC2138 (mit Keil
MCB-Board), bisher noch keinen Kontakt mit LPC214x (also "USB-LPC").
Habe inzwischen auch ein AT91SAM7-Board hier (das von Atmel/IAR, ist
aehnlich dem vom Olimex aber z.B. ohne SD-Slot). Die
Controller-Familien sind schon unterschiedlich (z.B UART, SPI, SSP,
SSC, PDC), auch wenn es beide "im Kern" ARM7TDMI sind. Subjektiv
finde ich die LPC2000s noch etwas einfacher zu programmieren, was aber
daran liegen mag, dass ich mit dem SAM7 noch nicht viel gemacht habe.
Vielleicht erstmal die Datenblatter, Erratas und verfuegbaren
Beispielcodes im Hinblick auf die geplante Anwendung anschauen und
darauf einstellen, dass das auf den ARM7-Controllern eines Herstellers
gelernte, v.a. im Bezug auf integrierte Module/"Cells" um den
ARM-Kern, nur begrenzt auf ARM7-Controller anderer Hesteller
übertragbar ist.

Martin Thomas

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls die Geschwindigkeit der Code Ausfuehrung aus dem Flash eine Rolle
spielt, dann ist der SAM7 mit Abstand langsamer.

@ Martin Vielleicht koennte mal noch ein unabhaengiger Vertreter hier
was dazu sagen, wenn im schnellsten Mode, das ist der ARM Mode bei
beiden SAM7S und LPC2148 der Code aus dem Flash ausgefuehrt wird. Die
Messungen, die wir gemacht haben waren ueber 30% Unterschied bei SAM7,
55 MHz und LPC2148, 60 MHz.

Halte mich mit anderen Kommentaren etwas zurueck, da ich etwas biased
bin.

Gruss, Robert

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, ich habe ein wenig gemessen (SD-CARD, SPI-Mode, FAT-Library,
LPC2138, AT91SAM7S64), moechte aber z.Zt. nichts detailliertes darueber
schreiben, da noch gilt: "wer einmal misst misst Mist". Die Methoden
zur Einstellung des Systems (PLL, WS etc.) beim AT91SAM7S kenne ich
noch nicht alle gut genug und sowohl bei LPC2k als auch bei AT91SAM
gibt es noch Optimierungsmoeglichkeiten an der SPI-Schnittstelle.
Benchmarkergebnisse sind beliebte Themen fuer ueberlange und
kontroverse Threads, daher hier jetzt keine halbgaren Messwerte von
mir.

ARM-Mode und Programmcode aus Flash - scheinbar noch die Domäne der
LPC2000s bzw. deren "MAMs" - ist ja nicht alles, auch wenn die
Ausfuehrungsgeschwindigkeit fuer die Anwendung wichtig ist. Mglw. sind
die Ergebnisse des Vergleichs bei thumb-interwork mit Code im RAM etwas
anders. Die weniger zeitkritischen Programmteilen in thumb-mode aus dem
Flashspeicher (also "speicherplatzoptimiert") und die zeitkritischen
Routinen in ARM-mode aus dem RAM-Speicher
("geschwindigkeitsoptimiert"). Dies duerfte fuer "reale Projekte"
keine unueblich Vorgehensweise sein.

Robert: Sind die Philips-eigenen Messungen irgendwo dokumentiert?
Wurden "Standard-Benchmarks" genutzt? Welche? Wo sind die Quellcodes
zu finden? Welche(r) Compiler? Welche Compileroptionen?
Controller-Setups? Gehe davon aus, dass diese fuer LPC bestmoeglich
eingstellt sind. Kann mich daran versuchen, die beste Einstellung fuer
den SAM7 zu erstellen und halbwegs "unbiased" Vergleichswerte zu
ermitteln.

Gruss,
Martin Thomas

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde es gibt andere Prioritäten als die Performance. Bei den SAM7
und LPC2000 bewegt man sich ja am unteren Rand der 32-Bitter, und wer
es eilig hat - es ist genug Luft nach oben vorhanden.

Interessanter finde ich die I/O-Komponenten. So kann ich mich
beispielsweise nur begrenzt mit dem 16C550 anfreunden, der Philips als
UART dient. Ich verstehe ja wieso, das Teil steckte fix und fertig in
der Schublade und musste nur reingeklebt werden. Aber im µC-Sektor mit
der dort recht häufigen RS485-Kommunikation eine UART einzubauen, die
nur mit üblen Verrenkungen zu 9-Bit Übertragung in der Lage ist...

Auch manche RTCs sind etwas zweifelhaft. Philips erster Generation
fehlt mindestens der 32KHz Takt, was ihr etwas den Sinn nimmt. Atmel
wiederum hat mit einer RTC, die ihren Takt aus einem RC-Oszillator
nimmt, wahrlich den Vogel abgeschossen (so jedenfalls lese ich deren
Datasheet, erklär mir bitte jemand dass das so nicht stimmt).

Philips nun wiederum hat zwar 32 Bit breite Timer, aber das ist erstens
Overkill, zweitens bleiben, wenn man einen davon für's RTOS braucht,
bei der älteren Generation mit grad mal 2 Timern nicht mehr viel
übrig.

Dass der ADC der älteren Versionen ziemlich dämlich konstruiert ist,
ist Philips gottlob auch aufgefallen.

Und wenn man bei den Philips-LPCs mit Open-Drain I/O zu tun hat, merkt
man, dass Set/Clr-Register für die Richtungssteuerung der Ports auch
ganz praktisch wären.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K.
"Ich finde es gibt andere Prioritäten als die Performance. Bei den
SAM7 und LPC2000 bewegt man sich ja am unteren Rand der 32-Bitter, und
wer es eilig hat - es ist genug Luft nach oben vorhanden."
Geb ich dir vollstaendig recht. Viele wollen dennoch fuer ihr Geld die
beste Performance haben, so wie viele Kaeufer ein Auto auf Grund der
Motorisierung waehlen und andere wieder auf Grund der Farbe ;-)

Als ein weiterer Vergleich, zaehlt mal die verfuegbaren I/O pins bei
beiden und sagt mir dann welcher mehr hat / flexibler ist.

16C550 mag ich auch nur bedingt aber viele Anwender wollen einfach mit
einem PC kommunizieren und da ist er optimal.

Autor: struberg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>dafür sind die Atmel nicht so fehlerbehaftet
Nur weil sie weniger Erratas veröffentlichen heißt das noch lange nicht
das sie weniger fehlerhaft sind (zumindest die aktuellen Versionen).
Vergleiche Linux und Windows. Bei Linux gibts auch um 30x mehr
patches...

> Philips erster Generation fehlt mindestens der 32KHz Takt
Haben die nicht sogar die Möglichkeit einen eigenen 32k Uhrenquarz
zusätzlich zum XTAL anzuhängen? Und die funktioiert auch im powerdown
Modus.

> grad mal 2 Timern
Ich zähle 5 Timer (2131):
T0, T1, PWM, RTC, WDT
Viele vergessen, daß zB der PWM oder der WDT beim Philips auch als
universelle Timer verwendet werden können.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
210x,212x jedenfalls haben keine Möglichkeit, die RTC separat zu
versorgen, nicht mit Takt, nicht mit Strom. 213x ist etwas anderes. Wär
ja schon was gewonnen, wenn der Takt der RTC wenigstens direkt vom Quarz
käme, nicht über die PLL.

Weder RTC noch WDT sind als Systemtimer irgendwie nutzbar. Der 32KHz
Zähler der RTC lässt sich allerdings für Delays nutzen. PWM hatte
bisher ich mangels PWM-Anwendung komplett ignoriert, danke für den
Tip.

Wenn man solche Böcke schiesst wie Philips, dann muss man sie auch
veröffentlichen. Das ist ok. Wenn Atmel ebensolche Böcke geschossen
haben sollte, aber geheim hält, können sie gleich wieder einpacken. Es
stört mich eher, das Philips "vergessen" hat, auf die Betaversion die
Releaseversion folgen zu lassen. Erst als jetzt mit Atmel ernst zu
nehmende Konkurrenz droht, kommt etwas Leben in die Bude.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Wenn der Eindruck aufkommen sollte, dass ich hier bloss über Philips
herziehe: Das liegt einfach daran, dass ich mit den LPCs näher befasst
habe als mit den Atmels.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin z.B. von den 32-Bit-Timer der LPC-Controller begeistert.
Endlich kann man mal ordentlich messen, ohne dass man ständig
irgendwelche Variablen hochzählen muss, nur weil der Timer immer wieder
überläuft.
Oder man muss ihn herunterteilen, was die Messgenauigkeit beeinflusst.
Ich finde das Atmel auch mal mit seinen lächerlichen 8-Bit Timern
einpacken könnte. Die Arbeitsfrequenz wird immer höher und die Timer
bleiben von der Bit-Weite immer gleich.

Ich selbst bin von der UART der LPCs auch nicht so begeistert. Aber
wenn die Treiber mal geschrieben wurden, stört das nicht mehr, so finde
ich. Der Vorteil aber dabei ist, dass wenn diese Architektur der UART
immer beibehalten wird, man die Treiber für einen neueren Prozessor
nicht immer neu schreiben muss. Und das ist echt toll. So gesehen ist
dann die Architektur der UART nicht mehr sor wichtig, da ich bei einem
anderen Prozessor nicht ständig das Rad wieder neu erfinden muss.

Bei den AVRs z.B. sind bei der UART der neueren Typen immer wieder neue
Schnick-Schnack-Funktionen dabei, die man meist nicht braucht und die
immer wieder die Kompatiblität vernichten. Dann gibt es wieder neue
Register oder Register mit anderen Namen und anderen Funktionalitäten.
Das finde ich wiederum bescheuert.

Tschüss, Martin

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin, Du musst Dich schon entscheiden.
Entweder ist die Hardware Wurst, dann hat man seine Timerroutine, die
das automatisch macht, als "Treiber" sowieso vorliegen. Dann jucken
auch 16 oder 8 Bit Timer nicht.
Oder es ist nicht Wurst, dann ist der UART der LPCs genauso ätzend.

Im Übrigen ist der UART ja nun nicht ein so komplexes Stück Hardware,
als daß man es nicht in spätestens ein paar Stunden im Griff hätte...

Ich halte es da aber mit A.K.:
Es ist gut, daß Philips jetzt durch Atmel Dampf unter den Hintern
bekommt.
Sonst müsste man sich noch ewig mit den Fehlern rumplacken, da die das
ja sonst nicht nötig hätten (Ja, auch wir nutzen Philips-Controller und
werden wohl dabei bleiben, wenn die Ankündigungen wahr werden).

Autor: Klaus Zietlow (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die ATMEL Prozessoren haben DMA fuer alle seriellen Schnittstellen. Ich
hab nichts dergleichen bei den Philipsteilen gefunden, (bitte
korrigiert mich hier). Datenuebertragung ist daher erheblich
effizienter selbst wenn man sein Program aus dem nur halb so schnellen
FLASH laufen laesst.
Ein Interrupt pro Block statt pro Wort.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus,

die DMA von Atmel ist definitiv besser als keine DMA von Philips aber
der Vorteil haelt sich in Grenzen. Die schnellen seriellen Peripherals
des LPC2148 (SSP und evtl. UART) haben FIFOs. Damit ist die Interrupt
Belastung ebenfalls um einen Faktor bis zu 16 reduziert.  Also kein
Interrupt pro Wort sondern ein Interrupt pro FIFO full.
Datenuebertragung erfolgt haeufig mit einen <EOT> End of Transmition
Zeichen.  Falls das der Fall ist, hilft die Atmel DMA wenig, denn dann
muss man jedes Zeichen im Interrupt anschauen, der DMA Controller
vergleicht nur auf die Anzahl der Zeichen. Wird also eine fest
Protokollaenge vereinbart ist die DMA gut, bei variabler Laenge,
ausgepsrochen maessig.
Witzigerweisse ist bei der Implementierung des USB die Sache gerade
umgekehrt, Philips spezielle DMA, Atmel, schau mal selbst rein.

Noch ein kleines Rechenexample. Uebertragung der SSP 16-bit Woerter bei
30 Mbit/s ergibt ca. 2 datenworte pro usec. Der 2148 kann 8 Datenworte
ins Fifo uebernehmen, also bekommt er ca alle 4 usec einen Interrupt.
Nehmen wir mal an der Interrupt wuerde 30 Befehle dauern, dann ist das
ca. 0.5 usec. Bleiben immer noch 7/8 der CPU Performance.

Zugegeben, wenn alle seriellen Schnittstellen mit maximaler
Geschwindigkeit Daten liefern, dann sind wahrscheinlich beide
Mircocontroller ueberfordert.

Noch ein kleiner Tip, mal den ADC anschauen. Der Philips ADC hat
Ergebnisregister fuer jeden Kanal. Da gibt es die Moeglichkeit
verschiedene Sensoren einfach immer abzufragen und bei Bedarf das
Ergebnis einfach zu lesen, es ist nicht aelter als ca. 20 usec.

Gruss, Robert

Autor: gerhardf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo zusammen,
ein paar anmerkungen zu roberts beitrag.

betreffend atmel uart:
der atmel pdc hilft bei uart buffering sehr wohl. der uart hat nämlich
eine ende-kennung (zeitgesteuert), welche einen interrupt auslösen
kann.

betreffend des ssp rechen-exempels:
mithilfe der pdc wird beim atmel für die komplette übertragung nur ein
interrupt ausgelöst (nämlich am schluß). desweiteren könnnem mehrere
spi-slaves abgefragt werden ohne das die cpu eingreifen muß. die anzahl
der wrote und deren breite ist einstellbar.

zum adc:
mithilfe der pdc ist das mehrmalige auslesen eine oder mehrerer
adc-kanäle ohne das die cpu eingrifen muß möglich.

p.s.: ich bin kein atmel-mitarbeiter!!

gruss
gerhard

Autor: Geri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo gerhard

Vielen Dank für den Link. Im verlinken Thread habe ich einige
interessante Informationen gefunden. Mein Schluss ist, dass jeder der
Controller seine Stärken und Schwächen hat. Auch die Fangemeinde teilt
sich meiner Meinung nach etwa zur Hälfte -die verfügbare Dokumentation
und die Beispiele halten sich nach meinem Wissen die Waage.

fulgo: eigentlich egal für welches Board man sich für den Einstieg
entscheidet.

Freundliche Grüsse

Geri

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.