Wird ARM der naechste "Volksprozessor"?

Hallo Leute,

Ihr seid in Europa naeher am Geschehen, da in Sachen ARM vieles von Philips kommt. ARM war bisher fuer viele Entwicklungen zu teuer, aber nun gibt es ja LPC2101 bis 2103 fuer um die $2 in Stueckzahlen. Mit 32 Bits rechnen zu koennen waere natuerlich das Sahnehaeubchen.

Was denkt der erlauchte Kreis hier? Wird ARM die naechste 8051er Generation?

Ist der Support bei Philips akzeptabel?

Gruesse, Joerg

formatting link

Reply to
Joerg
Loading thread data ...

Also eigentlich waer es mir total egal welcher Prozessor sich mal etwas verbreitet. Es waer nur schoen wenn es ueberhaubt mal einen Prozessor geben wuerde den man 20Jahre unveraendert von mehreren Herstellern kaufen kann.

Aber glaubst du wirklich daran?

Olaf

Reply to
Olaf Kaluza

Scheint irgendwie so. Überall wachsen ARMe. Atmel, Oki, Samsung, Intel, TI ... Selbst Analog baut schon ARM Kerne in ADDA Wandler mit ein ;-)

Grüsse Robert

Reply to
Robert Rottmerhusen

Hallo Olaf,

Beim 8051 war beziehungsweise ist es so. Das aelteste Design von mir, dass mit 8051 arbeitet, ging Anfang der 90er in Produktion und laeuft immer noch in Serienfertigung. Sollte der uC abgekuendigt werden, gaebe es einige alternative Versionen. Das war damals einer der Gruende fuer den Einsatz der 8051 Architektur.

Ok, das sind erst circa 15 Jahre, aber mich wuerde es nicht wundern, wenn dieses Geraet auch nach 20 Jahren noch vom Band liefe. Muss es sogar, denn mit dem Ding wird ziemlich rauh umgegangen und es gibt laufenden Ersatzbedarf. Hin und wieder wird schon mal eins zermalmt.

Gruesse, Joerg

formatting link

Reply to
Joerg

Wurde unter genau dieser Titelzeile langatmigst/kontrovers vor 12 Monaten in englischsprachigen newsgroups "diskutiert". Abgesehen davon, daß der 8051 stückzahlenmässig deutlich hinter 68HCxx und PICs liegt ( 8051 er ist nur langlebig, aber heute nichtmehr übermässig populär ), ist es die Pseudodiskussion der frühen 90er "in-jedem-Toaster-ist- bald-ein-x86". Dem war nicht so. ARM ist ein Speicherfresser der von externen DRAMs träumt und damit kein besonders guter embedded RISC.

Die ursprüngliche fab von ARM war glaube ich VLSI-Technology die von Philips geschluckt wurden. Dürften sich also gut mit der CPU auskennen. Wenn man versuchen wollte hierzulande bei ebay lose ICs zu kaufen findet man eher ARMs von Atmel. Wenn "Volksprozessor" heissen soll "Hobbyprozessor" für die- jenigen denen der AVR zu öde geworden ist ( Uiiii da läuft ja kein Linux drauf ... ) dann könnte das eher der Realität entsprechen.

MfG JRD

Reply to
Rafael Deliano

Hallo Joerg,

Ich denke schon das ARM sich einen guten Markanteil erobern kann. Es scheint zur Zeit eine regelrechte Artenexplosion zu geben. Auch die Tools sind schon da und auch weitest gehendst ausgereift, der GCC kann seit vielen Jahren mit ARM umgehen.

ARM scheint den ARM7-Core zur Zeit im Sonderangebot (Räumungsverkauf um Platz für ARM9 und ARM11) zu haben so das die Lizenzgebühren offensichtlich so niedrig sind das man daraus 2$-Chips machen kann. Das Segment der ganz kleinen (wie ATtiny oder PIC12) wird ARM wohl nicht allzu bald erobern aber überall dort wo etwas mehr RAM, viele IO-Pins oder einfach nur CPU-Power gefragt sind hat ARM eine gut Chance.

Ein weiterer Vorteil ist der Upgrade-Path nach oben (ARM9 und ARM11). Der Code läuft unverändert (die neueren Cores sind abwärtskompatibel) und der GCC kann die auch schon. Wenn der kleine ARM7-µC mit 50MHz nicht mehr reicht dann tuts bestimmt ein ARM11 mit 500MHz (der ist mehr als 10 mal so schnell).

In Projekten wo sich das lohnt ist der ARM auf jeden Fall einen Blick wert. Aber auch der Adressraum ist 32Bit breit und das bringt einfach viele Vorzüge, wenn ich mich an das Banking auf den PIC zurück erinnere dann ist der ARM eine echte Erleuchtung.

Mach dort auf keinen Fall den Fehler auf einen Hersteller einzugewöhnen. Der CPU-Kern ist bei allen gleich nur die Peripherie ist unterschiedlich, so das es ungeahnt leicht sein könnte sich für jedes neue Projekt den passenden µC, von verschiedenen Herstellern, rauszusuchen. Ansonsten gibts einige Foren im Netz, bei Yahoo sogar eins speziell für die LPC2xxx-Family. Die Fangemeinde wächst. Aber wie andere schon schrieben, die Auswahl ist groß.

Ich persönlich werde mir die LPC2xxx-Family von Philips und die AT91SAM7xxx-Family von Atmel als Arbeitspferd holen.

Grüße Erik

Reply to
Erik G.

Die $2 für die LPCs ist die logische Antwort auf das Erscheinen der SAM7-Familie von Atmel. Die scheinen die ARM7-Preise ja richtig gemein zu drücken.

Ich denke schon, dass der ARM7 der neue "VolksMC" wird. Es gibt gute und kostenlose Entwicklungswerkzeuge und MCs mit dem ARM7TDMI Kern gibt es ja schon seit Jahren von allen möglichen Herstellern.

Gerade die SAM7 in der kleinen Gehäusebauform (der kleinste ist TQFP48) und der supergenialen Peripherie werden sich durchsetzen. Atmel hat's halt drauf :-)

--
Mfg
Thomas Pototschnig
 Click to see the full signature
Reply to
Thomas Pototschnig

Und die schnellen 8051 Varianten von SiliconLabs (25-100MIPS) und von Winbond (10 MIPS) sind zur Zeit auch recht beliebt für Neuentwicklungen.

Michael

Reply to
Michael Koch

Nicht ganz so de facto standard wie der 8051 mit zahlreichen Second Sources (Pin und Funktionskompatibel), aber ich sehe diese Vorteile:

- Kern ist bei allen gleich -> Toolchain bei der Entwicklung ist dann ueberall einsetzbar, dito Know-How.

- Open-Source OSse (ecos) verfuegbar.

- Leistungsfaehige Peripherie On-Chip, z.B. 100 MBit Ethernet, CAN, USB. Dabei ist dann nur noch ein Transceiver zusaetzlich notwendig. Und die Rechenleistung ist ausreichend, um Daten in Wirespeed zu verarbeiten und uebertragen.

Ich sehe den Einsatz fuer mich hauptsaechlich dort, wo bisher noch ein Controller mit externem DRAM + Flash notwendig war (evtl. auch noch BGA), da reicht jetzt einer mit internem Flash und SRAM, im PQFP-Gehaeuse mit jeder Menge eingesparter externer Peripherie.

K.a. ich hatte mit denen noch nicht zu tun, eine Supportanfrage bei Atmel wegen dem On-Chip Ethernet-Controller dauerte eine Woche, wurde aber gut beantwortet, dabei ist das Produkt noch nicht am Markt.

cu,

Steffen

Reply to
Steffen Koepf

Hallo,

Speicherschoner sind richtige 32Bit-CPUs noch nie gewesen. Wer glaubt er könne sein Program vom ATmega32 auf nen LPC2103 portieren (beide 32kByte Flash) der irrt sich da gewaltig, die 32Bit fordern gnadenlos ihren Tribut. In dieser Hinsicht frage ich mich auch welches Zielsegment Philips mit den neuen LPC2101/LPC2102/LPC2103 (8k/16k/32k Flash) ansteuert. Projekte die bisher mit einem ATmega8 gut ausgekommen sind werden wohl auch weiterhin mit der Atmel-CPU besser fahren, auch ich werde die kleinen AVRs nicht wegschmeißen. Bei Projekten wo der ATmega128 schon eng wird hat Philips tatsächlich interessante Alternativen parat, aber eben nicht die LPC210x. Aber auch Atmel scheint diesen Zug nicht verpassen zu wollen, wobei ich dort aber den Eindruck habe das die alt bekannte AVR-Peripherie einfach übernommen wurde. So hat Philips nur 32Bit breite Timer wogen bei der AT91SAM7xxx-Family von Atmel noch vieles im alten 16 (oder gar 8) Bit-Gewand daher kommt. Auch die UARTs machen bei Philips einen besseren Eindruck (echte 16C550 mit je 2 echten FIFOs). Dafür hat Atmel mit der Peripherie einfach etwas mehr Erfahrung was einem beim Vergleich der Errarter-Sheets deutlich auffällt.

Für die Hobbyleute soll sogar ein LPC2103 in PLCC44 rauskommen, na das kann was werden. Hoffentlich bringt Philips auch den Support für die X-Tausend "5 Stück pro Jahr"-Bastler zu stande.

Grüße Erik

Reply to
Erik G.

on?

Hallo Joerg,

die Frage eignet sich wieder f=FCr einen Glaubenskrieg =E0 la "welcher Texteditor ist der beste?". Deshalb erstmal ein Disclaimer: hier kommt meine ganz pers=F6nliche und subjektive Meinung (und die m=FCsste vielleicht sogar hier und da revidiert werden, weil ich seit ungef=E4hr

8 Jahren fast nichts mehr mit dem ARM7 gemacht habe).

Es gibt verschiedene ARM Architekturen, aber ich glaube jeder bezieht sich hier auf den ARM7, genauer den ARM7TDMI. Es gibt m.E. so einiges an dieser Architektur zu kritisieren(*), genau so wie beim 8051. Insofern ist der Vergleich ziemlich treffend. Aber auch bei der vorherrschenden PC-Architektur hat sich ja schon vor langer Zeit gezeigt, da=DF sich nicht unbedingt das beste durchsetzt. Die meisten Architektur-Schwachpunkte brauchen denjenigen, der in einer h=F6heren Programmiersprache entwickelt, nicht zu interessieren (das war beim

8051 deutlich anders. Mein letztes Design damit habe ich 1988 gemacht und weil man ihn in Assembler programmieren musste, habe ich mir damals geschworen, diese verkorkste Architektur nie wieder anzufassen).

Was hat der ARM7 auf der Habenseite?

- breite und preisg=FCnstige Verf=FCgbarkeit von Bauteilen

- preiswerte und gute Entwicklungstools

- Verf=FCgbarkeit von Softwarebibliotheken insbesondere f=FCr alles was Telekommunikation hei=DFt

- moderate Rechenleistung

- verf=FCgbar als Core f=FCr eigene ASICs, sogar f=FCr FPGAs

Daraus ergibt sich, da=DF er f=FCr "Allerweltsaufgaben" sehr gut geeignet ist. F=FCr h=F6here Anforderungen wird man dann auf andere Architekturen, z=2EB. MIPS Risc, PPC, V850 oder auch ARM9/10/11 zur=FCckgreifen, denn der ARM7 kann beileibe nicht alle Aufgaben erschlagen. Warum es aber immer noch Leute gibt, die neue Designs mit 16-Bit Architekturen entwickeln, ist mir nicht wirklich klar (ok, existierender Code, Tools u.s.w). Aber es ist wirklich an der Zeit, diese alten Z=F6pfe abzuschneiden. An den Kosten kann es nicht liegen, denn 32-bitter sind heute oft g=FCnstiger als 16-bitter. Manchmal habe ich das Gef=FChl, da=DF zumindest manche Designer Angst vor Neuem haben.

Also als abschlie=DFende Bewertung und Antwort auf Deine Frage: ja, er k=F6nnte es werden!

Michael

(*) Meine ganz subjektive Kritikpunkte am ARM7TDMI sind: Im ARM Mode nur 16 General Purpose Register und alle Befehle sind 32-bit breit. Das kostet Codesize. Im Thumb Mode (IIRC) nur 8 Register und ein ziemlich eingeschr=E4nkter Befehlssatz. Das st=E4ndige Umschalten zwischen den Modi kostet Codesize und Performance. Alle Interrupts werden auf nur zwei Interrupt-Vektoren umgeleitet und die CPU mu=DF dann feststellen, wo der Interrupt herkam (wahrscheinlich gibt es inzwischen vern=FCnftige Interrupt Controller, die diesen Nachteil beheben). Eine Multiplikation braucht bis zu vier Takte, weil der eingebaute Multiplizierer nur 8x32 bit kann. Damit scheidet der ARM7 f=FCr etwas anspruchsvollere Signalverarbeitung aus. Ein ganz nettes Feature ist die bedingte Ausf=FChrung von Befehlen. Ob das allerdings jemand nutzt, kann ich nicht sagen.

Reply to
Michael Krämer

Hallo,

ich äußere mal ein paar Anmerkungen zu Deiner Kritik am ARM7-Core :

dafür auch echte Drei-Operanden-Befehle welche so manchen MOV einsparen können.

Der Interruptcontroller der Philips LPC2xxx-Reihe behebt diesen Nachteil tatsächlich recht gut, sowas hab ich mir für x86 immer gewünscht. Andere Hersteller bieten ähnliches.

Die Compiler sollten das nutzen können. Ob sie das wirklich tun hab ich nicht geprüft. Auf aktuellen x86-CPUs nutze ich die Conditional-MOVs in Assembler recht gerne.

Grüße Erik

Reply to
Erik G.

Hallo Rafael,

Die hatte ich vorher ein wenig abgeklappert, aber ich wollte das mal aus europaeischer Sicht erfahren. Ihr seid in Sachen uC (und bei Autos...) harte Realisten.

Bisher war es so, dass in jedem Geraet, was ich gewartet oder repariert hatte, irgendeine Variante des 8051er Konzepts werkelte. Sogar in unserem Pelletofen ist einer, der da drin wohl hoechstens zu 5% ausgelastet ist.

So wie mal ein "Forschungsminister" vor etwa 30 Jahren sagte, in ein paar Jahren gaebe es keine Fernseher mit Bildroehre mehr. Da fiel mir echt nichts mehr ein.

Speicherfressen waere nicht so gut. Die kleinen ARM von Philips wie LPC2101 haben davon nicht mehr als kleinere uC.

Gruesse, Joerg

formatting link

Reply to
Joerg

Hallo Michael,

Das ist allerdings ein Nachteil. Die Multiplikation dauert allerdings auch bei R8C oder den teuren MSP430 Versionen mit HW Muliplier 5-8 Takte (fuer 16*16).

Einen Haken bei vielen Arm sehe ich in der Spannungsversorgung. Die wollen meist zwei Spannungen und das auch noch fein geregelt. R8C und dergleichen sind da besser, wenn man den Takt nicht voll ausnutzt. Sie duerfen mit 5V laufen und man kann einfach eine Batterie dran haengen, zum Beispiel drei AA Zellen. Bis hinunter zu etwa 3V ist noch alles in Butter. Aus diesem Grund koennte LPC fuer den gerade vorliegenden Fall das Design-in verlieren, denn das macht den Kostenvorteil zunichte.

Gruesse, Joerg

formatting link

Reply to
Joerg

"Michael Krämer" schrieb:

[Kritikpunkte am ARM7TDMI]

Gibt es eine brauchbare Hardwaredivision? Ein HC(S)12 kann z.B. 32/16 in 11 Takten.

Servus

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz

Hallo zusammen,

meine ersten Projekte basierten auf den 8051 Mikrocontrollern

80C535 und 517 von Siemens (später Infineon), das war 1990. Ein PIC-Projekt hatte ich auch schon mal, ich fand aber damals die Mikrocontroller nicht so schön zu programmieren (Register und Hardwarestack), ist nun auch schon 10 Jahre her. TIs MSP430 hatte ich auch schon mal "in der Hand", habe aber noch kein Projekt damit realisiert.

Seit etwa 8 Jahren programmiere ich die Atmel AVRs und bin mit denen sehr zufrieden. Allerdings bin ich schon einigemale bezüglich der Rechenleistung nahe an die Leistungsgrenzen der Mikrocontroller gestossen. Anfang des Jahres wollte ich mich dann mit ARM7 auseinandersetzen und legte mir ein AT91SAM7-IAR Starterkit zu, leider habe ich bis heute (auch aus Zeitgründen) noch keinen Einstieg in ARM7 geschafft. Die Software des Starterkits läuft nicht mehr, da sie zeitlich begrenzt war.

Ich denke, dass Atmel AT91SAM7xx oder Philips LPC210x eine gute Alternative zu den AVRs (ATMega) sind, wenn man mehr Rechenleistung benötigt.

Welche Entwicklungsumgebung nutzt ihr denn für ARM7- Mikrocontroller?

Hat jemand mit AT91SAM7xx Erfahrungen?

Gruss Stefan

Reply to
Stefan Raeder

Hallo Joerg,

Also wenn Du +/-10% als fein geregelt betrachtest dann ist das natürlich ein Problem, aber sonst dürfte ein normaler "3Pinner" dafür ausreichen. Und die IO-Spannung ist nicht ganz so kritisch wie im Datenblatt abgegeben, da sind nach unten bestimmt mehr als 10% Möglich.

Da sehe ich eher mit den gut 4,5V Anfangsspannung ein Problem. Gibts für sowas eigentlich einfache Spannungsbegrenzer die sich unterhalb ihrer Nennspannung völlig transparent verhalten, am besten als einzelnes Bauteil?

Das ist bei den LPC nicht anders, die IO-Spannung ist nur für die Output-Treiber zuständig. Alles andere hängt an der Corespannung und die dürfte so ein 3Pinner bestimmt bis etwa 2,5V Batteriespannung stabil halten.

Ich würde eher sagen das der LPC die Batterie zu schnell leer hat. So ein ARMling ist was anderes als die MSP430.

So wie ich das sehe brauchst Du 4 zusätzliche Bauteile um einen LPC an 3 AA-Zellen (von max. 4,5V bis min. ca. 3V) betreiben zu können. Einen Längsregler für die Core-Spannung und einen Diskreten Längsregler aus einen FET, Verarmungstyp bzw. selbstleitend (weis jetzt nicht genau wie das heist), eine Z-Diode und einen Wiederstand. Den Rest der Schaltung kannst Du problemlos direkt an die Batterie anschließen (falls die Teile das verkraften), zumindest hat der LPC damit keine Probleme. Die Frage ist nur wie sich der LPC mit einer zu kleinen IO-Spannung verhält. Er wird wohl nicht kaputt gehen und auch die gesamte innere Peripherie fängt nicht das Spinnen an (die hängt nämlich auch an der Core-Spannung), ich vermute mal das die Output-Treiber etwas langsamer werden und sich die Input-Schaltschwelle vielleicht etwas nach unten verschiebt. Mein Tipp "Versuch macht Kluch". Ich werde das auf jeden Fall mal probieren, interessiert mich nämlich auch.

Grüße Erik

Reply to
Erik G.

Hab die dann nicht immer noch die Pferdefüße von 8Bit und min.

4Taktzyklen pro Machinenzyklus?
--
Mfg
Thomas Pototschnig
 Click to see the full signature
Reply to
Thomas Pototschnig

Thumb ist das Eingeständnis von ARM daß Codedichte schlecht ist. Ist keine wirkliche Lösung sondern kaputte Krücke für C-Programmierer die Unmengen Assembler linear ausführen wollen/müssen. In FORTH würde Bytecode helfen: in den meisten Anwendungen existiert viel Code der nicht zeit- kritisch ist. Was zeitkritisch ist muß man dann eben in Assembler machen. Das ist der Vorteil an ARM genau wie bei x86 daß man sinnvoll in Assembler programmieren kann. Erstens weil die Architektur langlebig und zweitens weil sie für manuelle Programmierung geeignet ist. Auf die von der Industrie propagierte Alternative bei exotischen CPUs/DSPs: "Sie programmieren alles in C, den Rest macht unser Compiler" beissen nicht alle embedded Anwender an.

MfG JRD

Reply to
Rafael Deliano

Nein, nicht mal eine unbrauchbare. Der ARM7 hat =FCberhaupt keinen Divisionsbefehl. Damit (und mit den vorher genannten Einschr=E4nkungen) ist der ARM7 eigentlich nur eine halbe CPU. Daf=FCr wird er aber sozusagen auch zum halben Preis verschleudert und hat damit wieder seinen Markt. Wem's halt langt...

Nicht, da=DF mich jemand falsch versteht. Ich finde das ok, aber: you get what you pay for. Anders ausgedr=FCckt: there is no such thing as a free lunch. Wer einen HW-Dividierer, schnelle Multiplikation und mehr Register haben will, der wird halt auch etwas mehr Geld anlegen m=FCssen.

Michael

Reply to
Michael Krämer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.