Was kann mit einem ARM realisiert werden, was mit einem PIC32 nicht möglich ist?
Simon :-) schrieb: > Was kann mit einem ARM realisiert werden, was mit einem PIC32 nicht > möglich ist? Sorry, aber die Frage macht so wirklich keinen Sinn. Erst gestern wurde ein ahnliches Thema ins Offtopic-Forum verschoben weils unter uns Betschwestern im Elektronik-Forum einfach unsinnig ist sich solche Fragen überhaupt zu stellen. Sowas steht in den Datenblättern der konkreten Derivate die man vergleicht.Punkt.
Loonix schrieb: > Erst gestern wurde > ein ahnliches Thema ins Offtopic-Forum verschoben weils unter uns > Betschwestern im Elektronik-Forum einfach unsinnig ist sich solche > Fragen überhaupt zu stellen Und dieser Thread gestern wurde auch von einem "Simon :-) (Gast)" eröffnet.
Ganz allgemein: Bei µControllern vergleicht man u.a.: - Rechenleistung, Datenbusbreite - Peripherals - Stromverbrauch - Chipkosten - notwendige Einarbeitung - Verfügbarkeit ARM punktet ganz klar in Sachen Stromverbrauch (s. Grossteil mobiler Geräte), und Verfügbarkeit (in wer-weiss-wie-vielen Microcontrollern steckt ein ARM Core). Rechenleistung haben alle irgendwo **grins**, nun muss abgewogen werden, wie viel Leistung man braucht, und welchen Stromverbrauch man sich leisten kann, sowie welche Peripherals Flash SRAM die verschiedenen Microcontroller mitbringen. Die Frage ist genau so, wie: - Was kann ich mit einem Mercedes, was ein Audi nicht kann? - was kann ein Häuschen im Grünen, was ein Stadthäuschen nicht kann?
Dipl.Ing.(FH) (Elektro) schrieb: > ARM punktet ganz klar in Sachen Stromverbrauch (s. Grossteil mobiler Deiner eigenen Argumentation folgend ist das eine Feststellung a la "Audi hat einen niedrigeren Spritverbrauch als andere Autos" ;) > Geräte), und Verfügbarkeit (in wer-weiss-wie-vielen Microcontrollern > steckt ein ARM Core). Auch der MIPS-Kern steckt in mehreren Controllern.
es war ein Beispiel. Von MIPS war nicht die Rede ^^ MIPS punktet so weit ich weiss in Sachen SetTop-Boxen...
Dipl.Ing.(FH) (Elektro) schrieb: > es war ein Beispiel. Von MIPS war nicht die Rede ^^ Doch der PIC32 ist ein Mips. Aber da ist wieder das Problem wie was vergleichen was man nicht vergleichen kann ?
K. J. schrieb: > Aber da ist wieder das Problem wie was vergleichen was man nicht > vergleichen kann ? Yep. Man kann ARM mit MIPS vergleichen (Architekturen), man kann Cortex-M3 mit MIPS32 M4K vergleichen (Cores), man kann STM32 mit PIC32 vergleichen (Controller-Familien), aber ARM mit PIC32 zu vergleichen ergibt keinen Sinn.
Simon :-) schrieb: > Was kann mit einem ARM realisiert werden, was mit einem PIC32 nicht > möglich ist? nichts.
Was kann mit Englisch ausgedrückt werden, was nicht auch mit Deutsch geht? - Nichts - klingt nur anders - Tja, trotzdem spricht die Welt Englisch - Pech für alle PIC32-Anhänger...
Mit einem ARM kann man sich an einem Seil hochziehen. Und selbst, wenn man herunterfällt, ist man (immer noch) ARM dran. Das ist der Beweis!
Robert schrieb: > - Tja, trotzdem spricht die Welt Englisch (Hr.Teufel?) Deren Marktanteil in allen Ehren aber die Welt dreht sich nicht nur um ARM, das müssen auch Fanboys irgendwann zugeben. > > - Pech für alle PIC32-Anhänger... Aus einem uC nen Anhänger basteln? Ein Fanboy, sag ich doch... ;)
Jetzt einen MIPS basierten Controller anstelle eines ARM basierten zu nehmen ist wie wenn du dir noch 1998 einen Amiga statt eines PCs zum arbeiten gekauft hättest. Kann man machen. Dann sollte man sich aber auch nicht wundern, wenn man alleine da steht. ;-)
>Jetzt einen MIPS basierten Controller anstelle eines ARM basierten zu >nehmen ist wie wenn du dir noch 1998 einen Amiga statt eines PCs zum >arbeiten gekauft hättest. Kann man machen. Dann sollte man sich aber >auch nicht wundern, wenn man alleine da steht. ;-) Hätten wir alle 1998 nur Amigas gekauft, dann hätten wir die Heute noch und Intel wäre vermutlich pleite. Also kauft PIC32! =D *Nicht ernst gemeint*
Robert schrieb: > Was kann mit Englisch ausgedrückt werden, was nicht auch mit Deutsch > geht? > - Tja, trotzdem spricht die Welt Englisch Nunja - Neben Englisch hast du aber noch große Chancen mit Französich, Spanisch und Russisch in vielen Teilen der Welt, die deutlich größer sind als das jeweilige Ursprungsland, weiterzukommen. Wenn man jetzt noch die -native Speakers- mit einbezieht, dann kann man auch noch Chinesich und Indisch mit einbeziehen. > - Pech für alle PIC32-Anhänger... Naja, wie ist eine Meinungsfrage. Natürlich ist ARM (welche ARM Architektur eigendlich genau?) GEFÜHLT am weitesten verbreitet. Aber MIPS ist dennoch ein großer Mitspieler. Deiner Argumentation zu folge müsste man aber diese "komischen AVR32" sofort begraben... Den diese sind mit Ihrer properitären Architektur im Gegensatz zu dem PIC32 mit MIPS Kern wirklich Exoten im Vergleich. ... schrieb: > Jetzt einen MIPS basierten Controller anstelle eines ARM basierten zu > nehmen ist wie wenn du dir noch 1998 einen Amiga statt eines PCs zum > arbeiten gekauft hättest. Kann man machen. Dann sollte man sich aber > auch nicht wundern, wenn man alleine da steht. ;-) Naja - Gefühlt würde ich aber sagen das der AMIGA in 1998 Vergleich eher auf die 32Bit AVRs zutrifft. Die MIPS sind dann eher die Apples. Sind bekannt - geringere Verbreitung als die PCs- haben aber ausreichende Verbreitung um auch auf langer Sicht in Ihrem Bereich mitspielen zu könen. Trotzdem ist die Fragestellung in Ihrer Art und Weise natürlich ein wenig "Unsinnig" Gruß Carsten
Gibts es nicht auch bei ARM/MIPS etc eine Vergleichsmöglichkeit wie es bei PCs die Mega/Giga-Flops oder Benchmarks sind? Da macht es ja auch kein Unterschied, was oder wieviel die CPU und die GPU macht. Da zählt letztendlich ja nur, wieviel Aufgaben einer bestimmten Rechenart schafft er in 1 Sekunde. Habe mal was von DMIPS/MHz oder Coremarks gelesen. Kann man anhand damit evtl ARM und MIPS vergleichen?
Carsten Sch. schrieb: > Aber MIPS ist dennoch ein großer Mitspieler. Hab ich grade bei Wikipedia entdeckt: ARM: * Apple: iPods (ARM7TDMI SoC), iPhone (Samsung ARM1176JZF, Apple A4), iPod touch (ARM11), iPad (Apple A4) * Canon: IXY Digital 700 Kamera (Eigenentwicklung, ARM-basiert) * Hewlett-Packard: HP-49/50 Grafikfähiger Taschenrechner (ARM9TDMI) * Linksys: NSLU2 Netzwerkspeicher/NAS [Intel XScale IXP420] * Nintendo: Game Boy Advance (ARM7), Nintendo DS (ARM7, ARM9) * Palm: PocketPC PDAs und Smartphones (Intel XScale und Samsung SC32442 – ARM9) * Sony: verschiedene Mobiltelefone, Network Walkman (Eigenentwicklung, ARM-basiert) MIPS: * AVM: FRITZ!Box WLAN/Telefonie-Router * SGI: Server und Workstations wie Indy, Onyx und Origin (R2000 bis R12000) * Sony PlayStation, PlayStation Portable Spielkonsolen * Nintendo 64 Spielkonsole * Linksys WRT54G und zahlreiche ähnliche Geräte[2] * MikroTik[3] RouterBOARD War für mich mal interessant zu sehen, was wo drin steckt.
DMIPS = Dhrystone-MIPS, ein im Controller-Sektor verbreiteter Trivialbenchmark, der dem Akronym MIPS = Meaningless Indicator of Processor Speed neues Leben einhaucht.
ich schrieb: > Habe mal was von DMIPS/MHz oder Coremarks gelesen. Kann > man anhand damit evtl ARM und MIPS vergleichen? Bringt auch nicht viel. Normale PICs (pic14, pic16 Architektur) z.B. arbeiten intern nur mit 1/4 des Taktes, hätten bei dem Vergleich also immer nur ein viertel des AVR-Wertes. Stört aber in der Praxis nicht, weil man die dann einfach mit z.B 40MHz rennen lässt, was einem AVR dann schon zuviel wäre. Eher interressant: MIPS pro Watt bei Stromspar-Anwendungen oder MIPS pro cm² Platinenfläche (Notwendige Spannungsregler dazunehmen!) oder ... Und bei vielen Anwendungen sind die MIPS auch wurscht, weil z.B. die intterrupt-Latenz oder die verfügbaren Bibliotheken ausschlaggebend sind. Also: Generelle Vergleiche sind meistens Mist. Nur speziell auf eine Anwendung zugeschnitten kann man vielleicht sagen "*Hier* ist der PIC32 ein wenig im Vorteil" oder "Der NXP-LPCxxx-ARM kann das ein wenig besser".
Anstatt wie viele meiner Vorredner schlau wirken zu wollen, versuche ich es mal mit einem konstruktiven Beitrag zum Thema: Bisher habe ich von keiner Aufgabe gehört, die man mit einem ARM aber nicht mit einem PIC32 lösen könnte. Ich denke man sollte aber auch bedenken, welche Firma die besten Libraries und einen kostenlosen Compiler (auf GCC Basis) + Debugger anbietet, der einfach vom Normaluser zu nutzen ist (ohne dass man sich die IDE selbst zusammenstricken muss) - und da steht momentan Microchip mit dem PIC32 vorne. Was nützt der beste Microcontroller, wenn man einen Compiler für 4000 EUR braucht oder alle Libs selber schreiben muss? Aus dieser Sicht kann man IMHO mit einem PIC32 mit Microchip Libs mehr machen: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784 Der FreeRTOS Port für den PIC32 ist soweit ich sehe auch ganz gut. Da soll mir mal einer einen ARM Cortex-M3 Anbieter nennen, der diese Sachen "aus einer Hand" anbietet. Ich bin zumindest kurz davor, mich für den PIC32 zu entscheiden. ARM ist schön und gut, aber ARM verkauft keine Mikrocontroller - die werden von ST, TI, NXP, etc. angeboten, und ob die zuverlässiger sind als Microchip, wage ich zu bezweifeln. Ansonsten kann der MIPS mit dem Cortex-M3 anscheinend auch gut mithalten bzw. ist sogar besser: http://www.bdti.com/MyBDTI/pubs/m4k.pdf Grüße, Anguel
Anguel S. schrieb: > Der FreeRTOS Port für den PIC32 ist soweit ich sehe auch ganz gut. > > Da soll mir mal einer einen ARM Cortex-M3 Anbieter nennen, der diese > > Sachen "aus einer Hand" anbietet. > FreeRTOS für ARM Cortex-M3 läuft auch tiptop. > ARM ist schön und gut, aber ARM verkauft keine Mikrocontroller - die > > werden von ST, TI, NXP, etc. angeboten, und ob die zuverlässiger sind > > als Microchip, wage ich zu bezweifeln. Das ist meiner Ansicht nach ein grosses Plus für ARM. Stichwort 2nd source. Und ARM bemüht sich extrem, ST, TI, NXP etc. wirklich codekompatibel zu halten (Stichwort CMSIS) Letztendlich bin ich aber auch der Meinung, dass es nicht so sehr drauf ankommt, wofür man sich entscheidet. Einen ordentlichen HAL einbauen, und dann kann man seine Software auch von einem dressierten Affen abarbeiten lassen.
Naja, ARM wird von GCC seit Jahr und Tag recht gut unterstützt, Debugging mit OpenOCD. Das, was du da schreibst, trifft wohl nur dann zu, wenn man partout das (X+1). UI eines Herstellers für sein Produkt erwartet. Wenn man stattdessen für die Arbeit mit i386, AVR, ARM und wasweißichnichtalles nicht jedesmal ein neues UI mit neuen Tastenbelegungen, neuer Suche "wo finde ich hier was?" usw. haben will, dann sieht die Welt wohl etwas anders aus. Für mich wären auf jeden Fall bei sowas Entscheidungsbasis: . darf ich mir das Betriebssystem meiner Wahl benutzen, oder bin ich darauf angewiesen, das zu haben, was der Controllerhersteller favorisiert? . darf ich in meiner gewohnten Umgebung weiterarbeiten? . wenn mal was nicht geht, kann ich es selbst reparieren, oder ist der Hersteller in der Lage, bei einem kritischen Fehler auch in annehmbar kurzer Zeit zu reagieren? . bei Bibliotheken würde ich prinzipiell einer solchen mit freigegebenem Quellcode den Vorzug vor einer rein binären Variante geben, und sei's nur, weil man sowas auch als Beispiel für eigene Routinen benutzen kann (das soll nicht heißen, dass sie deshalb nicht auch vom Hersteller selbst gepflegt werden kann)
Simon Huwyler schrieb: > Das ist meiner Ansicht nach ein grosses Plus für ARM. Stichwort 2nd > source. Und ARM bemüht sich extrem, ST, TI, NXP etc. wirklich > codekompatibel zu halten (Stichwort CMSIS) Halt...der MIPS-Kern ist nicht von Microchip. So schnell entstehen eben Gerüchte durch Halbwissen und/oder Halbwahrheiten.
Hi, Ich reihe mich hier mal ein. Eine Anwendung ist mit dem PIC32 ein Grauss, und zwar feldorientierte Regelung von Syncronmaschinen da ist der STM32 den ich zurzeit da für nehme von der Perepherie her besser, Ich habe aber auch schon den dsPic benutzt, der kann das auch. Von daher hinkt dieser Vergleich immer. Was der eine Controller an Perepherie nicht hat hat der andere egal ob unter den ARMs oder ne ds/PIC/32, Zu den Libs, ich bin mit den Libs von ST recht zufrieden. Klar sie sind nicht die schnellsten, aber das sind die von Microchip auch net. Das liegt eben daran das die so allgemein gültig wie möglich geschrieben sind. Von daher, nimmt man den Controller der einem für die Anwendung am ehersten zu sagt. MfG Tec
Loonix schrieb: > Simon Huwyler schrieb: >> Das ist meiner Ansicht nach ein grosses Plus für ARM. Stichwort 2nd >> source. Und ARM bemüht sich extrem, ST, TI, NXP etc. wirklich >> codekompatibel zu halten (Stichwort CMSIS) > > Halt...der MIPS-Kern ist nicht von Microchip. So schnell entstehen > eben Gerüchte durch Halbwissen und/oder Halbwahrheiten. Stimmt, hast recht, für den MIPS-Kern gilt das natürlich auch. Ich antwortete nur auf die Argumentation, dass ARM "nur" durch Fremdhersteller in Silizium vertreten sind, und dass das ein Nachteil sei. Also Fazit: Es ist kein Nachteil für ARM, sondern ein Vorteil sowohl für ARM als auch für PIC32, nö, eben, MIPS.
Tec Nologic schrieb: > Eine Anwendung ist mit dem PIC32 ein > Grauss, und zwar feldorientierte Regelung von Syncronmaschinen da ist > der STM32 den ich zurzeit da für nehme von der Perepherie her besser, Was genau ist das Problem beim PIC32? Interessiert mich, da ich mich noch nicht entschieden habe :)
Simon Huwyler schrieb: > Anguel S. schrieb: >> ARM ist schön und gut, aber ARM verkauft keine Mikrocontroller - die >> werden von ST, TI, NXP, etc. angeboten, und ob die zuverlässiger sind >> als Microchip, wage ich zu bezweifeln. > > Das ist meiner Ansicht nach ein grosses Plus für ARM. Stichwort 2nd > source. Und ARM bemüht sich extrem, ST, TI, NXP etc. wirklich > codekompatibel zu halten (Stichwort CMSIS) Auch die Peripheriebibliotheken? Ich meinte eigentlich, dass Microchip eine sehr stabile Firma ist, die auf sowas spezialisiert ist, während bei ST und TI die Mikrocontroller-Sachen neben vielen anderen Produkten laufen. Außerdem werde ich ST schon aus dem Grunde nicht nehmen, dass deren Flash-Seite im Jahre 2011 nicht mal läuft - ständig "not found". Wie soll man da etwas finden? Das müssen völlige Idioten sein, die haben sich damit komplett aus den Google-Suchergebnissen herausgeschossen. Außerdem finde ich deren Eval-Boards zu spartanisch.
> Was genau ist das Problem beim PIC32? Interessiert mich, da ich mich > noch nicht entschieden habe :) Es gibt keins. Sind ordentlich schnell und bieten jede Menge Peripherie. Das gilt aber gleichermaßen für die ARM basierten Controller. Ich nutze schon länger Produkte von Microchip (18F und PIC32) und bin sehr zufrieden. Die Libs sind gut, und mit Ethernet, USB, FAT, CAN, Grafik, ... ist eigentlich alles dabei was man sich wünscht. Auch die Microchip FAEs sind sehr zuvorkommend und hilfbereit.
Hans W. schrieb: >> Was genau ist das Problem beim PIC32? Interessiert mich, da ich mich >> noch nicht entschieden habe :) > Es gibt keins. Ach, bist du denn der Autor von Beitrag "Re: ARM vs. PIC32" ? An den war nämlich die Frage gerichtet.
Ich werde auch nur mit den PIC32 anfangen, weil ich vorher schon viel mit 8bit PICs gemacht habe. Denke viele, die sich am Anfang für die AVRs entschieden haben, bleiben bei Atmel und somit ARM. Habe nur mal gehört, dass Microchip mehr auf Multimedia Wert legt, wobei ich nicht weiß was da dran ist. Anguel S. schrieb: > spartanisch. ha, wortwitz "SPARTAN-isch"^^
Anguel S. schrieb: >> Das ist meiner Ansicht nach ein grosses Plus für ARM. Stichwort 2nd > >> source. Und ARM bemüht sich extrem, ST, TI, NXP etc. wirklich > >> codekompatibel zu halten (Stichwort CMSIS) > > Auch die Peripheriebibliotheken? So merkwürdig es klingt: Die Idee geht in diese Richtung, ja. Ich habe aber absichtlich das Verb "bemühen" verwendet. :-) Naja, Microchip ist meines Wissens vor nicht soooo langer Zeit mit 8Bittern (den Ur-Pics) auf dem Markt erschienen. Und diese Ur-Pics waren damals schon um etwa ein Jahrzehnt veraltet (Akkumulatormaschinen, keine conditional branches, HW-Stack --> Kaum ein Compiler wollte sich damit rumschlagen). Wie gesagt: so sehr kenne ich mich mit Microchip nicht aus. Mein Bauchgefühl, mit Erinnerung an diesen Pic-Knorz lässt mich diese Firma einfach nicht soooo professionell in dieser Sparte erscheinen, verglichen mit z.B. dem grössten Halbleiterunternehmen Europas (ST) (zugegeben - von deren eigenen 8-Bit-Architektur ich wenig bis gar nichts weiss). Ausserdem muss ich als Schweizer ja fast zu STM32 halten! ;-) Wer hat's erfunden?
Simon Huwyler schrieb: > Naja, Microchip ist meines Wissens vor nicht soooo langer Zeit mit > 8Bittern (den Ur-Pics) auf dem Markt erschienen. Ja, nicht sooo lange her, so 1976, 1977 ungefähr. ;-)
Sicher?? wow, das wusste ich nicht. Eben, wie schon geschrieben, ich sprach von Bauchgefühl. Auch bin ich überzeugt, dass PIC32 überhaupt nichts mehr mit PIC zu tun hat. Und ich bin immernoch der Meinung, dass es nicht soooo drauf an kommt, welche Hardware man reitet - solange man das Reiten beherrscht. :-)
Jörg Wunsch schrieb: > Ja, nicht sooo lange her, so 1976, 1977 ungefähr. ;-) Damals ist zwar der erste PIC aufgekreuzt, der Vorläufer der 12-Bit PICs, aber nicht von Microchip sondern von General Instrument. Microchip hat die erst 1989 aufgekauft.
A. K. schrieb: > Jörg Wunsch schrieb: > >> Ja, nicht sooo lange her, so 1976, 1977 ungefähr. ;-) > > Damals ist zwar der erste PIC aufgekreuzt, recht ähnlich den PIC10/12, > aber nicht von Microchip sondern von General Instrument. Microchip hat > die erst 1989 aufgekauft. BLÖDSINN MICROCHIP IST die IC Sparte von GENERAL INSTRUMENTS... Wurde nur 1989 Ausgegründet. Wie bei vielen anderen Halbleitersparten großer Unternehmen auch der Fall.(z.B. bei Motorola, Siemens, Oder um beim Thema zu bleiben : NXP was mal Phillips war) Immer dieses Halbwissen... Aber das passt auch zu den tollen PIC vs. AVR vergleichen wo dann immer ein Baustein ausgesucht wird der von MC bereits in den frühen 90er Jahren auf den MArkt gebracht wurde mit einem nach 2000 auf den Markt gekommenden AVR verglichen wird... (Und NEIN, es liegt daran das es keine Leistugnsfähigeren , aktuellen PICs gäbe) Gruß Carsten
Simon Huwyler schrieb: > Auch bin ich überzeugt, dass PIC32 überhaupt > nichts mehr mit PIC zu tun hat. Naja der Core, aber die Peripherals sind sogar mehr oder weniger noch zu den alten PICs kompatibel ;) Microchip eben... > Und ich bin immernoch der Meinung, dass es nicht soooo drauf an kommt, > welche Hardware man reitet - solange man das Reiten beherrscht. :-) Naja, manche haben aber nicht mal einen Sattel :) Ich denke, dass es wirklich wichtiger ist, dass man passende Boards und gute fertige Bibliotheken hat, als die paar DMIPS mehr oder weniger und den Rest verstecken die Compiler mittlerweile auch.
Loonix schrieb: > Robert schrieb: >> - Tja, trotzdem spricht die Welt Englisch > > (Hr.Teufel?) > > Ne Ne, das ist ein anderer Robert. Schau nach, ich bin angemeldet und poste immer mit vollem Namen. Kommentar zum Thema Deutsch / Englisch. Man kann den Stackpointer durchaus als Kellerstapelzeiger beschreiben, allerdings wissen dann viele Techniker (deutsche) nicht mehr welche Geheimsprache gesprochen wird ;-) Das Beispiel ist aus meiner Studienzeit und der Prof. hat das damals ernst gemeint. Robert
Robert Teufel schrieb: > Man kann den Stackpointer durchaus als Kellerstapelzeiger beschreiben, Im Ernst? Ich dachte dass der Stapelspeicher die Alternative des Kellerspeichers sei, nicht des Kellerstapelspeichers, es sich also um den Kellerzeiger handeln müsse. ;-)
Die Wortwahl ist unerheblich da zumindest der PIC32 ueber keinen Kellerstackzeiger (Hardware - Stack) verfuegt.
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.