PIC oder AVR, was ist besser

Pat schrieb:
> Eine Frage: Was ist besser für Anfänger.
> PIC oder AVR Prozessoren?
> Drei Sachen sind mir wichtig:
> 1. Einfacher Einstieg und leicht erlernbar
> 2. Preisgünstiger Einstieg mit möglichst niedrigen Kosten.
> 3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows mit
> der gleichen Programmiersprache und 100% gleiche Syntax.

Die Forderungen werden zumindest von den ATmegas problemlos erfüllt. 
Mehr kann ich Dir mangels Erfahrung mit PICs nicht dazu sagen.

Pat schrieb:
> PIC oder AVR Prozessoren?

Schau mal links oben, was da steht.
# Home
# AVR

Die PIC-Anwender sind also hier mit Sicherheit in der Minderzahl.

Pat schrieb:
> 3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows

Folgt man dem Link, findet man z.B.:
AVR Eclipse: Win, Linux, Mac


Peter

Pat schrieb:
> Eine Frage: Was ist besser für Anfänger.
> PIC oder AVR Prozessoren?
> Drei Sachen sind mir wichtig:
> 1. Einfacher Einstieg und leicht erlernbar
> 2. Preisgünstiger Einstieg mit möglichst niedrigen Kosten.
> 3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows mit
> der gleichen Programmiersprache und 100% gleiche Syntax.

Nummer 3 erzwingt AVR. Für den gibts einen freien GCC-Port, und der ist 
unter Linux und Windows identisch.

Bei PIC ist das anders. Die 8-Bit PICs (also bis PIC18) haben ein sehr C 
unfreundliches Design. Vollständig ANSI-kompatible C-Compiler gibts von 
Microchip (MPLAB C18) und von Microchip (Hitech C, Microchip hat die 
Firma gekauft), und hier hast Du die Wahl zwischen Windows und Windows. 
Man kann damit auch gut arbeiten, aber nicht unter Linux.

Ab PIC24 basieren die C-Compiler von Microchip auch auf dem GCC. 
Microchip bietet die nur für Windows an. Technisch könntest Du den auf 
Linux portieren (und dabei den Lizenzmanager rauswerfen), aber die 
Lizenz der Bibliotheken (kein GNU) verbietet Dir das. (*)

Das Debugging ist von Microchip meiner Meinung nach besser gelöst, die 
Tools billiger; und Du kannst z.B. MPLAB und ICD3 von PIC10 (6-Pinner) 
bis PIC32MX (80 MHz 32Bit MIPS-Kern) benutzen.

Architekturmäßig sind PIC24 und AVR relativ ähnlich, mit dem 
Unterschied, dass PIC24 eben 16-bittig intern ist.

Die kleineren PICs haben eine sehr spartanische Architektur, die 35 
Jahre alt ist und ein architekturbedingtes RAM-Maximum von 4k-128 Bytes 
hat, auch noch schön mit Bankswitching und so. Den Strass sparst Du dir 
beim AVR. Wenn Du einen mit externem Adress/Datenbus hast, kannst Du 
extern problemlos 64KB RAM anschließen, mit Bankswitching auch noch viel 
mehr.

fchk

(*) Ich bin kein Anwalt, daher keine Rechtsberatung!

Hi,

Marvin M. schrieb:
> Hallo,
> eindeutig AVR.
>
> Vor allem, wenn man interessehalber Assembler programmieren will, sind
> die AVRs wirklich einfach erlernbar. PICs in Assembler programmieren?
> Nur für Masochisten.
> Die PICs, die ich mal gekauft habe, liegen ungenutzt in der Ecke,
> seitdem ich die AVRs entdeckt habe.

IMMER wenn jemand bei einer solchen Frage: Pic oder AVR sagt das EINER 
der beiden EINDEUTIG besser ist, dann ist die Aussage schon mal mit 
großer Vorsicht zu genießen - (Ich wollte jetzt nicht schreiben: HAt der 
keine Ahnung...)
Beide Plattformen haben ihre Vor- und Nachteile und sind in der Summe 
für den Hobbybastler gleichwertig! Als ein Beispiel: Die Pics, auch 
exoten, bekommst du in DL fast ALLE Problemos -und das recht günstig. 
Bei dem was nicht 08/15 Bastlerware ist wird es bei Atmel dafür deutlich 
teurer und/oder schwieriger. Geht schon bei den Typen mit integrierten 
CAN oder USB los... Ausserdem bietet Microchip auch sehr Leistungsfähige 
Varianten noch in DIP an, also auch noch fürs Steckbrett oder den 
Grobmotoriker geeignet. Atmel nicht!
Andererseits ist die deutschsprachige ATMEL AVR Community sicherlich 
einiges Größer als die ebenfalls nicht kleine PIC Commuunity. 
(International sieht es wieder anders aus)

Und auch bei Tutorials, Frameworks usw. Für PIC gibt es eine Menge 
hervorragender Tools, Frameworks Beispielcodes direkt gut verständlich 
aufbereitet kostenlos von Microchip selbst. Aus der Community gibt es da 
natürlich auch noch was dazu.
Bei ATMEL ist das Angebot von Atmel selbst bei weiten nicht so gut, das 
wird aber durch die Community wieder super wettgemacht! In der Summe 
kommt es wieder auf ein ähnliches Niveau heraus. Wem nun was lieber ist, 
das ist jedem Selbst überlassen. Ist auch eine Glaubensfrage Gibt PRO 
und CONTRA Argumente zu beiden Philosophien!

Und es gibt noch viele andere Punkte mehr, Suche benutzen...

Aber da die obige Meldung sich auf Assembler bezog:
Wenn man zwischen PIC und AVR in Assembler vergleicht, dann gibt es 
Unterschiede. PIC hat einige Eigenheiten die Gewöhnungsbedürftig sind, 
keine Frage. Aber da reden wir von Dingen die ein normal begabter Mensch 
nach einer Stunde verstanden haben sollte. Dafür ist der Befehlsumfang 
beim Pic wesentlich kompakter als beim AVR, der auch so seine Tücken 
hat.
Dem einen liegt daher eher der AVR Assembler, dem anderen die PIC 
Variante, der Dritte kapiert von beiden nichts...
(Ausserdem sind auch die Vorerfahrungen entscheidend, wenn jemand vorher 
mit einem Controller gearbeitet hat dessen Assemblerprogrammierung eher 
der des AVRs glich, dann kommt er nun einmal anfangs mit PIC nicht so 
gut zurecht...
Daher: Beides anschauen und dir deine eigene Meinung bilden!

Frank K. schrieb:
> Die kleineren PICs haben eine sehr spartanische Architektur, die 35
> Jahre alt ist und ein architekturbedingtes RAM-Maximum von 4k-128 Bytes
> hat, auch noch schön mit Bankswitching und so. Den Strass sparst Du dir
> beim AVR. Wenn Du einen mit externem Adress/Datenbus hast, kannst Du
> extern problemlos 64KB RAM anschließen, mit Bankswitching auch noch viel
> mehr.

In dem Beistrag (gesamt) von Frank stehen viele richtige Sachen. Einer 
der (leder zu wenigen) AVR Freunde (so scheint es zumindest) der 
sachliche Argumente bringt. Wobei ich die Compilerfrage unter Linux 
nicht beurteilen kann. Ich akzeptiere das geschriebene mal so als 
Tatsache. (Will hier nicht den nächsten Krieg anzetteln, aber DAS was 
ICH mit MEINEM PC machen will und muss, das bekomme ICH mit 
Windows einfach mit deutlich weniger Aufwand und Ärger hin...)

Zu dem oben zitierten Textabschnitt aber muss ich sagen: Stimmt, die 
alten PICs beruhen auf einem sehr alten, aber doch imemr 
weiterentwickeltem Design, erfüllen ihren Zweck sehr sicher, sind aber 
sicher alles ander als hochperformante Controller.
Allerdings zieht man ja wenn man Mercedes und BMW vergleicht ja auch 
nicht auf der einen Seite einen 20Jahre alten Dreier und auf der anderen 
eine drei Monate alte S Klasse heran.
Fakt ist: Microchip hat noch Controller mit den obigen Einschränkungen 
im Programm und wird die auch weiter noch vertreiben, zur Freude vieler 
Anwender - im gegensatz zu vielen anderen Herstellern die Rücksichtslose 
Abkündigungspolitik betreiben, aber es sind seit jahren andere 
Generationen Standart!

Wenn man heute Anfängt, dann sicher nicht mehr mit einem 16C54, auch 
nicht mit einem 16F84, beides Fälle fürs Museum, sondern mit einem 
halbwegs modernen µC wie zum beispiel dem 18F4550 der auch gleich noch 
eine integrierte USB Schnittstelle (die man ja nicht benutzen muss) und 
universelle Takterzeugung mit PLL mitbringt, sowie sowohl in Assembler 
als auch in C Programmiert werden kann. (Wobei die Optimierung ganz klar 
in richtung C geht. Und wenn man dann die USB Schnittstelle nutzen 
möchte, dann ist ausser für den HArdcore Masochichsten alles andere als 
C eh ausgeschlossen, wo dann auch gleich ein super USB Stack von 
Microchip zur Verfügung gestellt wird.

DAHER:
Es gibt keine EINDEUTIG richtige Wahl. Mal ganz davon abgesehen das es 
noch deutlich mehr unter der Sonne gibt als PIC und AVR. (Wobei einer 
der beidne für den Anfang schon wohl das beste ist)
Schaue dir beide mal genauer an, überdenke deiner Liste der 
Anforderungen noch einmal wie wichtig jetzt alles für sich genommen ist 
und ob vieleicht noch etwas dazu kommt, dann triff deine Wahl und fange 
mit dem dann an.
Wenn jetzt die Frage nach der Toolgleichheit zwischen Windows und Linux 
(ohne Anwendung von virtuellen Maschinen) bei dir eine hohe Priorität 
hat, dann könnte es durchaus ja der AVR sein... Wobei mir das erst 
einmal zweitrangig wäre, denn in der virtuellen Umgebung läuft auch die 
PIC Windows Software unter linux - aber das muss jeder für sich wissen!

Willst du aber später wirklich sinnvoll Arbeiten, solltest du unbedingt 
auch den anderen und noch weitere Controller nach deinen ersten 
erfolgreichen Schritten kennelernen wollen.

Gruß
Carsten
(PIC und AVR Verwender (neben einigen anderen), allerdings mit einer 
Vorliebe für die Pics bei gleicher Eignung fürs jeweilige Projekt...)

ich habe mich für die PICs entschieden, und bin bis heute mit der wahl 
glücklich (ich musste auch mal AVRs programmieren). der ratschlag, eine 
münze zu werfen, wenn man nicht weiss, was man will, finde ich die beste 
lösung.

Wäre eine der beiden Architekturen der anderen wirklich größtenteils 
unterlegen, gäbe es sie sicher nicht mehr. Soviel zum Thema "besser". 
;-)

Einem Anfänger würde ich immer raten, mit C anzufangen und nicht mit 
Assembler. Sich mit der Hardware auseinander zu setzen ist auch so schon 
schwer genug. Details der Architektur wie "nur wenige, leicht erlernbare 
Assemblerbefehle" etc. sind da nicht mehr relevant.

Und das spricht aus meiner Sicht dann am Ende für die AVRs als 
Einsteiger-Familie. Denn im Gegensatz zum PIC kann man hier die ganze 
8-Bit-Familie - vom Acht-Beiner bis zum Tausendfüßler - mit ein und 
demselben Compiler (GCC) programmieren. Die Hardware ist in der Regel 
sehr konservativ und konsequent realisiert, so dass man sich bei einem 
neuen Stein sehr schnell zurecht findet. Das ist im Vergleich zu den 
PICs dem einen oder anderen vielleicht etwas langweilig ;-), ist für 
mich aber eher positiv zu werten.

-ausschlaggebend waren die 35 Befehle der kleinen Pics

Hi,
Detlev T. schrieb:
> Wäre eine der beiden Architekturen der anderen wirklich größtenteils
> unterlegen, gäbe es sie sicher nicht mehr. Soviel zum Thema "besser".
> ;-)
Full Ack

> Einem Anfänger würde ich immer raten, mit C anzufangen und nicht mit
> Assembler. Sich mit der Hardware auseinander zu setzen ist auch so schon
> schwer genug. Details der Architektur wie "nur wenige, leicht erlernbare
> Assemblerbefehle" etc. sind da nicht mehr relevant.

Sehe ich etwas gespalten...
Also die ALLERERSTEN Schritte mit einem Mikrokontroller würde ich immer 
in Assembler machen! Wenn man ein Programm vernünftige entwickeln 
möchte, dann braucht man einfach ein gewisses Grundverständniss für die 
Plattform auf der es läuft. Erst recht wenn man nur die extrem 
eingeschränkten DebugMöglichkeiten eines µC Anfängers hat, der die 
sowieso schon eingeschränkten Möglichkeiten mangels teurer Ausstattung 
nicht mal ansatzweise ausschöpfen kann.

Aber klar! Alles was über einen LED Blinkschaltung mit Tastenabfrage 
hinausgeht braucht für einen Anfänger nicht merh in Assembler sein. Ich 
sage immer: Sobald die LED auf Tastendruck -anders- Blinkt gehe nach C!

Allerdings hat der TE ja explizit nahc Assembler gefragt! Und dann 
gehören sowohl der Vorteil der nur wenigen Befehle wie auch der Nachteil 
-zumindest bei den ALTEN Modellen- der Bankumschaltung bei den 16F Pics 
genannt. (Auf AVR verzichte ich jetzt mal)

> Und das spricht aus meiner Sicht dann am Ende für die AVRs als
> Einsteiger-Familie. Denn im Gegensatz zum PIC kann man hier die ganze
> 8-Bit-Familie - vom Acht-Beiner bis zum Tausendfüßler - mit ein und
> demselben Compiler (GCC) programmieren. Die Hardware ist in der Regel
> sehr konservativ und konsequent realisiert, so dass man sich bei einem
> neuen Stein sehr schnell zurecht findet. Das ist im Vergleich zu den
> PICs dem einen oder anderen vielleicht etwas langweilig ;-), ist für
> mich aber eher positiv zu werten.

Das ist aber bei den PICs auch der Fall wenn man möchte... Verwendet man 
statt des Microchip C Compilers nun den Hi-TEch Compiler, der ja 
ebenfalls, wenn auch mit für Hobbyisten völlig irrelevanter 
eingeschränkter Codeoptimierung, frei von Microchip Verfügbar ist.

Dann hat du auch vom 6Pinner bis zum "großen Brummer" alles mit 
demselben Compiler. Die gesamte 8Bit Familie!!!
Oder du entscheidest dich für den Microchip C-Compiler, weil du sagst 
OK, 6 und 8 Pinner brauche ich momentan nicht, wenn dann kann ich mich 
da auch noch kurz einarbeiten (SO Unterschiedlich sind die beiden 
Compiler ja nicht) dann hast du sowohl den modernen Teil der 8Bit 
Familie, die 16Bit Familie und die 32Bit Familie grundsätzlich mit 
demselben Compiler (auch wenn sich die interne Struktur natürlich 
ändert, aber das merkt man nicht)

Darüberhinaus hast du hier vom 8Bit 6 beinigem Käfer bis zum 32Bit High 
End Controller mit DSP eigenschaften dieselbe Programmierhardware welche 
schon in der Grundversion für 30 Eur. umfangreiche 
Debuggingeigenschaften bietet. Das hast du bei AVR wiederrum nicht,
Ach ja, der 32Bit µC von Microchip hat einen MIPS kern welches von der 
technologie eine der beiden großen Architekturen ist (neben ARM). 32 Bit 
MIPS µC werden auch von anderen Herstellern angeboten!
32BIT AVR haben etwas völlig eigenes welches in der Verbeitung um welten 
kleiner ist...

Hat man aber gar nicht vor irgendwann auch auf 32Bit zu gehen -natürlich 
völlig irrelevant.

DAHER:
Die Münze ist manchmal ein echt guter Rat...
(Ich würde ja PIC sagen, aber das ist rein meine eigene Sichtweise)

Gruß
Carsten

P.S.: Ein echtes pro PIC Argument fällt mir aber gerade noch ein, mit 
dem Anfänger oft echt bei AVR zu kämpfen haben - Und mir fällt da bei 
leibe kein Gegenargument ein wo die Vorteile davon liegen könnten:
Diese dämliche Eigenschaft der FuseBits beim AVR!
Man kann sich beim AVR selbst aussperren, so das man über ISP nicht mehr 
in den IC reinkommt. Dies kann passieren wenn man einen Fehler beim 
setzen der FuseBits macht oder aber auch einfach wenn der 
Programmiervorgang gestörtt wird. Hat man keinen HV Programmen, dann 
kann man den IC wegwerfen... Hat man einen HV Programmer, geht das 
natürlich meist, manchmal muss man aber trotzdem den µC aus der 
Schaltung ausbauen und in einen eigenen Sockel setzen. Sehr toll bei SMD 
oder ungesockelten µC!
Bei PICs kann dir das niemals passieren.

Eine andere, aber hier nicht wirklkich tragische, Falle ist dann noch 
das JTAG Bit - denke aber das man hier mit leben kann. Für Anfänger nur 
manchmal ein Grund zum Stutzen...

Detlev T. schrieb:

> Wäre eine der beiden Architekturen der anderen wirklich größtenteils
> unterlegen, gäbe es sie sicher nicht mehr. Soviel zum Thema "besser".
> ;-)

In den 90ern entschied sich, welche Architektur den Server-, 
Workstation- und Desktop-Markt dominieren wird. Es war letztlich die 
unter diesem Aspekt unstrittig schlechteste von allen verfügbaren 
Alternativen. Das ist also kein Argument. Die Enscheidungen fallen 
anhand anderer Kriterien.

Sven P. schrieb:
> Die Kehrseite ist, dass Microchip ziemlich großzügig mit Bugs um sich
> wirft, selbst bei den kleinen 8-Bittern. Du wirst Mühe haben,
> irgendeinen Baustein zu finden, der keine Fehler im Silizium hat oder
> hatte.
> Leider sind das meistens nicht Fehler der Art, die man mit zwei
> Kondensatoren mehr am Quarz (ATmega8..) oder einem gescheiten Programmer
> (Signaturbytes gehen flöten bei einigen AVR) umgehen kann.
>
> Typische Fehler bei den PIC sind kaputte Instruktionen, die ungewollte
> Nebenwirkungen haben (löscht irgendwelche Bits) oder verbaute SRF: Der
> AD-Wandler hält nicht automatisch an, ein Timer-Modus ist kaputt, eine
> (erlaubte) Konfiguration des Timers löst einen Reset aus (der alte
> 12F635), um ein paar Beispiele zu nennen.
Naja, ganz so tragisch ist das aber nicht!
Bausteine die auf dem Markt sind und solche gravierenden Fehler haben, 
die musst du aber wirklich suchen. Und die gibt es auch bei AVR!
Da tun die sich nicht wirklich viel...
Natürlich, bei Microchip hast du in der Summer mehr µC mit Bugs, einfach 
weil es deutlich mehr Bausteine gibt! Und auch weil die fast nicht 
vollständig abkündigen sondern Bausteine für die es keinen Baustein gibt 
der garantiert fast ohne Codeänderung 100% kompatibel ist im Programm 
lassen. Da bleiebn halt auch die BUgs mit drin. In der Beschreibeung der 
Bausteine steht dann aber auch eindeutig das die nicht mehr für stand 
der technik sind.
Ob der Durchschnitt aber so viel schlimmer ist... Da gibt es bei AVR, 
wenn ich das jetzt noch richtig im Kopf habe, auch heute noch µCs wo zum 
beispiel das PWM Modul so buggy ist das es nicht zu nutzen ist.

> Das kann ganz schön an die Nerven gehen. Als Hobby-Mensch ist das erst
> Recht frustrierend: Microchip flickt zwar auch Fehler, aber wenn du --
> wie etwa bei Reichelt -- nicht erkennen kannst, welche Silizium-Revision
> du bekommst, ist das doof. Da ist der Fehler vielleicht schon drei Jahre
> behoben und du kriegst alte Lagerware.
Naja, normalerweise erkennt man es schon, wenn es nämlich bedeutende 
Fehler sind, dann schlägt sich die änderung im Namen nieder. Dann heist 
der URbaustein zum Beispiel 16Fxx0 und die bearbeitete Version 16Fxx0-A. 
Das stht auch drauf.
Davon abgesehen: Ich entwickle seit über 10 Jahren privat und beruflich 
Schaltungen mit µC. Und hatte erst -gerade extra noch nachgeschaut- drei 
mal den fall das ich bei Microchip wirklich im Errata Sheet nachschlagen 
musste warum der PIC nicht das macht was ich will und wie ich das zu 
umgehen habe. Bei AVR war es zwei mal der Fall. (Und ich nehme häufiger 
den PIC) Wenn man ehrlich ist, dann sind fast alle Fehler ja solcher aRt 
das die bei extrem speziellen Konstellationen erst auftreten!

> Schau für Spaß mal ins Errata des ENC28J60 (dieser Ethernet-PHY) rein.
Naja, wirkt erschreckend, aber das ist nun auch einer der ersten für 
Hobbyisten überhaupt verfügbaren Ethernet Controller gewesen. Und eine 
sehr Komplexe Funktion verbunden mit früher einführung ist nun einmal 
immer ein Fall für BUGs, KEIN Hersteller schaft das BUG-Frei.

Aber gerade der ENC28J60 ist ein schlechtes Beispiel, weil der ja 
eigendlich der Baustein ist den die ganze AVR Welt verwendet. Die PICler 
nehmen einfach einen der PICs mit integriertem Ethernetkern und sparen 
so Platz, Kosten und Bestückungsaufwand. Ausserdem bleibt die SPI 
schnittstelle frei ;-)
>
> Verglichen damit sind die 8-Bit-AVR quasi 'perfekt'.
Da wage ich zu wiedersprechen!

Gruß
Carsten

Detlev T. schrieb:

> Wäre eine der beiden Architekturen der anderen wirklich größtenteils
> unterlegen, gäbe es sie sicher nicht mehr. Soviel zum Thema "besser".
> ;-)

Fortsetzung:

Wäre die Architektur wirklich ein Thema, die PICs wären aufgrund der 
Dominanz von Programmierung in C längst weg vom Fenster (und die übrigen 
Harvard-Biester einschliesslich AVR und i51 hätten auch einen schlechten 
Stand). Die PIC10/12/16 sind eine Katastrophe für einen C Compiler und 
die PIC18 sind in der Hinsicht auch erst in der zweiten 
Architektur-Revision erträglich - das ist diejenige, die im kostenlosen 
C18 nicht genutzt werden kann ;-).

Statt dessen halten sich im 8-Bit Markt standhaft jene Architekturen, 
bei denen der C-Programmierer gezwungen ist, um Absonderlichkeiten der 
Hardware herumzuprogrammieren, wie getrennte Adressräume für ROM und RAM 
und ggf. gleich mehrere für RAM, Besonderheiten im Umgang mit Daten und 
Unterprogrammen in Interrupt-Handlern, ...

Tatsächlich aber kann man auch Architekturen sehr wohl nutzen, die einem 
in mancher Hinsicht das Leben schwer machen. Eben weil es auch andere 
Gründe gibt. Die Funktionalität der I/O-Module der PICs wurde schon 
genannt. Andere wie i51 haben der Vorteil, dass sie irgendwie immer 
schon da waren und fast jeder Hersteller mit dazu beiträgt. Und ein 
bischen auch, weil man es so gewohnt ist, schon immer so gemacht hat, da 
könnte ja jeder kommen ;-).

Das Gegenmodell wäre z.B. MSP430. Blitzsaubere Architektur, aber die 
Funktionalität hält sich verglichen mit PIC18, PIC24, AVR, ... sehr in 
Grenzen.

Und die Interessen der Massenkunden sind sowieso gänzlich anders. Anders 
als Atmel und Microchip schert sich Freescale einen feuchten Dreck um 
Bastler und Krämer und überlebt dennoch. Denn in deren Markt steckt das 
Geld, nicht im Kleinkram.

A. K. schrieb:
> Die PIC10/12/16 sind eine Katastrophe für einen C Compiler und
> die PIC18 sind in der Hinsicht auch erst in der zweiten
> Architektur-Revision einigermassen brauchbar - das ist diejenige, die im
> kostenlosen C18 nicht genutzt werden kann ;-).

Welche µCs können den im kostenlosen Compiler nicht genutzt werden... 
Das ist mir neu das es da welche gibt... ausser der schlechteren 
Codeoptimierung gibt es keine Einschränkung beim Compiler - und die ist 
für den Hobbyisten völlig irrelevant das diese in 95% der Fälle eh 
keinen Code schreiben der den Speicher selbst völlig ohne Optimierung 
auch nur Ansatzweise füllen würde. Und in den restlichen 5% der Fälle 
investiert man einfach die 10-20ct für den Bautein mit dem nächsthöheren 
Speicher.
Bei der Massenproduktion mit Stückzahlen im 1000er -oder auch schon nur 
100er- Bereich pro Tag sind die 10ct Baustein auf den Monat oder gar das 
Jahr gerechnet aber richtig Asche!

Das die PIC10-16 Architektur für C einen Katastrophe sind würde ich 
jetzt nicht so sagen. Schwierig in der Umsetzung des Compilers - Ja auf 
jeden Fall! Aber wenn man sich nicht selbst eine Compiler schreiben will 
dann spielt das ja keine Rolle, den Kopf haben sich andere bereits lange 
vorher Erfolgreich zerbrochen ;-)
Davon abgesehen waren die ja lange vor den AVR schon da, als von C als 
Standart-Programmiersprache für µC noch keine Rede war, die µC Welt fast 
Ausschließlich nur ASM Sprach!

Dem Recht deines Beitrages könnte ich aber Bedenkenlos unterschreiben!

Gruß
Carsten

Carsten Sch. schrieb:

> Bausteine die auf dem Markt sind und solche gravierenden Fehler haben,
> die musst du aber wirklich suchen.

Schon mal den CAN Controller der PIC18Fxx8 bewundert? Klar, es gibt 
längst die PIC18Fxx8x, die den urigen Adressierungsfehler nicht haben. 
Dafür einen anderen Bug. Nur dass der Adressierungsfehler leichter 
umgehbar ist.

Überhaupt die CAN Controller. Mindestens die Hälfte aller integrierten 
CAN Controller von Microchip haben einen Bug drin, der bei Störungen auf 
dem Bus oder weglaufender Takterzeugung zu defekten aber nicht als 
solches erkennbaren Messages führen kann.

Trösten tut einen allenfalls, dass es anderen nicht besser ergeht. 
Philips/NXP hatte sich in der ersten Generation der LPC2000 auch nicht 
grad mit Ruhm bekleckert.

Carsten Sch. schrieb:

> Welche µCs können den im kostenlosen Compiler nicht genutzt werden...

Sie können durchaus genutzt werden. Aber nicht in dem Modus, der für 
C-Compiler eminent interessant ist. Die erste Architektur-Revision hatte 
noch auf die klassische statische Adressierung aller lokaler Daten 
abgezielt, erst im zweiten Anlauf schwenkte Microchip bei den Chips auf 
die umgänglichere Datenadressierung über einen Stack um (ich habe grad 
nicht in parat wie die das nennen).

Der kostenlose Modus des C18 unterstützt diese zweite Revision jedoch 
nicht, verwendet daher die alte Methode. Wahlweise statisch oder auch 
als Stack, letzteres dann aber eher ineffizent.

Übrigens war das Ziel meines Sermons oben gerade nicht, Architekturen, 
die für C Compiler weniger geeignet sind, zu verdammen. Sondern im 
Gegenteil, ich schrieb ja, dass sie trotzdem verwendet werden können und 
verwendet werden. Was ich schrieb war nur: Die zweite Revision der PIC18 
Architektur ist für C Compiler deutlich besser geeignet als die erste.

> Das die PIC10-16 Architektur für C einen Katastrophe sind würde ich
> jetzt nicht so sagen. Schwierig in der Umsetzung des Compilers - Ja auf
> jeden Fall!

Eben, genau das war gemeint. Ich bin da ein bischen vorbelastet, weil 
ich sowas schon gemacht habe. Sowohl was geeignete wie auch was 
ungeeignete Architekturen angeht. Zeig mit eine ISA (Instruction Set 
Architecture) und ich sage dir, wieviel Flüche derjenige ablässt, der 
den Compiler dafür stricken darf ;-).

Dass eine Architektur für C weniger geeignet ist, heisst nicht, dass man 
damit nicht in C arbeiten kann. Es heisst nur, dass der entstehende Code 
oft etwas krampfig aussieht. Das kann und wird vielen Anwendern egal 
sein. Wer da nicht öfter mal reinschaut, den interessiert das allenfalls 
beim evtl. etwas gedrosselten Tempo oder irgendwann beim Platz im ROM. 
Letzteres ist jedoch selten ein Thema, weil Microchip den vergleichbaren 
Teilen traditionell wohlweislich erheblich mehr ROM gönnt als 
beispielsweise Atmel oder TI.

Jens schrieb:

> Mir fällt auf die Schnelle keine Anwendung ein, für die ein PIC im
> Gegensatz zu 430, 8051, etc nicht geeignet ist. Bei den AVRs dürfte das
> ähnlich sein.

Versuch mal, Bendikts Text-Ansteuerung eines controllerlosen QVGA-LCDs 
mit einem 8-Bit PIC an Stelle eines Mega8 zu machen. ;-)

Carsten Sch. schrieb:

> Davon abgesehen waren die ja lange vor den AVR schon da, als von C als
> Standart-Programmiersprache für µC noch keine Rede war, die µC Welt fast
> Ausschließlich nur ASM Sprach!

Keine Frage. Es ist massgeblich das Verdienst von Microchip, den Markt 
von kleinen günstigen Controllern mit damals noch EPROM erkannt zu 
haben. Die waren davor in Form von 8751 oder Huckepack-Versionen 
prohibitiv teuer. Und die wurden meist in Assembler programmiert. Viele 
altgedienten PIC-Fans tun das noch heute - es gibt wenige Controller, 
bei denen sich das so hartnäckig hält.

Jens schrieb:

> Das kann schon sein, der junge Entwickler, der nach dem Studium sein
> erstes eigenes Projekt hat, nimmt dann vermutlich eher eine vertraute
> Architektur,

Aber nur wenn dieser junge Entwickler in einem eher kleinen Unternehmen 
steckt, in dem das Projekt massgeblich sein eigenes Kind ist. Ist er 
aber beispielsweise in einer Schublade eines grösseren Unternehmens mit 
Ziel Massenproduktion untergebracht, dann hält sich seine 
Entscheidungskompetenz über solche Fragen wohl in Grenzen.

Verglichen mit dem schon seit Tagen laufenden AC/DC-Krieg ist das hier 
doch harmlos, gesittet und sogar sachlich.

Und anderswo streitet man sich grad drum, ob man Leuten überhaupt frohe 
Weihnachten wünschen darf, ohne sich als Religionsfanatiker zu outen.

micro1 schrieb:

> Ich finde auch die Programmiertools von Atmel (AVR ISP mk2 oder JTAG ice
> MK2 oder AVR Dragon) besser, da diese den besseren Connector haben.
> Bei PIC z.B so ein komische 6 polige Telefonbuchse. Da muss man immer
> irgendwelche Adpater basteln.

Nö, musst Du nicht. Einfach AC164110 ordern, dann hast Du das passende.

http://www.microchipdirect.com/productsearch.aspx?Keywords=AC164110

Auch das PICkit3 benutzt den Pfostenstecker.

fchk

Warum geht es hier denn immer nur um AVR vs. PIC? Die MSP430 sind IMHO 
auch eine alternative, insb. weil es mit MSPGCC und mspdebug eine 
brauchbare Toolchain für Linux gibt. Damit, dass es die nur in SMD gibt, 
muss man sich abfinden.

Luk4s K. schrieb:
> Damit, dass es die nur in SMD gibt,
> muss man sich abfinden.

Nun ja, die MSP430 Value Line gibt's auch in DIP. Siehe LaunchPad.

zum adapter: ich hab da ein 10-poliges flachbandkabel an das 
telefonsteckerkabel gemacht, wobei jede 2. ader des flachbandkabels GND 
ist und vorne den stecker deiner wahl. wenn jede 2. ader GND ist, kann 
das kabel ohne weiteres 50cm lang sein, was ich sehr praktisch finde :-) 
...und btw: so ein adapter bastelst du dir genau ein mal ;-)

Intel Freak schrieb:
> Intel MCS-48 Familie is the best! ;-)

Genau!

endlich sagt das mal einer!

mfg.

Mir fehlt dann aber unbedingt noch der 3850 (F8). Der Mikrocontroller 
der ersten Jahre. Der 8048 war doch bloss ein Abklatsch davon.

Frank K. schrieb:
> Nummer 3 erzwingt AVR. Für den gibts einen freien GCC-Port, und der ist
> unter Linux und Windows identisch.
>
> Bei PIC ist das anders. Die 8-Bit PICs (also bis PIC18) haben ein sehr C
> unfreundliches Design. Vollständig ANSI-kompatible C-Compiler gibts von
> Microchip (MPLAB C18) und von Microchip (Hitech C, Microchip hat die
> Firma gekauft), und hier hast Du die Wahl zwischen Windows und Windows.
> Man kann damit auch gut arbeiten, aber nicht unter Linux.

Kleine Ergänzung: Auf 
http://ww1.microchip.com/downloads/MPLAB/X_Beta/installer.html Linux x86 
auswählen...

> Ab PIC24 basieren die C-Compiler von Microchip auch auf dem GCC.
> Microchip bietet die nur für Windows an. Technisch könntest Du den auf
> Linux portieren (und dabei den Lizenzmanager rauswerfen), aber die
> Lizenz der Bibliotheken (kein GNU) verbietet Dir das. (*)
>
> Das Debugging ist von Microchip meiner Meinung nach besser gelöst, die
> Tools billiger; und Du kannst z.B. MPLAB und ICD3 von PIC10 (6-Pinner)
> bis PIC32MX (80 MHz 32Bit MIPS-Kern) benutzen.
>
> Architekturmäßig sind PIC24 und AVR relativ ähnlich, mit dem
> Unterschied, dass PIC24 eben 16-bittig intern ist.

Wobei die PIC24/dsPICs wesentlich besser in Maschinensprache 
programmierbar sind...

A. K. schrieb:
> Mir fehlt dann aber unbedingt noch der 3850 (F8). Der Mikrocontroller
>
> der ersten Jahre. Der 8048 war doch bloss ein Abklatsch davon.

Aber ich arbeite nur mit modernen Systemen. Immer auf der Höhe der Zeit!

mfg.

@micro1: adern auftrennen, die richtigen miteinander verlöten, 
schrumpfschlauch und fertig - sieht sauber aus und ist kein gebastel: 
aufwand 15min und kosten 2.- (zumindest meiner sieht sauber aus und hat 
schon viele strapazen überlebt)
wenn entwickler nicht fähig sind einen robusten adapter zu entwickeln, 
sind die entwickler das grössere problem für die firma als der 
suboptimale adapter ;-) ..aber wir reden hier ja sowieso von 
privat-hobby-entwicklern.

Wilhelm Ferkes schrieb:
> Und da fangen heute manche mit einem ARM-Board an, je größer desto
>
> besser, besser ARM9 als ARM7, und wissen oft nicht mal, was ein
>
> CMOS-Prozess ist, oder gar ein Spannungsteiler aus 2 Widerständen. Genau
>
> da sträuben sich mir die Haare, aber extrem. Die Fragen ließt man ja
>
> hier in der Threadliste immer wieder.

Richtig!

Wer mal mit 8085 oder 8048 oder so angefangen hat, hat nicht nur rund 30 
Jahre Erfahrung auf dem Buckel, sondern die ganze Materie zumeist auch 
wirklich verstanden. Wenn dann ein neuer Controller ran muß, nimmt man 
sich das Datenblatt...

mfg.