PIC32MZ vs. Atmel

m.n. schrieb:
> Zum Beispiel mit einem ATtiny13,

Ja, nen Tiny13 mit 512KB RAM und Ethernet hätte ich auch gern. ;-)

Hat sich magic smoke einen neuen Namen zugelegt?

Mikc schrieb:
> Mit welchen Atmel-µCs lassen sich diese Controller vergleichen?

z.B. mit dem ATSAM4SD32B:
- ARM Cortex-M4

Peter Dannegger schrieb:
> Mikc schrieb:
>> Mit welchen Atmel-µCs lassen sich diese Controller vergleichen?
>
> z.B. mit dem ATSAM4SD32B:
> - ARM Cortex-M4

Der gennannte Atmel uC ist deutlich langsamer/kleiner als der PIC32MZ.
So auf die schnelle verglichen:
150DMIPS vs. 330DMIPS
160KB RAM vs 512KB RAM
Kein Ethernet, kein CAN

Gibt es denn fuer die PICs ueberhaupt eine Opensource toolchain bzw. 
brauchbare Software fuer Linux?

MfG

Stephan B. schrieb:
> Gibt es denn fuer die PICs ueberhaupt eine Opensource toolchain bzw.
> brauchbare Software fuer Linux?

Die 32-Bit MIPS Architektur existiert schon seit den 80ern, als Basis 
der SGI Rechner, und wurde folglich bereits früh vom GNU Compiler 
unterstützt.

m.n. schrieb:
> Hast Du den PIC auf dem Tisch zu liegen und er ist Dir zu langsam, dass
> Du jetzt einen Ersatztyp suchen mußt?

Neugierig sein ist Teil des Geschäfts und nicht strafbar.

Da die PIC32MZ schon seit einigen Jahren in Entwicklung sind und mehr 
oder weniger Berichten zufolge überfällig, werden sie wohl nun in 
absehbarer Zeit verfügbar sein.
So gibt es bspw. auch schon Preise vom PIC32MZ2048ECH144
http://www.digikey.com/product-detail/en/PIC32MZ2048ECH144-I%2FPH/PIC32MZ2048ECH144-I%2FPH-ND/4500846

Dennoch, die Frage ist Quatsch. ATMEL scheint beim Überfliegen deren 
Produktkatalogs momentan keinen vergleichbaren zu haben. Da das aber 
nicht bedeutet, dass sie nicht was noch besseres haben, ist die Frage, 
was das Wissen nun einem weiterbringt, keine Ahnung.

m.n. schrieb:
> Aber gut PIC vs. AVR muß wohl mal wieder stattfinden.

Schreib MIPS vs ARM, dann klingt es nicht so altbacken. ;-)

Sven P. schrieb:
> Microchip steht im Ruf, ausführliche Errata zu schreiben. SCNR

Wobei in hier betrachteten Kategorie eine umfangreiche Sammlung an Bugs 
kein Alleinstellungsmerkmal von Microchip ist. Interessanter wäre, wer 
von den Herstellern ehrlicher ist, d.h. auch wirklich alle bekannten 
Bugs brav aufführt, und nicht etwas schummelt.

Nicht immer nett ist Microchips Eigenheit, Bugs gerne in Form neuer 
Typen verwandter Funktionalität zu fixen. Also statt den alten Typ zu 
reparieren, einen neuen Typ mit erweiterter Funktion zu bringen, in dem 
einige alte Bugs durch neue ersetzt werden.

Moin moin, bin auch mal wieder da.

Meiner Meinung nach hat Atmel keinen direkt vergleichbaren Chip. Die 
SAM4 bauen auf den Industrie Standard Cortex-M auf und werden von viel 
mehr Entwicklungstools unterstuetzt als der MIPS basierende PIC32.
Falls einer den Controller einsetzen will um den DMIPS Benchmark 
moeglichst schnell auszufuehren, dann ist der PIC wohl schneller. Wenn 
man allerdings die Zusatzbefehle beider Architekturen einsetzt, bin ich 
mir nicht mehr so sicher.
Atmel hat auch eine wunderschoene SAM5 Familie
http://www.atmel.com/Microsite/sama5d3/default.aspx
Die ist auch nur bedingt vergleichbar, denn sie ist VIEL schneller als 
der PIC32 bei vermutlich geringerem Preis, weil der Programmspeicher 
nicht auf dem Chip ist.

Also Atmel hat was schnelleres ohne Flash und was langsameres mit 
weniger Speicher, beide vermutlich deutlich guenstiger (hab die Preise 
noch nicht gesehen).

Gruss aus dem sonnigen Kalifornien

Robert

Ausführlicher:
http://ww1.microchip.com/downloads/en/Market_Communication/Microchips%20PIC32MZ%20Press%20Presentation.pdf

Den Preisen auf Digikey zufolge kosten der PIC32MZ, ATSAM4SD32B, sowie 
SAMA5D3 uC alle gleich viel, wodurch der PIC32MZ 
Preis/Leistungs-Technisch besser dasteht.

W.S. schrieb:
> Was ich an Vorankündigungen zu dieser PIC-Familiegelesen habe, klang mir
> nach Stückwerk:
> - ein Haufen DMA's, aber kein TFT-Controller
> - ne MMU, aber kein zu sowas passender externer Bus (kein SDRAM, kein
> DDRAM, nur 8 oder 16 Bit breit)
>
> und so weiter. Alles völlig unausgegoren, aber wahrscheinlich tut sich
> da in den nächsten Monaten noch so viel, daß man den jetzigen Stand in
> den finalen Chips garnicht wiedererkennt.

Wie gerne würde ich dir da zustimmen, aber genau dieser Stand ist leider 
aktuell das Produkt das du kaufen kannst.

Und ja, ich hab den auf dem Tisch und ja, ich weiß das auch schon 
länger. Es sind PICs in der Pipeline die diese Schwachstellen 
adressieren, aber nachdem wir schon 2 Jahre auf die MZ warten (mit sich 
kaum veränderten Spezifikationen) kann noch viel Zeit vergehen bis da 
was nachkommt.

Was ich nebenbei grandios finde: Es gab vor 3 Wochen einen Thread mit 
dem Titel PIC32MZ... Kaum 10 Beiträge und in der Versenkung 
verschwunden.

Jetzt kommt PIC32MZ vs. Atmel und die Leute kriegen sich kaum mehr ein 
vor Anteilnahme...

Michael H. schrieb:

> Und ja, ich hab den auf dem Tisch und ja, ich weiß das auch schon
> länger. Es sind PICs in der Pipeline die diese Schwachstellen
> adressieren, aber nachdem wir schon 2 Jahre auf die MZ warten (mit sich
> kaum veränderten Spezifikationen) kann noch viel Zeit vergehen bis da
> was nachkommt.

... wobei das möglicherweise auch mit dem Eigentümerwechsel von MIPS 
zusammenhängen mag.

fchk

Frank M. schrieb:
> Da die PIC32MZ schon seit einigen Jahren in Entwicklung sind und mehr
> oder weniger Berichten zufolge überfällig, werden sie wohl nun in
> absehbarer Zeit verfügbar sein.
Und ich warte auch schon seit Jahren, endlich sind da soweit :-)
Meiner ist an Dienstag angekommen, leider fehlt mir die Zeit etwas zu 
testen.

Stephan B. schrieb:
> Gibt es denn fuer die PICs ueberhaupt eine Opensource toolchain bzw.
> brauchbare Software fuer Linux?

Ja gibt es, und die Compiler kannst du auch kommerziell nutzen, 
natürlich hast du dann keine Optimierung.


Gruß
Hermann

Hermann U. schrieb:
> Ja gibt es, und die Compiler kannst du auch kommerziell nutzen,
> natürlich hast du dann keine Optimierung.

Wie siehts denn bei dieser ominösen Optimierung überhaupt aus? Bei den 
PIC30/33 verwendet Microchip ja den GCC und glaub irgendwie nicht recht, 
dass das beim PIC32 anders ist. Insofern sollte das Thema Optimierung 
wohl nicht so zentral sein. Weil man unter Linux in der Lage sein 
sollte, ggf. auch direkt den offiziellen GCC zu verwenden.