Hallo,
hat wer von euch ein/mehrere Argumente, warum man bei einem ATmega mit
zusätzlichen Ethernetcontroller bleiben soll, anstatt einen ARM mit
integrierten Ethernetcontroller??
-Preislich habe ich doch für die Entwicklung (so wie ich es sehe) keine
spekatkulären Unterschiede
-Entwicklungsumgebung gibt es doch auf für beide kostenlos
-Platine muss ich auch fertigen lassen
Ist es soviel komplizierter mit einem ARM zu arbeiten??
Gruß und DANKE
Es ist etwas komplizierter. Wenn du mal mit Interrupts programmierst,
dann wirst du das merken. Allerdings ist es nicht so kompliziert, dass
man deshalb keinen ARM nehmen sollte.
Ich würde das von anderen Gesichtspunkten abhängig machen:
- Schonmal mit ARM gearbeitet, oder ist das Neuland? (Ich gehe davon
aus, dass mit AVRs bereits gearbeitet wurde)
- Wird bei späteren Projekten der Einsatz eines ARM erwartet?
Falls nicht, würde ich bei dem Prozessor bleiben, den ich kenne. Das
Einarbeiten in ein neues System braucht schon seine Zeit.
Rechne mal aus, was einige Monate Entwicklungszeit kosten, dann kennst
du die Umstiegskosten. Wenn du dann 10000 Stück von baust, ist das
wieder irrelevant. Wenn du genügend freie Zeit und Lust darauf hast,
ebenso.
Ein externer Ethernetcontroller ist leichter erhältlich als das externe
Media-Interface für einen integrierten Ethernetcontroller. Die Dinger
sind ja leider nicht komplett integriert.
ARM braucht zwar etwas Eingewöhnung, WinAVR ist ziemlich plug-and-play,
WinARM nicht so ganz. Aber grad bei der Komplexitätsklasse von
Ethernet/TCPIP dürfte sich das letztlich lohnen. Egal ob nun mit
integriertem oder externem Ethernet.
Wirklich angenehm wäre allerdings ein 32bitter mit big-endian byte order
passend zur network byte order. Die ARM Cores können zwar im Prinzip
beides, sind aber in den gängigen Implementierungen auf little-endian
festgelegt.
Es erstaunt mich, dass preislich wenig Unterschiede sind. Wenn ich mal
einen ATMega64 nehm mit 64k Flash und 4k ;-) RAM, dann bezahlt man doch
so um die 6 Euro Einzelstueck bei Digikey.
Fuer einen LPC2364 mit 128k Flash und verteilten 34k RAM bezahlt man
weniger als 7 Euro ebenfalls in Einzelstueck.
Wenn jetzt noch der externe Ethernet Controller dazukommt, da wuerde ich
schon eindeutig einen Preisnachteil bei der low-performance Loesung
sehen.
Natuerlich bin ich etwas voreingenommen aber fuer ein groesseres Projekt
waere die Wahl extrem einfach.
Warum evtl. trotzdem AVR nehmen?
1. Time to market! Nicht dass die Entwicklung mit einem ARM langsamer
waere fuer jemanden, der beide Architekturen und die Tools kennt aber
wenn Du nur die AVRs kennst, dann dauert ARM (natuerlich) laenger.
2. Die Loesung mit AVR koennte schlicht und ergreifend gut genug sein
und wird nie erweitert.
3. Du baust nur ganz wenige Dinger davon, denn dann ist Deine Zeit der
massgebende Faktor fuer die Kosten, nicht die Bauteilkosten oder die
Performance.
Warum ARM nehmen?
1. Kannst was fuer Deine eigene Zukunft tun und falls das Produkt
erweiterbar sein soll, natuerlich auch fuer das Produkt.
2. Es gibt die Wahl zwischen min 3 verschiedenen Anbietern die schoene
Loesungen dafuer bieten, einer davon macht auch den AVR.
Gruss, Robert
Hi,
irgendwie scheint mir, das hier das Pferd falsch herum aufgezäumt wird!
Über was rede ich: ein Hobby-Projekt? (das ist nicht abwertend gemeint!)
Dann ist es eigentlich schnurz egal! Kosten (echte Gesamtkosten und
nicht nur Beschaffungskosten!) spielen nur am Rande eine Rolle. Und die
Rechnung von Robert, die zwischen ATMega und NGC-ARM nur einen geringen
Preisunterschied sieht, bestätigt das nur. Letztlich liegt es am Gusto
und Können des Einzelnen. Der eine fühlt sich bei ATMega wohl, der
andere bei ARM.
Ganz anders sieht es im professionellen Umfeld aus. Und da ist so eine
"pauschale" Entscheidung ATMega mit ext. Controller oder ARM mit
integriertem Controller nur unter "ferner liefen". Vorhandene
Code-Basis, Preise bei Stückzahlen, Zuverlässigkeit bei gegebenen
Umgebungsbedingungen, Lieferbarkeit in der Produktlebensdauer und ev.
darüber hinaus (Stichwort Abkündigung etc.), Wartbarkeit von sowohl
Software als auch Hardware etc. sind weitaus wichtigere Fragen - ebend
weil dahinter u.U. erhebliche Kosten stehen. Pauschal ist da nichts zu
entscheiden!
Schönen Tag noch,
Thomas
Axel Rühl wrote:
> wie siehts mit dem Stromverbrauch aus?> Braucht so ein (zB.) LPC2103 nicht um Längen mehr Strom, als ein> Mega128?
Ja, da ist der LPC erheblich im Nachteil durch den Verbrauch der 2 eng
tolerierten Spannungsregler.
Für Batteriebetrieb also nicht zu empfehlen.
Einen AVR kannst Du dagegen direkt an 1,8V ... 5V betreiben, ergibt
exakt 0µA für die Spannungsregler.
Deshalb gibts ja auch die Möglichkeit nen Uhrenquarz direkt
anzuschließen.
Peter
> Nachteil durch den Verbrauch der 2 eng tolerierten Spannungsregler.
Es gibt auch etliche LPC's die keine externe 1.8V Regelung brauchen,
sondern diese intern aus der 3.3V erzeugen. zB 213x und 214x.
Wobei gerade das Vorhandensein der expliziten 1.8V Leitung FÜR
Batteriebetriebene Systeme spricht. Die LPC mit 2 Anschlüssen sind so
designed, daß mit den 1.8V die clock und der Rechenkern aktiv sein
können, während die ganze Periperie im powerdown Modus ist. Da kommst
dann in Summe mit einigen µA aus.
Es muß halt im Schaltungsdesign darauf Rücksicht genommen werden, bei
einer 'normalen' Beschaltung hast du natürlich Recht.
Warum ist bei den ARM eigentlich immer von den LPC die Rede? Ich finde
die AT91SAM7S von Atmel deutlich besser.
Ich habe zb erfahren das die IO von den LPC ziemlich langsam sein
sollen, sogar langsamer als die eines AVR (Advantage AVR). Die AT91 sind
mit 55MHz zwar etwas langsamer getaktet als die LPC, aber durch eine
bessere Architektur und schnellere IO egalisieren die den Nachtteil fast
auf 0, je nachdem was man machen will.
Außerdem sind die nicht so Buggy wie die ersten LPC und brauchen auch
nur 3,3V
...mit gefallen bei den SAMs besonders die vielen PDCs (DMAs) sehr gut!
Damit kann man ARM-Core und Software sehr gut von der Peripherie
entlasten und bekommt nicht so viele Interrupts (z.B. erst wenn ein
String via UART gesendet wurde und nicht nach jedem Zeichen).
@ Markus,
"hab zB erfahren..." solltest Deine Informationsquellen mal wechseln ;-)
die I/Os der ersten LPCs war relativ langsam, ist auch ne berechtigte
Frage wer bit mit 30 MHz toggeln moechte und dazu einen 32-bit Micro
nimmt. Naja, wie dem auch sei, der LPC214x und z.B. der 2103 koennen
schneller toggeln als irgendein anderer ARM7 weil die Ports nicht mehr
am APB haengen wie frueher und auch nicht am AHB wie bei vielen
Mitbewerbern sonder am sogenannten Local Bus, ohne jegliche
Verzoegerung. Das ganze nennt sich Fast I/O und das hat in der Form
sonst keiner. Ist seit fast 2 Jahren am Markt aber Geruechte wie LPCs
haben langsame I/O halten sich natuerlich hartnaeckig.
Im uebrigen, was ist denn die bessere Architektur? Beides sind ARM7.
Jetzt geht es drum welcher die Programmdaten schneller zur Verfuegung
stellen kann. Ein kleiner Tip, das ist nicht der 32-bit breite Bus zum
Flash sondern der 128-bit breite. Es gibt ohne Zweifel Gruende fuer
jeden der beiden Typen aber Deine Gruende sind schlicht und
ergreifend....
Zum Thema Power. Wenn ich einen Ethernet Controller im Spiel hab, dann
sind Werte fuer 1 MHz oder aehnliche Frequenzen nicht mehr von
Bedeutung. Nehmen wir mal an ein MEGA wuerde mit 16 MHz laufen, das
entspricht dem Datendurchsatz von einem ARM7 bei 5-10 MHz. Da ist nicht
viel Unterschied in Power. Ausserdem sind nur wenige batteriebetriebene
Ethernet Anwendungen auf dem Markt.
Nichts fuer ungut, Robert
Seit dem 2106 hab ich mich nicht mehr ernsthaft mit den LPC befasst weil
der so bescheiden war (lahme IO, 2 Spannungen, lange Errata Liste).
Sowas prägt halt längerfristig. Mag sein das die mittlerweile ja besser
sind