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
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.
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
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
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
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.
@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.
>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.
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.
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.
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
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).
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.
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
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
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
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.