ARM vs. PIC32

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.

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.

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

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.

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)

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. ;-)