Archiv verlassen und diese Seite im Standarddesign anzeigen : ARM Mikrocontroller
Hi,
verwendet hier jemand die ARM Mikrocontroller von Philips ?? ( LPC21xx )
http://shop.mikrocontroller.net/images/lpc-p2129.jpg
Es gibt ja bei http://shop.mikrocontroller.net/csc_article_details.php?saArticle[ID]=58 bzw. http://www.olimex.com/ ganz interessante Boards dazu. Hat mit denen schon mal jemand gearbeitet ??
Mich würde vor allem mal die Geschwindigkeit in bezug auf AVRs interessieren . Es ist klar das sie die AVRs bei 32-Bit Operationen um längen abhängen, aber wie wirkt sich das in einer realen Anwendung aus ?? Was ist da möglich ??
MfG Kjion
Bei uns war eine kleine "Einführungsaufgabe" im Embedded-Systems-Labor die Realisierung eines digitalen Filters einer Wave-Datei, die seriell übertragen wird, dann der File-Header entfernt, gefiltert (Bandpassfilter 4. Ordnung), Prüfsumme berechnen und Header anfügen, und dann wieder über die serielle rückschicken...
Das Musikstück hatte rund 14 MB (unser Board hatte völlig übertriebene 32MB SD-Ram) und die Filterung hat rund 35ms gedauert. Das Versenden über die serielle (trotz 460kBit) hat am meisten Zeit gebraucht...
Der kleine ARM7TDMI hatte als prädestiniertes Einsatzgebiet Netzwerk-Hubs und hatte daher ne Ethernet-Schnittstelle... Auf dem lieben Teilchen läuft u.a. ucLinux, eine Spezial-Mini-Distri, die speziell für kleinere Mikrocontroller ohne MMU ausgelegt sind.
ARMs machen definitiv Spass, alles was man braucht bekommt man kostenlos (GCC) und daher werd ich mir auf Dauer auch irgendwann mal ein kleines ARM-Board bauen. Allerdings fang ich mit einem fertigen Board nichts an, da ich mir dann für den jeweiligen Einsatzzweck ne richtiges Board mache und ich dadurch ne ganz andere Menge brauche...
Aber zum rumspielen und für erste Versuche sind die Olimex-Boards sicher keine falsche Wahl...
MfG
Stefan
Mal eine Noob-Frage:
Was berwirkt denn genau bewirken denn 32 Bit im Vergelich zu 8?
In normalen PCs sind doch auch "nur" 32 Bit oder? Nur in den neuen AMDs 64.
77 € ist für so ein hochleistungssystem doch ein ganz agreabler Preis oder?
MFG Moritz
Die 32-bit bringen dir rein gar keinen vorteil, wenn du keine 32-Bit-Operationen benötigst. Wenn du immer nur einzelne Bytes hin und her schaufelst, ist dein 8-biter genauso schnell wie dein 32-biter, aber sobald du mal zwei 16-Bit oder zwei 32-Bit-Zahlen addieren musst, sieht die Welt schon ganz anders aus.
Bei einem 32-Bit-System sind zwei Sachen relevant anders als bei einem 8-Bit-System:
1.) Die ALU ist (mind.) 32 Bit breit (ALU=Rechenwerk).
2.) Dein Instruktionsformat ist mind. 40 Bit oder noch breiter
Der erste Punkt bringt dir bei Rechenoperationen Geschwindigkeitsvorteile, der zweite Punkt lässt dich zum Beispiel größeren Speicher ansteuern (mehrere Gigabyte)...
Zusätzlich hast du bei den meisten 32-Bittern Technologieänderungen, bedeutet, dass die
1.) von Haus aus schneller sind, da andere Prozessarchitektur
2.) meist Pipelinig haben (nachfolgende Befehle werden noch während der eine abgearbeitet wird aus dem Speicher geholt und vorverarbeitet)
3.) Viele Schnittstellen schon als Hardware-Modul, die du auf einem 8-Bitter in Software machen musst.
Zum Thema AMD64: das ist vom System her nochmal ganz anders, weil das kein Mikrocontroller ist, sondern ein Mikroprozessor. Das bedeutet, dass kein Speicher und keine Peripherie enthalten sind - aber das ist ja grade die Sache, warum man einen ARM nehmen will...
Und 77€ ist für einen Mikrocontroller viel zuviel...
die dürfen normalerweise als Einzelstück nicht mehr wie 10 Euro kosten, wenn doch, dann müssen die schon sehr viel drinnen haben...
Danke für die Info!
77€ kostet das ganze Board!
Für einfache Roboteranwendungen, wie Sensoren auswerten lohnt sich das ganze dann vermutlich nicht, oder? Für mich erweckt das jetzt so den Eindruck, als wäre das System Sinnvoll, wenn man direkt einen kleinen PC ersetzen will.
MFG Moritz
Das ganze klingt aber trotzdem hoch interessant, leider bin ich noch nciht so ganz schlau geworden, hat der Prozessor denn ADCs? PWms hat er auf jeden fall.
MFG Moritz
Ja er hat nen A/D Converter auch zwei UART´s und I2C. Schaut mal auf www.mikrocontroller.net unter wiki. Dort ist viel erklärt über den ARM, z.B. gibts auch WinARM ähnlich wie WinAVR, und es gibt dort Beispielsources für das Olimex Board.
Gruß Muraad
Für einfache Roboteranwendungen, wie Sensoren auswerten lohnt sich das ganze dann vermutlich nicht, oder? Für mich erweckt das jetzt so den Eindruck, als wäre das System Sinnvoll, wenn man direkt einen kleinen PC ersetzen will.
;-) Genau darum geht es mir ja.
Ich bin im Moment noch die ganze Zeit am überlegen ob ich einen MiniPC ( wie Via Epia Boards ), einen fertigen embedet PC ( viel zu teuer ) oder eben etwas in der Art wie den ARM in meinen Roboter einbauen soll, da ich doch eine ganze Menge an Rechenleistung für die Lokalisierung usw. benötigen werde...
Für kleine Messaufgaben, Motorsteuerung usw. werden AVRs zum Einsatz kommen. ARMs machen da nicht wirklich Sinn ...
MfG Kjion
Kjion was vielleicht auch ganz interessant für dich ist. Die Firma Axotec
www.axotec.de bietet sehr interressante ARM Board an. Mit sehr viel Ausstattung.
z.B.
µX-PRO
- Prozessor - ARM 920T / 180MHz / 200 MIPS mit MMU und code/daten cache
- Flash - bis zu 16 MB onboard
- SDRAM - bis zu 128 MB onboard
- SRAM - 512 KB batteriegepuffert
- Memory card slots - Compactflash bis zu 8 GB, MMC/SD card bis zu 4 GB
- Interfaces - 10/100BaseT Ethernet
- 1 x USB host 2.0 full speed
- 1 x USB client 2.0 full speed
- 5 x RS232
- 1 x RS485/422 (ersetzt eine RS232)
- Digital I/O ports
- TWI interface mit Master Mode support
- I2C-Interface
- Watchdog
- Temperatursensor
- A/D Wandler 8 Kanal
- Onboard JTAG Interface für Debugging
- Optionen - Akkuversorgung mit onboard I/10 Lader
- zusätzliche 4 RS232/485 Schnittstellen (gesamt 8 RS232, 4 RS485)
- (exp.board) mit vollem +-12V Signalpegel
- CAN interface (exp.board)
- weitere Schnittstellen wie Profibus, Interbus-S, Devicenet etc.
- auf Anfrage -
- Temperatur - Extended temperature range -40° .. + 85° available
- Power supply - Onboard DC-DC converter
- Stromverbrauch - < 400mW
- DC-Eingang - 9..40 Volt
- Abmessungen - ca. 100 x 160 mm
" Als Standardbetriebssystem steht ein voll ausgestattetes Linux System zur Verfügung. Das ganze System des µX-PRO ist offen und frei konfigurierbar wei auch in allen gängigen Programmiersprachen wie C/C++ oder Java programmierbar."
Leider habe ich keine Preise der Boards gefunden und weiss auch nicht ob sie auch in einzelnen Stückzahlen verkauft werden.
Gruß Muraad
@stegr
Schau mal bei embedit. Der LPC2106 kostet 24€ der LPC2129 29€, also ich glaube nicht das man den für 10€ oder darunter bekommt auser man kauft ihn in 100/1000der Stückzahlen. Ein ATmega128 kostet ja schon so um die 10€.
@stegr
Schau mal bei embedit. Der LPC2106 kostet 24€ der LPC2129 29€, also ich glaube nicht das man den für 10€ oder darunter bekommt auser man kauft ihn in 100/1000der Stückzahlen. Ein ATmega128 kostet ja schon so um die 10€.
100er-Stückzahlen sind völlig in Ordnung... Wenn man nicht vorhat sowieso min. 30-40 davon zu verbauen lohnt sich der Zeitaufwand für die Einarbeitung nicht... Und ab ca. 50-60 rechnet sich der Preis wieder... Notfalls verkauft man den Rest als Sonderposten...
zu dem LPC2106: die kosten bei 250 Stück Abnahme $10.19 , also nicht mal 10 Euro das Stück...
Das ist ja grade der Vorteil der ARM7TDMI-S-Reihe, die kosten nicht viel mehr als ein 8-Bit-uC, können dafür aber deutlich mehr... einziger Nachteil bei den TDMI: keine MMU drinnen...
Hast du dir wirklich schon mal privat im 100er Bereich Mikrocontroller gekauft? Ich nicht, und ich hätte auch keine 1000€ deswegen kostet er für mich, wie wohl denke ich für viele andere auch 25€.
Jep, schön häufiger...
bisher nur PICs, und da merkt man den Preisunterschied so richtig deutlich...
die 16F870er kosten bei Sasko nur knapp 2 EUR, während man bei Reichelt für die 3,50 EUR zahlt... bei anderen siehts ähnlich aus...
Daher hol ich mir lieber 100 Stück, bevor ich mir da im Laufe der Zeit die Hälfte einzeln hol und gleich viel zahle...
Aber ich muss zugeben, das ganze ist bei mir nicht vollständig privat, sondern ich hab ne kleine Firma und entwickel in meiner Freizeit ein bissle was... Als Student hat man davon ja eigentlich noch genug (mehr oder weniger)...
zu dem LPC2106: die kosten bei 250 Stück Abnahme $10.19 , also nicht mal 10 Euro das Stück...
hmm, das sind 2500€!
Um mal ein wenig damit rumzubasteln wäre mir das _etwas_ zuviel. Aber ich weis ja jetzt, wen ich frage wenn ich einen oder zwei für 10-15€ brauche ;-)
Mal 'ne andere Frage: Welche µCs gibt es sonst noch, die 'ne gute Rechenleistung haben, aber einfach aufzubauen und zu programmieren sind? Die ich mir bisher so angesehen habe (68HCXX, ..) sind entweder recht lahm, oder zu kompliziert (externer Speicher usw)
ciao .. bernd
1.) War nur ne Preisinfo bei nem Distri, aber selber hab ich noch keine, da ich erstmal bei der Embedded in Nürnberg die Hersteller abklapper, wer mir da den besten Support liefern kann... Und wenn ich nicht konkrete Pläne habe, werde ich mir auch keine größeren Mengen holen... das muss solange alles als Sample vom Hersteller kommen...
2.) Die ARM7TDMI haben sich eigentlich zum Marktführer in dem Bereich herausgebildet. Die sind dafür ausgelegt um die nächste Ebene über den 8-Bittern zu bilden - 16-Bitter lohnen sich fast nicht, da die nahezu gleichviel kosten wie die 32er, man aber zusätzliche Entwicklungskosten hat. Daher verwenden die meisten Firmen nur 8 oder 32-Bitter.
Für den Privatbereich gibt es aber einen 16-Bitter, der recht interessant ist: Die MSP430 von TI, kosten ungefähr gleich viel wie die 8-Bitter, sind aber ein Stückle schneller und einfach zu programmieren. Einziger Nachteil: 44-Pin-TQFP-Gehäuse... aber bei Olimex (und anderen Anbietern) gibt es welche davon auf Header-Boards...
Was vielleicht auch interessant wird, sind die dsPICs von Microchip, die sind deutlich schneller, haben Hardware-Multiplizierer und schnelle AD-Wandler...
Nachteil: man bekommt se bisher kaum (selbst bei den Distris) und Preislich werden die auch nicht ganz so günstig sein.
über die MSPs (bzw über einen Artikel in der C't dazu) bin ich erst zu der Beschäftigung mit µCs gekommen. Aber wegen der Gehäuse hab ich dann doch lieber die Atmels genommen.
Vermutlich werde ich aber früher oder später etwas mehr Performance haben wollen. Dafür sind die ARMs natürlich sehr schön, vor allem weil sie recht viel SRAM haben.
ciao .. bernd
Die Boards von Axotec.de sehen echt interessant aus. Ich hab jetzt einfach mal per Mail angefragt, mal sehen was zurück kommt.
Die MSP430 hab ich mir auch schon angeschaut und werde in der nächsten Zeit vermutlich mal was damit machen. Allerdings laufen die mit maximal 8 MHz im Gegensatz zu den 16 MHz bei AVRs macht das dann schon einen Unterschied. Außerdem gibts die ganzen netten Features ( wie Hardware I2C ) erst bei den etwas "größeren" Modellen wie dem MSP430F169 oder so ...
MfG Kjion
Kijon binn mal gespannt was sie zurück schreiben. Ich werd nämlich nächste Woche eine Bewerbung für eine Ausbildung als Systeminformatiker and die Firma schreiben. Ich binn übers Arbeitsamt (online) auf die Firma gekommen und fand auch gleich ihre Board´s ziemlich interresant.
Gruß Muraad
@muraad: was ich dir wirklich empfehlen kann ist, dass du am 22. - 24. 2. auf der Embedded-World in Nürnberg vorbei schaust... Dort findest du eigentlich alles, was im Mikrocontrollermarkt und DSP-Markt Rang und Namen hat und es ergeben sich hervoragende Kontakte...
Und es macht sich auch immer gut, wenn man eine Bewerbung mit dem Satz beginnen kann: "Wie mit einem Mitarbeiter Ihrer Firma auf der Embedded-World 2005 in Nürnberg besprochen, möchte ich mich hiermit um eine Ausbildungsstelle als Systeminformatiker bewerben. [...]" ;)
Dadurch hat man einen konkreten Bezug und dadurch viel bessere Möglichkeiten auch eine Stelle zu bekommen.
Karten gibt es bei Vorbestellung kostenlos, allerdings solltest du dich dann ein wenig beeilen, denn arg lange gibt es die nicht mehr kostenlos...
Die Messe kann ich dir echt empfehlen, wenn man irgendwas wissen will oder Kontakte zu einer speziellen Firma will.
Und Nürnberg ist ja nur rund 2,5h mitm Auto von dir entfernt, daher würde sich das wirklich lohnen...
Homepage: www.embedded-world.de
MfG
Stefan
Danke Stegr das ist echt eine gute Idee. Axotec ist auch einer der Aussteller. Leider hab ich noch kein Auto/Führerschein, binn grad erst 18 geworden. Aber ich hoffe das ich nen Freund finde der mit mir nach Nürnberg fährt. Ich hoffe einfach so das ich die Ausbildung bei Axotec bekomm, des wäre Traumhaft O:) und da ist es mir auf jeden Fall wert nach Nürnberg zu fahren und mich noch mehr zu informieren.
Also nochmal danke Stegr
Gruß Muraad
Die 32-bit bringen dir rein gar keinen vorteil, wenn du keine 32-Bit-Operationen benötigst. Wenn du immer nur einzelne Bytes hin und her schaufelst, ist dein 8-biter genauso schnell wie dein 32-biter, aber sobald du mal zwei 16-Bit oder zwei 32-Bit-Zahlen addieren musst, sieht die Welt schon ganz anders aus.
Bei einem 32-Bit-System sind zwei Sachen relevant anders als bei einem 8-Bit-System:
1.) Die ALU ist (mind.) 32 Bit breit (ALU=Rechenwerk).
2.) Dein Instruktionsformat ist mind. 40 Bit oder noch breiter
Der erste Punkt bringt dir bei Rechenoperationen Geschwindigkeitsvorteile, der zweite Punkt lässt dich zum Beispiel größeren Speicher ansteuern (mehrere Gigabyte)...
Das ist nicht richtig. Wieso sollte das Instruktionsformat mind. 40bit sein?
Was Du meinst, ist das Addressformat. Operanden müssen aber nicht im jeweiligen Befehl stehen. Im Prinzip sind also durchaus 8bit-Instruktion denkbar.
Zusätzlich hast du bei den meisten 32-Bittern Technologieänderungen, bedeutet, dass die
1.) von Haus aus schneller sind, da andere Prozessarchitektur
2.) meist Pipelinig haben (nachfolgende Befehle werden noch während der eine abgearbeitet wird aus dem Speicher geholt und vorverarbeitet)
3.) Viele Schnittstellen schon als Hardware-Modul, die du auf einem 8-Bitter in Software machen musst.
Das ist auch nicht richtig. Moderne 8bitter benutzen ebfalls Pipelining, zum Beispiel die silabs-8051er. Die schaffen bis zu 100 Mips, womit sie insbesondere den kleinen ARMs leistungsmässig deutlich überlegen sind.
Von der Ausstattung können sie ebenfalls mithalten bzw. übertreffen viele 16- oder 32-bitter.
Zum Thema AMD64: das ist vom System her nochmal ganz anders, weil das kein Mikrocontroller ist, sondern ein Mikroprozessor. Das bedeutet, dass kein Speicher und keine Peripherie enthalten sind - aber das ist ja grade die Sache, warum man einen ARM nehmen will...
Naja, auch nicht ganz richtig. Der AMD hat jede Menge Cache-Speicher und ausserdem auch den Speichercontroller sowie jede Menge andere Peripherie an Board (Timer, etc.).
Allerdings nutzt das Ding ohne Zusatzbeschaltung in der Tat nicht viel ;)
2.) Die ARM7TDMI haben sich eigentlich zum Marktführer in dem Bereich herausgebildet. Die sind dafür ausgelegt um die nächste Ebene über den 8-Bittern zu bilden - 16-Bitter lohnen sich fast nicht, da die nahezu gleichviel kosten wie die 32er, man aber zusätzliche Entwicklungskosten hat. Daher verwenden die meisten Firmen nur 8 oder 32-Bitter.
Das ist nicht ganz richtig. Der 16bit-Markt ist sehr aktiv und gerade aus Kostengründen sehr attraktiv. Schau mal bei den grössten Controller-Anbietern (Renesas und Motorola) nach, welche Vielfalt die anbieten.
Für den Privatbereich gibt es aber einen 16-Bitter, der recht interessant ist: Die MSP430 von TI, kosten ungefähr gleich viel wie die 8-Bitter, sind aber ein Stückle schneller und einfach zu programmieren. Einziger Nachteil: 44-Pin-TQFP-Gehäuse... aber bei Olimex (und anderen Anbietern) gibt es welche davon auf Header-Boards...
Das ist Geschmackssache. Fakt ist, dass die MSPs von TI für einen recht eingschränkten Anwendungsbereich entwickelt wurden und man das auch merkt. Leistungsmässig stehen sie noch unter den meisten 8bittern (nur 8Mhz) und haben auch kein externes Speicherinterface. Ein aktueller AVR (24MHz) oder 8051 (bis zu 100MHz) hängt die MSPs (erst seit November 2004 mit 16MHz, aber natürlich noch nicht erhältlich) also locker ab.
Was vielleicht auch interessant wird, sind die dsPICs von Microchip, die sind deutlich schneller, haben Hardware-Multiplizierer und schnelle AD-Wandler...
Nachteil: man bekommt se bisher kaum (selbst bei den Distris) und Preislich werden die auch nicht ganz so günstig sein.
Die benutzt leider kaum einer, man sollte sich also ein bisschen mit der Thematik auskennen.
Bekommen tut man sie (als Hobbyist) aber recht gut, Microchip schmeisst schliesslich recht grosszügig mit Samples um sich ;)
Die 32-bit bringen dir rein gar keinen vorteil, wenn du keine 32-Bit-Operationen benötigst. Wenn du immer nur einzelne Bytes hin und her schaufelst, ist dein 8-biter genauso schnell wie dein 32-biter, aber sobald du mal zwei 16-Bit oder zwei 32-Bit-Zahlen addieren musst, sieht die Welt schon ganz anders aus.
Bei einem 32-Bit-System sind zwei Sachen relevant anders als bei einem 8-Bit-System:
1.) Die ALU ist (mind.) 32 Bit breit (ALU=Rechenwerk).
2.) Dein Instruktionsformat ist mind. 40 Bit oder noch breiter
Der erste Punkt bringt dir bei Rechenoperationen Geschwindigkeitsvorteile, der zweite Punkt lässt dich zum Beispiel größeren Speicher ansteuern (mehrere Gigabyte)...
Das ist nicht richtig. Wieso sollte das Instruktionsformat mind. 40bit sein?
Was Du meinst, ist das Addressformat. Operanden müssen aber nicht im jeweiligen Befehl stehen. Im Prinzip sind also durchaus 8bit-Instruktion denkbar.
Wenn kein einheitliches Instruktionsformat verwendet wird, ist Pipelining nicht mehr in dem Maße sinnvoll einsetzbar, da dabei structural hazards nur durch intensives stallen vermeidbar sind. Und dies senkt den cpi-Wert deutlich.
Zusätzlich hast du bei den meisten 32-Bittern Technologieänderungen, bedeutet, dass die
1.) von Haus aus schneller sind, da andere Prozessarchitektur
2.) meist Pipelinig haben (nachfolgende Befehle werden noch während der eine abgearbeitet wird aus dem Speicher geholt und vorverarbeitet)
3.) Viele Schnittstellen schon als Hardware-Modul, die du auf einem 8-Bitter in Software machen musst.
Das ist auch nicht richtig. Moderne 8bitter benutzen ebenfalls Pipelining, zum Beispiel die silabs-8051er. Die schaffen bis zu 100 Mips, womit sie insbesondere den kleinen ARMs leistungsmässig deutlich überlegen sind.
Von der Ausstattung können sie ebenfalls mithalten bzw. übertreffen viele 16- oder 32-bitter.
Ich hab mir grade mal das Datenblatt zu deinem super-8051 mit 100 MIPS angeschaut... das lustige Teil läuft mit externen 50MHz (intern-2x-PLL), und schafft nur bei einem Viertel der Befehle die auch in einem Systemzyklus auszuführen, rund die Hälfte braucht zwei Zyklen und der Rest bis zu 8 Zyklen - soviel zu den 100 MIPS. Da der 8051 kein einheitlich langes Instruktionsformat hat, geht weitere Rechenleistung durch stalls verloren, so dass der nette Controller überschlagsweise noch rund 30 MIPS real im Schnitt hat. Das ist schon deutlich weniger, oder?
Zum Thema AMD64: das ist vom System her nochmal ganz anders, weil das kein Mikrocontroller ist, sondern ein Mikroprozessor. Das bedeutet, dass kein Speicher und keine Peripherie enthalten sind - aber das ist ja grade die Sache, warum man einen ARM nehmen will...
Naja, auch nicht ganz richtig. Der AMD hat jede Menge Cache-Speicher und ausserdem auch den Speichercontroller sowie jede Menge andere Peripherie an Board (Timer, etc.).
Allerdings nutzt das Ding ohne Zusatzbeschaltung in der Tat nicht viel ;)
Der AMD64 hat keinen Programmspeicher und ist somit kein Mikrocontroller. (<- Dies ist ein Punkt!)
Cache ist auch nicht als internen Speicher nutzbar, auch wenn es eine Speicherform ist, da dieser lediglich eine Zwischenspeicherung häufig benötigter Werte des RAMs darstellt. Dies lässt sich aber nicht direkt beeinflussen.
2.) Die ARM7TDMI haben sich eigentlich zum Marktführer in dem Bereich herausgebildet. Die sind dafür ausgelegt um die nächste Ebene über den 8-Bittern zu bilden - 16-Bitter lohnen sich fast nicht, da die nahezu gleichviel kosten wie die 32er, man aber zusätzliche Entwicklungskosten hat. Daher verwenden die meisten Firmen nur 8 oder 32-Bitter.
Das ist nicht ganz richtig. Der 16bit-Markt ist sehr aktiv und gerade aus Kostengründen sehr attraktiv. Schau mal bei den grössten Controller-Anbietern (Renesas und Motorola) nach, welche Vielfalt die anbieten.
Der 16-Bit-Markt ist auf dem absterbenden Ast. Die Kosten liegen in den meisten Fällen in der selben Größenordnung wie 32-Bit-Systeme, sind dafür aber nicht so leistungsfähig (bis auf wenige Ausnahmen). Motorola selbst empfiehlt für neue Designs auf 32-Bit-Systeme umzusteigen (und das war vor einem Jahr auf der Embedded-World) oder 8-Bit-Systeme zu verwenden.
Für den Privatbereich gibt es aber einen 16-Bitter, der recht interessant ist: Die MSP430 von TI, kosten ungefähr gleich viel wie die 8-Bitter, sind aber ein Stückle schneller und einfach zu programmieren. Einziger Nachteil: 44-Pin-TQFP-Gehäuse... aber bei Olimex (und anderen Anbietern) gibt es welche davon auf Header-Boards...
Das ist Geschmackssache. Fakt ist, dass die MSPs von TI für einen recht eingschränkten Anwendungsbereich entwickelt wurden und man das auch merkt. Leistungsmässig stehen sie noch unter den meisten 8bittern (nur 8Mhz) und haben auch kein externes Speicherinterface. Ein aktueller AVR (24MHz) oder 8051 (bis zu 100MHz) hängt die MSPs (erst seit November 2004 mit 16MHz, aber natürlich noch nicht erhältlich) also locker ab.
Ich hab nicht gesagt, dass die MSPs das absolute non-plus-ultra sind. Sie sind klar für minimale Leistungsaufnahme optimiert und daher natürlich nicht in allen Punkten 8-Bittern überlegen. Aber das hab ich ja auch nicht behauptet. Was bei den MSP430s sehr interessant ist, ist dass sie nen echten Hardware-Multiplizierer haben, was man bei den meisten 8-Bittern nicht findet (zumindest keinen echten single-cycle).
Externes Speicherinterface macht bei einem auf Batterieanwendung ausgelegten MikroCONTROLLER keinen Sinn - wöllte ich ein externes Speicherinterface würde, würde ich nen MicroPROZESSOR nehmen.
Was vielleicht auch interessant wird, sind die dsPICs von Microchip, die sind deutlich schneller, haben Hardware-Multiplizierer und schnelle AD-Wandler...
Nachteil: man bekommt se bisher kaum (selbst bei den Distris) und Preislich werden die auch nicht ganz so günstig sein.
Die benutzt leider kaum einer, man sollte sich also ein bisschen mit der Thematik auskennen.
Bekommen tut man sie (als Hobbyist) aber recht gut, Microchip schmeisst schliesslich recht grosszügig mit Samples um sich ;)
Bei vielen Firmen sind die, zumindest in Prototypen, bereits im Einsatz, allerdings sind Kleinmengen nicht sinnvoll verfügbar (100er-Bereich). Samples bekommt man natürlich, allerdings will ich nicht für ne Kleinserie 17 Monate warten, bis ich die dann vollständig hab.
Für reine Hobby-Zwecke reichen natürlich die Samples, aber wir haben hier ja nicht nur Hobby-Leute...
So, noch mehr Fehler?
MfG
Stefan
Wenn kein einheitliches Instruktionsformat verwendet wird, ist Pipelining nicht mehr in dem Maße sinnvoll einsetzbar, da dabei structural hazards nur durch intensives stallen vermeidbar sind. Und dies senkt den cpi-Wert deutlich.
Wir sind hier in einem allgemeinem Forum. Mich beeindruckst Du jedenfalls nicht durch schlechtes Deutsch mit ein paar Fachbegriffen.
Im Übrigen ist meine Vorlesung "Rechnerarchitekturen", speziell das Kapitel "Pipelines und superskalare Architkekturen" noch gar nicht so lange her ;)
Daher weiss ich auch, dass structural hazards zwar durch stallen begegnet wird, das aber nicht am Instruktionsformat liegt.
Ich hab mir grade mal das Datenblatt zu deinem super-8051 mit 100 MIPS angeschaut... das lustige Teil läuft mit externen 50MHz (intern-2x-PLL), und schafft nur bei einem Viertel der Befehle die auch in einem Systemzyklus auszuführen, rund die Hälfte braucht zwei Zyklen und der Rest bis zu 8 Zyklen - soviel zu den 100 MIPS. Da der 8051 kein einheitlich langes Instruktionsformat hat, geht weitere Rechenleistung durch stalls verloren, so dass der nette Controller überschlagsweise noch rund 30 MIPS real im Schnitt hat. Das ist schon deutlich weniger, oder?
Du hast wohl vergessen, zu erwähnen, dass das beim ARM genauso ist!
Speziell bei den LPCs ist es so, dass der Flash über 20MHz nicht mehr mitkommt und jedesmal 2 Wartezyklen einlegen muss, sobald etwas nicht mehr im Cache steht. Das bedeutet, dass man bei 60MHz im Schnitt nur etwa die doppelte Geschwindigkeit erreicht wie bei 20MHz.
Viele Befehle dauern auch 2 Zyklen.
Ein simples Pin setzen in kostet 3 Befehle also insgesamt 6 Zyklen, das geht beim 8051er viel besser.
Ich hab mal testweise mit einem Timerinterrupt nur eine Variable hochgezählt, sonst nichts. Da konnte ich die Interruptfrequenz auf maximal 60 Zyklen setzen oder es gehen Interrupts verloren.
D.h. nur Interrupt betreten, Interruptflag löschen, Wert hochzählen und Interrupt verlassen kostet allein schon mal etwa 50 Zyklen -> Übel!
Was die LPCs angeht, so sind die allenfalls sinnvoll, wenn viel mit 32bit gerechnet wird. Ansonsten schneiden die schlecht ab.
Der 16-Bit-Markt ist auf dem absterbenden Ast. Die Kosten liegen in den meisten Fällen in der selben Größenordnung wie 32-Bit-Systeme, sind dafür aber nicht so leistungsfähig (bis auf wenige Ausnahmen). Motorola selbst empfiehlt für neue Designs auf 32-Bit-Systeme umzusteigen (und das war vor einem Jahr auf der Embedded-World) oder 8-Bit-Systeme zu verwenden.
Klar, dass die das empfehlen. Die haben ja ordentlich Miese gemacht und an Marktanteil sowie Gewinn verloren. Nicht umsonst ist die Sparte jetzt ausgegliedert und heisst Freescale. Des weiteren war 16bit schon immer Motorolas Schwäche. Ausser der 12er und der 16er Reihe hatten die nichts zu bieten.
Der Marktführer Renesas jedenfalls baut seine 16bit-Reihe massiv aus und gewinnt gerade deswegen auch enorm an Marktanteilen.
Ich hab nicht gesagt, dass die MSPs das absolute non-plus-ultra sind. Sie sind klar für minimale Leistungsaufnahme optimiert und daher natürlich nicht in allen Punkten 8-Bittern überlegen. Aber das hab ich ja auch nicht behauptet. Was bei den MSP430s sehr interessant ist, ist dass sie nen echten Hardware-Multiplizierer haben, was man bei den meisten 8-Bittern nicht findet (zumindest keinen echten single-cycle).
Was nutzt der Hardware-Multiplizierer, wenn die schnellere MCU das in Software genauso fix macht?
Aber ich wollte den MSP430 nicht schlecht machen. Als Allzweck-MCU ist er aber sicherlich nicht geeignet.
Im Übrigen hat die genannte silabs-100Mips-8051er-Familie eine Reihe MCUs mit 2-Zyklus-MAC-Einheit. Das ist schon wesentlich interessanter als ein Hardware-Multiplizier.
Externes Speicherinterface macht bei einem auf Batterieanwendung ausgelegten MikroCONTROLLER keinen Sinn - wöllte ich ein externes Speicherinterface würde, würde ich nen MicroPROZESSOR nehmen.
Das ist ja Unsinn. Viele Geräte benötigen die Eigenschaften eines Controllers samt externem Speicher.
Wieso sollte auch sonst in so viele Controller ein externes Speicherinterface implementiert sein, wenn es denn keiner benötigen würde?
Stromsparende Speicher gibt es auch viele.
So, noch mehr Fehler?
Hey, nicht gleich beleidigt sein.
Noch Fragen?
öhm, ja, welches ist denn nun der beste µC ? (Öl-auf's-Feuer-gieß ...)
nee, ernsthaft, welcher µC wäre wohl geeignet um zB das Bild einer Webcam in Echtzeit zu verarbeiten (zB Kanten finden) ? Er braucht ja wohl zum einen etwas Rechnenpower und zum andern auch reichlich Speicher.
ciao .. bernd
Wenn kein einheitliches Instruktionsformat verwendet wird, ist Pipelining nicht mehr in dem Maße sinnvoll einsetzbar, da dabei structural hazards nur durch intensives stallen vermeidbar sind. Und dies senkt den cpi-Wert deutlich.
Wir sind hier in einem allgemeinem Forum. Mich beeindruckst Du jedenfalls nicht durch schlechtes Deutsch mit ein paar Fachbegriffen.
Im Übrigen ist meine Vorlesung "Rechnerarchitekturen", speziell das Kapitel "Pipelines und superskalare Architkekturen" noch gar nicht so lange her ;)
Daher weiss ich auch, dass structural hazards zwar durch stallen begegnet wird, das aber nicht am Instruktionsformat liegt.
Hab grade extra nochmal nachgelesen, weil bei mir die Vorlesung auch noch nicht so lange her ist: Wenn das Instruktionsformat uneinheitlich ist, würden durch die quasiparallele Abarbeitung einige Befehle auf die selbe Ressource zugreifen, was aber nicht möglich ist. Daher muss in diesem Fall ge-stall-t werden. Structural hazards sind nicht nur bei uneinheitlichem Instruktionsformat auftretend, aber hier jedoch in hohem Maße.
Und sorry, ein kleiner Fehler von mir, der dir gar nicht aufgefallen ist, sondern erst mir beim wiederholten durchlesen: Der CPI-Wert wird natürlich erhöht, nicht gesenkt, aber das ist ja eigentlich klar.
Ich hab mir grade mal das Datenblatt zu deinem super-8051 mit 100 MIPS angeschaut... das lustige Teil läuft mit externen 50MHz (intern-2x-PLL), und schafft nur bei einem Viertel der Befehle die auch in einem Systemzyklus auszuführen, rund die Hälfte braucht zwei Zyklen und der Rest bis zu 8 Zyklen - soviel zu den 100 MIPS. Da der 8051 kein einheitlich langes Instruktionsformat hat, geht weitere Rechenleistung durch stalls verloren, so dass der nette Controller überschlagsweise noch rund 30 MIPS real im Schnitt hat. Das ist schon deutlich weniger, oder?
Du hast wohl vergessen, zu erwähnen, dass das beim ARM genauso ist!
Speziell bei den LPCs ist es so, dass der Flash über 20MHz nicht mehr mitkommt und jedesmal 2 Wartezyklen einlegen muss, sobald etwas nicht mehr im Cache steht. Das bedeutet, dass man bei 60MHz im Schnitt nur etwa die doppelte Geschwindigkeit erreicht wie bei 20MHz.
Viele Befehle dauern auch 2 Zyklen.
Ein simples Pin setzen in kostet 3 Befehle also insgesamt 6 Zyklen, das geht beim 8051er viel besser.
Ich hab mal testweise mit einem Timerinterrupt nur eine Variable hochgezählt, sonst nichts. Da konnte ich die Interruptfrequenz auf maximal 60 Zyklen setzen oder es gehen Interrupts verloren.
D.h. nur Interrupt betreten, Interruptflag löschen, Wert hochzählen und Interrupt verlassen kostet allein schon mal etwa 50 Zyklen -> Übel!
Was die LPCs angeht, so sind die allenfalls sinnvoll, wenn viel mit 32bit gerechnet wird. Ansonsten schneiden die schlecht ab.
Hab ich jemals behauptet, dass die ARM7TDMI, speziell die LPCs besonders stark leistungsfähig sind im Vergleich zu deinem Controller?
Ich hab nur gesagt, dass man nicht Äpfel mit Birnen vergleichen kann. Natürlich ist an jedem Controller irgendwo ein Pferdefuss zu finden, aber wenn man einen Controller für eine spezielle Aufgabe sucht, dann wählt man genau den aus, den man braucht. So käme wohl auch keiner auf die Idee nen MSP430F4xx (also aus der Displayreihe) für ne Motorsteuerung zu verwenden, da der einfach nicht dafür ausgelegt ist.
Der 16-Bit-Markt ist auf dem absterbenden Ast. Die Kosten liegen in den meisten Fällen in der selben Größenordnung wie 32-Bit-Systeme, sind dafür aber nicht so leistungsfähig (bis auf wenige Ausnahmen). Motorola selbst empfiehlt für neue Designs auf 32-Bit-Systeme umzusteigen (und das war vor einem Jahr auf der Embedded-World) oder 8-Bit-Systeme zu verwenden.
Klar, dass die das empfehlen. Die haben ja ordentlich Miese gemacht und an Marktanteil sowie Gewinn verloren. Nicht umsonst ist die Sparte jetzt ausgegliedert und heisst Freescale. Des weiteren war 16bit schon immer Motorolas Schwäche. Ausser der 12er und der 16er Reihe hatten die nichts zu bieten.
Der Marktführer Renesas jedenfalls baut seine 16bit-Reihe massiv aus und gewinnt gerade deswegen auch enorm an Marktanteilen.
Klar, viele Kunden, die bisher 16-Bitter im Einsatz haben wollen ja wohl auch nicht alle bereits geschriebene Software neu schreiben. Und grade für den Motorola nach Renesas-Wandel stellt IAR schöne Cross-Compiler zur Verfügung. Was ich damit sagen wollte ist nur, dass in Zukunft mehr Leute 32-Bitter verwenden werden als 16-Bitter und auf Dauer (die nächsten 5-10 Jahre) werden die für die Massenproduktion aussteigen. Das sind aber Fristen, die in dem Bereich normal sind. Und am Ende wird es trotzdem immer noch mindestens einen Anbieter geben, der die weiterhin im Programm hat, auch wenn se dann nur noch ein Nieschen-Dasein leben.
Ich hab nicht gesagt, dass die MSPs das absolute non-plus-ultra sind. Sie sind klar für minimale Leistungsaufnahme optimiert und daher natürlich nicht in allen Punkten 8-Bittern überlegen. Aber das hab ich ja auch nicht behauptet. Was bei den MSP430s sehr interessant ist, ist dass sie nen echten Hardware-Multiplizierer haben, was man bei den meisten 8-Bittern nicht findet (zumindest keinen echten single-cycle).
Was nutzt der Hardware-Multiplizierer, wenn die schnellere MCU das in Software genauso fix macht?
Aber ich wollte den MSP430 nicht schlecht machen. Als Allzweck-MCU ist er aber sicherlich nicht geeignet.
Im Übrigen hat die genannte silabs-100Mips-8051er-Familie eine Reihe MCUs mit 2-Zyklus-MAC-Einheit. Das ist schon wesentlich interessanter als ein Hardware-Multiplizier.
Nein, eine Allzweck-MCU ist er sicher nicht, aber für viele Aufgaben, grade wenn es auf Leistungsaufnahme ankommt, gut geeignet. Er ist aber gut erhältlich, die Entwicklungswerkzeuge sind sehr günstig und man bekommt in D recht guten Support für, auch Hobby'ler. Und das sind für mich die hier interessanten Argumente. Wobei er natürlich in vielen Gebieten sogar einem normalen AVR unterlegen ist, aber das ist, wie oben schon erwähnt, vom Einsatzzweck abhängig.
Externes Speicherinterface macht bei einem auf Batterieanwendung ausgelegten MikroCONTROLLER keinen Sinn - wöllte ich ein externes Speicherinterface, würde ich nen MikroPROZESSOR nehmen.
Das ist ja Unsinn. Viele Geräte benötigen die Eigenschaften eines Controllers samt externem Speicher.
Wieso sollte auch sonst in so viele Controller ein externes Speicherinterface implementiert sein, wenn es denn keiner benötigen würde?
Stromsparende Speicher gibt es auch viele.
Hab ich gesagt, dass es keiner benötigt? Nein. Manchmal brauch ich auch ein externes Speicherinterface, weil ich einfach zu viele Daten für den internen Speicher habe.
In den meisten Fällen, die hier auftreten, braucht man jedoch kein externes Speicherinterface, sondern einen schönen kompakten Controller, der alles drinnen hat, bei dem ich mir keine Gedanken um irgendwelche Speichertimings machen muss, sondern der einfach so läuft, wie ich es will. Natürlich sieht die Geschichte je nach Anwendungsgebiet anders aus: Wenn ich, wie z.B. bhm, Bildverarbeitung machen möchte, dann brauch ich in erster Linie viel Speicher, und das wird kaum ein Controller zu einem sinnvollem Preis integriert haben. Also wird man etwas externen SRAM oder, je nach Controller, auch DRAM dran hängen. Wenn man auf die ARMs gehen würde, wären das beispielsweise die ARM720-CPUs. Die haben sogar meist etwas internen Speicher, aber auch ein externes Speicherinterface. Man muss jedoch immer unterscheiden, was man braucht - es gibt keinen absolut universellen, für alles passenden Controller, sondern für jeden Anwendungsfall einen am besten dafür geeigneten. Da man meist nicht die Zeit hat sich in zig verschiedene Controller einzuarbeiten wird man eher hingehen und schaun, welche für die einem interessierenden Haupteinsatzgebiete am besten geeigneten Controller erhältlich sind und auf den 2-3 Controllern versuchen möglichst alle Anwendungen zu implementieren.
Ich selber bin überzeugter PIC-Programmierer, obwohl ich weiss, dass die AVRs zu einem ähnlichen Preis deutlich leistungsfähiger sind. Dies ist bei mir aus zwei Gründen so:
1.) Ich hab mit 8051 angefangen, bin dann aber recht schnell auf nen anderen Controller umgestiegen, da damals die Entwicklungsumgebungen nicht bezahlbar waren. Die PICs haben sich damals angeboten und daher hab ich se mal ausprobiert.
2.) Hab ich recht viele Firmenkontakte in dem Bereich und die meisten verwenden für kritische Anwendungen PICs, weil diese einfach extrem viel robuster sind als die AVRs. Das hab ich schon oft erlebt und es gibt viele Sachen, die man mit AVRs einfach nicht sauber machen kann (wie beispielsweise das direkte Betreiben an 220V und die Gleichrichtung über die internen Schutzdioden).
Mittlerweile zieht Atmel nach, was die Robustheit angeht, und Microchip zieht bei der Leistung nach. Da ich mich mit den PICs recht gut auskenne, werde ich wohl auch bei denen bleiben.
Nun gibt es aber auch bei mir einen Bereich, für den die PICs zu schwach sind, nämlich eine sinnvolle Ansteuerung von graphischen Displays. Natürlich könnte man das auch auf PICs realisieren (hab ich teilweise schon gemacht) aber es macht nicht mehr wirklich Spass. Als gut geeignet scheinen die ARM7TDMI, ob se im Praxiseinsatz wirklich für diesen Zweck geeignet sind, muss ich noch herausfinden. Für ARM7 hab ich schon in Assembler und C programmiert, kenn daher die Architektur und muss mich auch nicht mehr vollständig einarbeiten. Auch wenn se mir in manchen Bereichen nicht gefällt, scheint der ARM7 mir doch als guter Kompromiss. Sollte der interne Speicher nicht reichen, kann ich ohne große Änderungen zu einem ARM720 gehen, welcher ein externes Speicherinterface hat und daran einige Megabyte SD-RAM anschließen. Von welchem Hersteller ich jetzt aber einen Controller mit ARM-Kern nehmen werde, das weiss ich jetzt noch nicht. Da warte ich einfach die Embedded ab und unterhalte mich mal mit den verschiedenen Herstellern. Bei Controllern mit ARM-Kern gibt es für fast jedes Einsatzgebiet spezielle Abwandlungen von, die genau für diesen Zweck ausgelegt sind, und man muss sich nicht so sehr einarbeiten.
Bei den komplexeren Motorsteuerungen, zum Beispiel, würde ich jedoch keinen ARM (obwohl es dafür spezielle gibt) nehmen, sondern eher einen dsPIC, aber das sind persönliche Vorlieben und jeder muss selber schaun, was für ein Controller im am besten schmeckt. Es gibt keinen für alle Anwendungen am besten geeigneten Controller.
Meine persönlichen Empfehlungen:
- Im 8-Bit-Bereich empfehlen sich die PICs oder AVRs (genaueres siehe oben); Die 8051 mag ich aufgrund der Architektur nicht so wirklich. Es sind jedoch die Controller, die sich seit Jahrzehnten auf dem Markt gehalten haben (wobei das aber bei vielen Firmen daran liegt, dass se keine funktionierende Software neu schreiben wollen, wozu auch).
- Im 16-Bit-Bereich ist der Marktführer Renesas, aber deren Entwicklungsumgebungen sind unheimlich teuer, so dass das für die meisten nicht finanzierbar ist - und ich bekomm für nahezu den gleichen Preis nen 32-Bit-System, das sonst nahezu nichts kostet.
- Im 32-Bit-Bereich empfehle ich die ARM7, weil man dafür so ziemlich alles frei bekommt und auch die Controller zu vernünftigen Preisen in Kleinmengen und Großmengen erhältlich sind. Welche Controller im Details von welchem Hersteller, das muss man selber sehen und das hängt auch von den persönlichen Wünschen bezüglich der Ausstattung und den Einsatzgebieten ab.
So, noch mehr Fehler?
Hey, nicht gleich beleidigt sein.
Noch Fragen?
Bin nicht beleidigt... aber ich mag keine Fehler, die offen stehen bleiben... darum frag ich ja auch, bin auch nicht allwissend... ;)
MfG
Stefan
Hab grade extra nochmal nachgelesen, weil bei mir die Vorlesung auch noch nicht so lange her ist: Wenn das Instruktionsformat uneinheitlich ist, würden durch die quasiparallele Abarbeitung einige Befehle auf die selbe Ressource zugreifen, was aber nicht möglich ist. Daher muss in diesem Fall ge-stall-t werden. Structural hazards sind nicht nur bei uneinheitlichem Instruktionsformat auftretend, aber hier jedoch in hohem Maße.
In meiner Vorlesung war das aber etwas anders ;)
Wenn nämlich (aus Kostengründen) einzelne Funktionseinheiten, beispielsweise Speicherbusse, eingespart werden, dann tritt Dein Fall in Kraft. Das ist dann aber bewusst so hingenommen.
Gerade bei den DSPs aber ist es halt so, dass es mehrere Busse gibt, so dass diese halt nicht den Flaschenhals bilden und somit structural hazards im Wesentlichen durch diese bewussten Einsparungen bedingt sind.
Hab ich jemals behauptet, dass die ARM7TDMI, speziell die LPCs besonders stark leistungsfähig sind im Vergleich zu deinem Controller?
Ich hab nur gesagt, dass man nicht Äpfel mit Birnen vergleichen kann. Natürlich ist an jedem Controller irgendwo ein Pferdefuss zu finden, aber wenn man einen Controller für eine spezielle Aufgabe sucht, dann wählt man genau den aus, den man braucht. So käme wohl auch keiner auf die Idee nen MSP430F4xx (also aus der Displayreihe) für ne Motorsteuerung zu verwenden, da der einfach nicht dafür ausgelegt ist.
Ich meinte damit auch nur, dass speziell die LPCs meiner Meinung nach nur den 32bit-Hype ausnutzen, in vielen Fällen aber nichtmal 8bit Niveau erreichen (speziell I/O).
Klar, viele Kunden, die bisher 16-Bitter im Einsatz haben wollen ja wohl auch nicht alle bereits geschriebene Software neu schreiben. Und grade für den Motorola nach Renesas-Wandel stellt IAR schöne Cross-Compiler zur Verfügung. Was ich damit sagen wollte ist nur, dass in Zukunft mehr Leute 32-Bitter verwenden werden als 16-Bitter und auf Dauer (die nächsten 5-10 Jahre) werden die für die Massenproduktion aussteigen. Das sind aber Fristen, die in dem Bereich normal sind. Und am Ende wird es trotzdem immer noch mindestens einen Anbieter geben, der die weiterhin im Programm hat, auch wenn se dann nur noch ein Nieschen-Dasein leben.
Das hat man schon vor über 15 Jahren zu den 8bittern gesagt. Bis heute wird aber noch prima damit verdient (sogar 4bitter gibt es etliche!).
Fakt ist, dass Chipfläche viel Geld kostet. Und ein 32bit-Bus samt 32bit-Speicher (Cache, onboard-RAM/ROM/FLASH) frisst viel Fläche. Das macht Controller teuer. Dazu kommt die grössere Code-Grösse, die grössere Speicher erforderlich macht.
Sogar bei den Arms gibt es dazu ja die Thumb-Erweiterung, die eine Reduktion auf 16bit ermöglicht, damit eben Ressourcen eingespart werden können.
Nein, eine Allzweck-MCU ist er sicher nicht, aber für viele Aufgaben, grade wenn es auf Leistungsaufnahme ankommt, gut geeignet. Er ist aber gut erhältlich, die Entwicklungswerkzeuge sind sehr günstig und man bekommt in D recht guten Support für, auch Hobby'ler. Und das sind für mich die hier interessanten Argumente. Wobei er natürlich in vielen Gebieten sogar einem normalen AVR unterlegen ist, aber das ist, wie oben schon erwähnt, vom Einsatzzweck abhängig.
Wobei gerade Deine Argumente eher für den AVR sprechen (bis auf die Stromaufnahme, die allerdings nur für wirkliche "Nur-MCU-Anwendungen" interessant ist)- er ist günstiger erhältlich, da selbst Hobbyisten sie in ihren Webshops führen, es gibt wesentlich mehr Projekte damit, die Einsteigern behilflich sind und dazu 2 exzellente Foren (deutsch und englisch), die sehr rege und von vielen Fachleuten besucht werden.
Ich selber bin überzeugter PIC-Programmierer, obwohl ich weiss, dass die AVRs zu einem ähnlichen Preis deutlich leistungsfähiger sind. Dies ist bei mir aus zwei Gründen so:
1.) Ich hab mit 8051 angefangen, bin dann aber recht schnell auf nen anderen Controller umgestiegen, da damals die Entwicklungsumgebungen nicht bezahlbar waren. Die PICs haben sich damals angeboten und daher hab ich se mal ausprobiert.
2.) Hab ich recht viele Firmenkontakte in dem Bereich und die meisten verwenden für kritische Anwendungen PICs, weil diese einfach extrem viel robuster sind als die AVRs. Das hab ich schon oft erlebt und es gibt viele Sachen, die man mit AVRs einfach nicht sauber machen kann (wie beispielsweise das direkte Betreiben an 220V und die Gleichrichtung über die internen Schutzdioden).
Mittlerweile zieht Atmel nach, was die Robustheit angeht, und Microchip zieht bei der Leistung nach. Da ich mich mit den PICs recht gut auskenne, werde ich wohl auch bei denen bleiben.
Hehe, ich habe mit dem 8048er angefangen und dann mit nem selbstgelöteten Eprom-Emulator auf dem 8051er weitergemacht. Das war auch nicht sehr teuer. Den PIC16C84 habe ich dann probiert und mich dann mit Grausen abgewandt (man denke nur an den begrenzten Hardwarestack, das umständliche W-Register, die umständlichen Interrupts, etc.). Gegenwärtig nutze ich privat die Renesas M16C sowie für kleiner Sachen die AVRs.
Meine persönlichen Empfehlungen:
- Im 8-Bit-Bereich empfehlen sich die PICs oder AVRs (genaueres siehe oben); Die 8051 mag ich aufgrund der Architektur nicht so wirklich. Es sind jedoch die Controller, die sich seit Jahrzehnten auf dem Markt gehalten haben (wobei das aber bei vielen Firmen daran liegt, dass se keine funktionierende Software neu schreiben wollen, wozu auch).
Dass der 8051 so lange gehalten hat, liegt ganz einfach daran, dass er eben gerade eine Architektur hat, die trotz ihrer Schwächen gerade im embedded-Bereich mit den vielen Port-Ein- und Ausgaben den AVRs und ARM überlegen ist. Das braucht nicht mehrere Befehle/Zyklen. Da kann man dann oft den Controller eine Nummer kleiner (und billiger) wählen als bei der Konkurrenz. Des weiteren gibt es den wohl weltbekannten Keil-C-Compiler, der für den 8051 einfach eine Klasse für sich ist und in der Effizienz von keinem Compiler geschlagen wird.
- Im 16-Bit-Bereich ist der Marktführer Renesas, aber deren Entwicklungsumgebungen sind unheimlich teuer, so dass das für die meisten nicht finanzierbar ist - und ich bekomm für nahezu den gleichen Preis nen 32-Bit-System, das sonst nahezu nichts kostet.
Das trifft aber nur Hobbyisten und kleine Ingenieurbüros. Bei Massenanwendungen fällt das schlicht nicht ins Gewicht.
Deshalb sind die 16bitter auch billiger als die 32bitter. Jeder Cent bei der MCU zählt da.
Im Übrigen gibt es die M16C-MCUs (jeweils 4 Stück) samt Development-Kits gerade bei Renesas für lau - vom "kleinen" R8C/13 bis hin zum "fetten" M32C/83 samt eingebautem DRAM-Controller :)
- Im 32-Bit-Bereich empfehle ich die ARM7, weil man dafür so ziemlich alles frei bekommt und auch die Controller zu vernünftigen Preisen in Kleinmengen und Großmengen erhältlich sind. Welche Controller im Details von welchem Hersteller, das muss man selber sehen und das hängt auch von den persönlichen Wünschen bezüglich der Ausstattung und den Einsatzgebieten ab.
Trifft für Hobbyisten zu, im Massenbereich ist das wieder anders, wobei die ARMs da ordentlich zulegen.
So, und jetzt feiert mal schön!
öhm, ja, welches ist denn nun der beste µC ? (Öl-auf's-Feuer-gieß ...)
nee, ernsthaft, welcher µC wäre wohl geeignet um zB das Bild einer Webcam in Echtzeit zu verarbeiten (zB Kanten finden) ? Er braucht ja wohl zum einen etwas Rechnenpower und zum andern auch reichlich Speicher.
ciao .. bernd
Dafür würde ich einen DSP nehmen.
Wenn Du das als Hobby machen willst, dann bestell Dir bei Analog Devices kostenlos 2 Samples des 21065ers. Die kann man auch mit wenig Aufwand (da Hardware-unterstützt) parallelschalten und haben auch den DRAM-Controller eingebaut. Einfach alte PC-SIMMs anschliessen und los gehts.
Nur ne 4Layer-Platine wäre halt sinnvoll.
Dafür würde ich einen DSP nehmen.
Wenn Du das als Hobby machen willst, dann bestell Dir bei Analog Devices kostenlos 2 Samples des 21065ers. Die kann man auch mit wenig Aufwand (da Hardware-unterstützt) parallelschalten und haben auch den DRAM-Controller eingebaut. Einfach alte PC-SIMMs anschliessen und los gehts.
Nur ne 4Layer-Platine wäre halt sinnvoll.
Ist 'ne nette Idee, nur das mit den 2-Layer-Platinen wird wohl ein Problem, da Hobby. Ich wollte mir eh mal DSPs ansehen, schon allein wegen der ganz anderen Philosophie.
ciao .. bernd
Hi,
mittlerweile hab ich auch schon ne Antwort von Axotec.de bekommen, leider sind die Preise wie ich das schon erwartet hatte recht hoch.
Zum Beispiel das µX-PRO Board kostet 438 € in der Grundausstattung, für die zusammengestellten Linux System wollen sie nochmal 350 € ( bzw. 2000 € für die Developer Edition ) haben. Das ist mir dann doch etwas viel ...
Diese Boards gehen leider alle in diese Preisklasse, allerdings bekommt man für diesen Preis schon ein VIA Epia Board mit Netzteil und allem Zubehör. Wenn da nicht der Stromverbrauch und der benötigte Platz wäre eigentlich Ideal :-(
MfG Kjion
engineer
18.02.2005, 12:08
Das ist in der Tat sehr hoch. Ich habe mich mal eine Weile mit solchen embedded Webservern befasst- ebenfalls auf der BAsis von ARM. Wie man den Bildern entnimmt, sind die Viecher recht komplex:
http://home.arcor.de/devicemaster/images.html
Dieser läuft auf ECOS, mit einem free SDK. Kosten für des Teil (16 Kanäle) €1450,- im Jahre 2002.
Was Eigenentwicklungen angeht, würde ich zu einem der olimexboards raten. Hier gibt es eines für 69,- www.shop.mikrocontroller.net "olimex board LPC2101"
Das habe ich auch bestellt. Dazu habe ich mir eines in EAGLE gebaut - mit den jeweils benötigten Sonderfunktionen.
Schade das sie echt so teuer sind, vor allem die Developer Edition :( . Ich fand die Boards auch so interresant da sie ideal für nen Roboter währen.
Aber gibt es jetzt echt keine ARM Boards, außer das olimexboard, welche für privat/hobby erschwinglich sind?!
Gruß Muraad
Von den Philips-ARMs kann ich nur abraten. Die haben, wie oben schon geschrieben wurde, zu viele Haken und Ösen.
Wenn ARM, dann bietet sich z.B.
http://www.gumstix.com
an.
Die sind richtig interessant vor allem vom Preis her :) Und mit Intel XScale® PXA255 Prozessoren, die sind in den ganzen neuen Handheld PC´s.
Und hab ich des richtig verstanden, die Entwicklung (dank Linux) ist komplett kostenlos?!
http://www.gumstix.org/tikiwiki/tiki-index.php?page=Programming&PHPSESSID=a4bc014f28f8f839852ed89530cad31e
Gruß Muraad
Richtig.
Die nutzen auch einen schön aktuelle Kernel. Bei einigen anderen muss man sich noch mit dem 2.4er rumschlagen.
Weiß einer von euch wie viel so ein Board verbraucht?
Mfg.Attila Földe
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.