www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATMEL billiger und leistungsfähiger als PIC


Autor: Mark Thalle (bitts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich beschäftige mich seit langem mal wieder mit µCs und stelle fest, 
dass (fast?) alle ATMELs einen integrierten Taktgenerator mit 10MHz 
haben und damit 10 Mio Befehle/s abarbeiten können.
Etwas vergleichbares finde ich bei PICs nicht. Da gibt es nur selten 
8MHz, die nur 2 Mio Befehle/s bringen.

Obendrein sind die ATMELs auch noch preiswerter.

Sehe ich das richtig, dass die PICs da derzeit nicht mithalten können?

Autor: (geloescht) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(Dieser Beitrag wurde geloescht)

Autor: Clifford (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
von diesen hochgetakteten Teilen halte ich gar nichts. Vielleicht kennt 
jemand die CMUcam2. Da ist ein mit 75MHz getakteter 8051 Clone drauf. 
Kann Color Tracking mit einem Objekt und einer Farbe und der UART musste 
afaik in Software emuliert werden. Zu allem Überfluß braucht die gesamte 
Cam weit über 200mA

Es gibt einen Nachbau mit einem ATmega8, der mit 17,7MHz getaktet wird. 
Heißt AVRcam. Kann Color Tracking mit 8 Objekten in 8 verschiedenen 
Farben und braucht dabei nur rund 50mA.

Meine Meinung: Wenn ein AVR nicht mehr reicht kann man gleich nen ARM 
nehmen

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zumal es recht "dicke" AVRs oberhalb des Mega128 gibt, die schon ´ne 
ganze Latte an Peripherie mitbringen und auch gut Speicher für 
extravagante Anwendungen haben.

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark Thalle wrote:
> Hallo,
>
> ich beschäftige mich seit langem mal wieder mit µCs und stelle fest,
> dass (fast?) alle ATMELs einen integrierten Taktgenerator mit 10MHz
> haben und damit 10 Mio Befehle/s abarbeiten können.
> Etwas vergleichbares finde ich bei PICs nicht. Da gibt es nur selten
> 8MHz, die nur 2 Mio Befehle/s bringen.

Es gibt viele 20MHz Typen (5 MIPS).
Die PIC18 laufen je nach Typ mit 25 bis 64MHz, das sind nach der 
Microchip'schen Division durch vier immer noch bis zu 16 MIPS.


> Obendrein sind die ATMELs auch noch preiswerter.

Welchen Vergleich legst Du zugrunde?


> Sehe ich das richtig, dass die PICs da derzeit nicht mithalten können?

"Die PICs" sind eine extrem breit gefächerte Familie vom 6-Pin-Typ bis 
zum 100-Pin Typ. Dabei kommen von USB über CAN bis zu DSP alle möglichen 
Features vor.

So gesehen kann ein realistischer Vergleich jeweils nur durchgeführt 
werden, wenn die Kriterien dokumentiert werden.
(wie hiess es damals noch: "Dash wäscht weisser...").

Severino

Autor: Mark Thalle (bitts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bezog mich jetzt auf die typischen Bastel-µCs mit FLashspeicher in 
der 2-Euro-Klasse.

Da finde ich keinen PIC, der mit einem ATMEL mithalten kann, was die 
Rechenleistung und den Preis angeht. Vor allem finde ich auch den 
internen Takt von 9,6 MHz extrem praktisch.


Autor: Clifford (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf der CMUcam ist ein SX52 von Ubicom. 75MIPS @ 75MHz. Hat 3 Timer, nen 
Watchdog und das wars. Und dafür brauch er bei 75MHz noch >100mA. 
Irgendwie unbefriedigend.

>>"Die PICs" sind eine extrem breit gefächerte Familie vom 6-Pin-Typ bis
>>zum 100-Pin Typ. Dabei kommen von USB über CAN bis zu DSP alle möglichen
>>Features vor.

Naja, die neuen 16 Bit PICs kann man mit den "klassischen" ja nicht 
vergleichen. Da darf ich dann auch die AVR32 (zumindest die UC3) mit 
ranziehen. Die normalen AVR gibts auch von 8 bis 100 Pins, von 2-256kB 
Flash, USB, CAN, sogar FPGA. Und einen Controller mit >60MHz takten zu 
müssen um die Rechenleistung eines 16MHz Controllers zu erreichen? 
Kostet nur Strom

Also was Preis/Leistung/Energieverbrauch... angeht sind die AVR 
unschlagbar. Die neueste Generation mit PicoPower braucht nur noch gut 
die Hälfte der Energie bei gleicher Rechenleistung 
(ATmega32/ATmega324P). Mag sein das es für Spezialaufgaben besser 
Controller gibt.

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn ich z.B. mal einen Tiny 45 nehme, da gibt es zwar einige 
Befehle mit einem Takt, viele brauchen aber 2, 3 oder 4 Takte.

Was den Preis angeht, ist es ein Unterschied, ob du als Firma tausende 
einkaufst oder ob du Hobbybastler bist. Und selbst als Hobbybastler 
macht es z.B. einen Unterschied, ob du die Preise von Reichelt oder 
Conrad als Messlatte nimmst. Oder noch andere.

Mein letzter Vergleich bei sehr preiswerten Mikrocontrollern und 
Reichelt fiel auch zugunsten von AVR aus. Also die Klasse Tiny 11 oder 
Tiny 12/13. Die gibt es teilweise deutlich unter 1 Euro. Tiny 11 für 60 
Cent.

Nur: Was interessiert beim Basteln, ob ein Chip 1 oder 4 Euro kostet? 
Das ist doch absolut uninteressant. Die vielen Stunden, die man in ein 
Projekt steckt, da ist das völlig Peanuts. Und eine Holzleiste, die man 
im Baumarkt kauft, um sie irgendwo im Projekt zu verbauen, kostet schon 
3-5 Euro.

Anders sieht es aus, wenn man einige hundert Stück von irgendwas baut.

Autor: Clifford (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Winfried: was das angeht geb ich dir völlig recht. Ein paar Cent rauf 
oder runter sind im Hobbybereich egal. Deshalb verstehe ich auch nicht 
warum viele unbedingt immer den kleinstmöglichen Controller für etwas 
verwenden wollen. Ich nehm sicherheitshalber immer 1-2 Nummern größer, 
sofern die Größe keine Rolle spielt

Autor: Roland Praml (pram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also aer Vergleich AVR vs PIC ist ja irgendwie wie der Vergleich Linux 
vs Windows.
Alles hat seine Vor und Nachteile.

Ich bevorzuge als Hobbybastler die AVR's, da ich bis jetzt weder einen 
PIC, R8C oder MSP430 programmiert noch verbaut habe. Diese haben sicher 
auch einige Vorteile, bei denen sie gegen die AVR's punkten können, aber 
wenn ich die Einarbeitungszeit wieder rechne, spricht das bei einem 
Bastelprojekt eindeutig gegen einen Wechsel.

Wenn es nicht unbedingt sein muss und nicht unbedingt das Feature X vom 
Chip Y brauche, werd ich also noch ne Weile bei den AVR's bleiben :-)

Gruß
Roland

Autor: Mark Thalle (bitts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als ich heute gesehen habe, dass die ATMELs alle eine interne 
Taktversorgung haben, die keine externen Bauteile mehr benötigen, war 
ich überrascht.
Und wenn man vergleichbare uCs zu PIC 16Fxxx von AVR ranzieht, dann sind 
die AVRs meistens schneller. Insofern finde ich das schon einen 
beachtlichen Vorteil.

Der Preisunterschied mag nicht gewaltig sein und für Bastelprojekte auch 
nicht entscheidend, aber man kauft ja auch nicht nur einen Baustein, 
wenn man etwas bestellt, sondern gleich das Eine oder Andere dazu, was 
man meint bald mal gebrauchen zu können. Und wenn man dann 5 statt 2 
Euro hinlegt, dazu noch die passenden Quarze und Kondensatoren, dann ist 
man schonmal einen Zwanni mehr quitt.

Da ich gerade im Bereich Modellbau bastele, kommt es auf die Größe und 
das Gewicht an. Da fänd ich es schon angenehm, wenn ich mir ein 
zusätzliches Quarz sparen könnte und damit nicht auf der möglichst 
kleinen Lochrasterplatine die Portpins zubauen müsste.

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Sehe ich das richtig, dass die PICs da derzeit nicht mithalten können?

Naja - das ist wieder ein halbes Troll-Posting ...

Jeder nimmt das her was er kennt und woran er sich gewöhnt hat, ABER: in 
der Industrie setzt sich immer der preisgünstigste Controller durch der 
die gewünsche Aufgabe zufriedenstellend erledigen kann. Und hier können 
die PIC sehr wohl mithalten!

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PICs sind GRATIS... hab noch nie einen Controller kaufen müssen, bestell 
mir regelmäßig Samples...

Aber dieses PIC vs. AVR ist schon so oft diskutiert worden, nehmt doch 
was ihr wollt. Beim Entwickeln von Elektronik geht es schlussendlich nur 
darum, dass die Entwicklung das macht was man von ihr erwartet. Ob man 
das mit einem AVR oder PIC macht ist dann egal. Man kann PIC und AVR 
auch nicht wirklich gegenüberstellen. Bei PIC, auch wenn er schlechtere 
Performance hat, hat man eben mehr Auswahl an Typen mit 
unterschiedlichen Peripherien.
Es geht nicht nur um MIPS!!! Wer MIPS braucht soll sich einen BF561 
zulegen und taktet ihn mit 600MHz...


Aber mein ARM7 kann viiiieeeeellll mehr als eure klumpigen AVRs und PICs 
ätsch

lol

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber mein ARM7 kann viiiieeeeellll mehr als eure klumpigen AVRs und PICs
> *ätsch*

Full ACK :-)

Autor: Clifford (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>PICs sind GRATIS... hab noch nie einen Controller kaufen müssen, bestell
>mir regelmäßig Samples...

Schnorrer

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Clifford wrote:

> Schnorrer


Tja man tut was man kann ;-)

Aber das ist für Firmen ganz legitim.

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Aber mein ARM7 kann viiiieeeeellll mehr als eure klumpigen AVRs und 
PICs
*ätsch*"


Aus dem Alter bin ich raus.
Ich benutze nur noch die ARM9 (von ST). Mehr Speicher, schneller durch 
längere Pipeline und höheren Takt, etc. pp.

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenns den ARM9 in kleineren Bauformen geben würde und dann noch per Hand 
lötbar, würd ich dir zustimmen.

Ich hab in meinem letzten Projekt einen AT91RM9200 verwendet, der funzt 
auch recht gut.

Autor: Marius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das programmieren der ARM9er ist aber nicht so einfach wie AVR oder 
ARM7. Geht ja nix mehr ohne Betriebssystem (linux). Dann muss man ja 
irgendwie treiber für seine peripherie programmieren (kA mit was für 
funktionen linux dafür schon daher kommt) usw.

Es fehlt auch an solch schönen tutorials für ARM7 und ARM9 wie die 
beiden AVR tutorials auf dieser Seite.

Autor: Bastler0815 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also was Preis/Leistung/Energieverbrauch... angeht sind die AVR
unschlagbar

So ähnlich hatte ich auch gedacht, bis ich mich mal mit der MSP430 
Familie von TI beschäftigt habe. Seit dem bleiben die AVRs in der Kiste.

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Das programmieren der ARM9er ist aber nicht so einfach wie AVR oder
ARM7. Geht ja nix mehr ohne Betriebssystem (linux). Dann muss man ja
irgendwie treiber für seine peripherie programmieren (kA mit was für
funktionen linux dafür schon daher kommt) usw."


Das ist Quatsch.
Der ARM9 ist schlichtweg ein aufgebohrter ARM7. Insofern (fast) kein 
Unterschied.
Ich nutze die einfachste Variante, nicht die mit FPU oder MMU.
Ein bißchen komplexer als ein AVR, aber der Umstieg vom AVR zum ARM9 ist 
nicht komplexer als der Einstieg in die Mikrocontrollerwelt.

Im Übrigen läßt sich der STR9-80Pinner mit ruhiger Hand recht einfach 
löten. So viel größer als ein 64Pinner ist der auch nicht.

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heee!

Hier ging es um PIC und AVR!

Bitte, ARM7- und ARM9-Fans, und Fans von Exoten, eröffnet doch einen 
eigenen Thread für Euch.

Die Diskussion um PIC vs. AVR ist endlos.
Ganz im Ernst: sachliche Argumente wären sehr nützlich, sind aber in der 
ganzen Komplexität kaum statisch darstellbar.
Eine einfache Tabelle mit Kriterien und Plus- und Minus-Punkten reicht 
da nicht, da offensichtlich die Kriterien sehr individuell gewichtet 
werden (inkl. Entwicklungsumgebung, Einarbeitungsaufwand, Support, 
langfristige Verfügbarkeit, ...)

Severino

Autor: Bastler0815 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Severino R.:

Dann hätte die Aussage aber lauten müssen:
"Also was Preis/Leistung/Energieverbrauch... angeht sind die AVR in der 
Klasse bis 2,- EUR den PIC in der Klasse bis 2,- EUR überlegen"

Zudem würde ich die MSP430 - Familie nicht als Exoten bezeichnen.

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Bastler0815

Nimm's nicht persönlich mit den "Exoten". Die MSP430 sind hervorragende 
Controller, nur leider weniger bekannt als andere.
Ich wollte damit sagen, dass es ja schon schwierig ist, PIC und AVR 
einander gegenüber zu stellen. Wenn jetzt auch noch andere Produkte ins 
Spiel kommen....

Die zitierte Aussage ist ja nicht von mir.
Aber Du siehst, es ist absolut unmöglich zu sagen, welcher Controller 
der bessere ist, da Uneinigkeit herrscht über die Bewertungskriterien 
und deren Gewichtung.

Wertvoll wären Aussage wie: "Wenn Feature xxx ein Muss ist, dann ist Typ 
yyy im Vorteil". Alle wesentlichen Kriterien und deren Werte pro 
Mikrocontroller darzustellen bedeutet eine mehrdimensionale Tabelle 
erstellen.
Was toll wäre (wenigstens für die "harten" Kriterien), einen Product 
Selector zu haben, wo man Kriterien auswählen und denen einen Minimum- 
und Maximum-Wert zuordnen, so wie die Tools auf den Websites des 
Hersteller.
Doch das Ganze müsste dann herstellerübergreifend sein... 
(Wunschdenken).

Severino

Autor: Arno M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwei klare Vorteile von den PIC'S:
1) Vieeel bessere Dokumentation (Datasheets)
2) für low power Anwendungen mehr Möglichkeiten und deutlich weniger 
Stromverbrauch.
Grüße
Arno M.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klare Argumente:
- Es gibt keinen Freeware C-Compiler für PICs.
- MPLAB ist dem AVR Studio unterlegen (maximal 64 Zeichen für die 
Verzeichnis/Dateinamen, es gab Versionen die Windows zerstört haben, die 
Anordnung der einzelnen Fenster durcheinander finde ich lässtig, usw.)
- AVRs haben 32 Arbeitsregister, PICs nur 1. Bei geschickter 
Programmierung kann das ein ordentlicher Gewschwindigkeitsvorteil 
bringen kann. Dafür muss man bei AVRs erst alle Variablen in die 
Register laden. Meiner Erfahrung nach, sind AVRs entweder bei sehr 
einfachen Programmen wo man alle Variablen in den Registern lassen kann 
etwa schneller als PICs bei gleichen MIPS, ebenso bei komplizierten 
Operationen mit 16 oder 32Bit. Hier erspart man sich beim AVR das 
ständige Laden der Werte aus den File Registern.
- AVRs haben einen durchgehenden Speicherbereich, kein Banking. Das ist 
nur eine Fehlerquelle und ist lästig.

Die PIC Datenblätter der PICs halte ich für eine Katastrophe, wenn man 
mal was sucht. Teilweise sind die ziemlich chaotisch organisiert.

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Severino:
> Heee!

> Hier ging es um PIC und AVR!

> Bitte, ARM7- und ARM9-Fans, und Fans von Exoten, eröffnet doch einen
> eigenen Thread für Euch.
Der OP hat in seinem Posting weder im Betreff noch im Text an 
irgendeiner Stelle den Begriff "AVR" erwähnt! Da steht nur was von 
ATMEL, und die bauen auch ARMs...

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:
> Klare Argumente:
> - Es gibt keinen Freeware C-Compiler für PICs.
Ist das erforderlich? Willst Du am Compiler herumentwickeln?

> - MPLAB ist dem AVR Studio unterlegen (maximal 64 Zeichen für die
> Verzeichnis/Dateinamen, es gab Versionen die Windows zerstört haben, die
Nimm doch einfach die aktuelle statt einer früheren Version.

> Anordnung der einzelnen Fenster durcheinander finde ich lässtig, usw.)
Kannst Die Fenster ja anordnen wie Du willst.

> - AVRs haben 32 Arbeitsregister, PICs nur 1. Bei geschickter
> Programmierung kann das ein ordentlicher Gewschwindigkeitsvorteil
> bringen kann. Dafür muss man bei AVRs erst alle Variablen in die
> Register laden. Meiner Erfahrung nach, sind AVRs entweder bei sehr
> einfachen Programmen wo man alle Variablen in den Registern lassen kann
> etwa schneller als PICs bei gleichen MIPS, ebenso bei komplizierten
> Operationen mit 16 oder 32Bit. Hier erspart man sich beim AVR das
> ständige Laden der Werte aus den File Registern.
Stimmt!

> - AVRs haben einen durchgehenden Speicherbereich, kein Banking. Das ist
> nur eine Fehlerquelle und ist lästig.
Stimmt! Mit der Zeit weiss man's aber. Und dem C-Programmierer ist es eh 
egal.


Und jetzt noch das:

> Die PIC Datenblätter der PICs halte ich für eine Katastrophe, wenn man
> mal was sucht. Teilweise sind die ziemlich chaotisch organisiert.

Arno M. wrote:
> Zwei klare Vorteile von den PIC'S:
> 1) Vieeel bessere Dokumentation (Datasheets)

Was jetzt? Hier geht es wohl um persönliche Vorlieben.

Severino

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entschuldigung für folgende Destruktivität...

...aber ich werd mir jetzt doch einen Formel-1-Boliden kaufen statt 
einem VW Golf, weil Golf Sch*** ist...


Man kann nicht so adhoc sagen welchen Controller man nehmen soll, 
einfach ausprobieren. Was einem liegt soll man nehmen. Die Entscheidung 
ist sowieso immer subjektiv und nur weil jemand aus diesem Forum meint 
AVR ist besser geeignet um irgendwelche LEDs zu schalten heißt dass noch 
lange nicht, dass der auch geeignet ist um Video Streaming zu 
realisieren.

Also weg von diesem Schwachsinn PIC und AVR zu vergleichen. Betrachtet 
eure Anforderungen und dann sucht nach dem Controller der das schafft. 
Da irgendwelche Thesen und Meinungen bezüglich eines Typs kundzutun ist 
ja absolut wertlos. Die Energie die ihr dabei verbratet müßt ihr beim 
Abendessen wieder tanken, das kostet Geld, sicher mehr als 2€... damit 
könnte man einen AVR kaufen ggg
Diese Diskussion wird nie ein Ende finden... Weshalb mit jemanden 
diskutieren der auf BLAU steht, wenn ich selbst überzeugter GELB 
Fetischist bin...

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  johnny.m

Der OP hat anschliessend präzisiert:

> Ich bezog mich jetzt auf die typischen Bastel-µCs mit FLashspeicher in
> der 2-Euro-Klasse.

Wo gibt's ARMs von ATMEL für 2 Euro?

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Severino R. wrote:

> Wo gibt's ARMs von ATMEL für 2 Euro?


Hier gibts ARMs für 0 Cent ;-)
http://www.atmel.com/forms/Samples.asp?family_id=605

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Thomas P.

Also, der Formel-1-Bolide wäre in ROT auch sehr schön, oder neuerdings 
doch eher SILBER?

Hast aber im Prinzip recht. Wie oben schön zu sehen ist, werden immer 
"weiche" Kriterien angeführt, wo man ja geteilter Meinung sein kann.

Das mit dem Banking / Paging bei den meisten PICs ist aber wirklich 
nicht so toll, das muss ich als Microchip-Kunde wirklich sagen.

> Hier gibts ARMs für 0 Cent ;-)
So, dann bestell mir doch bitte mal ein paar Hundert davon.


Severino

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja das Banking ist mir in der Hinsicht egal, weil das erledigt eh mein 
Compiler...

Ich verwende auch PIC. Der Grund ist einfach der, weil die damals, liegt 
schon einige Jährchen zurück, für MICH (subjektiv) bessere 
Entwicklungsumgebungen und ausgereiftere Peripherie zur Verfügung 
gestellt haben und ich außerdem die Controller haufenweise geschenkt 
bekommen habe...


Würde ich jetzt neu einsteigen, würd ich weder PIC noch AVR nehmen 
sondern direkt nach ARM greifen. Aber wie gehabt, alles eine 
Gefühlsentscheidung...

Bei den meisten Projekten werden die Controller ohnehin 
überdimensioniert, da brauch ich nicht wegen ein paar einzelnen MIPS 
heulen.

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Severino R. wrote:


> So, dann bestell mir doch bitte mal ein paar Hundert davon.



Willst dir damit den Fussboden pflastern? g

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Severino:
> Wo gibt's ARMs von ATMEL für 2 Euro?

Ist ein Argument...

es ging mir aber eher darum, dass ich durchaus verstehen kann, dass bei 
einer solchen Fragestellung logischerweise Antworten aus dem Bereich 
kommen. Man fragt ja auch nicht "Was ist besser, ATMEL oder Philips?", 
gelle?

Bei der Dokumentation denke ich auch, dass das durchaus mit persönlichen 
Vorlieben zu tun hat. Ich persönlich finde die Datenblätter und sonstige 
Dokumentation von ATMEL im Prinzip sehr gut (ausführliche Beschreibung, 
übersichtlicher Aufbau), mit einigen Abstrichen was bestimmte kleine 
aber feine Fallen angeht, deren Beschreibung irgendwo versteckt ist, wo 
man sie nicht auf Anhieb vermuten würde (z.B. die berühmte M103C-Fuse 
bei den ATMega103-Derivaten, die anderen Anschlüsse für die ISP bei eben 
diesen Bausteinen und noch ein paar andere Kleinigkeiten, nach denen man 
sich beim ersten Mal den Wolf sucht). PIC-Datenblätter kenne ich 
allerdings nur vom "mal reinschauen", da ich nicht mit PICs arbeite, 
hatte jedoch von dem was ich gesehen habe zumindest auf den ersten Blick 
keinen großartig negativen Eindruck (Auch was den oben mal kritisierten 
Aufbau angeht). Ich denke, es hängt im Wesentlichen davon ab, mit 
welchem System man angefangen hat. Irgendwann kennt man die Eigenheiten 
"seiner" Controller und speziell der Dokumentation. Und das ist 
weitgehend unabhängig vom Hersteller. Richtig "schlechte" Datenblätter 
kann sich ein namhafter Hersteller auf Dauer nicht leisten... Beim 
Umstieg auf einen anderen Hersteller muss man sich dann eben mit dessen 
Datenblatt-"Philosophie" anfreunden.

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas P. wrote:
> Severino R. wrote:
>
>
>> So, dann bestell mir doch bitte mal ein paar Hundert davon.
>
>
>
> Willst dir damit den Fussboden pflastern? *g*

Nein, aber wenn wir von Preisen sprechen, dann sollen es normale 
Handelspreise sein, auch in beliebigen Mengen, und keine einzelne 
Gelegenheiten, die nicht beliebig wiederholbar sind wie:
Samples, Geschenk, Ausschlachen aus altem Gerät, Diebstahl, "ohnehin 
rumliegen haben".

Ein Preisvergleich von Samples ist ja nicht möglich, und ein Teil, das 
nicht als Sample erhältlich ist, kosten sonst ja unendlich Prozent mehr 
als ein Sample!

Severino

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
johnny.m wrote:
> es ging mir aber eher darum, dass ich durchaus verstehen kann, dass bei
> einer solchen Fragestellung logischerweise Antworten aus dem Bereich
> kommen. Man fragt ja auch nicht "Was ist besser, ATMEL oder Philips?",
> gelle?

Anscheinend ist es verbreitet, ATMEL als Synonym für AVR zu verwenden, 
da die anderen Controller von ATMEL ('51 und ARM) ja eben nicht 
ATMEL-typisch sind,  sondern Cores verwenden, die auch bei anderen 
Herstellern eingesetzt werden.

Bei einigen Kriterien ist aber die Frage nach ATMEL als Hersteller 
berechtigt (oder bei Microchip für die PICs): Firmenpolitik, ökologische 
und ethische Aspekte, Herkunftsland. Diese haben nichts mit der 
Architektur zu tun.

Ansonsten bin ich betr. Dokumentation mit Dir einverstanden.

Severino

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also seit es von Atmel den AVR-Dragon gibt, hab ich ein absolutes
Totschlagargument für Atmels. Jeder der mal eine ganze Weile einen
Fehler gesucht hat und bisher nur von Debugtools (z.B. JTAG-ICE)
träumen durfte, hat jetzt die Möglichkeit relativ günstig an sowas
ranzukommen.

Vergleichen wir mal( allgemein - Tools ):

PIC:
----

ISP-Programmer: (gibts wie Sand am mehr für ca. 10-20 Euro - Eigenbau)
Debug-ICD2 von Microchip: ca. 300-400 Euro
Nachbau ICD2: ca. 30 Euro (nur RS232 und SEHR langsam. Meiner Meinung 
nach
zu langsam für vernünftiges Arbeiten.
(Es gibt zwar einen Nachbau mit USB-Chip, dieser Chip ist allerdings
abgekündigt und nicht mehr allzu leicht zu bekommen! kostet ca. 20 Euro)
Der Picstart Plus  - hier nicht weiter aufgeführt, weil schon durch
ISP Programmer oben "ausgestochen vom Preis her)

Atmel:
------

ISP-Programmer wie bei PIC (gleiche Preisklasse - Eigenbau)
Debug-Tools: ca. 200-250 Euro JTAG-ICE MK2 (sehr schönes Gerät ;) )
Nachbau Evertool (alter JTAG ICE) ca. 30 Euro (Lochraster ;) )
(kann kein Debug-Wire, dafür kann er alle "klassischen AVRs mit JTAG
ohne Begrenzung (siehe Dragon) debuggen und Flashen(JTAG))

AVR-Dragon: ca. 60 Euro (JTAG, Debug-Wire, HighVoltage parallel Prog.)
meiner Meinung nach unschlagbares Preis-Leistungs-Verhältnis, aber
kann keine Devices mit mehr als 32k Flash Debuggen (ok, Atmel möchte ja 
auch noch die teuereren JTAG-ICE MK2 verkaufen ;) )
Für Hobbyzwecke und "kleine Projekte" absolut unschlagbar.

Ach ja, wer sich mal einen Ausflug zur "Embedded World" leisten will;
dort wurden die Teile letztes Mal verlost. Hab auch einen abgestaubt ;)

Es gibt wohl kaum jemand, der schonmal mit Debug-Tools gearbeitet hat, 
der
hier sagen würde, dass es auch ohne Debug-Tool zeiteffiziente 
Fehlersuche
gibt. (gut, hängt von der Art der Fehler ab die man macht ;) )
Aber jedes Mal zusätzlichen Code für Fehlersuche einbauen ist auch
aufwändig und Zeitraubend, wenn man es viel einfacher mit nem Debug-Tool
geht.

Davon abgesehen, sind die Teile die USB beherrschen ziemlich schnell
was Programmierung und Debug betrifft.

Eine allgemeine Aussage noch:
-----------------------------
Einer meiner Profs hier an der Hooschule hat mal gesagt, dass einem 
jeder
Mikrocontroller spätestens nach 2-3 Wochen Einarbeitung "aus der Hand
fressen" sollte. Vorausgesetzt man kennt sich mit den Mikrorechner
Grundlagen aus.

Autor: Clifford (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, nochmal zusammenfassen:

AVR: preisgünstig, universell, schnell, stromsparend, einfach, 
kostenlose Software, preisgünstige Programmier- und Debughardware und 
ein unschlagbares Angebot von sehr hilfreichen Application Notes vom 
Hersteller selbst

Die Summe der Vorteile machts.

Für alle anderen Controller sprechen in bestimmten Fällen vielleicht 
besondere Gründe, zb in der viel zitierten Industrie wo ein 5 Cent 
billigerer PIC genommen wird, ein ARM wenn Rechenleistung und/oder 
Speicher nicht mehr ausreicht oder ein spezielles Feature wie MP3 oder 
DSP. Aber ich habe bisher noch nichts davon gebraucht.

Aber im Hobbybereich ist die Kombination der Vorteile ein erschlagendes 
Argument für die AVR. Oder für welchen Controller bekommt man ein 
komplettes Entwickungspaket mit C-Compiler, IDE, In System 
Programmer/Debugger usw für <100€ (selbstbastelkram mal weggelassen)?

Autor: EGO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für den PIC !
PICKIT2 koste ca. 50 €, MPLAB und C-Compiler (Student Edition) für die 
interresanteren PIC's (18) giebt es dazu, und debuggen kann das Ding 
auch schon (noch nicht viele, aber mit jeder neuen MPLAB Version werden 
es mehr). Einen ICD2 Clone ohne spezial Chips giebt's auch. Ein PIC 
16F877 und ein 18F4550 und ein wenig Kleinkram aus der Bastelkiste 
reichen.
MFG

Autor: D. H. (slyd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe schon viel mit beiden Controllerfamilien gearbeitet und finde 
beide gut!

So! :)




PS: Den C18 Compiler gibts umsonst - solange man den nur Privat 
verwendet und in Firmen sind die paar Euro eh nicht so wichtig (die 
würden für den AVR dann sowieso den IAR oder so kaufen)...

Achja und AVRStudio stürzt ständig ab und hat ein paar nervige Bugs (s. 
anderen Thread hier im Forum...) -  MPLAB läuft hingegen stabil.

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir ist AVRStudio noch nie abgestürtzt, aber ein paar nervige bugs 
gibts, das stimmt :> aber man lernt damit umzugehen.

Autor: Dieter Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> MPLAB läuft hingegen stabil.

Das hängt vom PC ab auf dem es installiert ist.
Ich kenne beides, sowohl stabiler Betrieb über mehrere Tage als auch 
Abstürze mehrmals am Tag.

Autor: Sascha Focus (sascha_focus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus eigener erfahrung, kommt es immer auf den Anwendungsfall und den 
eigenen Wünschen und Vorstellungen an. Selber nutze ich AVR, M16C, PSOC.
Vom Datenblatt her gefällt mir auch PIC24H. Diesen werde ich mir 
demnächst samt Pickit2 gönnen und begutachten. Einzigst das flashen von 
1000mal finde ich nicht zeitgemäß.

Gruß Sascha

Autor: Schorsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> - Es gibt keinen Freeware C-Compiler für PICs.

Es gibt eine kostenlose Studentenversion, die nach 90(?) Tagen lediglich 
spezielle Optimierungen abschaltet, auf die man eh verzichten kann zumal 
man kritische Teile ohne weiteres in ASM einbinden kann.

>- MPLAB ist dem AVR Studio unterlegen (maximal 64 Zeichen für die
>Verzeichnis/Dateinamen, es gab Versionen die Windows zerstört haben, die
>Anordnung der einzelnen Fenster durcheinander finde ich lässtig, usw.)

MPLAB erinnert mich so bisschen an DOS-Zeiten. Die Oberfläche, die 
Darstellung der Register usw. ist nicht sonderlich gut gelungegen. Dafür 
hat MPLAB einen ganz entscheidenden Vorteil: es läuft stabil*. Das neue 
AVR Studio ist einfach nur ne Katastrophe hinsichtlich Stabilität und 
Startverhalten.

>Die PIC Datenblätter der PICs halte ich für eine Katastrophe, wenn man
>mal was sucht. Teilweise sind die ziemlich chaotisch organisiert.

Bei Microchip gibt es halt ein Datenblatt sowie i. d. R. ein Family 
Reference Manual. Generell finde ich, dass Microchip ausgezeichnete, 
verständliche und ausführliche Dokus veröffentlicht. Einzig die Infos zu 
den dsPICs sind unter aller Sau.


*) Ist meine persönliche Erfahrung.

Autor: Schorsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh, hab gerade gesehen, dass alles schon genannt wurde; naja egal...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schorsch wrote:
>> - Es gibt keinen Freeware C-Compiler für PICs.
>
> Es gibt eine kostenlose Studentenversion, die nach 90(?) Tagen lediglich
> spezielle Optimierungen abschaltet, auf die man eh verzichten kann zumal
> man kritische Teile ohne weiteres in ASM einbinden kann.

Das ist kein gutes Argument: Dem Argument nach, kann man die Software 
gleich in Assembler schreiben... Außerdem werden alle Optimierungen 
abgeschaltet, wenn ich mich noch richtig erinnere.

> Einzig die Infos zu
> den dsPICs sind unter aller Sau.

Eindeutig. Aber auch da bessern die sich langsam. Eigentlich ist bei den 
dsPICs so ziemlich alles unter aller Sau: Dieser "Visual Initializer" 
hat bei mir noch nie einen funktionierenden Code generiert. Die Errata 
sheets sind ziemlich lang und unvollständig. Die mitgelieferten dsPIC 
Libs sollen angeblich teilweise fehlerhaft sein. Der Compiler für die 
dsPIcs ist eigentlich nur ein normaler C Compiler und nutzt keine 
einzige DSP Funktion. Mein erstes Assembler Programm auf einem dsPIC war 
direkt doppelt so schnell wie der vom Compiler generierte Code.

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:

> Das ist kein gutes Argument: Dem Argument nach, kann man die Software
> gleich in Assembler schreiben... Außerdem werden alle Optimierungen
> abgeschaltet, wenn ich mich noch richtig erinnere.

Du erinnerst Dich falsch...
Einzig die Procedural Abstractions werden in der Student Edition nach 
Ablauf der 60 (?) Tage abgeschaltet.

> Mein erstes Assembler Programm auf einem dsPIC war
> direkt doppelt so schnell wie der vom Compiler generierte Code.

Ist es ein schlechter Compiler oder Du ein guter 
Assembler-Programmierer?
Es ist doch absolut nicht erstaunlich, dass ein Hochsprachen-Compiler 
langsameren Code generiert als ein Assembler-Programmierer. (Falls man C 
zu den Hochsprachen zählen will ;-)

Severino

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist es ein schlechter Compiler oder Du ein guter
> Assembler-Programmierer?
> Es ist doch absolut nicht erstaunlich, dass ein Hochsprachen-Compiler
> langsameren Code generiert als ein Assembler-Programmierer. (Falls man C
> zu den Hochsprachen zählen will ;-)


...und weils so ist, braucht man keine Diskussion führen welcher 
Controller schneller ist. Wenn der Compiler schlecht ist, kann man 3x so 
viele MIPS haben und es bringt trotzdem nichts...


Gibts eigentlich schon PICs mit JTAG? JTAG wäre schon ein schönes 
Feature.

Autor: Kanonenfutter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein guter Programmierer braucht kein JTAG.

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JTAG ist ja auch nicht nur zum Programmieren da... folglich hat das auch 
rein gar nichts mit fachlicher Kompetenz zu tun, die dir offenbar fehlt, 
sonst würdest du nicht zu so einer Aussage kommen.

Autor: willivonbienemaya (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Thomas P.

Nein, gibt es noch nicht.
Es ist wohl vorgesehen, aber aktuell gibt es keinen bei dem es 
funktioniert.

Autor: Dan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von der Peripherie und Scalierbarkeit sind die AVRs klasse. EMV-mässig 
sind die wegen der 5V-Technik sehr solide.
Leider ist der Stromverbrauch bei AVR bescheiden.... aus dem Grund fällt 
bei mir die Wahl nur noch auf MSP...2-6uA sind schon nett...

Autor: Marco S. (masterof)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mal eine frage was braucht ein MSP340 an strom wenn er rechnet und nicht 
in einem energiespar-modus ist?

Autor: Dan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kann ur für einige typen die ich kenne sprechen, das sind 600uA bei ca. 
2MHz..Aber der interne DCO läuft nur kurz an, den großteil seiner Zeit 
schläft der Msp und wartet auf ein Int.....
Das Prinzip ist kurz mit hoher Taktfrequenz was amchen, udn sonst 
schlafen...in der Summe kommt man da auf einen super schönen Verbrauch..

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn ich einen PIC schlafen schicke, braucht er auch fast nix...
MSP ist dennoch sicher die bessere Wahl wenn man batteriebetriebene 
Projekte realisiert und wenn man kaum Rechenleistung braucht, denn 
soviel ich weiß sind maximal 8MHz drinnen. Meinen Webserver oder MP3 
Player hätte ich mich damit nicht realisieren getraut.

Autor: Dan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die sind bnis 16MHz spect....meine der DCO kann mit einem externen 
Widerstand auch bis auf 16Mhz....

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab da noch ne Anmerkung zu den Entwicklungstools für
PIC Controller:

Der Debugger von PICKIT ist begrenzt. Un zwar heftiger als der AVR 
Dragon.
Man kann damit nur ne Handvoll Controller Debuggen. Programmieren kann
man wohl alle.

Es gibt aber für den ICD2 inzwischen eine USB-taugliche Nachbauversion
für knapp 70 Euro. Hab auch ein Gerücht gehört, dass die Teile auch
im Original für ca. 120 Euro zu haben sein sollen.

Hier die Bezugsquelle:

http://www.wselektronik.at/WS/index.php?option=com...

Mit den 70 Euro liegt das Teil zwar noch über dem Dragon und ist "nur"
ein Haufen Einzelteile, aber für die PIC-Enthusiasten wohl das Mittel 
der Wahl, wenn man nicht >100 Euro ausgeben will.

Eigentlich hab ich nix gegen PIC Controller. Leider haben die ein paar
"Eigenheiten", die ich nicht gerade praktisch finde und die einem das
Leben unnötig schwer machen.

Zum Beispiel wenn ein Controller auf einen Bereich 3V-5V spezifiziert 
wird
aber zum "sauberen" Programmieren mindestens 4,5V benötigt werden!
Da bin ich bei einem Projekt ganz schön auf die Nase gefallen.
Auch das Fehlen einer vernünftigen indirekten Adressierung ist nicht 
gerade
Programmierer-freundlich (PIC16xxx). Mit PIC 18 hab ich mich noch nicht 
befasst.

Aber jeder hat so seine Präferenzen. Wer mit dem einen oder dem anderen
angefangen hat, wird wahrscheinlich aus Gewohnheitsgründen nicht gerne
wechseln. Ich hab geschäftlich mit PIC16xx und AVRs zu tun und muss mich
damit abfinden, dass der PIC eben ein paar Eigenarten hat. Wenn man
in C programmiert, dann ist das allgemein nicht ganz so tragisch.
Ich persönlich würde mir >>nie<< freiwillig PIC-Assembler antun!
Zumindest nicht bei der 16er Serie oder den kleineren PICs.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe auch nichts gegen PICs, denn ich verwende keine. :-)

Ich verwende AVRs, da ich mich aber auch für andere Kontroller 
interessiere, wäre ich schon einige Male dabeigewesen, mich in die 
PIC-Welt einzuarbeiten.
Zwei Anläufe hat es gedauert und dann habe ich es aufgegeben. Nicht 
deshalb, weil ich zu blöd wäre, sondern weil ich die PICs blöd finde.

Zum einen gibt es bei den PICs so viele verschiedene Familien, die alle 
nicht zusammenpassen. Ein C-Compiler funktioniert wieder nur für eine 
kleine winzige Anzahl von PICs und nicht für alle. Wenn man die gesamte 
Familie ausnützen würde, bräuchte man wahrscheinlich 5 verschiedene 
C-Compiler. Dann die Quarz-Division durch 4 gefällt mir nicht.
Dann gibt es nicht für jeden IRQ einen eigenen Vektor. Angeblich ist das 
bei neueren PICs behoben (Wenn man Glück hat.).
Mir kommt die PIC-Philosophie folgendermaßen vor: "Konstruieren wir mal 
einen Mikrocontroller. Diese Entwicklung hat zwar jetzt eine Menge 
Nachteile, aber bei der nächsten Familie können wir uns verbessern. 
Diese ist dann zwar wieder völlig anders als die erste, aber bei dem 
Durcheinander wird sich dann schon mal irgendjemand auskennen."

Also mir scheinen die AVR-Entwickler sehr viel mehr nachgedacht zu 
haben. Ich habe einen Compiler, den Codevision AVR und mit dem kann ich 
alle AVRs programmieren. Alle AVRs funktionieren nach einem gleichen 
Schema. Die neueren Prozessoren haben zwar Verbesserungen gegenüber den 
älteren Modellen, aber die Grundstruktur ist gleich. (Bei der einen 
PIC-Familie ist ein Befehlssatz mal 12-BIT breit bei der anderen wieder 
anders.).

Es stimmt zwar, dass es immer auf die Anwendung ankommt, welchen Typen 
man nimmt, aber ich habe das Gefühl, wie wenn ein AVR immer die bessere 
Wahl wäre als ein PIC.

Und dann kommen immer so total nette Argumente von den PIC-Anhängern wie 
z.B. Die Fuse-Bits eines AVRs würden mich verwirren.
Oder: Ich brauche keinen internen Oszillator auf einem Prozessor.
..
Die Liste dieser Pseudoargumente ist unendlich lang und tatsächlich ist 
kein Argument wirklich überzeugend und jedes durch ein Gegenargument 
sofort entkräftbar.
Es ist natürlich klar, dass wenn man mal eine Familie wie z.B. PIC 
gewöhnt ist, man dort weiterarbeiten möchte, aber ich finde es dann 
immer einwenig schwach, wenn dann PIC-Anhänger meinen, dass PICs besser 
sind.

Also ich habe die Erfahrung gemacht, dass wenn sich einer in der 
PIC-Familie und in der AVR-Atmel-Familie auskennt, die AVR-Familie nicht 
nur bevorzugt, sondern nur noch diese verwendet.

Tschüss
Mario

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mario wrote:
> Also ich habe auch nichts gegen PICs, denn ich verwende keine. :-)
>
> Ich verwende AVRs, da ich mich aber auch für andere Kontroller
> interessiere, wäre ich schon einige Male dabeigewesen, mich in die
> PIC-Welt einzuarbeiten.
> Zwei Anläufe hat es gedauert und dann habe ich es aufgegeben. Nicht
> deshalb, weil ich zu blöd wäre, sondern weil ich die PICs blöd finde.
>

????

> Zum einen gibt es bei den PICs so viele verschiedene Familien, die alle
> nicht zusammenpassen.

Das würd ich so nicht behaupten, aber es sind eben verschiedene Familien 
und in jeder Familie gibt es Derivate und die sind bis zu einem gewissen 
Grad schon ähnlich/kompatibel. Passen alle AVRs zusammen? Blöd, weil 
dann braucht man sich ja eh immer nur ein und denselben kaufen ;-)

> Ein C-Compiler funktioniert wieder nur für eine
> kleine winzige Anzahl von PICs und nicht für alle. Wenn man die gesamte
> Familie ausnützen würde, bräuchte man wahrscheinlich 5 verschiedene
> C-Compiler.

Verwende CCS Compiler und du kannst damit sowohl PIC16, PIC18 und dspPIC 
programmieren bzw. debuggen, also sogar Familien-übergreifend!!!!


> Dann die Quarz-Division durch 4 gefällt mir nicht.

Mir gefällt blau nicht, aber das hatte ich weiter oben schon erwähnt...

> Dann gibt es nicht für jeden IRQ einen eigenen Vektor. Angeblich ist das
> bei neueren PICs behoben (Wenn man Glück hat.).

Na sicher gibts das. Wo soll es das nicht geben??

> Mir kommt die PIC-Philosophie folgendermaßen vor: "Konstruieren wir mal
> einen Mikrocontroller. Diese Entwicklung hat zwar jetzt eine Menge
> Nachteile, aber bei der nächsten Familie können wir uns verbessern.
> Diese ist dann zwar wieder völlig anders als die erste, aber bei dem
> Durcheinander wird sich dann schon mal irgendjemand auskennen."
>
> Also mir scheinen die AVR-Entwickler sehr viel mehr nachgedacht zu
> haben. Ich habe einen Compiler, den Codevision AVR und mit dem kann ich
> alle AVRs programmieren. Alle AVRs funktionieren nach einem gleichen
> Schema. Die neueren Prozessoren haben zwar Verbesserungen gegenüber den
> älteren Modellen, aber die Grundstruktur ist gleich. (Bei der einen
> PIC-Familie ist ein Befehlssatz mal 12-BIT breit bei der anderen wieder
> anders.).

Und noch einmal, Familien dürfen unterschiedlich sein!!!!!!! Deswegen 
sind es auch verschiedene Familien... ist das so kompliziert?!?!

>
> Es stimmt zwar, dass es immer auf die Anwendung ankommt, welchen Typen
> man nimmt, aber ich habe das Gefühl, wie wenn ein AVR immer die bessere
> Wahl wäre als ein PIC.

Wenn der PIC Gefühle hätte, wäre er jetzt sicher traurig...

>
> Und dann kommen immer so total nette Argumente von den PIC-Anhängern wie
> z.B. Die Fuse-Bits eines AVRs würden mich verwirren.
> Oder: Ich brauche keinen internen Oszillator auf einem Prozessor.
> ..

PIC hat auch FUSE-Bits, sofern wir jetzt vom gleichen sprechen.

> Die Liste dieser Pseudoargumente ist unendlich lang und tatsächlich ist
> kein Argument wirklich überzeugend und jedes durch ein Gegenargument
> sofort entkräftbar.

Achso? Bitte fang an... Gibts AVRs mit externem Speicherinterface, mit 
integriertem Ethernet, 16Bit????

> Es ist natürlich klar, dass wenn man mal eine Familie wie z.B. PIC
> gewöhnt ist, man dort weiterarbeiten möchte, aber ich finde es dann
> immer einwenig schwach, wenn dann PIC-Anhänger meinen, dass PICs besser
> sind.
>
> Also ich habe die Erfahrung gemacht, dass wenn sich einer in der
> PIC-Familie und in der AVR-Atmel-Familie auskennt, die AVR-Familie nicht
> nur bevorzugt, sondern nur noch diese verwendet.
>

Ich hab die Erfahrung gemacht, dass solche Threads schlussendlich alle 
wertlos sind.


Also mein Ratschlag: Nehmt PIC wenn ihr PIC wollt und nehmt AVR wenn ihr 
AVR wollt. Wenn PIC so scheiße ist, warum sind die dann so gut am Markt 
vertreten? Sicher nicht wegen den Kosten, weil bei 1000 Stück sind kaum 
noch Unterschiede.


Nur noch eines... mir gefallen PICs einfach viiíeeeellll besser... das 
Gehäuse ist schwärzer und glatter als bei den AVRs... Ist das ein 
schlagkräftiges Argument??? loool

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Thomas:
---------

>Gibts AVRs mit externem Speicherinterface, mit
SRAM oder DRAM?

SRAM bis 64k kein Problem. Man kann an die Schnittstelle auch
andere Peripherie dranhängen. Z.b. ein USB Controller mit parallelem
Interface.

>integriertem Ethernet, 16Bit????
Ethernet? Nein. Leider net.
16bit? -> Es gibt AVR32 mit 32bit.

<Ironie>
 Was Ethernet betrifft, kann man ja auch nen AVR mit nem ENCxxxx von
 Microchip verbinden. Dann hat man auch Ethernet ;-)
</Ironie>

Autor: Opacer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein ARM ist größer, mein 8051 ist länger, PIC ist doof und AVR kann nix

<- Nicht ernstgemeint, aber was bringt dieses Schw*nzvergleichen 
eigentlich. Was ist das für ein Argument "Ich finde PICs blöd?" Mein 
Gott, generell ist kein µC wirklich "schlecht" und ein µC muss nicht 
alles können sondern hat immer eine Nische. Sonst hätte wahrscheinlich 
bald jeder Hersteller alles in einem BGA4000 Gehäuse was man ja evtl. 
irgendwann mal brauchen könnte.

Sagt doch lieber mal konkret "Das ist beim AVR nicht gut gelöst" "Das 
gefällt mir beim PIC gut/schlecht". Vorteile/Nachteile .. kein "blöd, 
doof, mag ich nicht, schönes Wetter"

Autor: Hans Wilhelm (hans-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der einzige grund einen avr zu bevorzugen ist der gcc-support...

zumindest wars meiner und solang es keinen gcc für die pic dinger gibt 
werd ich sie auch nicht angreifen...

sonst gilt das übliche.. man nimmt was grad gut passt...

73

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja AVR32 kenn ich, aber das ist eine andere Liga. Für die Bastlerstube 
hat der eindeutig das falsche Gehäuse... und zu viele Pins zum Routen 
g


Static Memory Controller, wie z.B. für Flash oder SRAM wäre gefragt um 
Programmspeicher bis zu 2MByte zur Verfügung zu haben.

ENC28J60 zu verwenden zählt nicht :-)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn PIC so scheiße ist, warum sind die dann so gut am Markt
vertreten?

Leider hat sich in der Vergangenheit gezeigt, dass sich nicht immer das 
beste System durchsetzt, sondern immer nur jenes, welches am besten 
vermarktet wird.
Beispiel VHS und Video 2000

Windows und Linux

In der Steinzeit:
1,44MB-Floppies und 2,88MB-Floppies

Tschüss
Markus

PS: Nehmt doch was ihr wollt.

Autor: Sergey (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich persönlich würde mir >>nie<< freiwillig PIC-Assembler antun!

Warum nicht? Damit kann man aus jedem PIC das maximale herausholen
und kann auch mit dem 12C508 sinnvolle Applikationen entwickeln.
Durch die Verwendung von Hochsprachen ist das nicht zu schaffen.

Es gibt eine bessere Auswahl an PICs in extrem vielen Kombinationen,
man findet fast immer genau den PIC der ideal ist.

C oder gar BASIC ("BASCOM AVR", etc) auf einem 8-Bit MCU? Nein danke!

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nichts gegen Assembler, ich mache das mal so mal so. Nur finde ich die 
Assemblersprachen der PICs sehr gewöhnungsbedürftig. In meisten 
Assemblersprachen gibt die Syntax der Operanden schon einen gewissen 
Hinweis darauf, wo Quell- und wo Zieloperand liegen. Nicht so die PICs, 
in denen eine harmlose 0 oder 1 hinten dran angibt, ob das Ergebnis im 
Speicher oder im Akku landet.

Natürlich gibt es auch andere abstossende Beispiele. Zilog 
beispielsweise hat ziemliche Klimmzüge gemacht, damit die Z80 auch ja 
keine optische Ähnlichkeit mit 8080 hat (Copyright?). Weshalb alle 
Zilog-CPUs mit dem Ladebefehl auch speichern, aus Gewohnheit auch jene 
bei denen das nie nötig gewesen wäre (Z8).

Autor: Kloung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nur finde ich die Assemblersprachen der PICs sehr gewöhnungsbedürftig.

Stimmt. Der Mensch ist aber zum Glück kein enthirntes Wesen sondern kann 
sich an bestimmte Situationen anpassen und eben gewöhnen.

>In meisten Assemblersprachen gibt die Syntax der Operanden schon einen
>gewissen Hinweis darauf, wo Quell- und wo Zieloperand liegen.
>Nicht so die PICs, in denen eine harmlose 0 oder 1 hinten dran angibt,
>ob das Ergebnis im Speicher oder im Akku landet.

Gerade das ist doch positiv. Mir ist das so lieber, als noch einen 
zusätzlichen Befehl zu haben.

>C oder gar BASIC ("BASCOM AVR", etc) auf einem 8-Bit MCU? Nein danke!

Bei BASIC stimme ich dir zu, aber ein 8-Bit µC ohne C? Möchte dich mal 
sehen, wenn du die Aufgabe bekommst, einen TCP/IP-Stack auf einem 
8-Bitter zu implementieren und du das unbedingt in ASM machen willst. 
Ich will nicht bestreiten, dass es grundsätzlich geht. Du kannst auch 
eine Textverarbeitung für Windows XP in ASM schreiben. Allerdings läufst 
du dann Gefahr, dass dich jemand in die Anstalt einliefert.

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A.K. wrote:
> Assemblersprachen gibt die Syntax der Operanden schon einen gewissen
> Hinweis darauf, wo Quell- und wo Zieloperand liegen. Nicht so die PICs,
> in denen eine harmlose 0 oder 1 hinten dran angibt, ob das Ergebnis im
> Speicher oder im Akku landet.

Das ist so nicht ganz richtig, unter MPASM steht f für file-register und 
w für working-register. Dabei kann f=1 oder w=0 als Operand gegeben 
werden. Reicht um einen Rückschluss auf Quelle und Ziel ziehen zu 
können.

Gruss,
Edson

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich verwende PIC un bin damit zufrieden. Ich wurde dazu genötigt 
mich mit PICs zu beschäftigen da diese in der Abschlussprüfun vorkommen. 
Ob ich PIC oder AVR genommen hätte wenn ich mich frei entscheiden hätte 
können weiß ich nicht, da ich mich mit AVR noch nicht näher beschäftigt 
habe.

Gruß Carsten

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich glaube, bezüglich preis/leistung gibts hier nicht zu motzen: 
http://www.microchip.com/stellent/idcplg?IdcServic...
...ich bleibe bei den PICs, denn mit denen habe ich mich gut 
angefreundet, und  kenne ich mittlerweile recht gut und bin sehr 
zufrieden. ich finde, man soll einfach bei einer sorte bleiben (ARM, 
Atmel, Microchip...), wenn man nicht (z.b. aus beruflichen gründen) 
drauf angewiesen ist, die vierschiednen "marken" zu gebrauchen

Autor: tanolino (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin für beides. Wie viele weiter oben geschrieben haben ist das 
total egal. Aktuell kommt es mir aber so vor als ob Reichelt die Atmel 
Preiße anzieht. (weil ein ehemals 95 ct teurer Chip heute auf einmal 160 
ct kostet)

Die PIC haben für den selben Preiß mehr Programmspeicher aber dafür kein 
EEPROM.
Beispiel (Preiße laut Reichelt):
 ATMEGA 8-16 (DIL-28) max. 16MHz und 23 IO Ports
 8kB Flash, 512B EEPROM, 1kB RAM
 -> 2.60€

 PIC 16F648A-I/P max.20MHz und 16 IO Ports
 4kx14 Flash, 256B EEPROM, 256B RAM
 dafür USART
 -> 2.30€

Also ich denke das man das in vielerlei Hinsicht interpretieren kann.
Ich habe mit atmel angefangen und würde mich auch nicht vor PIC scheuen 
... es ist nur eben was anderes

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Warum gräbst du eine 4 Jahre alte Leiche aus?

Außerdem kann man jemand, der Preis mit 'ß' schreibt nicht ernst nehmen.

MfG Spess

Autor: Ina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist neulich aufgefallen, daß bestimmte ATMEL µC (z.B. der 164 oder 
328) keinerlei Spezifikationen über maximale ADC-Fehler in den 
Datenblättern enthalten. Was soll man davon halten??

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Mir ist neulich aufgefallen, daß bestimmte ATMEL µC (z.B. der 164 oder
>328) keinerlei Spezifikationen über maximale ADC-Fehler in den
>Datenblättern enthalten. Was soll man davon halten??

Das du keine Datenblätter lesen kannst.

In den Datenblättern unter:

Electrical Characteristics->ADC Characteristics

zu finden. Auch bei den von dir genannten Typen.

MfG Spess

Autor: Ina (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>In den Datenblättern unter:
>
>Electrical Characteristics->ADC Characteristics
>
>zu finden.

So, und wo??

Autor: Jonathan Strobl (joni-st) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ähm... Wie wär's mit "Absolute accuracy"?


Gruß
Jonathan

Autor: Ina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ähm... Wie wär's mit "Absolute accuracy"?

Faßt alle vier anderen Fehlerarten zusammen, ist aber nur typisch 
spezifiziert, nicht maximal!

In den "Notes" findet sich übrigens noch das nette Sprüchlein "Values 
are guidelines only", können also jederzeit beliebig unter- bzw. 
überschritten werden...

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man den Thread vieleicht mal sperren?
Das hat mit dem "blödsinnigen" Thema nichts zu tun.
Unterhaltet euch doch per E-Mail.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ina schrieb:

> In den "Notes" findet sich übrigens noch das nette Sprüchlein "Values
> are guidelines only", können also jederzeit beliebig unter- bzw.
> überschritten werden...

Das steht bei den anderen Typen aber auch drin. Bei denen mit "max". 
Dieser innere Widerspruch ist Atmel wohl mittlerweile aufgefallen und 
"max" musste weichen.

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Hi
>
> Warum gräbst du eine 4 Jahre alte Leiche aus?
> Außerdem kann man jemand, der Preis mit 'ß' schreibt nicht ernst nehmen.
>
> MfG Spess

Jau,

und dann noch den Vergleich mit dem wohl ältesten Bausteinen die 
überhaupt im Katalog zu finden waren zu ziehen... Die Pic16F84 waren vor 
10 Jahren schon als Auslaufend gekennzeichnet und werden heute nur noch 
in kleiner Stückzahl eigendlich für Altdesigns hergestellt...

Zudem:
tanolino schrieb:
> Die PIC haben für den selben Preiß mehr Programmspeicher aber dafür kein
> EEPROM.
>
Ähh... PIC und keinen EEPROM? Bei diesem deinen Vergleich?
>  ...PIC16F84
>  4kx14 Flash, ***256B EEPROM***,
>  dafür USART
Nicht jeder PIC hat EEPROM, aber gerade der 16F84, (bzw. der C84 wie er 
vor der Überarbeitung hieß...) hatte schon EEPROM da war von ATMEGA8 und 
Co. noch nicht mal die Rede!

Aber wenn wir schon willkürlich vergleichen wollen:
Dein Beispiel AVR:
 ATMEGA 8-16 (DIL-28) max. 16MHz und 23 IO Ports
 8kB Flash, 512B EEPROM, 1kB RAM
 -> 2.60€

Und dann vergleiche hiermit
 PIC 18F14K50, DIL-20, Temperaturbereich -40 ... +125 °C, 8-bit
Program Memory, 16 KBytes, Self-Write yes, RAM, 768 Byte, EEPROM 
256Byte,
I/O-Pins 15, 1 8-bit Timer, 3 16-bit Timer, Geschwindigkeit 48 MHz,
Internal Oscillator 16 MHz, 32 kHz.
Anschlüsse / Schnittstellen:
9 ADC, 1 A/E/USART (Auch USB), MSSP (SPI/I²C)
Elektrische Werte: Spannungsbereich 1,8 - 5,5 V

-> PREIS: 2,30 Euro (reichelt)

Und wie sieht es nun aus?
JA- der Vergleich hinkt auch, einfach weil der Atmega8 auch ein altes 
Design ist. Trotzdem liegen diese beiden Designs viel näher zusammen als 
dein ursprünglicher Vergleich...

Mal ganz davon abgesehen das man wie schon geschrieben das so gar nicht 
vergleichen kann. Denn z.B. die IO Ports hängen vom Gehäuse ab das man 
wählt. Wer ein DIL 28 mit einem DIL 20 vergleicht, obwohl es auch dort 
DIL28 modelle gibt, der kann wohl nicht ernsthaft die Anzahl IOs als 
argument heranziehen wollen.
Genauso gibt es Modelle mit größerem, aber auch ohne Eprom speicher... 
usw. usf!

Aber einen großen Vorteil speziell für Bastler gibt es bei den PIC, der 
hier auch noch nicht genannt wurde: Es gibt viel viel mehr auführungen 
noch im DIP Gehäuse! Auch neue Modelle.
Bei den AVR ist ja alles was nur ein wenig moderner ist ja nur noch in 
SMD zu bekommen. Für die Industrie egal, ja meist sogar gewünscht, aber 
für die Einsteiger...

Aber trotzdem bleibt es dabei:
Es gibt nicht den einen Universalcontroller. Für jede Anwendung kann es 
ein anderer sein. Trotzdem ist bei mir im 8Bit bereich der PIC fast 
immer das Mittel der Wahl... (Im 32Bit bereich halten sich ARM und PIC32 
die Waage, je nach Anforderung)

Gruß
Carsten

Autor: Ina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das steht bei den anderen Typen aber auch drin. Bei denen mit "max".
>Dieser innere Widerspruch ist Atmel wohl mittlerweile aufgefallen und
>"max" musste weichen.

Das Problem ist nur, wenn mich mein Chef fragt, wie genau denn der ADC 
ist, kann ich ihm keinen Maximalfehler angeben. Ich muß dann sagen: 
"Typisch weniger als 3LSB. Maximale Abweichung ist aber unbekannt". 
Kommt garnicht gut...

Autor: Ina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei den PICs ist es aber auch nicht viel besser: Die geben zwar 
Maximalwerte an, halten sich aber nicht immer dran. Im Errata steht dann 
manchmal, daß die Maximalwerte leider nicht eingehalten werden...

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Ina schrieb:

>Mir ist neulich aufgefallen, daß bestimmte ATMEL µC (z.B. der 164 oder
>328) keinerlei Spezifikationen über maximale ADC-Fehler in den
>Datenblättern enthalten. Was soll man davon halten??

Ich habe jetzt mal ein paar Datenblätter durchgesehen (die ältesten von 
2006, zum Ausgraben älterer ATMEL-CDs hatte ich keine Lust). Dort habe 
ich nirgends deine vermissten Angaben gefunden. Scheint also schon 
länger (oder immer) so zu sein. Oder hast du ein Datenblatt, in dem das 
drin steht.

Die AVR vs. PIC Diskussionen gehen mir übrigens an der hinteren 
Körperöffnung vorbei.

MfG Spess

Autor: Ina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich habe jetzt mal ein paar Datenblätter durchgesehen (die ältesten von
>2006, zum Ausgraben älterer ATMEL-CDs hatte ich keine Lust). Dort habe
>ich nirgends deine vermissten Angaben gefunden. Scheint also schon
>länger (oder immer) so zu sein. Oder hast du ein Datenblatt, in dem das
>drin steht.

Nee, ist mir erst neulich aufgefallen, als ich extra danach gesucht 
habe. Wir setzen bisher sowieso schnelle, externe 12bit-Wandler ein. Ich 
frage mich nur, welcher Profi einen ADC einsetzt, bei dem keine 
Maximalwerte spezifiziert werden. Die ATMEGAs zielen dabei doch 
keineswegs nur auf Bastler ab, oder? Die Teile sind sonst doch ganz 
potent und ich arbeite auch gerne mit ihnen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:

> Ich habe jetzt mal ein paar Datenblätter durchgesehen (die ältesten von
> 2006, zum Ausgraben älterer ATMEL-CDs hatte ich keine Lust). Dort habe
> ich nirgends deine vermissten Angaben gefunden.

Im Mega16(A) Datasheet, aktuelle Version. Scheint aber wirklich der 
einzige zu sein wo das drinsteht.

Autor: Simon S. (-schumi-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Meinung nach ist der AVR-GCC + AVRDude ein absolutes 
Todschlagargument für die AVRs.

Ich muss mich leider mit den PICs etwas quälen. Es ist schon hart einen 
PIC in C zu programmieren, wenn man den GCC gewohnt ist ;-)
(Natürlich muss man auch erst einmal den richtigen Compiler für den 
jeweiligen PIC finden...Und bei ~300 Zeilen Code kommt dann so ein 
tolles "Demo limit". Da könnt ich den ganzen Scheiss einfach ausm 
Fenster schmeißen. Aber das Hexfile dann auf den Controller zu bekommen 
ist genauso ein gefrickel. 16F887/18F4550+EasyPic6+MikroCPro (so heißt 
das Programmiertool glaub ich, bin mir aber nicht sicher). In der Doku 
für MikroCPro finden sich wunderbare Beispiel zum Ansteuern über die 
Kommandozeile. Der Shicedreck ist aber total nutzlos wenn das in 
keinster Weise funzt! Diese Programm ist einfach nicht in der Lage das 
via Parameter übergebene Hexfile zu flashen... (bzw. mit einer 
Warscheinlichkeit von etwa 10%). Und wenns mal geht (oder man alles 
manuell macht) kommt zu 70% keine Fehlermeldung, der PIC ist aber 
trotzdem NICHT geflasht. Wobei ich mich frage warum das "verify" dann 
erfolgreich ist??)

Ich werde wohl in meiner Abschlussprüfung einen AVR verwenden, und 
keinen PIC wie er in der Berufsschule benutzt wird...

(Und das nicht unbedingt weil der PIC an sich so schlecht währe, sondern 
die Entwicklertools (meiner Meinung nach) einfach schlecht sind)

Gruß

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>(Und das nicht unbedingt weil der PIC an sich so schlecht währe, sondern
>die Entwicklertools (meiner Meinung nach) einfach schlecht sind)

Für Volldeppen sind die nicht gemacht. Die AVR Tools auch nicht.
Viel Spass beim ersten verfusen deines AVR. Das geht bei PICs
gar nicht;) Soviel mal zu besser oder schlechter.

Und wenn wir schon mal bei leistungsfähiger und billiger
sind: Ein Cortex M3 ist billiger und leistungsfähiger
als ein AVR. Warum sollte man überhaupt noch AVR benutzen?
Das ist uralter Kram der den heutigen Anforderungen
überhaupt nicht mehr standhalten kann.

Soviel mal zu PIC versus AVR.

Stellen wir doch mal eine neue Frage:
Warum AVR benutzen wenn es ARM gibt?

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na geht's noch länger?

http://www.youtube.com/watch?v=I-jfS0bxW-o&feature...

Oben kam schon mal was von ARM9...

So und jetzt macht mal jemand diesen ollen Thred dicht!

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Simon S. schrieb:
> Meiner Meinung nach ist der AVR-GCC + AVRDude ein absolutes
> Todschlagargument für die AVRs.

Nö...
Denn GCC basierende Compiler sind auch bei PIC üblich...
Zwar nicht für die kleinen 8bitter, aber die Compiler für die 
Leistungsfähigeren basieren auf GCC und sind sogar Open Source., nur mit 
dem Unterschied das der Support hier in erster Linie durch Microchip 
eigene Programmierer erbracht wird die ganu dafür angestellt sind und 
bezahlt werden... Im gegensatz zum AVR wo man dann daruaf angewiesen ist 
das sich jemand mal in der Freizeit erbarmt und dazu gleich dann zig 
unterschiedliche Versionen nebeneinander existieren.

> Ich muss mich leider mit den PICs etwas quälen. Es ist schon hart einen
> PIC in C zu programmieren, wenn man den GCC gewohnt ist ;-)
> (Natürlich muss man auch erst einmal den richtigen Compiler für den
> jeweiligen PIC finden...Und bei ~300 Zeilen Code kommt dann so ein
> tolles "Demo limit". Da könnt ich den ganzen Scheiss einfach ausm
> Fenster schmeißen. Aber das Hexfile dann auf den Controller zu bekommen
> ist genauso ein gefrickel. 16F887/18F4550+EasyPic6+MikroCPro (so heißt
> das Programmiertool glaub ich, bin mir aber nicht sicher). In der Doku
> für MikroCPro finden sich wunderbare Beispiel zum Ansteuern über die
> Kommandozeile. Der Shicedreck ist aber total nutzlos wenn das in
> keinster Weise funzt! Diese Programm ist einfach nicht in der Lage das
> via Parameter übergebene Hexfile zu flashen... (bzw. mit einer
> Warscheinlichkeit von etwa 10%). Und wenns mal geht (oder man alles
> manuell macht) kommt zu 70% keine Fehlermeldung, der PIC ist aber
> trotzdem NICHT geflasht. Wobei ich mich frage warum das "verify" dann
> erfolgreich ist??)
> ...
> (Und das nicht unbedingt weil der PIC an sich so schlecht währe, sondern
> die Entwicklertools (meiner Meinung nach) einfach schlecht sind)
>
> Gruß

Warum fällt es einigen so schwer zwischen Entwicklungsumgebung von 
dritten und dem Produkt sowie der dafür vom Hersteller herausgegebenen 
Entwicklungsumgebung zu unterscheiden. Alles was du hier beschreibst 
sind einzig deine Probleme mit der MikroC umgebung...
Dabei wird hier - und an vielen anderen Stellen- immer wieder darauf 
hingewiesen das man es sich doch nicht so schwer machen soll und man 
direkt die Original Tools verwenden soll.

Für den Einstieg ein PK3 (oder Clone) ab 20 Euro und MPLAB +microchip 
Compiler... DAs läuft zusammen, ist Stabil, dafür gibt es gute 
Dokumentationen und es gibt keinerlei Codelimit. Lediglich die maximale 
Optimierung wird nach drei Monaten zurückgefahren...
(Das kann man aber bei den GCC basierenden Compilern auch umgehen in dem 
man die Quellcodes -die ja offen liegen- selbst kompiliert)

Mit dieser Umgebung sieht es dann so aus:
Einmal den µC auswählen, sowie ob der Debug Mode oder aber nur reines 
Brennen geplant ist. Danach Programm schreiben, auf Compilieren klicken 
und dann noch einmal schaltfläche (oder Tastenkürzel) brennen. Fertig!
Man kann aber auch einstellen das direkt nach erfolgreichen Build 
gebrannt werden soll, dann ist es nur noch ein Tastendruck/Click.
Und wenn dann MPLAB meldet das der Vorgang erfolgreich war, DANN war es 
auch erfolgreich.

Wer sich da mit Merkwürdigen Fremdprodukten (Woebi ich zugeben muss das 
ich MikroC gar nicht wirklich kenne) rumquält, der ist selbst schuld...
Aber alles was du oben als "Nachteil" geschrieben hast ist nun einmal 
ein Problem des Fremdproduktes. Im Gegenteil - bei der Original IDE muss 
man sich überhaupt keine Gedanken über iregenwelche zusammengestellten 
Toolchains machen, das läuft alles Intern ohne das der Nutzer für die 
StandartKonfig da irgendetwas ändern muss. Ein Click und fertig.

Zudem:
Die Microchip IDE gibt es im Original auch für Linux.
AVR Studio nicht...

Markus Müller schrieb:
> So und jetzt macht mal jemand diesen ollen Thred dicht!

Und warum dies... Bringt doch nichts, spätestens nach 12 Std. ist dann 
der nächste Thread eröffnet udn das ganze geht wieder von vorne los. 
Dann lieber einen Thread wo sich das alles sammelt.
Zudem geht es ja hier sogar noch merkwürdig gesittet zu. Das kenne ich 
bei diesem Thema ganz anders.

Gruß
Carsten

Autor: Master Snowman (snowman)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ich möchte auch mal etwas benzin ins feuer werfen und habe eine uralte 
benchmark angehängt (keine ahnung mehr, woher ich die habe). leider sind 
da die aktuelleren uC nicht drin (z.b. ARM, oder die 60MIPS PIC24s oder 
60MIPS dsPICs, ich vermuete mal, dass auch bei Atmel neuere uC draussen 
sind)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ina schrieb:
> Mir ist neulich aufgefallen, daß bestimmte ATMEL µC (z.B. der 164 oder
> 328) keinerlei Spezifikationen über maximale ADC-Fehler in den
> Datenblättern enthalten. Was soll man davon halten??

Verwendet habe ich den ADC bisher beim ATmega8 und beim ATtiny261 mit 
10Bit Auflösung. Mit einem 10-Gang Poti konnte ich auf der Anzeige jede 
Zahl von 0 .. 1023 stabil einstellen.

Ich hab jetzt nicht alle 1024 Stufen nachgemessen, aber die Wandlungen 
sind streng monoton und sehr stabil, also der ADC sehr rauscharm.
Man kann selbst mit dem Mittelwert über 256 Messungen kein elftes Bit 
rauskitzeln, dazu müßte man erst die Eingangsspannung mit nem 
Dreiecksignal überlagern.
Der ADC hätte also durchaus das Potential für 12Bit.


Wenn man sich dagegen die Errata der neuen Xmega-Serie ansieht, scheint 
dort der ADC deutlich schlechter zu sein.


Peter

Autor: Ina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, Peter!

Autor: Simon S. (-schumi-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Viel Spass beim ersten verfusen deines AVR

Dank AVR-Burn-O-Mat passiert das nicht ;-)

holger schrieb:
> Für Volldeppen sind die nicht gemacht. Die AVR Tools auch nicht.

Privat habe ich folgende Konfiguration: AVR-GCC + Geany + AVRDude + 
AVRBurnOMat für Fuses

Diese Kette ist für mich viieeel einfacher zu Bedienen und logischer als 
MPLAB, MikroCPro usw...

Die sind mir so unangenehm zu bedienen, dass ich nicht die Mühe gescheut 
habe, Geany zu installieren und jeweils ein make-all.bat-Skript und 
make-program.bat-Skript zu schreiben (in der Arbeit ist Win angesagt)...
(Allerdings bei make-program eben das Problem dass man sich den 
Programmer eigentlich in den Popo schieben kann)

Carsten Sch. schrieb:
> Nö...
> Denn GCC basierende Compiler sind auch bei PIC üblich...
> Zwar nicht für die kleinen 8bitter, aber die Compiler für die
> Leistungsfähigeren basieren auf GCC und sind sogar Open Source.

Die bei uns verwendeten Controller sind 16F887 (laut Sprut 14Bit) und 
18F4550 (16Bit). Für die gibt es ja dann GCC-Derivate? Kannst du mir die 
nennen oder einen Link geben? Währe wirklich eine große Erleichterung 
für mich!

Dann hätte ich endlich Compiler, die Fehlermeldungen in vollständigen, 
deutschen Sätzen ausgeben. Wo das interpretieren der Fehlermeldung 
schneller geht als sich nur die Zeilennummer rauszupicken und sich die 5 
Zeilen davor/dahinter selbst nochmal durchzulesen...
z.B.
for(unsigned char bla=0; bla<10; bla++)
{
//blubb
}
ist da nur "Syntax error". Nix weiter. (Ich weis, dass das nicht 
C-konform ist. Aber es ist ein Stückchen Komfort des GCC, und diese 
nichtssagende Fehlermeldung rechtfertigt das auch nicht (Ich hab 0h5 
damit verbracht rauszufinden was die Fehlermeldung soll))

Carsten Sch. schrieb:
> Für den Einstieg ein PK3 (oder Clone) ab 20 Euro und MPLAB +microchip
> Compiler...
Hardware ist schon vorhanden: 
http://www.mikroe.com/eng/products/view/297/easypi...
Compiler möchte auf jeden Fall ein GCC-Derivat.
Gibt es für dieses Board einen anständigen Programmer? (also Software 
meine ich jetzt). Am besten Kommandozeile. Tut mir leid wenn ich so blöd 
frage, aber ich benutze nur AVRDude und damit geht mehr oder weniger 
ALLES...

Gruß

Autor: bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Gibt es für dieses Board einen anständigen Programmer? (also Software

Das macht MPLAB mit, wenn Du ein PICkit oder ICD als Hardware nimmst

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Stellen wir doch mal eine neue Frage:
> Warum AVR benutzen wenn es ARM gibt?

Weil es kein ARM-Studio gibt?
Eine freie Entwicklungs-Umgebung für ARM hätte mal was - und kommt mir 
jetzt bloss nicht mit so einem Schrott wie Yagarto mit Eclipse.

Truestudio ist schon ganz drollig, sowas wie AVR-Studio ist das aber 
längst nicht.

Autor: Nein ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schrieb:
> Truestudio ist schon ganz drollig, sowas wie AVR-Studio ist das aber
> längst nicht.

Truestudio IST Eclipse...

Und welches AVR-Studio meinst du? Das veraltete 4er oder das verbuggte 
5er?

Autor: Markus B. (markus_b77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon S. schrieb:

> Privat habe ich folgende Konfiguration: AVR-GCC + Geany + AVRDude +
> AVRBurnOMat für Fuses
Bis auf AVRBurnOMat verwende ich das auch. Ich hab mir ein einfaches 
Script geschrieben, in dem ich avrdude aufrufe. Das nenne ich jeweils so 
wie das Target und mache es ausführbar. Dann kann ich einfach auf den 
"Run" Button von Geany klicken oder F5 drücken. Mich stört aber, dass 
man zum Compilieren immer zu einer passenden Datei wechseln muss.
>
> Für die gibt es ja dann GCC-Derivate? Kannst du mir die
> nennen oder einen Link geben? Währe wirklich eine große Erleichterung
> für mich!
Es gibt den SDCC. Was der allerdings taugt weiß ich nicht.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon S. schrieb:
> Privat habe ich folgende Konfiguration: AVR-GCC + Geany + AVRDude +
> AVRBurnOMat für Fuses
>
> Diese Kette ist für mich viieeel einfacher zu Bedienen und logischer als
> MPLAB, MikroCPro usw...

Für den PIC wäre es aber auch nur MPLAB (inkl C18/30 -> C-Compiler) + 
PICKIT2 oder 3 (Brenner). Wem eine IDE und ein Gerät zum programmieren, 
brennen, debuggen und emulieren zu umständlich ist, den kann ich nicht 
verstehen. Ein Programm nur für Fuses?? DAS klingt für mich umständlich.

Außerdem: Wieso sollte man eine kostenlose Version eines Compilers mit 
Code-Limit benutzen, statt dem Original-Compiler ohne Codelimit, der 
auch kostenlos ist? Zumindest, wenn der Code groß wird?


Das Video was es genau auf den Punkt bringt, was aus meiner Sicht auch 
ALLES Wahr ist, ist dieses hier:

Youtube-Video "EEVblog #63 - Microchip PIC vs Atmel AVR"

Autor: Markus B. p. (mbp-bayern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Master Snowman schrieb:
> ich möchte auch mal etwas benzin ins feuer werfen und habe eine uralte
> benchmark angehängt (keine ahnung mehr, woher ich die habe). leider sind
> da die aktuelleren uC nicht drin (z.b. ARM, oder die 60MIPS PIC24s oder
> 60MIPS dsPICs, ich vermuete mal, dass auch bei Atmel neuere uC draussen
> sind)

Hallo Snowman,

Das interressanteste am Benchmark wäre für mich der Vergleich PIC18F 
gegen die anderen - insbesondere gegen Ateml.
Leider steht aber an keiner PIC18 Zeile irgendwas.

Kennst da jemand eine Quelle ?

MFG:MBP
Markus.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus B. p. schrieb:
> Master Snowman schrieb:
>> ich möchte auch mal etwas benzin ins feuer werfen und habe eine uralte
>> benchmark angehängt (keine ahnung mehr, woher ich die habe). leider sind
>> da die aktuelleren uC nicht drin (z.b. ARM, oder die 60MIPS PIC24s oder
>> 60MIPS dsPICs, ich vermuete mal, dass auch bei Atmel neuere uC draussen
>> sind)
>
> Hallo Snowman,
>
> Das interressanteste am Benchmark wäre für mich der Vergleich PIC18F
> gegen die anderen - insbesondere gegen Ateml.
> Leider steht aber an keiner PIC18 Zeile irgendwas.
>
> Kennst da jemand eine Quelle ?

Dafür nicht (sollte aber mit dem Simulator vom MPLAB genau genug machbar 
sein), aber es gibt zumindest für einige AVR, AVR32, PIC18, PIC24, PIC32 
Coremark-Ergebnisse:
http://www.coremark.org/benchmark/index.php
(Atmel und Microchip auswählen, suchen und nach Coremark/MHz 
sortieren...)


> MFG:MBP
> Markus.

Autor: Markus B. p. (mbp-bayern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun interressante Diskussion - ich kann die gut verstehen.

PIC und MEGA-AVR haben alle ihre Daseinsberechtigung.
Mittlerweile nutzte ich beide insbesondere wegen CAN-Bus.
Auch wenn ich anfangs von PIC nichts wissen wollte.

Bei AVR habe ich mit 100% Assembler begonnen.
(AVR Assembler 2 und Makros ist was echt feines.)
Bin mittlerweile aber meist bei 100% C.

PIC18 / dsPIC programmiere ich nur in C,
der ASM von PIC18 gefällt mir überhaupt nicht.

Da ich also beide kenne, so habe ich auch viel verglichen.
Sowohl die Datenblätter als auch die Features.


So wie es aussieht,
so gibt es noch immer keine TQFP44 AVR mit CAN
oder habe ich da was übermerkt ?

--> PLUS für PIC.


Die TQFP44 Pinbelegung von MEGA16 VS PIC18...

PIC18F     SPI schließt Hardware-TWI aus. (mit ext. TWI Puffer gehts.)
PIC18F45x  8 Kanal ADC mit Externer ARef: GEHT NICHT.
PIC18F4xxx 8 Kanal ADC mit Externer ARef: klaut Digitale IO's

Aber auch Atmel ist nicht perfekt:
Wenn man zB. einen 8-Bit breiten IO Port benötigt,
so muss man auch auf SPI, ADC, TWI oder UART verzichten.

--> dennoch ein knappes PLUS für AVR.

Wenn man die Datenblatt-Optik von Atmel gewöhnt ist,
so findet man sich anfangs bei PIC wirklich nicht zurecht.
Mit der Zeit geht aber auch das vorbei.

--> Unentschieden.

Somit kann auch ich keinen eindeutigen Sieger küren.


Ähm...
S12/S12X sticht Mega-AVR's ;-)
S12 = Freescale (früher Motorola)

Und...
Der dsPic ist übrigens auch was ganz nettes,
der hat die Port-Probleme vom PIC18 nicht,
kann zwar keine 5V ab, dafür aber eine PLL,
die aus fast jedem Quarz den richtigen System-Takt erzeugt.

Ja ich weiß die sind BEIDE eine andere Klasse.

ABER ES BLEIBT DABEI:
Je nach Anwenfungsfall ist meist EINER besser als ein anderer.
(manchmal erst recht auch mehrere)

MFG:MBP
Markus.

Autor: Markus B. p. (mbp-bayern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> aber es gibt zumindest für einige AVR, AVR32, PIC18, PIC24, PIC32
> Coremark-Ergebnisse:
> http://www.coremark.org/benchmark/index.php

Danke !

Oh,

da sieht PIC18 aber schlecht gegen die beiden AVR aus.
Selbst noch, wenn man das PIC Ergebniss mit 4 multiplizert.

Naja...
Irgendwer hat mal gesagt:
"Traue keiner Statistik, die Du nicht selbst gefälscht hast."

Da muss ich mir wohl wirklich eine selber fälschen.
Aber die Idee mit dem Simulator ist gut.

MFG:MBP
Markus.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Master Snowman schrieb:
> ich möchte auch mal etwas benzin ins feuer werfen und habe eine uralte
> benchmark angehängt (keine ahnung mehr, woher ich die habe).

Wahrscheinlich von hier:

  Beitrag "Re: LPC2103 63MIPS?"

Weiter unten im Thread wurden die Benchmarkergebnisse von anderen
Forenteilnehmern um weitere Controllertypen ergänzt.

Markus B. p. schrieb:
> da sieht PIC18 aber schlecht gegen die beiden AVR aus.
> Selbst noch, wenn man das PIC Ergebniss mit 4 multiplizert.

Wenn ich mir den Befehlssatz der beiden Controller anschaue, würde ich
sagen, dass sich ein 64MHz-PIC18 und ein 20MHz-ATmega nicht allzu viel
schenken. Der ATmega ist zwar etwas höher getaktet (1 Befehlstakt des
PIC entspricht ja 4 Oszillatortakten), dafür führt der PIC18 einige
Befehle in 1 Zyklus aus, wo der ATmega 2 braucht (z.B. die Multiplika-
tion). Jeder der beiden Controller hat ein paar Befehle, die man auf dem
jeweils anderen aus zwei oder mehr Befehlen zusammensetzen muss.

Dass die Benchmarkergebnisse so weit auseinander liegen, würde ich des-
wegen darauf zurückführen, dass der Benchmark auf Grund der getesteten
Kriterien den ATmega bevorzugt, oder dass der AVR-GCC besser optimiert
als der C18-Compiler des PIC.

Die Ergebnisse im obigen benchmark.c für den ATmega erscheinen mir übri-
gens viel zu hoch. Bei den ersten beiden Tests und einer Taktfrequenz
von 16MHz komme ich mit einem aktuellen GCC (4.3 oder neuer) auf 96,4µs
statt 641µs bzw. 657µs. Entweder war damals der GCC sehr viel schlechter
als heute oder (wahrscheinlicher) es wurde vergessen, die Optimierung
einzuschalten.

Autor: frankman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
John schrieb:
> "Aber mein ARM7 kann viiiieeeeellll mehr als eure klumpigen AVRs und
> PICs
> *ätsch*"
>
>
> Aus dem Alter bin ich raus.
> Ich benutze nur noch die ARM9 (von ST). Mehr Speicher, schneller durch
> längere Pipeline und höheren Takt, etc. pp.

Dafür nur Portzugriff, keine Bitmanipulation....

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
frankman schrieb:

> Dafür nur Portzugriff, keine Bitmanipulation....

Sehr viele ARMs haben GPIO-Ports mit Bitmanipulation. Nicht unbedingt 
als Prozessorbefehl, aber als Eigenschaft des Ports. Nur eben jeder 
anders.

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein ich schrieb:
> Truestudio IST Eclipse...

Stimmt auffällig, ist aber dennoch besser integriert als so ein Gemurkse 
wie Yagarto.
Und gefallen tut mir alles nicht was ich bisher an kostenlosen IDEs für 
ARM gesehen habe.

> Und welches AVR-Studio meinst du? Das veraltete 4er
> oder das verbuggte 5er?

Die finde ich beide besser als alles was mir für den ARM bisher 
untergekommen ist.

Wobei das 4er ARV-Studio kaum als veraltet bezeichnet werden kann und 
das 5er Studio gerade mal den ersten Release hatte.

Das 4er Studio wird für die 8-Bit AVR noch lange seinen Dienst tun, so 
schnell wirft Atmel dann auch nicht mit neuen Controllern nach dem Markt 
das man da ein Problem bekommt.
Zumal man das was Atmel ankündigt noch lange nicht auf dem Tisch haben 
wird.

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

"Ich nochmal"

Es ist schon recht interessant auf was hier einige Ihre Wahl gründen. 
Und noch interessanter sind diejeniegen die hier meinen 
"Schwanzvergleiche" führen zu müssen und anscheinend dadurch den 
Eindruck von Kompetenz vermitteln zu wollen das SIE ja die "Dicksten" 
Controller verwenden und alles andere Spielzeug ist. (Ich verwende nur 
noch ARM...)

Das ist abe rmitnichten ein Merkmal von Kompetenz, sondern genauso 
Frickelverhalten wie die Bemühungen wirklich alles mit einem einzigen 
AVR Typ erledigen zu wollen. Egal ob man dazu fünf verschiede 
Interfacebausteine anhängen muss und es genügend andere µC gibt die 
alle, oder zumindest den Großteil, der Funktionen bereits an Board haben 
und dabei sogar noch weniger Kosten.

JA, die Leistungsfähigen Controller haben natürlich ihre 
daseinsberechtigung. Für einen großen Teil der Anwendugnen sind sie die 
Einzig Sinnvolle Wahl, da die Aufgaben mit den kleinen Brüdern nur mit 
erheblichen Aufwand -oder überhaupt nicht- lösbar sind.

Aber diese Schlacht um MIPS und Co ist absoluter Blödsinn.
Wenn man es in der Masse sieht, dann ist wohl klar das der absolute 
Großteil de rheute verbauten Prozessoren sich einfach nur "langweilt", 
die vorhandene Leistung nicht mal Ansatzweise ausgenutzt wird. Es spielt 
schlicht keine Rolle ob der CPU Kern nun zu 10% oder zu 5% ausgenutzt 
ist.

Die 32Bit µC sind überall da das Mittel der Wahl wo große Datenmengen 
verarbeitet werden müssen. Das können sehr schnelle 
Datenerfassungsgeräte sein, komplexere Web Basierende Systeme, alle 
Arten von schnellen Modems oder schlicht Anwendungen mit aufwendiger 
Grafik.
Wie weiter oben schon geschrieben haben die 32Bit aber in der Regel 
keine "einfache" Möglichkeit für simple Funktionen wie Pin-Togglen.

Gerade das ist aber die Stärke der 8Bitter. Schon wenn man sich deren 
Ports ansieht merkt man schnell das die Ausgabe in ganzer Busbreite von 
den Herstellern als eher unbedeutend eingeschätzt wird und die 
Schwerpunkte auf bitweise Ausgaben und den im bereich einfacher Aufgaben 
vorherschenden seriellen Bussysteme.

Es handelt sich also um zwei recht verschiedene gedachte Einsatzgebiete 
die natürlich auch mal geringe Überschneidungen haben können.
Gerade aber recht einfache Steueraufgaben die mit fast allen 8 Bittern 
mit einem Handstreich erledigt werden können erfordern bei den 32 
Bittern einiges an Aufwand.

Insbesondere gilt das für alles was man früher durch "Gattergräber", 
teilweise ergänzt durch Datentabellen irgendwo im Speicher (fest 
verdrahtet, Prom) gelöst hat. Wer für solche Sachen auf teufel komm raus 
einen 32Bitter einsetzen will, der hat irgendetwas nicht verstanden.

Wenn man dies überdenkt, dann wird schnell klar warum also für einen 
8Bitter die vorhandene Peripherie und Bibliotheken dazu viel viel 
wichtiger sind als die reine REchenleistung.

GRuß
Carsten

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wie weiter oben schon geschrieben haben die 32Bit aber in der Regel
>keine "einfache" Möglichkeit für simple Funktionen wie Pin-Togglen.
Nur manche 32Biter (typ.weise LD/ST Archit.) haben diese Probleme.
Auch AVR  ist LD/ST und ist langsam, wenn im RAM (nicht im IO) bits 
geändert werden müssen.

Autor: Markus B. p. (mbp-bayern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Wenn ich mir den Befehlssatz der beiden Controller anschaue, würde ich
> sagen, dass sich ein 64MHz-PIC18 und ein 20MHz-ATmega nicht allzu viel
> schenken. Der ATmega ist zwar etwas höher getaktet (1 Befehlstakt des
> PIC entspricht ja 4 Oszillatortakten)

Hallo Yalu,

Das scheint mir auch realistischer, als der andere Benchmark.
Die 4 Oszillator-Takte kann man ja bei den PIC18 mit dem HS-PLL-Mode 
wieder reinholen - somit sind 10 MHz außen 10 MIPS innen.

"Optimierung"
... stimmt.

Für einen schlechten Compiler,
oder gar ein mieses Programm kann der Controler ja nichts.


Eigenlich müsste man die selbe Aufgabe in der jeweiligen 
Assemblersprache des Controlles selbst erstelen und optimieren, um 
wirklich nur Controller und nicht auch die Compiler zu vergelichen.


Selbst die FFT auf AVR (ASM) (Abgewandelt aus [ 1 ])
benötigt bei einem Testaufbau von mir mehr Zeit für das
Sampeln und Filtern des Signales vor den Funktionen der FFT
und für die Datenausgabe danach. [ 2 ]

Auch ich habe den AVR nur wegen der Abtastrate Übertaktet:
48 KSps @ 20MHz, NF 24 KHz MAX, 187,8 Hz each Bar, 128 Bars.


Somit sollten die MIPS bei "Kleinkram" wohl wirklich selten bedeutsam 
werden.


MFG:MBP
Markus
*********************************************************************
[ 1 ] Beitrag "Schnelle FFT in Assembler"

Dass Dort im Thread was von PIC = SEHR LANGSAM steht,
das fällt wohl auch wieder unter fehlende / falsche Optimierung,
bzw. den Vergelich C vs. ASM etc.

[ 2 ]
Der eigentliche Flaschenhals ist RS232 @ 115 KBaud zu meinem 
VB6-Programm.
Die 1. Test-Daten-Ausgabe / Aufzeichnung hat alles ausgbremst.

Nach Änderungen läuft die Live-Auswertung unter WIN XP reibungslos auf 
dem etwas betagen AMD Athlon XP 2000+.

Ein Experiment mit dem selben PC und dem VB6-Programm unter Wine/Linux:
Die Auswertung läuft über 2 Minuten nach Testende immer noch...

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
>Wie weiter oben schon geschrieben haben die 32Bit aber in der Regel
>keine "einfache" Möglichkeit für simple Funktionen wie Pin-Togglen.

Pin Toggeln ist auch auf 32Bittern einfach, nur meist nicht besonders 
schnell ;). Die LPC122x hätten aber ein spezielles Pin-Toggel Register. 
Damit lassen sich sogar mehrere Pins gleichzeitg toggeln. Da streichen 
dann die 8Bitter wiederum die Segel.

> Wenn man dies überdenkt, dann wird schnell klar warum also für einen
> 8Bitter die vorhandene Peripherie und Bibliotheken dazu viel viel
> wichtiger sind als die reine REchenleistung.

Ich verwende fast nur noch 32Bitter. Aber eben nicht wegen der 
Geschwindigkeit sondern aufgrund von Peripherie, Preis und 
Kompatibilität. Als Takt stelle ich bisweilen auch mal 1Mhz ein.
Einige PICs haben mitunter recht interessante Zusätze. Doch Pullups nur 
an vier Pins. Pulldowns fehlen ganz. Die Timer haben nur 8 oder 16 Bits 
und deren Prescaler sind sehr unflexibel. Wenn ich bei einem 32Bitter 
die Clock durch 285 teilen will dann stelle ich den Vorteiler 
entsprechend ein.
Bei allen GPIOs kann man Pullup-/down/opendrain einstellen. SPI und I2C 
lassen sich gleichzeitig verwenden.
Wenn der Takt für eine nachträglich eingebaute Funktion nicht ausreicht 
kann man einfach per Software die PLL umkonfigurieren und so z.B. von 
12Mhz auf 15Mhz gehen. Oder auf 60Mhz.
Ein spezielles Programmiergerät wird nicht benötigt. Die Uarts brauchen 
keine Baudratenquarze.
Wenn der LPC1764 gerade nicht lieferbar ist, setze ich eben einen 
LPC1766/1768 oder 1769 ein. Die sind binärkompatibel. Wie oft habe ich 
mich schon über Microchip geärgert weil ein Chip gerade nicht lieferbar 
ist und der Liefertermin bei MicrochipDirect Woche um Woche nach hinten 
geschoben wird. Ein Programm ist zwar schnell für einen anderen Typen 
angepasst aber das gibt ein neues Binary. Bei zukünftigen Updates muss 
man also erst nachsehen welcher µC gerade in dem Gerät verbaut ist.
Und wenn ich mir dann einmal die Preise ansehe - zumindest ab 32k Flash 
- frage ich mich schon weshalb ich für einen Controller der weniger kann 
mehr Geld ausgeben soll. Weil er ausreicht und 32Bit "übertrieben" sind?


Markus B. p. schrieb:
> Für einen schlechten Compiler,
> oder gar ein mieses Programm kann der Controler ja nichts.

Für ein schlechtes Programm kann er nichts, für den Compiler zwar auch 
nicht aber wenn ich in C programmieren will/muss und mir kein gescheiter 
Compiler zu Verfügung steht, dann muss das letzlich der Controller 
ausbaden. Das trifft in dieser Diskussion vor allem die Microchip 
Compiler in den kostenlosen Ausführungen. Beim C18 weiß ich nicht was 
passiert (habe ihn nie verwendet) aber bei den GCC basierten C30 und C32 
steht nach der Testzeit anscheinend nur noch die Optimierungsstufe "-O1" 
zur Verfügung. Das habe ich mal bei einem M3 Projekt mit einem GLCD 
probiert. Gegenüber der Stufe "-O2" kostet das über 20% Geschwindigkeit 
und das Programm ist etwa doppelt so groß. Wenn das bei den PICs auch so 
ist dann aber gute Nacht.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Die LPC122x hätten aber ein spezielles Pin-Toggel Register.
>Damit lassen sich sogar mehrere Pins gleichzeitg toggeln. Da streichen
> dann die 8Bitter wiederum die Segel.

Bei den ATXMegas (8 Bit) hat jeder Port sogar jeweils ein Register zum 
Setzen, Löschen und Togglen von Pins. Und bei neueren AVRs bewirkt ein 
Schreiben einer 1 auf ein, oder mehrere, Bit(s) auf das bei allen AVRs 
vorhandene PIN-Register ein Togglen der angesprochenen PINs. Da werden 
eher Segel gehisst.

MfG Spess

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:

> Schreiben einer 1 auf ein, oder mehrere, Bit(s) auf das bei allen AVRs
> vorhandene PIN-Register ein Togglen der angesprochenen PINs. Da werden
> eher Segel gehisst.

Es gibt neben dem Setzen, Löschen und Toggeln einzelner Bits eine 
weitere wesentliche aber eben nicht obligatorische Grundoperation auf 
Ports: Eine Untermenge der Bits (>1) eines Ports gleichzeitig und atomar 
auf einen bestimmten Wert setzen.

Nicht-atomar ist das die übliche read-modify-write Kiste aus mehreren 
Befehlen. Nicht extrem schnell, aber sonst kein Problem.

Aber wenn der Port auch in einer ISR verwendet wird, dann wirds 
schwieriger und da sind die CISCs ohne Hilfestellung durch Portlogik 
meist auch nicht besser dran als die RISCs. Sowas kann man dann per 
Maske lösen wie bei der ARM PrimeCell in der Adresse und den LPCs im 
Register, oder aber in wie bei den STM32 in den Daten selbst. Bei den 
AVRs kommt man u.U. mit der erwähnten XOR-Masche der PINx weiter.

Hat man nichts dergleichen, dann muss man Inerrupts sperren. Unschön. 
Bei den PIC30 geht das zwar im Prinzip sehr einfach, bildet sich aber 
extrem schlecht auf C-Programmierung ab.

Autor: Markus B. (markus_b77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. schrieb:
> Die LPC122x hätten aber ein spezielles Pin-Toggel Register.
> Damit lassen sich sogar mehrere Pins gleichzeitg toggeln. Da streichen
> dann die 8Bitter wiederum die Segel.
>
> Als Takt stelle ich bisweilen auch mal 1Mhz ein.
> Wenn ich bei einem 32Bitter die Clock durch 285 teilen will dann stelle
> ich den Vorteiler entsprechend ein.
> Bei allen GPIOs kann man Pullup-/down/opendrain einstellen. SPI und I2C
> lassen sich gleichzeitig verwenden.
> Wenn der Takt für eine nachträglich eingebaute Funktion nicht ausreicht
> kann man einfach per Software die PLL umkonfigurieren und so z.B. von
> 12Mhz auf 15Mhz gehen. Oder auf 60Mhz.
> Ein spezielles Programmiergerät wird nicht benötigt. Die Uarts brauchen
> keine Baudratenquarze.

Klingt nach Xmega SCNR

Autor: Markus B. p. (mbp-bayern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Und bei neueren AVRs bewirkt ein
> Schreiben einer 1 auf ein, oder mehrere, Bit(s) auf das bei allen AVRs
> vorhandene PIN-Register ein Togglen der angesprochenen PINs.

Aua.
Die armen AVR-Anfänger oder Umsteiger auf AVR.

Wenn ich mich recht erinnere,
so hat "Write" an "PIN" früher einfach NIX geändert,
und nun Toggelt der...

Wer das nicht beachtet und einen solchen neuen Controller erwischt,
der hat noch größere Freude am Fehlersuchen als ich damals.

Da ist PIC18 echt einsteigerfreundlich :-)
Aus dem PIC18F4685 Datenblatt:
"Reading the PORTA register reads the status of the
pins, whereas writing to it, will write to the port latch."


MFG:MBP
Markus.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das wieder so ein typischer "Religionskrieg". So was gab es übrigens 
schon immer, berühmt war beispielsweise in den 1980gern der Z80 - 6502 
Krieg.

Für mich persönlich ist das so:
Ich habe mir mal die PICs angeschaut, aber die die ich da gesehen hatten 
konnten damals nur 16 Bytes auf einmal aufrufen, den Rest musste man per 
Bankswitching machen. Auch waren die für die ersten Sachen die ich 
machen wollte damals zu langsam.

AtMegas hab ich mir dann mal angeschaut als ich eine CCD Kamera gegen 
ein Evaluationsboard von Atmel getauscht habe. Der war dann auch schnell 
genug für Video.

MSP430 hab ich mir mal ein wenig angeschaut, damals gab es aber noch 
keine freien Entwicklungswerkzeuge. Inzwischen gibts zumindest einen 
freien C-Compiler, aber anscheinend noch keinen freien Assembler. Da ich 
persönlich C nicht mag, ist das ein Ausschlusskriterium für mich.

Wie schon gesagt, das sind persönliche Meinungen. Wenn mir jemand eine 
komplett freie Entwicklungsumgebung Assembler für die MSP430 Serie 
zeigen kann, oder ein Unix, welches auf den Controllern läuft. (Dann 
würde meiner Meinung nach C Sinn haben)

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die LPC122x hätten aber ein spezielles Pin-Toggel Register.
> Damit lassen sich sogar mehrere Pins gleichzeitg toggeln. Da streichen
> dann die 8Bitter wiederum die Segel.
Das ist nichts weiter als ein NOT/NEG-Befehl. Dauert bei STM8 1 Takt; 
bei einigen anderen Nicht-32-Bitern 1..4 Takte.

> Ich verwende fast nur noch 32Bitter. Aber eben nicht wegen der
> Geschwindigkeit sondern aufgrund von Peripherie, Preis und
> Kompatibilität.
Bei einigen 8/16/32-Bit-Serien ist die Peripherie gleich.

Autor: Markus B. (markus_b77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier wird sogar von einem ARM zu Xmega gewechselt

http://www.kickstarter.com/projects/itdaniher/cee-...

ARM ist kein Allheilmittel. Und so lange man unter Debian zum 
installieren und einrichten einer funktionierenden Toolchain länger 
braucht als eine Schnecke um die Erde ist es eh uninteressant.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Die armen AVR-Anfänger oder Umsteiger auf AVR.

>Wenn ich mich recht erinnere,
>so hat "Write" an "PIN" früher einfach NIX geändert,
>und nun Toggelt der...

Ja. Und das steht dann auch im jeweiligen Datenblatt. Wie bei deinem 
PIC. Wo ist das Problem?

MfG Spess

Autor: Markus B. (markus_b77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus B. p. schrieb:
> Wer das nicht beachtet und einen solchen neuen Controller erwischt,
...ist selber schuld. Wer schreibt schon in das PIN Register?

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Ich verwende fast nur noch 32Bitter. Aber eben nicht wegen der
>> Geschwindigkeit sondern aufgrund von Peripherie, Preis und
>> Kompatibilität.
> Bei einigen 8/16/32-Bit-Serien ist die Peripherie gleich.

Zum Beispiel?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. schrieb:

>> Bei einigen 8/16/32-Bit-Serien ist die Peripherie gleich.
>
> Zum Beispiel?

Bei STM8 und STM32 sind sie zwar nicht gleich, aber verwandt. Auch bei 
PIC18/30/32 finden sich Verwandschaften.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus B. schrieb:
> ARM ist kein Allheilmittel. Und so lange man unter Debian zum
> installieren und einrichten einer funktionierenden Toolchain länger
> braucht als eine Schnecke um die Erde ist es eh uninteressant.

Man bräuchte für ARM so eine Art CP/M. Quasi ein kleines Betriebssystem 
mit dem man direkt auf den Controllern entwickeln könnte.

Autor: Markus B. p. (mbp-bayern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Hi
>
>>Die armen AVR-Anfänger oder Umsteiger auf AVR.
>
>>Wenn ich mich recht erinnere,
>>so hat "Write" an "PIN" früher einfach NIX geändert,
>>und nun Toggelt der...
>
> Ja. Und das steht dann auch im jeweiligen Datenblatt. Wie bei deinem
> PIC. Wo ist das Problem?
>
> MfG Spess

Hi Spess,

Problem sehe ich für mich keines,
aber viele Anfänger werden die Datenblätter entweder nicht lesen,
oder nicht verstehen.

Selbst wenn sie es lesen und verstehen,
so gibt es für sie noch immer die Möglichkeit den Fehler zu machen.
Und die Möglichkeiten nutzt man als Anfänger fast ALLE aus.

Aber frage einmal AVR Anfänger - jene werden diese Stelle am AVR als 
Schwierig einstufen, bis sie Routine daruf haben.

Bei AT89S52 gibt es gar nur ein Register pro Port.
Das wäre für Anfänger also noch einfacher.

MFG:MBP
Markus.

Autor: stiller Beobachter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus welchem Grund ist es so kompliziert eine funktionierende Toolchain 
für ARM-xy zu installieren? Sollte es doch für die gebräuchlichsten 
Typen  vorgefertigt geben, oder beißen sich da Interessen(gruppen) 
irgendwo?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Problem sehe ich für mich keines,
>aber viele Anfänger werden die Datenblätter entweder nicht lesen,
>oder nicht verstehen.

Wer sie nicht lest hat eh verloren. Verdient keine Gnade. Wer sie liest 
kann nachfragen. Ich stamme aus einer Zeit wo man sich Wissen ohne 
Internet aneignen musste. Deshalb habe ich für Weicheier in dieser 
Beziehung kein Verständnis.

MfG Spess

Autor: Sebastian G. (jaseg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger schrieb:
> Man bräuchte für ARM so eine Art CP/M. Quasi ein kleines Betriebssystem
> mit dem man direkt auf den Controllern entwickeln könnte.
Siehe da: http://www.freertos.org/

Ich habe neulich nach einem Controller gesucht, mit dem ich die PWM für 
drei LED-Schaltregler in Software implementieren kann, und wurde da bei 
den MSP430 fündig -- davon gibt es sogar einige sehr einfache Modelle 
(4kB Flash, 8MHz, DIP, ca. 1,5€) mit vier 16-Bit-PWM-Kanälen, beim AVR 
muss es dann schon ein ATMega8U2 oder größer sein (der hat dann auch USB 
etc. und ist entsprechend teurer, außerdem schwer zu bekommen).

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian G. schrieb:
> Christian Berger schrieb:
>> Man bräuchte für ARM so eine Art CP/M. Quasi ein kleines Betriebssystem
>> mit dem man direkt auf den Controllern entwickeln könnte.
> Siehe da: http://www.freertos.org/

FreeRTOS scheint weder eine Shell zu haben, noch einen C-Compiler. Das 
scheint ein reiner Kernel zu sein. Zu einem Betriebssystem gehört jedoch 
auch das "Userland", sprich die ganzen Betriebssystemswerkzeuge. Unter 
FreeRTOS scheint es weder einen Texteditor, noch einen Compiler zu 
geben.

> Ich habe neulich nach einem Controller gesucht, mit dem ich die PWM für
> drei LED-Schaltregler in Software implementieren kann, und wurde da bei
> den MSP430 fündig -- davon gibt es sogar einige sehr einfache Modelle
> (4kB Flash, 8MHz, DIP, ca. 1,5€) mit vier 16-Bit-PWM-Kanälen, beim AVR
> muss es dann schon ein ATMega8U2 oder größer sein (der hat dann auch USB
> etc. und ist entsprechend teurer, außerdem schwer zu bekommen).

Ich verstehe irgendwie nicht, was an der LED PWM-Steuerung so besonders 
sein soll. Das scheint mir ein Trivialproblem zu sein, das auf jedem 
Controller einfach funktioniert. Entweder mit Hardware PWM, oder einfach 
einen Timer laufen lassen, der dann die PWM für die n-Kanäle laufen 
lässt. Pro Kanal sind das grob 10 Taktzyklen. Macht bei 8 Kanälen 80 
Taktzyklen, also kann man beispielsweise mit einem 128-tel der 
Taktfrequenz arbeiten.

Autor: ein Tscheche (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tanolino schrieb:

> Die PIC haben für den selben Preiß mehr Programmspeicher aber dafür kein
> EEPROM.
> Beispiel (Preiße laut Reichelt):
>  ATMEGA 8-16 (DIL-28) max. 16MHz und 23 IO Ports
>  8kB Flash, 512B EEPROM, 1kB RAM
>  -> 2.60€
>
>  PIC 16F648A-I/P max.20MHz und 16 IO Ports
>  4kx14 Flash, 256B EEPROM, 256B RAM
>  dafür USART
>  -> 2.30€
>

Das Problem war die Wirtschafftskrise, da hatte Atmel teilweisse die 
Preisse verdoppelt während Microchip bei den niedrigen Preissen blieb.

Autor: Sebastian G. (jaseg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger schrieb:
> FreeRTOS scheint weder eine Shell zu haben, noch einen C-Compiler. Das
> scheint ein reiner Kernel zu sein. Zu einem Betriebssystem gehört jedoch
> auch das "Userland", sprich die ganzen Betriebssystemswerkzeuge. Unter
> FreeRTOS scheint es weder einen Texteditor, noch einen Compiler zu
> geben.
http://rowebots.com/products/dspnano_rtos
scheint eine shell zu bieten. Wikipedia nennt noch ein paar weitere:
http://en.wikipedia.org/wiki/List_of_operating_sys...

Christian Berger schrieb:
> Ich verstehe irgendwie nicht, was an der LED PWM-Steuerung so besonders
> sein soll. Das scheint mir ein Trivialproblem zu sein, das auf jedem
> Controller einfach funktioniert. Entweder mit Hardware PWM, oder einfach
> einen Timer laufen lassen, der dann die PWM für die n-Kanäle laufen
> lässt.
Ich wollte 3W-RGB-LEDs ansteuern, und hatte selbst bei 16-Bit-PWM einen 
merklichen Unterschied zwischen  Helligkeitsstufe 1/65536 und 2/65536. 
Nun wollte ich noch die Strombegrenzung mit der PWM implementieren 
(Schaltregler), was dazu führt, dass ich die 16 Bit noch nicht einmal 
komplett ausschöpfen kann (da z.B. 330mA Maximalstrom z.B. 50% duty 
cycle entsprechen und ich somit für die Helligkeitseinstellung nur den 
Bereicht von 0-50% zur Verfügung habe).

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus B. p. schrieb:
> Eigenlich müsste man die selbe Aufgabe in der jeweiligen
> Assemblersprache des Controlles selbst erstellen und optimieren, um
> wirklich nur Controller und nicht auch die Compiler zu vergelichen.

Diese Zahlen spiegeln aber nicht das wieder, was dich an einem µC 
interessiert, nämlich wie leistungsfähig er in der Entwicklungsumgebung 
ist, die tatsächlich eingesetzt wird bzw. werden soll.

Was bringt dir ein Assembler-Benchmark wenn angedacht ist, den µC in C 
zu programmieren oder umgekehrt? Nichts ausser ein paar nichtssagenden 
Zahlen.

Einige Compilerhersteller frickeln ewig an ihren Tools rum, um gute SPEC 
oder welche Benchmarks auch immer zu erzielen und schöne Zahlen 
veröffentlichen zu können.  Das ist doch alles Augenwischerei; was 
wirklich interessiert ist die letztendliche Entwicklungsumgebung und die 
Anatomie der Software (Dateilastig, Arithmetik, ...):
µC, Energieverbrauch, Softwareumgebung, Support, Architektur (die man 
nicht dauern wechseln will), Kosten, zu lösende Probleme und ein 
Profiling unter diesen Rahmenbedingungen.

Master Snowman schrieb:
> ich [...] habe eine uralte benchmark angehängt
> (keine ahnung mehr, woher ich die habe).

Gleiche Kerbe: Wer programmiert schon mit lokalen volatiles? Einfach ein 
unrealistischer Märchencode.

Carsten Sch. schrieb:
> Denn GCC basierende Compiler sind auch bei PIC üblich...
> Zwar nicht für die kleinen 8bitter, aber die Compiler für die
> Leistungsfähigeren basieren auf GCC und sind sogar Open Source.

Jeder GCC ist Freie Software (was anderes als Open Source).
Übrigens ist frei nicht gleichbedeutend mit kostenlos:
free as in freedom not as in free beer :-)

> nur mit
> dem Unterschied, daß der Support hier in erster Linie durch Microchip
> eigene Programmierer erbracht wird, die genau dafür angestellt sind und
> bezahlt werden... Im Gegensatz zum AVR, wo man dann darauf angewiesen
> ist, daß sich jemand mal in der Freizeit erbarmt und dazu gleich dann
> zig unterschiedliche Versionen nebeneinander existieren.

Du kannst auch ein Softwarehaus mit GCC-Expertise mit einem avr-gcc 
Support beauftragen; entsprechende Portokasse vorausgesetzt.

Allerdings sehe ich hier eher Atmel, also den Hersteller der AVRs, in 
der Pflicht, mehr für den Support von avr-gcc, seine Weiterentwicklung 
und Qualitätssicherung zu tun.  Aber irgendwie bekommt Atmel es nicht 
auf den Appel.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Meinung nach hat fast jeder einzelne Microcontroller seine 
Daseinsberechtigung. Wenn ich ein kleines Ambi-Light machen will mit 3 
Tastern und einem PWM-Ausgang, würde ich nie im Leben einen 16bit, 
gescheige denn einen 32bit MCU nehmen. So habe ich einen kleinen 8bit, 
8pol PIC genommen und alles hat wunderbar geklappt. Auch, wenn ein SOIC8 
vielleicht halb so groß ist, wie ein TQFP44 oder 64 eines 32bitters und 
wenn der 32bitter vielleicht nur 10 cent teurer aber deutlich 
leistungsfähiger ist, bringt mir das trotzdem nichts.
Anders hingegen sieht es aus, einen FTP-Server und Touch-LCD auf einen 
MCU zu bringen.

Deswegen: Für alles gibt es Anwendungsfälle. Da ist für mich ein 
Argument wie "Der und der kann aber besser/einfacher Pins togglen" viel 
zu speziell und unwichtig.

Autor: RonS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich schrieb:
> Für alles gibt es Anwendungsfälle.

Da haste schon recht, aber hier gings ja um "ATMEL billiger und 
leistungsfähiger als PIC"- und dem muss man eigentlich uneingeschränkt 
zustimmen. Zum gleichen Preis erhält man bei Atmel meist die technisch 
bessere Lösung. Und zumindest auch aus meiner bescheidenen 
Assemblerprogrammierer-Sicht. Wenn ich daran zurückdenke wie ich mich 
bei meinem ersten Projekt mit dem kastrierten Befehlssatz und dem 
elenden Banking rumgeschlagen habe! Da waren die aufkommenden Atmels 
eine Erlösung! Dann bleibt man natürlich dabei und mir fehlt bis heute 
jeder Grund wieder umzusteigen. Und wenns wirklich mal was Multimediales 
sein soll dann besser gleich zu ARM & Co.

Autor: Markus B. (markus_b77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atmel hat eigentlich nur zwei Fehler gemacht, und das gleich zwei mal.

Sowohl USB als auch CAN kamen zu spät und zu inkonsequent. Es gibt bis 
heute keine "großen" ATmega mit USB. Auch ein Xmega A1 mit USB fehlt 
noch. Dafür gibt es keine kleinen ATmega mit CAN und Xmega mit CAN gibt 
es gar nicht.

Dazu kommt noch, dass die ersten ATmega mit USB noch auf einer 
veralteten AVR Architektur aufbauten und es keine DIP Versionen gibt.

PS: ich sehe gerade, dass es inzwischen immerhin TQFP32 mit CAN gibt. 
Dafür wurden aber wieder Features weggelassen wie ein 8 Bit Timer oder 
TWI

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hast du wohl recht. Dann ist das Thema wohl zwischendurch ein wenig 
abgedriftet. Ich kenn mich zu wenig mit AVRs aus um hier qualitativ 
mitzureden ;) Das, was ich hier im Forum mal mitbekommen habe ist, das 
8bit-PICs, wenn es um CAN, USB und Ethernet geht, wohl besser geeignet 
sein sollen, als 8bit-AVRs. Doch das kann ich wie gesagt nicht 
beurteilen.

Autor: Markus B. (markus_b77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich schrieb:
> Das, was ich hier im Forum mal mitbekommen habe ist, das
> 8bit-PICs, wenn es um CAN, USB und Ethernet geht, wohl besser geeignet
> sein sollen, als 8bit-AVRs. Doch das kann ich wie gesagt nicht
> beurteilen.

Besser geeignet würde ich nicht sagen. Aber besser und konsequenter 
vermarktet.

Die AVR mit USB sind ja inzwischen schon nicht schlecht, mit Bootloader 
und so. Und dank dem LUFA Projekt bleiben eigentlich auch kaum Wünsche 
offen. Aber wie ich schon schrieb halt zu spät, nur in SMD usw.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wenn ich daran zurückdenke wie ich mich
>bei meinem ersten Projekt mit dem kastrierten Befehlssatz und dem
>elenden Banking rumgeschlagen habe!
Dies (grässliche Banking) gilt nicht mehr bei 16-Bit-Datenbreite-PICs!
Die sind auch schneller als AVR. (Sehr viele (rel complexe Befehle) mit 
nur 1 Cyc(2Takte)).
wie Bsp: (innerhalb 64kB-Bereich)
  MOV{.B}      [Ws++], [Wd++]               oder
  ADDC{.B} Wb, [Ws++], [Wd++]

Allerdings kann bei diesen PICs Ext.Mem-Anschaltung umständlich werden.

Autor: CPUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soll das heißen das ein 16bit Controller schneller ist als ein 8bitter ?
Das hätte ich jetzt nicht gedacht. Bist du dir da sicher?

>Allerdings kann bei diesen PICs Ext .Mem-Anschaltung umständlich werden.
Was will uns der Künstler damit sagen?

Autor: usw. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das thema stellt sich an und für sich nur für einsteiger. als solcher 
würd ich bei der umfangreicheren pic-modellpalette heute eher schwach 
werden, insbesondere als c-programmer. nun bin ich allerdings lange 
jahre atmel-sozialisiert und werd einen teufel tun da noch mal 
umzusteigen.

Autor: Conny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Warum gräbst du eine 4 Jahre alte Leiche aus?

Na siehst doch, wie groß der Bedarf ist :)
PIC vs. AVR ist halt in einem MC-Forum immer ein aktuelles Thema!

Conny

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Na siehst doch, wie groß der Bedarf ist :)
>PIC vs. AVR ist halt in einem MC-Forum immer ein aktuelles Thema!

Aber nur für Leute mit fortgeschrittenem Alzheimer.

MfG Spess

Autor: Conny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Aber nur für Leute mit fortgeschrittenem Alzheimer.

na na na... das ist schon ein wenig von oben herab, meinst Du nicht 
auch? Irgendwie hat dieser Thread ja wohl sebst auf Dich noch ein wenig 
Anziehungskraft :)

Beitrag #2289454 wurde von einem Moderator gelöscht.
Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Conny schrieb:
> Na siehst doch, wie groß der Bedarf ist

Für Religionskriege ist bei einigen Leuten immer Bedarf...

...

Autor: Down (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da Atmel demnächst 40 Typen der ATmega-Serie einstampfen wird, ist das 
Thema wieder offen. Wer wird dann gegen PIC antreten dürfen ? ....

Autor: Markus B. (markus_b77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Down schrieb:
> da Atmel demnächst 40 Typen der ATmega-Serie einstampfen wird
Nämlich?

Autor: Down (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die Typen sind mir noch nicht bekannt, aber das es kommen wird, habe ich 
heute erfahren. Atmel will nur noch 32-Bit machen.

Autor: heinzhorst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Quelle?

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Down schrieb:
> da Atmel demnächst 40 Typen der ATmega-Serie einstampfen wird

Naja, von vielen Typen gibt es bis zu vier Untertypen (*, *A, *P
und *PA). Wenn man hier die veralteten weglässt, hat man die 40 schon
fast zusammen.

> Atmel will nur noch 32-Bit machen.

Dass in näherer Zukunft (nächste 5 Jahre) alle 8-Bitter abgeschafft
werden sollen, kann ich mit kaum vorstellen. Aber die Entscheidung
treffe natürlich nicht ich, sondern irgendwelche Strategen bei Atmel.

Autor: Markus B. (markus_b77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Down schrieb:
> die Typen sind mir noch nicht bekannt, aber das es kommen wird, habe ich
> heute erfahren. Atmel will nur noch 32-Bit machen.

In welchem Kaffeesatz hast du denn das gelesen?

Klar kann es sein, dass Atmel demnächst jede Menge ATmega aus dem 
Programm schmeißt

ATmega8-16PU und ATmega8L-8PU - Wird ersetzt durch ATmega8A-PU
ATmega8-16AU und ATmega8L-8AU - Wird ersetzt durch ATmega8A-AU
ATmega8-16MU und ATmega8L-8MU - Wird ersetzt durch ATmega8A-MU

Sind schon sechs. Das ganze noch mit ATmega16, ATmega32, 64, 128. Die 
ATmega88 werden vermutlich auch  bald durch ATmega88PA ersetzt usw usw 
usw

Autor: Down (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dass in näherer Zukunft (nächste 5 Jahre) alle 8-Bitter abgeschafft

nein, das habe ich ja auch nicht geschrieben, aber das Angebot von den 8 
Bittern wird erheblich reduziert. Der XMEGA wird bleiben, aber andere 
Typen werden einfach verschwinden.
Wir setzen selbst einen Atmega in >20k ein, deshalb war ich heute auch 
etwas geschockt.

> In welchem Kaffeesatz hast du denn das gelesen?

mit Kaffee hat das eigentlich nichts zu tun.

Frage einfach deinen Distri und schaue ihn dabei in die Augen. Das sagt 
alles.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke auch, daß es nur darum geht, den Wildwuchs quasi identischer 
AVRs zu bereinigen.
Also alle ATmega*, ATmega*A, ATmega*P weg und nur jeweils den ATmega*PA 
übrig lassen.

Die Abschaffung der 5V-Typen generell wäre aber schlecht.
Das würde ne Menge Arbeit kosten, auf 3,3V umzustellen, ohne das die 
technischen Daten schlechter werden.
Bei 3,3V hat man kaum noch Luft für saubere Analogsignale.
Echtes Rail to Rail funktioniert nicht wirklich.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Down schrieb:
> Der XMEGA wird bleiben, aber andere
> Typen werden einfach verschwinden.

Also ausgerechnet der, den keiner braucht. Gibt doch schon reichlich 
andere 3,3V MCs.


Peter

Autor: Markus B. (markus_b77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Also ausgerechnet der, den keiner braucht. Gibt doch schon reichlich
> andere 3,3V MCs.

Also ich finden die Xmega mehr als interessant. Alte Tools 
weiterverwenden, neue Features und mehr Rechenleistung bekommen

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:

> Die Abschaffung der 5V-Typen generell wäre aber schlecht.

Es würde allen Kunden signalisieren: Finger weg von Atmel Produkten, 
weil ab und zu populäre Ware ohne langfristige Ankündigung und 
kompatiblen Ersatz eingestampft wird. Der sicherste Weg in die Pleite. 
Kaum anzunehmen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So schlecht kann doch AVR bei Atmel nicht angesehen sein, immerhin haben 
sie in Ermangelung einer besseren Idee AVR32 danach benannt.  Ganz im 
Bewusstsein, daß AVR einen guten Namen hat und in der Hoffnung, daß es 
ein bissl auf AVR32 abfärbt -- was wohl nicht ganz gelang.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.