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
Auch 'ne Frage: wie siehts mit dem Stromverbrauch aus? Braucht so ein (zB.) LPC2103 nicht um Längen mehr Strom, als ein Mega128?
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
Der Vollständigkeithalber: Texas Instruments bieten auch einige ARM7 an (TMS470)
...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
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.