Atmel oder PIC

[Manu (Gast)]

Hallo ich möchte mich mit Mikrocontrollern beschäftigen, da will ich 
mich zwischen Atmel und PIC entscheiden. Vielleicht gibts auch noch 
bessere Hersteller?

Was spricht denn für Atmel und was für PIC?

Was habe ich denn bei einem 8 Bit MCU für Einschränkungen gegenüber 
einem 16 oder 32 Bitter?

Kann man den hier auf der HP angebotenen GCC-Compiler für ALLE MCUs von 
Atmel nutzen?

[Lothar (Gast)]

Atmel hat auf der Homepage inzwischen nur noch Werbung für ihre 
ARM-Mikrocontroller, das ist doch eine Aussage :-) http://www.atmel.com

Aber im Ernst, es kommt drauf an: wenn es nur ein Hobby ist kann man 
schon AVR machen. In der Industrie gibt es aber 8-bit praktisch nur 8051 
und 32-bit praktisch nur ARM (Ausnahme TriCore und Renesas, aber lassen 
wir das).

Leider sind die Atmel ARM Eval-Boards etwas teuer, und da es keine Rolle 
spielt, kann man auch günstigere mit NXP oder STM nehmen, z.B.

minimal: http://www.watterott.com/de/LPC1343-QuickStart-Board oder 
http://elmicro.com/de/lpc1300-proto.html

maximal: http://elmicro.com/de/lpc1700-proto.html

[Michael L. (eagle87)]

> Was spricht denn für Atmel und was für PIC?
Hatte selbst mit PIC noch nichts zu tun, kann dir über die also wenig 
sagen. Aber für AVR's wirst hier vermutlich mehr Informationen finden.

> Was habe ich denn bei einem 8 Bit MCU für Einschränkungen gegenüber
> einem 16 oder 32 Bitter?
Ist beim Rechnen mit großen Zahlen langsamer.

> Kann man den hier auf der HP angebotenen GCC-Compiler für ALLE MCUs von
> Atmel nutzen?
Soweit ich weiß funktioniert der GCC nicht für alle. Dies betrifft aber 
eher alte Derivate (z.B. ATtiny11).

[Thomas (Gast)]

Andere Hersteller gibt es noch genug, im Prinzip ist es vollkommen egal 
welchen du nimmst,vor allem am Anfang muss man sich halt einarbeiten. 
Wenn du in C programmierst gibts nicht "soo" große Unterschiede, 
Strukturmäßig ist es immer das gleiche.
Für Pic's gibt es ein gutes und günstiges Programmiertool, das Pickit 2 
oder 3 
:http://at.farnell.com/microchip/pg164120/programmierer-pickit-2/dp/9847170

[Stefan (Gast)]

Sowohl AVR als auch PIC Controller sind fürs Hobby leicht zu beschaffen 
und in der Handhabung praktisch. Ich habe selbst noch keinen PIC 
eingesetzt, weil ich mich nach Zufallsprinzip für AVR entschieden habe 
und dabei geblieben bin, weil ich mit AVR zufrieden bin. Sicher wäre ich 
mit PIC genau so gut klar gekommen. Da ich einiges an Hardware speziell 
für AVR gekauft habe, werde ich auch erstmal dort bleiben.

Controller mit 8, 16, 32 Bit halte ich für gleichwertig. Denn auch 8 Bit 
Controller können 32 Bit berechnungen durchführen (nur langsamer).

Wo ein kleiner 8 Bit Mikrocontroller nicht ausreicht, würde ich zu ARM 
Controller wechseln. Die Module von Mbed scheinen den schnellsten 
Einstieg zu versprechen, während das STM32 Discovery wenig kostet.

Allerdings genügten mir bisher die "kleinen" 8 Bit AVR's. Nur einmal 
sollte es mehr sein, da hatte ich gleich ein Notebook verwendet.

[Anja (Gast)]

Thomas schrieb:
> Für Pic's gibt es ein gutes und günstiges Programmiertool

... das auch gleichzeitig ein Debugger für die neueren PICs ist.

Bei den AVRs hat man es beim debuggen wesentlich schwerer.

Gruß Anja

[Ulrich (Gast)]

Genutzt habe ich die PIC nicht - für die ASM Programmierung war mir die 
Architektur etwas unübersichtlich (PIC16 / PIC18). Für die 
Programmierung in C ist da aber eher wenig Unterschied. Im Gegensatz zu 
ARM und ähnlichen kann man die 8 Bit µCs wie PIC, AVR oder 8051 wenn es 
sein muss auch noch einfach auf dem Steckbrett oder Lochraster aufbauen.

[Stefan (Gast)]

Bei Reichelt ist der In-Circuit Debugger für PIC aber nicht billiger, 
als der für Atmel. Ich würde sagen, da steht's bei 1:1 Unentschieden.

Mit dem Dragon, der nocht alle AVR's unterstützt, kann man diese 200 
Euro Geräte natürlich nicht vergleichen. Der Dragon ist auch auf billig 
getrimmt und schon einige Jahre alt.

[Frank M. (frank_m35)]

Ich habe noch nie einen AVR in der Hand gehabt, da ich alles mit PIC 
machen.
Also wie du siehst, geschmackssache.

Schön bei PICs finde ich die große Bibliotheken und Beispiel-Projekte 
von Microchip, die freie und auf PICs abgestimmte IDE Mplab mit einem 
freiem Compiler und damit die gute Debuggbarkeit mittels Pic Kit 3, 
sowie die zahlreichen Starter-Kits von Microchip.
Wie das alles bei Atmel ausschaut weiß ich nicht, daher ist das eine 
Einseitige beschreibung meinerseits ^^

Im 8-Bit Bereich sind die PICs allgemein sehr stark vertreten. Die 
Einschränkugen sind eben Variablengröße, Speicher, Geschwindigkeit, 
Funktionen. Hier sind die PIC18 die beste Wahl. (also nicht mit den 
alten PIC16 anfangen)

Dann gibt es noch die 16-Bit, PIC24/dsPIC/..., die umfangreicher, und 
dank breiterem Bus flexibler, großspuriger programmierbar sind. (man 
muss sich weniger Gedanken um den internen Aufbau machen, man kann 
verschwenderischer arbeiten)

Und dann gibt es noch die 32-Bit, PIC32, die komplett anders als die 
PIC18/PIC24 sind, da sie auf der MIPS Architentur aufbauen (Konkurrenz 
zu ARM, verwendet von Atmel in 32Bit Prozessoren, Freescale, ...) Sie 
sind eben deutlich leistungsfähiger, aber auch größer, teuerer, 
Stromfressender. Wobei hier Microchip erst seit ein paar Jahren 
mitspielt, und stark am Aufholen arbeitet.

Dann kommt es auf deinen Einsatz an. Für den Hobby reichen 8-Bit, willst 
du mehr Power dann eben 16-Bit, willst du TFT Displays ansteuern mit 
einer Grafischen Oberfläche etc. 32-Bit.
Willst du top Stromsparen wirst du auf 16-Bit und 8-Bit beschränkt sein.
Willst du mini-ICs mit nur 6 Pins oder so gibt's ebenfalls keine 32-Bit.

[Frank M. (frank_m35)]

Stefan schrieb:
> Bei Reichelt ist der In-Circuit Debugger für PIC aber nicht billiger,
> als der für Atmel. Ich würde sagen, da steht's bei 1:1 Unentschieden.

Es reicht das deutlich günstiger Pic Kit 3, das auch Debuggen kann:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2519&param=en534451

[scherzkeks (Gast)]

Das ist Banane, such Dir den Controller aus der das kann was Du brauchst 
und werd' glücklich damit.
Alle 8bit AVRs kommen mit internem Taktgenerator das gibt's nicht bei 
allen PICs, wenn Du schnell zu einem ergebnis kommen willst sieh Dir die 
entsprechenden Arduinos oder PIC-Kits an, die haben schon vorgefertigte 
Bibiotheken und Du mußt nicht lernen wie Du nun die PWM richtig 
initialisierst und ausgibst.
Noch einen Unterschied gibt's in der Architektur, AVRs sind Havard haben 
also getrennte Code- und Datenspeicher während beim PIC alles auf einer 
"Halde" landet (such hier nach progmem).

[Manu (Gast)]

Danke für die informativen Auskünfte. Mein Anwendungsbereich ist der 
Hobbybereich. Wenn es im Prinzip egal ist ob ich Atmel oder Microchip 
verwende, wie sieht es denn dann mit den C-Compilern aus?

Da gibts meines Wissens nach schon Unterschiede, Bei Microchip gibts die 
Lite Compiler die auf 2000 Worte begrenzt sind, kann man damit was 
anfangen? 2000 Worte klingt nach mittelgroßen Programmen. Bei Atmel 
gibts ja den kostenlosen GCC Compiler wie erwähnt.

Wenn der Lite Compiler für den Hobbybereich ausreichend ist, würde ich 
mich für Microchip entscheiden (einfach weil es etwas professioneller 
anmutet).

[Mik (Gast)]

scherzkeks schrieb:
> AVRs sind Havard haben
> also getrennte Code- und Datenspeicher während beim PIC alles auf einer
> "Halde" landet (such hier nach progmem).

nennt sich dann "von Neumann".

Es gibt auch noch den MSP430 mit dem Launchpad als Entwicklungsumgebung.
http://www.ti.com/ww/en/launchpad/msp430_head.html ist auch recht 
günstig.

Glücklich werden kannst du im Prinzip mit allen,, hängt davon ab was du 
machen willst.

[Manu (Gast)]

Danke für die informativen Auskünfte. Mein Anwendungsbereich ist der
Hobbybereich. Wenn es im Prinzip egal ist ob ich Atmel oder Microchip
verwende, wie sieht es denn dann mit den C-Compilern aus?

Da gibts meines Wissens nach schon Unterschiede, Bei Microchip gibts die
Lite Compiler die auf 2000 Worte begrenzt sind, kann man damit was
anfangen? 2000 Worte klingt nach mittelgroßen Programmen. Bei Atmel
gibts ja den kostenlosen GCC Compiler wie erwähnt.

Wenn der Lite Compiler für den Hobbybereich ausreichend ist, würde ich
mich für Microchip entscheiden (einfach weil es etwas professioneller
anmutet).

[Mik (Gast)]

Manu schrieb:
> Bei Microchip gibts die
> Lite Compiler die auf 2000 Worte begrenzt sind, kann man damit was
> anfangen? 2000 Worte klingt nach mittelgroßen Programmen.

Ich würde mit keinem Anfangen der in Codegröße beschränkt, es sei denn 
wenn ich auch bereit bin den ohne Einschränkung zu kaufen, man hat 
schnell mal etwas was groß wird, gut wenn man sich dann nur nen größeren 
uC kaufen muß. Ich arbeite am liebsten mit den AVR. Die Einstiegstkosten 
sind sehr gering, eigentlich braucht man nur einen ISP programmer für 
3€. Bei dem TI reicht das Launchpad.

[Eumel (Gast)]

Manu schrieb:
> Danke für die informativen Auskünfte. Mein Anwendungsbereich ist der
> Hobbybereich. Wenn es im Prinzip egal ist ob ich Atmel oder Microchip
> verwende, wie sieht es denn dann mit den C-Compilern aus?
>
> Da gibts meines Wissens nach schon Unterschiede, Bei Microchip gibts die
> Lite Compiler die auf 2000 Worte begrenzt sind, kann man damit was
> anfangen? 2000 Worte klingt nach mittelgroßen Programmen. Bei Atmel
> gibts ja den kostenlosen GCC Compiler wie erwähnt.
>
> Wenn der Lite Compiler für den Hobbybereich ausreichend ist, würde ich
> mich für Microchip entscheiden (einfach weil es etwas professioneller
> anmutet).

Nimm einen MSP430 und werde glücklich.

[Dominic A. (neo123)]

Manu schrieb:
> Da gibts meines Wissens nach schon Unterschiede, Bei Microchip gibts die
> Lite Compiler die auf 2000 Worte begrenzt sind, kann man damit was
> anfangen? 2000 Worte klingt nach mittelgroßen Programmen. Bei Atmel
> gibts ja den kostenlosen GCC Compiler wie erwähnt.

Bei Microchip gibts den XC8/16/32. Dies sind auch alles Free Compiler 
ohne Codebeschränkung.
http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/

[Robert V. (Gast)]

Manu schrieb:
> Wenn der Lite Compiler für den Hobbybereich ausreichend ist, würde ich
> mich für Microchip entscheiden (einfach weil es etwas professioneller
> anmutet).

Die XC Compiler von Microchip gibt es in einer Free-Variante ohne 
Größenbeschränkung. Lediglich die Optimierung ist ausgeschaltet. Das ist 
für den Hobbybereich folgenlos, da man einfach einen Controller mit mehr 
Flash kauft (manchmal nur 30..50 Cent teurer), falls man an die Grenzen 
des Speichers stoßen sollte.

http://www.microchip.com/pagehandler/en-us/devtools/mplabxc/home.html

Was auch schön ist: die IDE mit Debugger (MPLAB-X) gibt es für Windows, 
Mac und Linux. Das AVR-Studio gibt es dagegen nur für Windows.

[Anja (Gast)]

Manu schrieb:
> Lite Compiler die auf 2000 Worte begrenzt sind,

Ich kenne keine Code-Beschränkung bei den Microchip-Compilern. Wo hast 
Du denn die Info her?
Ich kenne es so daß lediglich die Code-Optimierung nach der 
Evaluierungszeit abgeschaltet wird.

Gruß Anja

[Thomas (Gast)]

also entweder den 
http://www.microchip.com/pagehandler/en-us/devtools/mplabxc/home.html
oder Hi-Tech C lite, die sind alle nicht codebeschränkt soweit ich weiß, 
es fehlt nur die Codeoptimierung.
Microchip hat übrigends auch ein ziemlich gutes Tool um für die 
jeweilige Anforderung den richtigen Pic zu finden, nennt sich MAPS. Da 
kannst einfach eintragen was der Pic können muss und kriegst dann eine 
Liste welche das können.

http://www.microchip.com/maps/microcontroller.aspx

[Peter D. (peda)]

Das AVRStudio bzw. der AVR-GCC sind uneingeschränkt und gut brauchbar. 
Selbst die kleinen 8Pin-AVR haben reichlich Flash (8kB), da kommt man 
bequem mit aus. Float rechnen ist überhaupt kein Problem (einmalig 1kB).

Die 8Bit-AVRs habe die gleiche Architektur. Bei den PIC sind da 
erhebliche Unterschiede zwischen PIC12, 14, 16, 18.

Die AVR sind linear adressiert, die PIC unterteilen alles in kleine 
Häppchen (Code, IO, SRAM), daher muß der Compiler viele zusätzliche 
Umschaltbefehle einfügen.
Die moderneren PIC18 haben zusätzliche Befehle als IO-Zugriffe getarnt. 
D.h. ein IO-Zugriff macht in Wirklichkeit einen Indexzugriff, damit man 
Arrays zugreifen kann. Sowas ist im Assemblerlisting natürlich schwer 
lesbar, wenn man diese magischen IO-Adressen nicht kennt.

Die PIC haben eine größere Auswahl an CAN und USB als die AVR und auch 
im DIP.

[egal² (Gast)]

scherzkeks schrieb:
> Noch einen Unterschied gibt's in der Architektur, AVRs sind Havard haben
> also getrennte Code- und Datenspeicher während beim PIC alles auf einer
> "Halde" landet (such hier nach progmem).

Du Scherzkeks! Wenn wir bei den 8-Bittern bleiben, so ist PIC genauso 
"Harvard" (getrennte Code- und Datenspeicher) und nicht "v.u.z. 
Neumann".

[egal² (Gast)]

Peter Dannegger schrieb:
> Die moderneren PIC18 haben zusätzliche Befehle als IO-Zugriffe getarnt.
> D.h. ein IO-Zugriff macht in Wirklichkeit einen Indexzugriff, damit man
> Arrays zugreifen kann. Sowas ist im Assemblerlisting natürlich schwer
> lesbar, wenn man diese magischen IO-Adressen nicht kennt.

Das ist nicht uninteressant. Kannst Du hierfür mal ein Bespiel zeigen, 
anhand eines Befehls und woran man das erkennt?

[Manu (Gast)]

@ Dominic: Interessant. Muss ich hierfür dann die MPLAB X IDE nutzen 
oder geht das auch mit dem normalen MPLAB?

@ Thomas: Der Link von dir verweist auf dieselbe Seite wie auch von 
Dominic, d.h. die Lite Compiler sind die "XC" Compiler?

@ Anja: In der Beschreibung des PICkit 3 steht, dass ein kostenloser 
Compiler enthalten ist.
Exakt steht es so: "CCS-Compiler für PIC18F45k20 (2 K 
Word-Programm-Limit)"

[Cyblord -. (cyblord)]

Gerade der kostenlose und IMO sehr gute avr-gcc Compiler ist für mich 
DAS Killerargument für AVRs. Bisher konnte mich kein PIC davon 
überzeugen dass er so gut ist, damit ich mich mit teuren oder 
eingeschränkten Compilern rumärgere.
Für >8 Bit nimmt man ARM und hat wieder einen freien kostenlosen 
Compiler.

gruß cyblord

[Anja (Gast)]

Manu schrieb:
> Exakt steht es so: "CCS-Compiler für PIC18F45k20 (2 K
> Word-Programm-Limit)"

Die kostenlose Werbung mußt Du ja nicht installieren.
Da ist aber auch der Hitech Compiler auf der CD
und der MPLAB C18 + MPLAB C30.

Gruß Anja

[Robert V. (Gast)]

Manu schrieb:

> @ Thomas: Der Link von dir verweist auf dieselbe Seite wie auch von
> Dominic, d.h. die Lite Compiler sind die "XC" Compiler?

Microchip hat vor einigen Jahren Hi-Tech aufgekauft und deren Compiler 
weiterentwickelt. Das sind die heutigen XC compiler.

> @ Anja: In der Beschreibung des PICkit 3 steht, dass ein kostenloser
> Compiler enthalten ist.
> Exakt steht es so: "CCS-Compiler für PIC18F45k20 (2 K
> Word-Programm-Limit)"

Die Beschreibung auf der Conrad-Seite ist schon ein paar Jahre alt und 
veraltet (nur das alte MPLAB wird erwähnt). Der CCS-Compiler tut es auch 
für kleine Programme, aber wie gesagt, die XC-Compiler kannst du dir 
frei herunterladen und du hast keine Codegrößenbeschränkung.

[Chris B. (dekatz)]

egal² schrieb:
> Peter Dannegger schrieb:
>> Die moderneren PIC18 haben zusätzliche Befehle als IO-Zugriffe getarnt.
>> D.h. ein IO-Zugriff macht in Wirklichkeit einen Indexzugriff, damit man
>> Arrays zugreifen kann. Sowas ist im Assemblerlisting natürlich schwer
>> lesbar, wenn man diese magischen IO-Adressen nicht kennt.
>
> Das ist nicht uninteressant. Kannst Du hierfür mal ein Bespiel zeigen,
> anhand eines Befehls und woran man das erkennt?

Magische IO-Adressen???

Es handelt sich un die "Table read" und "Table write" Befehle mit post 
increment  bzw. pre increment (und decrement) um vom Programmspeicher zu 
lesen und schreiben z.B:
TBLRD*
TBLRD*+
TBLRD*-
TBLRD+*
TBLWT*
TBLWT*+
TBLWT*-
TBLWT+*

Und dann gibt es noch eine Befehlserweiterung zur "Indexed Literal 
Offset Addressing" in ´Zusammenhang mit den RAM Zugriffen via FSR/INDF 
(FSR/INDF Adressierung kennen aber bereits die Steinzeit-PIC).
FSR ist der Pointer in das RAM und mit INDF werden die Befehle ans 
Stelle fixer RAM-Adressen durchgeführt.

Steht aber eh alles in den Datenblätter....

[Klaus (Gast)]

Manu schrieb:
> @ Dominic: Interessant. Muss ich hierfür dann die MPLAB X IDE nutzen
> oder geht das auch mit dem normalen MPLAB?

Um die Verwirrung auf die Spitze zu treiben:

die aktuelle Version vom Microchip MPLAB ist MPLABX V1.60, die aktuelle 
Version des ehemaligen Hi-Tech Compilers für 8-Bit PICs heißt jetzt XC8 
V1.12 und die aktuelle Version des 16 Bit Compilers (ehemals C30) heißt 
jetzt XC16 V1.11 und ist immernoch der GCC. In der freien Version gibt 
es keine Codebeschränkung, nur die Optimierung ist beschränkt.

Der CCS Compiler ist nicht von Microchip, sondern von der Fa. CCS.

MfG Klaus

[Chris B. (dekatz)]

Klaus schrieb:
> Manu schrieb:
>
> die aktuelle Version vom Microchip MPLAB ist MPLABX V1.60,> MfG Klaus

Klein Verwirrung ;-)

Die aktuelle Version von MPLAB ist 8.90
Die aktuelle Version von MPLABX ist 1.70

Und nachdem auch in Version 1.70 von MPLABX noch so einiges nicht so 
läuft wie es soll,bevorzuge ioch derzeit noch MPLAB 8.90.

Allerdings ist für Juni die letzte Version von MPLAB (8.92) angekündigt. 
Ab dem Zeitpunkt werden neue Controller nur mehr von MPLABX unterstützt.

[Manu (Gast)]

Robert V. schrieb:
> Microchip hat vor einigen Jahren Hi-Tech aufgekauft und deren Compiler
> weiterentwickelt. Das sind die heutigen XC compiler.
>
>> @ Anja: In der Beschreibung des PICkit 3 steht, dass ein kostenloser
>> Compiler enthalten ist.
>> Exakt steht es so: "CCS-Compiler für PIC18F45k20 (2 K
>> Word-Programm-Limit)"
>
> Die Beschreibung auf der Conrad-Seite ist schon ein paar Jahre alt und
> veraltet (nur das alte MPLAB wird erwähnt). Der CCS-Compiler tut es auch
> für kleine Programme, aber wie gesagt, die XC-Compiler kannst du dir
> frei herunterladen und du hast keine Codegrößenbeschränkung.



Ok ich glaube jetzt habe ich den Überblick:

- MPLAB IDE + Hi-Tech C-Compiler == veraltet

- MPLAB X IDE + XC-Compiler (XC8, XC16 XC32) == aktuell

[Klaus (Gast)]

Chris B. schrieb:
> Die aktuelle Version von MPLAB ist 8.90
> Die aktuelle Version von MPLABX ist 1.70

Da hab ich wohl ein Update verpennt. Aber wie du selber sagst, für MPLAB 
gibts höchsten noch ein Bugfix, aber nichts neues mehr. Ich selbst komme 
aber mit MPLABX, was ja eigentlich Netbeans ist, gut klar. MPLAB würde 
auf meinem Ubuntu wohl auch nicht laufen.

MfG Klaus

[Chris B. (dekatz)]

Klaus schrieb:
> Chris B. schrieb:
>> Die aktuelle Version von MPLAB ist 8.90
>> Die aktuelle Version von MPLABX ist 1.70
>
> Da hab ich wohl ein Update verpennt. Aber wie du selber sagst, für MPLAB
> gibts höchsten noch ein Bugfix, aber nichts neues mehr. Ich selbst komme
> aber mit MPLABX, was ja eigentlich Netbeans ist, gut klar. MPLAB würde
> auf meinem Ubuntu wohl auch nicht laufen.
>
> MfG Klaus

Ja unter Ubuntu etc. läuft nur MPLABX.
MPLABX 1.70 ist ja eh nicht schlecht - wenn man sieht was sich so ab 
1.30 getan hat und es ist ja noch Zeit einige Kanten zu glätten.

[(prx) A. K. (prx)]

Manu schrieb:
> 2000 Worte klingt nach mittelgroßen Programmen.

In C eher nach kleinen.

[Manu (Gast)]

Robert V. schrieb:
> Die Beschreibung auf der Conrad-Seite ist schon ein paar Jahre alt und
> veraltet (nur das alte MPLAB wird erwähnt). Der CCS-Compiler tut es auch
> für kleine Programme, aber wie gesagt, die XC-Compiler kannst du dir
> frei herunterladen und du hast keine Codegrößenbeschränkung.

http://www.conrad.de/ce/de/product/160402/PICkit-3-Debug-Express-DebuggerProgrammer-DV164131-Microchip-DV164131-Ausfuehrung-PICkit-3-Debug-Express-DebuggerProg

Das würde also bedeuten, ich bekomme bei Conrad eine veraltete CD und 
auch ein älteres Modell des PICkit 3? (Es gibt ja diese transparenten 
und die die matt sind). Von der Softwareseite gesehen ist es ja 
eigentlich egal, da man ja eh alles auf der Microchipseite downloaden 
kann, Hardwaremäßig hoffe ich mal, dass es zwischen dem älteren und 
neueren PICkit keine gravierenden Unterschiede gibt.

[ET Student (Gast)]

Noch ein paar Überlegungen:
- MSP430 in DIL-Packages gibt es nur mit sehr kleinem RAM/Flash  und die 
Controller unterstützen nur <= 3.3V  Betriebsspannung, ausserdem haben 
die DIL-Package Varianten auch kaum Peripherie an Bord (das gilt nicht 
für die SMD-Package Varianten welche besser ausgestattet sind)
- PIC und AVR gibt es mit reichlich RAM/Flash in DIL-Packages 
(ATMEGA1284 mit 128K Flash und z.b. PIC18F27J13 ebenfalls mit 128K 
Flash) und die Controller unterstützen weite Betriebsspannungs-Bereiche, 
zumeist von 1.8V-5.5V wobei es auch einige PICs gibt, die nur bis 3.3V 
gehen.
- PICs haben Hardware-USB Unterstützung in DIL-Packages, z.b. 18F2550

Wenn du dich für PIC entscheidest, so beginne gleich mit der modernen 
18er-Serie. Nur in Ausnahmefällen, z.b. wenn es unbedingt ein kleiner 
8-beinige Chip sein muss, solltest du zur 16er Serie greifen.

[Vn N. (wefwef_s)]

Das ewig gleiche Thema.

Lothar schrieb:
> Aber im Ernst, es kommt drauf an: wenn es nur ein Hobby ist kann man
> schon AVR machen. In der Industrie gibt es aber 8-bit praktisch nur 8051
> und 32-bit praktisch nur ARM (Ausnahme TriCore und Renesas, aber lassen
> wir das).

Klar, mit Bastlerstückzahlen lässt sich ja auch Entwicklung und 
Fertigung von Chips finanzieren. Eigenartig, dass Atmel, Microchip und 
TI nicht pleite gehen.

Ansonsten ist bereits alles gesagt: AVR bietet eine uneingeschränkte 
Entwicklungsumgebung, dafür ist die Hardware etwas teurer, MSP430 bietet 
billige Hardware für den Einstieg, dafür sieht es bzgl. IDE etwas 
schlechter aus (entweder eingeschränkte IDE oder Bastellösung mit gcc 
und Eclipse, was unter Umständen Probleme bereiten kann), PIC keine 
Ahnung, soll angeblich bei den Hardwarekosten etwas günstiger sein.

[Robert V. (Gast)]

Manu schrieb:
> Das würde also bedeuten, ich bekomme bei Conrad eine veraltete CD und
> auch ein älteres Modell des PICkit 3?

Ich denke dass nur die Artikelbeschreibung alt ist. Conrad legt sich 
sicherlich nicht 1000e auf Lager sondern fordert die Teile je nach 
Bedarf vom Distributor ab. Mir ist auch nicht bekannt, dass Microchip 
verschiedene HW-Versionen des PicKit 3 hat. Es gibt natürlich auch noch 
diverse preiswertere China-Klons davon.

[Manu (Gast)]

Ok, ich denke ich habe jetzt alle Infos die ich benötige.

Ich möchte mich für eure Beiträge bedanken, mir wurde in diesem Thread 
wirklich super geholfen :-) Danke auch für die Nennung der Alternativen 
zu Atmel und Microchip, auch wenn es für mich bei Microchip bleibt.

[Anja (Gast)]

Manu schrieb:
> auch wenn es für mich bei Microchip bleibt.

Du solltest wenn Du "C" verwenden willst nicht einen der Uralt-PICs 
verwenden:
Im 28-Pin Gehäuse würde ich z.B. den PIC18F2520 nehmen wenn USB und CAN 
kein Thema sind und du auch 5V Versorgung verwenden willst. Als 
40-Pinner ist es dann der PIC18F4520. Die entsprechenden 3.3V Derrivate 
heißen PIC18F25K20 oder PIC18F45K20. (Der ist beim "PICKIT3 Debug 
Express" mit dabei).

Bei 3.3V würde ich jedoch einen PIC24 (16 Bit) bevorzugen z.B. 
PIC24FJ64GA004.
Wobei es allerdings neuerdings auch 5V-Typen gibt: PIC24FV32KA304.

Gruß Anja

[Wilhelm F. (Gast)]

Manu schrieb:

> auch wenn es für mich bei Microchip bleibt.

Ist doch fast egal, was man hat, wenn man schon einmal z.B. in 8-Bitter 
irgendwo eingearbeitet ist. Dann bleibt man dabei.

Wenn ich nicht schon ewig mit dem unsterblichen immer weiter lebenden 
8051 geprägt wäre, es gibt ja auch dort schöne hochperformante Derivate 
mittlerweile, vielleicht dann auch PIC, wer weiß? Wenn ich den 8051 
nicht gekannt hätte, wäre ich vermutlich beim PIC gelandet.

[Anja (Gast)]

cyblord ---- schrieb:
> Gerade der kostenlose und IMO sehr gute avr-gcc Compiler ist für mich
> DAS Killerargument für AVRs.

Ich würde das nicht am Compiler festmachen: Sowohl mit PIC als auch AVR 
kann man mit den Compilern gut arbeiten.

Unter "sehr gut" verstehe ich allerdings was anderes aber: das kann man 
wohl von einem kostenlosen Tool nicht erwarten.

Beispielsweise versucht der GNU-C compiler krampfhaft viele uint8 
Berechnungen als sint16 zu rechnen ohne daß dies notwendig ist.
Außerdem wird immer wieder das "Zero-Register" auf null gesetzt.
Besonders schmerzlich ist dies bei Interruptroutinen da dann natürlich 
noch mehr Register als sonst nötig in die Kontextsicherung einbezogen 
werden müssen.

/*
**************************************************
* interrupt-routine of CCP2 (atomic)
* 
* - input time synchronous adc-values
**************************************************
*/
SIGNAL(SIG_OUTPUT_COMPARE2)
{
    /* Interrupt flag is cleared automatically by call           */
    /* routine is called all 250 us                              */
    /* all 4 input channels are sampled within 1 ms              */
    /* all 10 ms (40 interrupts) the 10 ms event is triggered    */

    TP25_ON; /* toggle pin for measurement */

    /* store ADC-Value to FIFO and increment InPoi */
    (*InPoi++) = ADCW;
    if (InPoi >= &ADC_RawVal[NUM_FIFO])
    {
        InPoi = &ADC_RawVal[0];
    }

    /* increment Timer, Trigger 10 ms event on overflow */
    if (TimerIL >= (NUM_ADC_INT - 1))
    {
        TimerIL = 0;
        TimerIH ++ ;  /* trigger 10 ms event */
    }
    else 
    {
        TimerIL ++;
    }

    if ((TimerIL & TMR_MS_MASK) == 0)
    {
        TimerIMS++; /* trigger 2 ms event */
    }

    /* start next conversion LSBs of TimerL select Chanel */
    ADMUX = ADMUX_INIT + (TimerIL & 0x03);
    BIT_SET(ADCSRA, ADSC);

    TP25_OFF; /* toggle pin for measurement */
}

und das was der GNU-C Compiler daraus macht:

163                 /* epilogue end (size=9) */
 164                 /* function __vector_6 size 46 (28) */
 165                 .LFE10:
 167                 .global  __vector_4
 169                 __vector_4:
 170                 .LFB11:
 171                 .LM16:
 172                 /* prologue: frame size=0 */
 173 00bc 1F92          push __zero_reg__     <- wird nur 1* gebraucht
 174 00be 0F92          push __tmp_reg__
 175 00c0 0FB6          in __tmp_reg__,__SREG__
 176 00c2 0F92          push __tmp_reg__
 177 00c4 1124          clr __zero_reg__      <- wird nur 1* gebraucht
 178 00c6 2F93          push r18
 179 00c8 8F93          push r24
 180 00ca 9F93          push r25
 181 00cc EF93          push r30
 182 00ce FF93          push r31
 183                 /* prologue end (size=10) */
 184                 .LM17:
 185 00d0 979A          sbi 50-0x20,7
 186                 .LM18:
 187 00d2 E091 0000     lds r30,InPoi
 188 00d6 F091 0000     lds r31,(InPoi)+1
 189 00da 84B1          in r24,36-0x20
 190 00dc 95B1          in r25,(36)+1-0x20
 191 00de 8193          st Z+,r24
 192 00e0 9193          st Z+,r25
 193 00e2 F093 0000     sts (InPoi)+1,r31
 194 00e6 E093 0000     sts InPoi,r30
 195                 .LM19:
 196 00ea E050          subi r30,lo8(_A+128)
 197 00ec F040          sbci r31,hi8(_A+128)
 198 00ee 30F0          brlo .L7
 199                 .LM20:
 200 00f0 80E0          ldi r24,lo8(_A)
 201 00f2 90E0          ldi r25,hi8(_A)
 202 00f4 9093 0000     sts (InPoi)+1,r25
 203 00f8 8093 0000     sts InPoi,r24
 204                 .L7:
 205                 .LM21:
 206 00fc 8091 0000     lds r24,TimerIL
 207 0100 8732          cpi r24,lo8(39)
 208 0102 40F0          brlo .L8
 209                 .LM22:
 210 0104 1092 0000     sts TimerIL,__zero_reg__    <- R24 wäre "frei"
 211                 .LM23:
 212 0108 8091 0000     lds r24,TimerIH
 213 010c 8F5F          subi r24,lo8(-(1))
 214 010e 8093 0000     sts TimerIH,r24
 215 0112 03C0          rjmp .L9
 216                 .L8:
 217                 .LM24:
 218 0114 8F5F          subi r24,lo8(-(1))
 219 0116 8093 0000     sts TimerIL,r24
 220                 .L9:
 221                 .LM25:
 222 011a 2091 0000     lds r18,TimerIL
 223 011e 822F          mov r24,r18
 224 0120 9927          clr r25           <-unnötige Erweiterung auf sint16
 225 0122 8770          andi r24,lo8(7)
 226 0124 9070          andi r25,hi8(7)   <-unnötiger sint 16 High(7) = 0
 227 0126 892B          or r24,r25        <-unnötiges or wegen sint16
 228 0128 29F4          brne .L10
 229                 .LM26:
 230 012a 8091 0000     lds r24,TimerIMS
 231 012e 8F5F          subi r24,lo8(-(1))
 232 0130 8093 0000     sts TimerIMS,r24
 233                 .L10:
 234                 .LM27:
 235 0134 2370          andi r18,lo8(3)
 236 0136 2C5F          subi r18,lo8(-(4))
 237 0138 27B9          out 39-0x20,r18
 238                 .LM28:
 239 013a 369A          sbi 38-0x20,6
 240                 .LM29:
 241 013c 9798          cbi 50-0x20,7
 242                 /* epilogue: frame size=0 */
 243 013e FF91          pop r31
 244 0140 EF91          pop r30
 245 0142 9F91          pop r25
 246 0144 8F91          pop r24
 247 0146 2F91          pop r18
 248 0148 0F90          pop __tmp_reg__
 249 014a 0FBE          out __SREG__,__tmp_reg__
 250 014c 0F90          pop __tmp_reg__
 251 014e 1F90          pop __zero_reg__       <- wird nur 1* gebraucht
 252 0150 1895          reti
 253                 /* epilogue end (size=10) */

Gruß Anja

[(prx) A. K. (prx)]

Wenn man unbedingt leidlich schönen Assemblercode aus dem C Compiler 
bekommen will, dann sollte man die 8-Bit Klasse komplett meiden. Ob das 
aber wirklich ein Kriterium ist, das muss jeder selbst entscheiden.

[M. N. (Gast)]

Anja schrieb:
> Besonders schmerzlich ist dies bei Interruptroutinen da dann natürlich
> noch mehr Register als sonst nötig in die Kontextsicherung einbezogen
> werden müssen.

Besorg Dir mal die Kickstart Version von IAR. Die ist zwar auf 4k 
begrenzt, optimiert sehr gut und man kann Register 'reservieren', dass 
sie nicht vom Compiler benötigt und nur in eigenen Interrupt-Routinen 
verwendet werden: kein push-pop.

Trotz 4k Limit kann man sogar 'double'-Berechnungen mit 64 Bit darin 
unterbringen. Ich hatte mal ein Beispiel dazu 
Beitrag "reziproker Frequenzzähler, GPS-stabilisiert, ATmega162"

[Wilhelm F. (Gast)]

Anja schrieb:

> das kann man
> wohl von einem kostenlosen Tool nicht erwarten.

SDCC für den 8051 ist aber schon völlig problemlos. Es hat allerdings 
keine Spezialfunktionen wie die MDU vom 80C517 drin, das muß man selber 
machen, und es ist nicht einfach, nicht mal eben beim Frühstückskaffee 
nebenbei angepaßt. In Floating-Point-Arithmetik eingebunden würde die 
MDU um den Faktor 100 schneller rechnen, als der Standard-8051. Auch die 
Multiple Datapointer, womit man Funktionen wie memcpy() arg 
beschleunigen kann. Keil hat die volle Funktionalität des 80C517, ist 
aber wiederum teuer.

Aber es ist im Grunde wahr: Was nichts kostet, da erwarte ich nur 
Grundfunktionalität.

[someone (Gast)]

Meine kurze Meinung: Fang mit einem AVR-Setup an. Wenn du alles 
ausprobiert hast und es dir Spaß macht, kauf dir die Sachen für PICs 
noch zusätzlich dazu.

Warum? AVRs sind gut erhältlich, es gibt gerade für den Hobbybereich 
viele Code-Beispiele (die oft ziemlich furchtbar sind, aber was soll's 
...). Viel wichtiger finde ich aber den sehr preisgünstigen Einstieg. 
Ein einfacher usbasp- oder usbtiny-Klon kostet unter 10 Euro und kann 
flashen. Debuggen leider nicht. Die Entwicklungswerkzeuge sind komplett 
kostenlos, der Compiler (avr-gcc) ist sogar freie Software und sehr gut. 
Für unter 30 Euro kannst du dir also alles kaufen, was du zum 
Ausprobieren der Microcontroller-Programmierung mit einem AVR benötigst.

Wenn es dir dann Spaß macht, kannst du überlegen, ob du dir nicht auch 
noch ein Pickit kaufst. PICs sind hierzulande leider nicht ganz so gut 
erhältlich (was aber auch kein Wunder ist, da es viel mehr Modelle 
gibt), aber haben oftmals sehr interessante Peripherie. Auch Dinge wie 
einen "kleinen" PIC mit vielen Pins gibt es, was bei AVRs leider nicht 
der Fall ist. Mit PICs anfangen kannst du ebenfalls, kostet aber viel 
mehr als die beiden anderen Optionen.

Ein MSP430 Launchpad kannst du dir natürlich auch anschauen. Das ist (da 
subventioniert) sehr kostengünstig, kann debuggen usw. Problematisch ist 
die unendlich schlechte Verfügbarkeit der Prozessoren bei bekannten 
deutschen Händlern. Zum Einstieg in die Thematik 
Microcontroller-Programmierung halte ich die Launchpads allerdings für 
recht gut geeignet, da alles verfügbar ist, insbesondere ein Debugger 
mit guter IDE-Integration. Um Grundkonzepte zu lernen, ist das ziemlich 
gut, auch die Datenblätter sind schön geschrieben (und sehr lang!). Wenn 
du aber mehr machen willst, musst du wahrscheinlich aufgrund der 
schlechten Prozessorverfügbarkeit einen anderen Controller einsetzen. 
Zum Rumspielen, Entdecken und Ausprobieren ist das Launchpad aber sehr 
gut geeignet.

[Robert V. (Gast)]

someone schrieb:
> PICs sind hierzulande leider nicht ganz so gut
> erhältlich (was aber auch kein Wunder ist ...

Wo lebst Du? Alleine Reichelt hat derzeit 667 verschiedene PICs im 
Angebot und fast alle sind ab Lager verfügbar.

[W.S. (Gast)]

Was wollt ihr eigentlich? Euch in C ergehen und über den besten 
C-Compiler streiten oder euch mit uC befassen? Der Ausgangspunkt war 
doch wohl:

Manu schrieb:
> Hallo ich möchte mich mit Mikrocontrollern beschäftigen, da will ich
> mich zwischen Atmel und PIC entscheiden. Vielleicht gibts auch noch
> bessere Hersteller?

Also Manu, was verstehst du unter "dich beschäftigen"? Ist es eher so, 
daß du:

a) mit irgendeiner IDE oder mit C dich beschäftigen willst oder daß du

b) irgendeinen uC näher kennenlernen und verstehen willst oder daß du

c) irgendein Bastelprojekt realisieren willst und dafür einen uC 
brauchst?

Je nachdem, ob du jetzt a oder b oder c denkst, sind unterschiedliche 
Teile der vielen weiter oben geposteten Ansichten für die Katz. Die 
Atmelfans raten zu Atmel, die Picfans zu Pic, andere zu 8051 oder MSP 
oder ARM... Und die fanatischen C-Programmierer raten natürlich zu 
größeren uC's (..Nimm lieber nen PIC18 oder PIC24 aber keinen PIC16.. 
usw), weil sie zu doof oder zu faul sind, um auch mal was in Assembler 
zu machen oder weil sie ihre Nase zu hoch tragen - kurzum, wirklich alle 
Ratschläge sind in irgend einer Richtung tendenziös.

Mein Rat: geh in dich und finde heraus, was du wirklich willst. DU und 
kein anderer. Anschließend guck auf dein Budget und sieh dich um, was du 
dafür kriegst und ob du damit das erreichen kannst, was dir vorschwebt.

Noch ein Rat: Bei so gut wie allen 8 Bittern ist die Anschaffung eines 
Programmiergerätes angesagt, ob nun in Form eines USB-Sticks oder 
sonstwie. Ja - man kann auch heutzutage noch sich sowas selbst basteln. 
Ich befürchte nur, daß die heutige Fertigkost-Mentalität die angehenden 
uC-"Spezialisten" nach Fertigkost aus IDE + Debugger + Brenner + 
Evalboard + RTOS + Demoapps + Libs greinen läßt.

Bei einigen (aber nicht allen) 32 Bittern, allen voran ARM bzw. Cortex 
sind ab Werk in die Chips Bootlader eingebaut, die das Programmieren der 
Chips per serieller Schnittstelle ermöglichen. Die dazu benötigte 
Hardware läßt sich mit deutlich weniger Aufwand selbst basteln als einen 
o.g. Brenner für 8 Bitter. Das ist für den Bastler ne echte 
Erleichterung.

W.S.

[Manu (Gast)]

Wie gesagt, warscheinlich ist mein Post in der Flut an Antworten 
untergegangen, es ist Microchip womit ich mich beschäftigen werde.

Microchip macht einen professionellen Eindruck, es gibt einen 
Hauseigenen kostenlosen C-Compiler, MCUs von 8 - 32 Bit, Digitale 
Signalprozessoren, eine kostenlose IDE, eine Einführung mit 
Beispielprojekten in PDF Form und das alles aus einem Haus, was will man 
mehr.

Das PICkit3 als Programmer und Debugger mit Entwicklungsboard + Software 
CD kostet knappe 70€, das ist in Ordnung für mich. Beginnen werde ich 
mit den 8 Bittern.

[Chris B. (dekatz)]

Umfassende Info speziell für die 8-Bit PIC findes du bei "Sprut"
http://www.sprut.de/

2 spezielle PIC-Foren (auf Deutsch):
http://pic-projekte.de/phpBB3/
http://www.fernando-heitor.de/

Das MICROCHIP eigene Forum (mit aktuellen Hinweisen auf Updates) gibt es 
hier
http://www.microchip.com/forums/

Für MPLABX gibt es hier eine - wenn auch noch sehr unvollständige - 
Anleitung (nach Monatelanger Stagnation schein man in den letzten Wochen 
wieder daran zu arbeiten)
http://microchip.wikidot.com/start

[MCUA (Gast)]

>Was spricht denn für Atmel und was für PIC?
(bzw AVR vs PIC)
Die AVR-CPUs sind alle (fast) gleich (auch die ATXmegas), somit ist da 
von Architekt. her keine Rechenleistung erweiterbar. (bsp nur 3 
Ind-Register, fast alles nur über LD/ST)

Bei PICs gibt es die ganz kleinen (bsp 16F54 , uralt, oder 10Fer (mit 5 
f-bits , also nur 32 Reg ohne Umschaltung ansprechbar) / Grössere mit 7 
f-bits (darunter auch Erweiterungen wie zB 2 Ind.-Registern) / die PIC18 
mit 8 f-bits (und 4 BSR-bits) und weiteren 
Linear-Adressier-Möglichkeiten.
Und die PIC24,30,33 als 16 biter mit sehr leistungsfähigen Befehlen (das 
meiste in 2 Takten, ua 13 f-bits , 8kB direkt ansprechbar, ohne LD/SD 
o.ä.), und PIC32 32bit.
Also (obwohl unterschiedliche CPUs ist doch vieles kompatibel) über 
weiten Bereich skalierbar.

[Peter D. (peda)]

egal² schrieb:
> Das ist nicht uninteressant. Kannst Du hierfür mal ein Bespiel zeigen,
> anhand eines Befehls und woran man das erkennt?

Welcher PIC das genau ist, weiß ich nicht mehr.
Er hat folgende IO-Register:
- Adresse Low-Byte
- Adresse High-Byte
- Lesen/Schreiben von Adresse
- Lesen/Schreiben von Adresse mit Adreßincrement
- Lesen/Schreiben von Adresse mit Adreßdecrement
Und das ganze 3-mal, also 15 "magische" Register.

Ist vermulich angeregt worden durch die 3 Pointer X,Y,Z des AVR.
Die C-Compilerbauer mögen ja mindestens 3 Pointer (Quelle, Ziel, lokaler 
Daten-Stack) sehr gerne für effizienten Code.

Daß zusätzliche Befehle als IO-Zugriffe implementiert werden, ist mir 
von keiner anderen Architektur bekannt.

[Thomas S. (doschi_)]

Manu schrieb:
> Das PICkit3 als Programmer und Debugger mit Entwicklungsboard + Software
> CD kostet knappe 70€, das ist in Ordnung für mich.

Watterott hat eine Alternative von Olimex:
http://www.watterott.com/de/PIC-KIT3  (knapp 28 EUR)
Allerdings habe ich keine eigenen Erfahrungen damit.

[Thomas S. (doschi_)]

Eine Ergänzung zur Linksammlung von Chris B.:

http://www.stefan-buchgeher.info/elektronik/elektronik.html#Kap2
- PIC-Projekte und -Routinen,
- Tipps für die Einbindung von CC5X in MPLAB
(http://www.stefan-buchgeher.info/elektronik/cc5x/cc5x.html)
Damit kann man auch die kleinen PIC (16F..) in C programmieren.

[Frank K. (fchk)]

Meine Erfahrungen:
Ich habe vor 30 Jahren mal mit Z80 angefangen und inzwischen einen 
ganzen Haufen verschiedener Architekturen kennen gelernt. AVR war auch 
darunter, die verschiedenen PIC-Architekturen auch. Ich kenne also 
beides und habe auch mit beiden Architekturen umfangreiche Projekte 
gemacht.

Ich bin inzwischen bei Microchip hängen geblieben. Warum:

1. bessere Auswahl an Peripherie und leistungsfähigere Peripherie. Such 
mal einen AVR mit integriertem Ethernet. Gibts nicht. Oder einen kleinen 
AVR mit eingebautem CAN. Gibts nicht. Oder einen AVR mit 
Hardware-LIN-Support. Ja gibts, musst Du aber mit der Lupe suchen. Oder 
einen AVR mit Framed SPI Support (TDM, die verallgemeinerte Form von 
I2S). Schade, nochmal daneben.

2. bessere Langzeitverfügbarkeit. Microchip hat noch nie irgendeinen PIC 
abgekündigt. Atmel schon. Mich hätte es fast beim AVR32AP7000 kalt 
erwischt. Kann man zwar noch kaufen, ist aber eine Sackgasse. Sowas 
vergesse ich nicht.

3. bessere Debugbarkeit: Egal wie doof man sich anstellt, man kann sich 
bei keinem PIC aussperren. Geht nicht. Bei AVR schon. Man kann so gut 
wie jeden PIC über ICSP nicht nur programmieren, sondern auch debuggen 
(die ganz alten EPROM-basierten Typen mal ausgenommen). PICKIT3 und ICD3 
sind durchgängig von den 8 Bit PICs bis hin zu den 32 Bit PICs 
verwendbar.

4. besserer Software-Support. Atmel hat vieles der Community überlassen, 
Microchip hat selber USB- und TCP/IP-Stacks für seine Klientel gebaut. 
Gut, ist keine freie Software, aber auch für kommerzielle Projekte 
kostenlos verwendbar. GPL-Code will bzw darf ich teilweise nicht in 
kommerziellen Projekten einsetzen.

5. Preis/Leistung. Da gehe ich eben mal bei Reichelt schauen, was ein 
Mega328P im 28 SDIP kostet. Der aktuelle Kurs steht bei 4.25€. Dann mal 
flugs zu Microchip geblättert: PIC32MX150F128B-I/SP 3.60€. 40 MHz, 32 
Bit, USB, 128k Flash, 32k RAM. Äh... da fällt die Wahl ja wohl nicht 
schwer. Wer da für mehr Geld etwas schlechteres nimmt, ja sorry, der hat 
die Zeit verpennt.

An der etwas kruden 8-Bit Architektur habe ich mich anfangs auch 
gestört, aber heutzutage wird eh das meiste in C gemacht, und da kratzt 
mich das wenig. Man kann erstaunlich gut damit leben, und wenn nicht, 
dann wirds eben ein PIC24 - der sieht vom Übersichtsdiagramm eher aus 
wie ein 16 Bit AVR.

Viele Leute denken bei PIC immer noch nur an die 8 Bit Dinger. Das ist 
inzwischen nicht mal mehr die halbe Wahrheit. Die 16 und 32 Bit 
Architekturen sind auch empfehlenswert ... und ehrlich, ich würde zum 
Einstieg eher einen PIC24 empfehlen als einen PIC16/PIC18. Er ist 
einfacher zu handhaben, schneller (bis zu 70 MHz!) und oft nicht einmal 
teurer.

Es kamen Kommentare über den AVR-GCC als dem Killerkriterium. Nun ja, 
dem kann ich nicht so zustimmen. AVR und GCC ist kein Traumpaar, es gibt 
andere Compiler, die viel besser auf die AVR-Architektur angepasst sind. 
Ich habe auf dem AVR mit ImageCraft angefangen und im Automove-Bereich 
viel IAR verwendet, und IAR saß bei der AVR-Entwicklung mit am Tisch, 
und der IAR-Compiler ist auch ziemlich gut, wenngleich auch asig teuer, 
aber ${kunde} hat die Lizenz bezahlt, und so wars mir gleich.

Ich bin also kein Frickler oder Open-Source-Verfechter, Zeit ißt Geld.

fchk

[Fallobst (Gast)]

Frank K. schrieb:
> Egal wie doof man sich anstellt, man kann sich
> bei keinem PIC aussperren. Geht nicht. Bei AVR schon.

Von Aussperren kann nicht die Rede sein. Mit HV-Programmierung kommt man 
in jeden Avr.

Frank K. schrieb:
> Preis/Leistung. Da gehe ich eben mal bei Reichelt schauen, was ein
> Mega328P im 28 SDIP kostet.

Reichelt ist auch das Maß der Dinge. Schau mal bei digikey, mouser, tme 
oder gulo vorbei. Der Preis für den Mega238 liegt beim guloshop bei 2€.

Außerdem unterliegen die 8bit PICs m.W. den Avrs, da sie den Takt nicht 
durch 4 teilen.

Wie sehen die PICs eigentlich gegenüber der Atxmega-Serie aus? 
Atxmega16d4 für 1,60€ mit Event-System, Mehrere Usart, SPI und TWI. Oder 
die A1-Serie, die zwischen 3-4€ beginnt und SDRAM unterstützt.

[Dirk P. (Gast)]

Fallobst schrieb:
> Wie sehen die PICs eigentlich gegenüber der Atxmega-Serie aus?
> Atxmega16d4 für 1,60€

Der Preis klingt gut. Kannst du mir bitte die Quelle verraten? Bei 
Conrad habe ich letzte Woche noch 5 Euro dafür gelöhnt.

[Fallobst (Gast)]

Ich merke gerade, dass ich den Preis für 5 Stück im Kopf hatte. Einzeln 
gibt es ihn bei Tme für 1,85.

[GroberKlotz (Gast)]

Hallo Manu,
nachdem Du jetzt weißt was Du willst kannst Du ja loslegen! Ich betreibe 
das µC-Hobby ausschließlich mit PICs. Dabei habe ich mich mit den 
16Fxxxx und Assembler angefangen. Damit ließen sich alle Aufgaben welche 
ich mir bis jetzt stellte lösen:
LCD-Ausgabe, Drehencodersteuerung,DCF77-Uhr, Voltmeter, Ohmmeter, 
Morsedecoder, RS232 Schnittstelle usw.....

Ich habe mit Assembler begonnen, dies erschien mir "durchsichtiger" als 
kryptisches "C". Wobei ich aber inzwischen auch beginne die Vorteile von 
C zu verstehen. Dennoch kann ich den Start mit Assembler nur empfehlen!

Als sehr wertvolle Hilfe hat sich dazu das 18-Pin-Testboard von 
www.sprut.de erwiesen (muss man sich selbst bauen). Mit den dazu 
möglichen Zusatzplatinen, welche einfach  in die Portbuchsen darauf 
gesteckt werden, lassen sich jede Menge Experimente durchführen.
Inzwischen bin ich zur 28pin-Testplatine "aufgestiegen" und beginne mich 
damit in die 18F2xxx + C mit HiTech-Compiler PICC-Lite einzuarbeiten.

Pack's einfach an!

mfG GroberKlotz

[Tippgeber (Gast)]

Seit längerer Zeit bin ich auch bei den PICs gelandet. Ich verwende u.a. 
auch sehr kleine Typen 12Fxx, 16Fxx. Leider muß man sich manchmal auf 
böse Überraschungen gefasst machen.
Z.B. haben manche Typen keine Debug Engine und müssen deshalb über 
spezielle PODs debuged werden. Dazu muss der Controller aber gesockelt 
sein, was aber bei SMD natürlich nicht so leicht möglich ist.
Auch wird manche Peripherie in der Simulation nicht unterstüzt. Ich 
konnte z.B. den relativ komplizierten Self Flash eines kleinen Typen 
nicht simulieren. Da nun weder Simulation noch Debugging möglich war 
ging die ganze Aktion nur noch über Try and Error.
Ansonsten sind die PICs aber unschlagbar wenn es um Preis und Auswahl 
geht.

[Frank K. (fchk)]

Fallobst schrieb:
> Frank K. schrieb:
>> Egal wie doof man sich anstellt, man kann sich
>> bei keinem PIC aussperren. Geht nicht. Bei AVR schon.
>
> Von Aussperren kann nicht die Rede sein. Mit HV-Programmierung kommt man
> in jeden Avr.

Und was nützt Dir das, wenn Dein TQFP100 auf einem Board festgelötet 
ist?

> Reichelt ist auch das Maß der Dinge. Schau mal bei digikey, mouser, tme
> oder gulo vorbei. Der Preis für den Mega238 liegt beim guloshop bei 2€.

Gut, das Verhältnis €/Rechenleistung bleibt aber.

> Außerdem unterliegen die 8bit PICs m.W. den Avrs, da sie den Takt nicht
> durch 4 teilen.

64MHz durch 4 sind auch 16, so what? Und wie gesagt, bei mir spielen die 
8 Bit PICs keine so große Rolle mehr. PIC24 ist oftmals nicht mal 
teurer.

> Wie sehen die PICs eigentlich gegenüber der Atxmega-Serie aus?
> Atxmega16d4 für 1,60€ mit Event-System, Mehrere Usart, SPI und TWI. Oder
> die A1-Serie, die zwischen 3-4€ beginnt und SDRAM unterstützt.

Ein externes Memory Interface fehlt leider. DAS ist der einzige 
wirkliche Schwachpunkt. Wenn ich das brauche, nehme ich halt ARM oder 
AVR32 oder so - schließlich bin ich mit Microchip nicht verheiratet, und 
ich habe die Tools für alle gängigen Architekturen da, auch MSP430 oder 
einige 8051.

Versionen mit mehreren UART/SPI/I2C hat Microchip auch, DMA ab PIC24 
auch, und was ich sehr praktisch finde: remappable Pins. Da bist Du 
nicht drauf angewiesen, dass UARTx auf Pin x liegt, sondern Du kannst 
einer Peripheriefunktion einen (fast) beliebigen Pin zuordnen, je 
nachdem, was Du gerade brauchst und wie es für Dein Layout am Besten 
passt. Gibts bei PIC24/dsPIC33 und kommt auch in die neuen PIC32 Typen 
rein. Extrem nützlich!

fchk

[Manu (Gast)]

GroberKlotz schrieb:
> Ich habe mit Assembler begonnen, dies erschien mir "durchsichtiger" als
> kryptisches "C". Wobei ich aber inzwischen auch beginne die Vorteile von
> C zu verstehen. Dennoch kann ich den Start mit Assembler nur empfehlen!

Würde ich sogar sehr gerne lernen (habe dann Zeit mich in C 
einzuarbeiten), gibts von PIC zufällig auch eine "Lessons" pdf in 
Assembler? Habe noch nichts gefunden.

[Grasshopperfan (Gast)]

Frank K. schrieb:
> schließlich bin ich mit Microchip nicht verheiratet

das ist aber traurig. Im Gegensatz dazu bin ich ein Kind von Microchips 
und Computern im allgemeinen. Aber lassen wir das.

[MCUA (Gast)]

>Leider muß man sich manchmal auf böse Überraschungen gefasst machen.
>Z.B. haben manche Typen keine Debug Engine
Ist an der Übersichts-Tabelle bei denen zu sehen unter "ICD-Debug".

>Ein externes Memory Interface fehlt leider. DAS ist der einzige
>wirkliche Schwachpunkt.
Vielleicht über EPMP. (haben aber nur wenige)

>und was ich sehr praktisch finde: remappable Pins
Ja. M.W. ab PIC24.

[Wilhelm F. (Gast)]

Manu schrieb:

> GroberKlotz schrieb:
>> Ich habe mit Assembler begonnen, dies erschien mir "durchsichtiger" als
>> kryptisches "C". Wobei ich aber inzwischen auch beginne die Vorteile von
>> C zu verstehen. Dennoch kann ich den Start mit Assembler nur empfehlen!
>
> Würde ich sogar sehr gerne lernen (habe dann Zeit mich in C
> einzuarbeiten), gibts von PIC zufällig auch eine "Lessons" pdf in
> Assembler? Habe noch nichts gefunden.

Die Datenblätter der PIC-µC haben oft oder sogar immer eine Beschreibung 
des Befehlssatzes mit drin. Anhand von Assembler-Beispielen kann man das 
dann recht gut lernen. Zumindest die kleinen PIC, die ich kenne, z.B. 
12F675, haben einen sehr überschaubaren Befehlssatz aus nur 35 Befehlen, 
das hat man schnell.

Wie man Programme gut strukturiert, muß man aber woanders suchen, das 
ist auch eher allgemein, und nicht PIC-spezifisch. Z.B. wie man 
Struktogramme oder Flußdiagramme erstellt. Für umfangreichere Programme 
braucht man das tatsächlich auch, nicht immer ist es mit reiner 
Codierung nur aus dem Kopf heraus getan.

Auf der CD zu meinem PICkit1 ist z.B. eine Unmenge an Beispielcode 
dabei. Auf der Homepage findet man aber auch ziemlich viel. Unter 
Umständen auch alles, was auf so einer CD drauf ist.

[Robert V. (Gast)]

MCUA schrieb:
>>und was ich sehr praktisch finde: remappable Pins
> Ja. M.W. ab PIC24.

Die J-Typen der PIC18F Serie haben dieses Feature auch, da diese bereits 
auf der PIC24 Fertigungstechnologie basieren.

[Wilhelm F. (Gast)]

Robert V. schrieb:

> MCUA schrieb:
>>>und was ich sehr praktisch finde: remappable Pins
>> Ja. M.W. ab PIC24.
>
> Die J-Typen der PIC18F Serie haben dieses Feature auch, da diese bereits
> auf der PIC24 Fertigungstechnologie basieren.

SiLabs hat sowas schon lange in den 8051-Derivaten. Schade, daß die 
Konfiguration aber nicht voll flexibel ist, es lassen sich nicht alle 
Pins frei zu allen Funktionen mappen. Man hätte da besser eine völlig 
frei wählbare Multiplexer-Matrix eingebaut. Keine Ahnung, warum man das 
nicht macht, vielleicht braucht es mehr oder weniger Chipfläche, oder es 
hat andere Nachteile, z.B. Signallaufzeiten. Sonst wäre man auch im 
Platinenlayout völlig frei.

[Moby (Gast)]

Frank K. schrieb:
> Ein externes Memory Interface fehlt leider. DAS ist der einzige
> wirkliche Schwachpunkt.

Nö. Die XMegaA1 Typen haben es.

[GroberKlotz (Gast)]

Manu schrieb:
> Würde ich sogar sehr gerne lernen (habe dann Zeit mich in C
> einzuarbeiten), gibts von PIC zufällig auch eine "Lessons" pdf in
> Assembler? Habe noch nichts gefunden.

Meistens sind diese "lessons" in englisch. So wie diese hier:
Assembler
[http://www.amqrp.org/elmer160/lessons/index.html]
[http://www.gooligum.com.au/tut_baseline.html]
[http://www.gooligum.com.au/tut_midrange.html]
C (freier Compiler Hi-Tech PICC-lite)
[http://www.gooligum.com.au/tut_midrange_C.html]
Damit man das Rad nicht nochmals erfinden muss, gibt es hier jede Menge 
Code für alle möglichen Zwecke:
[http://www.piclist.com/techref/microchip/routines.htm]

Überhaupt gibt es im Netz jede Menge an Projekten welche mit den PICs 
von einfach bis schwierig durchgeführt werden können.

mfG GroberKlotz

[Wilhelm F. (Gast)]

GroberKlotz schrieb:

> C (freier Compiler Hi-Tech PICC-lite)

Ist limitiert, wo und in was genau, steht nirgends. Jedenfalls fand ich 
nichts. Bei mir machte das schon mal Probleme, wenn ich mehrfach 
geklammerte Terme verarbeite. Es gab beim Compilieren keine Warnung, 
Fehlermeldung, nichts. Aber ein Hex-File wurde erzeugt. Das spielt dann 
eben einfach nicht.

Nach dem ich die Codezeilen in mehrere nacheinander auseinander 
klamüserte, dann gehts plötzlich.

SDCC für den 8051 ist mir da viel geheuerer.

[MCUA (Gast)]

>>>>und was ich sehr praktisch finde: remappable Pins
>>> Ja. M.W. ab PIC24.
>> Die J-Typen der PIC18F Serie haben dieses Feature auch, da diese bereits
>> auf der PIC24 Fertigungstechnologie basieren.
>SiLabs hat sowas schon lange in den 8051-Derivaten. Schade, daß die
>Konfiguration aber nicht voll flexibel ist, es lassen sich nicht alle
>Pins frei zu allen Funktionen mappen. Man hätte da besser eine völlig
>frei wählbare Multiplexer-Matrix eingebaut.
Darum geht es ja. Wählbare Pins haben viele uCs, aber einer MUX-Matrix 
(wie bsp PICs, Silabs CM3, LPC800 (nicht AVR oder STM32)) haben extrem 
wenige.
Das braucht nat Silic-Fläche, was aber bei neuen kleinen Strukturen ja 
nicht mehr so teuer wäre/ist.

>> Ein externes Memory Interface fehlt leider. DAS ist der einzige
>> wirkliche Schwachpunkt.
>Nö. Die XMegaA1 Typen haben es.
Die obige Aussage bez fehlendem Interface bezog sich auf PICs, nicht auf 
AVRs.

[W.S. (Gast)]

O ha, zweimal fast dasselbe - die Architektur betreffend -, wenn man 
genau hinguckt. einmal negativ und einmal positiv gestimmt:

Fallobst schrieb:
> Außerdem unterliegen die 8bit PICs m.W. den Avrs, da sie den Takt nicht
> durch 4 teilen.

Tja, das glaubst aber nur du, denn die Architektur ist völlig anders. 
AVR sind - soweit ich mich an den ATmega169 entsinne - eigentlich 
klassische Registermaschinen:
- RAM in Register laden
- Operation durchführen
- Register in RAM zurückschreiben.
fertig.

Bei den kleinen PIC's sieht das Ganze völlig anders aus:
- Operation im RAM durchführen
fertig.

Kurzum, dadurch, daß sehr viele Befehle direkt im RAM durchgeführt 
werden, wozu ja auch die Ports gehören, kommt man 
(Assemblerprogrammierung vorausgesetzt) mit recht wenigen 
Maschinenbefehlen zum Ziel. Das spart massiv an Zeit, so daß die obige 
Milchmädchenrechnung mit dem Takt durch 4 so einfach nicht stimmt. Wer 
weniger Befehle braucht, braucht damit auch weniger Takte. Nach meiner 
Einschätzung liegen die AVR's und die kleinen PIC's so lala gleichauf, 
was die Geschwindigkeit betrifft.

Aber es ist schon wahr: An die PIC16-Architektur muß man sich erstmal 
ein bissel gewöhnen. Ist also eher nix für Leute, die sich nicht mit 
Hardware befassen wollen.


...wegen Assemblerprogrammierung:
Manu schrieb:
> Würde ich sogar sehr gerne lernen (habe dann Zeit mich in C
> einzuarbeiten), gibts von PIC zufällig auch eine "Lessons" pdf in
> Assembler? Habe noch nichts gefunden.

Da kenne ich auch nix, aber die Manuals zu den einzelnen PIC's sind 
eigentlich sehr gut und beschreiben den Befehlssatz recht ausführlich. 
Da es nun recht wenige Befehle gibt, bleibt das Ganze auch im Rahmen und 
ufert nicht aus.

Den Assembler von Microchip für die 16Fxxx finde ich hingegen nicht 
wirklich gut gelungen. In den 1990ern hieß das Teil "PICALC" und hatte 
mich derart in Rage gebracht, daß ich mir meinen eigenen Assembler 
schrieb, den ich auch heute noch verwende - und den ich auch heutzutage 
noch für wesentlich besser halte als das Originalteil. Allerdings hab 
ich bislang noch keinen weg gefunden, ihn in die IDE als externen 
Assembler mit einzubauen. Daß sowas prinzipiell geht, sieht man an 
einigen Beispielen.

Hier nur ein paar Tips der allgemeinen Art:
- gewöhne dir an, immer brav den Zielswitch zu schreiben, also
  ADDWF MyVariable,F   oder
  ADDWF MyVariable,W
je nachdem, ob das Ergebnis zurück in den RAM oder in's W-Register 
kommen soll. Ich weiß, daß es auch Default-Einstellungen gibt oder man 
,0 bzw. ,1 schreiben kann, aber auf lange Sicht ist das viel zu 
unübersichtlich und damit fehlerträchtig. ,W oder ,F sind hingegen viel 
einprägsamer.

- merke dir, daß die Subtraktion beim PIC anders läuft als du es dir 
denkst. Es ist die Addition des Zweierkomplementes und damit kehrt sich 
das Carry um.

Also
100 - 99 macht normalerweise 1 und NoCarry,

aber beim PIC wird draus
100 - 99 wird zu  100 + 157 --> 257, was gleich 1 + Carry bedeutet.

- mach dir am besten eine Art Quellvorlage, die du dann immer benutzt. 
Immerhin starten die Dinger bei Adresse 0, der Interrupthandler startet 
immer bei Adresse 4 und du mußt dir die Register W, Status, FSR und evtl 
PCLATH selber retten und restaurieren.

W.S.

[Tippgeber (Gast)]

Schön wäre es, wenn der PICF12/16 Assembler den Status des Bank- und 
Page Switchings mitloggen würde. Das müsste ohne weiteres möglich sein. 
Leider erhält man stattdessen nur nichtssagende Warnungen, dass man 
aufpassen soll, weil dieses oder jenes Register nicht in Bank0 liegt.

[Tester (Gast)]

W.S. (Gast):
>Nach meiner
>Einschätzung liegen die AVR's und die kleinen PIC's so lala gleichauf,
>was die Geschwindigkeit betrifft.

Traumrechnung! Das funktioniert nur so lange, wie ständig nur aus dem 
Ram geladen wird beim AVR. Alleine, dass die oft genutzte Null in einem 
Register ist lässt den AVR gewinnen. Meiner Erfahrung ist man mit einem 
Faktor von > 2,3 dichter an der Realität, vor allem wenn Kryptografische 
Sachen gemacht werden. Ich musste bei Geschwindigkeitskritischen Sachen 
bis jetzt immer kämpfen, damit der kleine PIC die Anforderungen erfüllt 
hat, welche aus einem Vorgänger AVR resultierten. Andersherum kein 
Problem!

Aber die PICs sind was Perepherie anbelangt wirklich großartig und aus 
meiner Sicht eines ursprünglichen AVR Jüngers auch teilweise eigenartig 
und furchtbar. Aber hier überwiegen definitiv die Pluspunkte.

Zum Compiler, sowohl GCC als auch XC8 bieten, wenn man ungewöhnliche 
Konstrukte verwendet Fehlerquellen, aber auch jeder andere Compiler 
glaube ich. Wenn man nur die Free Version vom XC hat ist der GCC besser 
würde ich aus meiner kurzen aber doch hart vergleichenden Erfahrungswelt 
heraus sagen. Der Unterschied zwischen XC8 PRO und Free ist deutlich, 
was den generierten Code anbelangt, vor allem wenn man nicht schon 
automatisch selbst mit optimiert.

Industrielle Realität aus dem was ich sehe:
Sehr viel AVR 8-Bit (kennt jeder von der Hochschule oder alte 8051)
Sehr viel PIC 8 - Bit
Viel ARM 9 bis 11 (Freescale am häufigsten)
Etwas AVR 32 (bald Geschichte)
Wenig Renesas RX, wo es um kritische Komponenten geht und Geld keine 
Rolle spielt.

Ich bin selbst als C Programmierer in der Regel auf kleinen µC unterwegs 
im Bereich hoher Stückzahlen (>10k je Gerät bei langer Produktlaufzeit). 
Hier sind 10 Cent differenz zwischen µC Welten und in der Regel mit 
nichts zu rechtfertigen. Ich habe letztes Jahr (Berufseinstieg) immer 
den generierten Assembler Code direkt neben dem C Fenster gehabt, ist 
schon interessant effektiven und schönen Code in C zu schreiben.

Wenn ich meine letzten drei Projekte Betrachte steht es  2 : 1 für die 
PICs, auch wenn ich sie nicht mag. Bei gleicher Eignung würde ich immer 
einen AVR nehmen. Einmal hat sich der PIC zB nur wegen genauerem 
internen Oszillator durchgesetzt, da so eine externe genauere Taktquelle 
eingespart werden konnte.

Privat bin auf AVR 8-Bit, Cortex M-3 von ST und Renesas RX unterwegs. 
Letzterer übrigens mein Liebling, den ich niemandem empfehlen würde. 
Alleine schon aufgrund schlechter Verfügbarkeit!

Viel Erfolg mit den PICs, definitiv keine Schlechte wahl, falls es die 
überhaupt gibt und vielleicht sieht man sich mal im Microchip Forum wenn 
der C Compiler zum ersten mal nicht macht was er soll ;) (meist sitzt 
der Bug vor dem Bildschirm, es geht aber auch anders)

[Rolf R. (ultra-low)]

Nimm AVR. Allein schon wegen AVR Studio. Da haste alles(Software) 
kostenlos im Einen. Vor allem für Einsteiger konkurenzlos...

[Anja (Gast)]

Tippgeber schrieb:
> Schön wäre es, wenn der PICF12/16 Assembler den Status des Bank- und
> Page Switchings mitloggen würde.

Was hindert dich daran deine eigenen Bank-Makros zu schreiben?

Für den PIC16C84 könnte das dann so aussehen:

; Definition aller Register in Bank 1 als __register

;
    CBLOCK 0x80
  __indf2    ; = indf
  __option
  __pcl2    ; = pcl
  __status2  ; = status
  __fsr2    ; = fsr
  __trisa    ; PORTA data direction register
  __trisb    ; PORTB data dir. register 1 = input
  __null2
  __eecon1
  __eecon2
  __pclath2  ; = pclath
  __intcon2  ; = intcon
    ENDC

; Verknüpfung der Register mit Assembler-Variablen BankMask

#define _indf2   __indf2   ^ BankMask
#define  _option   __option  ^ BankMask
#define  _pcl2   __pcl2    ^ BankMask
#define  _status2 __status2 ^ BankMask
#define _fsr2   __fsr2     ^ BankMask
#define _trisa   __trisa   ^ BankMask
#define  _trisb   __trisb   ^ BankMask
#define _null2   __null2   ^ BankMask
#define _eecon1   __eecon1  ^ BankMask
#define _eecon2  __eecon2  ^ BankMask
#define _pclath2 __pclath2 ^ BankMask
#define _intcon2 __intcon2 ^ BankMask


; Initialisierung Assembler-Variable
BankMask        set     0x00
;
; Makro für Umschaltung auf Bank0
Bank0  macro
  bcf     _rp0
BankMask  set  0x00
  endm
; Makro für Umschaltung auf Bank1
Bank1  macro
  bsf  _rp0
BankMask  set  0x80
  endm


; Beispielcode

Init:
  movwf  _portb
  Bank1    ;Registerbank 1 adressieren
  movlw  0x01  ;RB0 (Taster) als Input, Rest (LED's) Output
  movwf  _trisb  ;Portb-Pins konfigurieren
  movlw   0x18    ;FIN und Endschalter Input, Rest Output
  movwf   _trisa  ;Porta-Pins konf.
;
      ;Option-Register
        movlw   0xF9    ;Timer0 takt extern, fallende Flanke
        movwf   _option ;(Frequenzteiler); Prescaler WDT = 1/2
                        ;ergibt Timeout zwischen 16..66 ms bei 5V

  Bank0    ;Registerbank 0 selektieren
;
; Variablen_init
;
  movlw  TMO    ;Beginn init mit TMO
  movwf  _fsr

Der Assembler meckert dann nur wenn tatsächlich mal vergessen wurde die 
Bankumschaltung zu betätigen. Ansonsten wird die _Variable über den XOR 
mit der aktuellen Bank immer in Bank0 gespiegelt wenn die bits richtig 
stehen.

Man könnte natürlich auch die Assemblervariable nutzen um festzustellen 
ob überhaupt eine Bankumschaltung notwendig ist und mit bedingter 
Assemblierung im Makro arbeiten.

Gruß Anja

[Matthias (Gast)]

Gerade wenn man die freie Wahl hat spricht heute einiges dafür ein ARM 
Cortex-M Derivat zu wählen. Warum?

1. PIC, MSP430 und AVR sind proprietäre Architekturen von nur jeweils 
einem einzelnen Anbieter. Wer steigt schon in einen Flieger mit nur 
einer Turbine?
ARM Mikrocontroller gibt es heute von jedem namhaften Hersteller in 
jeder Geschmacksrichtung. Geht einer vom Markt gibt es schnell jemanden 
der die Lücke schliesst.

2. Eine Masse an Tools und Software. Tendenz steigend.

3. Stromverbrauch im Bereich eines 8-bitters (bei M0+)

4. Vorteile einer 32-bit Architektur:
- Flacher 4GByte Adressraum mit nur einer Adressierungsform. Kein 
Banking, kein Paging. Deutlich einfacheres Programmiermodell.
- Wesentlich bessere 32 und 16 bit Arithmetik als 8-Bitter. Zum 
Vergleich braucht ein Cortex-M3 fuer eine 16x16bit Multiplikation einen 
Zyklus. Ein ueblicher 16-bitter etwa 8-12 und ein 8-bitter wie der 8051 
mindestens 45 (und das bei einem Bruchteil des Kerntaktest und im 
schlimmsten Fall 12Clocks/cycle).
- Breitere Busse für bessere Speicherbandbreite.

Was würde ich dir heute konkret empfehlen?
DevBoard mit on-board Debugger:
https://www.element14.com/community/community/knode/dev_platforms_kits/element14_dev_kits/kinetis_kl2_freedom_board
Toolchain:
http://www.keil.com/arm/mdk.asp

Das ganze kostet dich keine 20 Euro und bietet einen Einstieg mit 
Werkzeugen auf professionellem Niveau. Alles andere ist Vergeudung von 
Zeit und Geld.

[Steffen (Gast)]

Hallo,

habe nun viele Jahre Privat und auch im Geschäft mit beiden Firmenenorm 
viel zu tun.

Ich tendiere defintiv zu Atmel AVR.

Natürlich funktionieren die PICs genauso gut, jedoch ist der Umgang mit 
den Conrollern bei Atmel wesentlich besser..

Ich rede hier nur mal für den 8bit-Sektor. Bei den 32ern macht das nicht 
mehr so viel aus... (Eh nur in C).

Ich programmiere beide Hersteller in Assembler und auch in C.
Atmel ist definitiv der bessere Einstieg... Wesentlich schnellere 
Erfolge. Den PIC kann man danach immernoch lernen. Allein dieses 
Bankenwechseln bei den PICs zwecks den SFR-Registern nervt unheimlich 
und produziert unheimlich viele Fehler... So haben die PICs einige 
Nachteile...

Dazu ist der AVR viel schneller ;-) (PIC braucht vier Zyklen für einen 
Befehl und Atmel nur einen)


Ich programmiere größtenteils immernoch ohne JTAG und debugge höchstens 
mal in der Software. So habe ich das ganze auch gelernt. Wer sich mit 
der Thematik gut auskennt braucht normal kein JTAG etc...

Meine Meinung,

Grüße Steffen

[egal (Gast)]

Manu schrieb:
> Hallo ich möchte mich mit Mikrocontrollern beschäftigen, da will ich
> mich zwischen Atmel und PIC entscheiden. Vielleicht gibts auch noch
> bessere Hersteller?

Atmel oder Microchip. Bascom oder C. Arduino oder nicht.

Ganz egal! Der Controller ist Mittel zum Zweck und wird dementsprechend 
ausgewählt. Als Anfänger kannst du solange nicht wählen, bis DU 
Erfahrung gesammelt hast.

Anfänger lassen LEDs am Anfang blinken. Mach das mit einem ATTiny44 oder 
ATMega88 deren Datenblatt noch überschaubar ist; für Atmel gibt es am 
meisten Antworten auf Forumfragen. Probiere dann andere µC aus. Nach 
Bedarf auch andere Reihenfolge.

[MCUA (Gast)]

>Bei den kleinen PIC's sieht das Ganze völlig anders aus:
>- Operation im RAM durchführen
>fertig.
Aber nur wenn die richtige Bank schon selectiert ist.

Massgebend ist doch in 1.Linie die Anzahl direkt ansprechbaren 
(RAM)Stellen im OP-code.
Bei AVR (und auch bei MIPS) sinds nur 5 Bits (also max 32 Register, 
dafür aber als Quell u Ziel gleichzeitig nutzbar Bei grösserer Menge 
gehts nur mittels LD/ST).
Bei PIC sinds 5 (ältere), 7(PIC16F1xxx), 8 (PIC18) oder 13 (PIC24) Bits, 
allerd. ist das Reg nur entweder als Quell oder Ziel nutzbar.

Wenn man für die Berechn mit 32 Zellen (Registern) hinkommt, werden typ. 
RISC-Archit. (bsp AVR, MIPS, ARM) weniger Befehle benötigen als 
PIC16,18.
Wenn aber ständig mit grösserer Menge (bsp 100..200 Bytes) gerechnet 
werden muss, wären bei den typ RISCs viele LD/STs nötig, und PICs 
(PIC16,PIC18) wird wohl schneller sein, weil der direkt auf 256 Zellen 
(PIC18) zugreifen kann und auch (wenn das nicht reicht) eine 
Bankumschaltung ruckzuck gemacht ist.

Aber gerade bei typ. Steuerungsanwendungen (bei denen permanent viele 
Zellen und Bits geschrieben u. abgefragt werden müssen) ist deshalb die 
RISC-Archit. im Nachteil.

...es hängt also von der Anwendung ab.

[Mehmet K. (mkmk)]

Steffen schrieb:
> Ich programmiere größtenteils immernoch ohne JTAG und debugge höchstens
> mal in der Software. So habe ich das ganze auch gelernt. Wer sich mit
> der Thematik gut auskennt braucht normal kein JTAG etc...

Und wieder einmal fühle ich mich dumm, klein, haesslich und 
ausgestossen.

[M. N. (Gast)]

Steffen schrieb:
> Ich tendiere defintiv zu Atmel AVR.
>
> Natürlich funktionieren die PICs genauso gut, jedoch ist der Umgang mit
> den Conrollern bei Atmel wesentlich besser..
>
> Ich rede hier nur mal für den 8bit-Sektor. Bei den 32ern macht das nicht
> mehr so viel aus... (Eh nur in C).
>
> Ich programmiere beide Hersteller in Assembler und auch in C.
> Atmel ist definitiv der bessere Einstieg... Wesentlich schnellere
> Erfolge. Den PIC kann man danach immernoch lernen.

Das sehe ich ganz genau so.
Im neuen Katalog von Reich... sind unterschiedliche PICs aufgelistet: 
auf 7 Seiten. Gerade für einen Anfänger ist das doch Verwirrung pur!

Für den Einstieg einen ATmega48, der sich bei zunehmender Programmgröße 
pinkompatibel bis zum ATmega328 steigern läßt. Wenn's danach mal ein PIC 
sein soll - bitte schön. Aber nicht in Assembler!

[Moby (Gast)]

Matthias schrieb:
> Gerade wenn man die freie Wahl hat spricht heute einiges dafür ein ARM
> Cortex-M Derivat zu wählen.

ARM ist mitsamt seiner Tools wesentlich komplexer und komplizierter 
anzuwenden. Ist doch abenteuerlich, das einem Einsteiger zu empfehlen. 
Gerade für einfache Aufgaben, die wohl die Masse der Hobby-Projekte hier 
stellen. Nimm PIC oder AVR und nimm zuerst Assembler zum Lernen aller 
Basics. Da heisst es dann einfach z.B. sbi PORTA,0 zum Setzen eines 
Portbits und erfordert kein elendes Library Gewürge. Wenn Du dann einen 
gewissen Level (jemals) erreichst kannst Du bei Bedarf nach höchster 
Performance immer noch auf ARM umsteigen.

[Tippgeber (Gast)]

Anja schrieb:
> Man könnte natürlich auch die Assemblervariable nutzen um festzustellen
>
> ob überhaupt eine Bankumschaltung notwendig ist und mit bedingter
>
> Assemblierung im Makro arbeiten.

Vielen Dank für Deinen Beitrag, man könnte sich da sicherlich was 
stricken. Ich dachte aber eher an eine komfortablere Unterstützung 
direkt in der IDE. Manche wichtige Register (Status) benötigen ja auch 
gar keine Umschaltung, und oft entscheidet sich der Verlauf erst während 
der Laufzeit, so dass auf jeden Fall geschaltet werden muss.
Mit einer besseren Unterstützung würden sicherlich mehr Leute Gefallen 
an den kleinen PICs finden.

[Matthias (Gast)]

Moby schrieb:
> ARM ist mitsamt seiner Tools wesentlich komplexer und komplizierter
> anzuwenden.

Da widerspreche ich einmal. Mal sehen wie schwer der Einstieg ist. Ich 
hab mir gerade da von mir angesprochene Freedom-Board aus dem Regal 
genommen.

1. ARM's MDK-ARM installiert.
2. Freedom Board an USB gestöpselt.
3. Ein Beispiel für das Board in uVision IDE laden (Ich nehme 
\ARM\Boards\Freescale\FRDM-KL25Z\Blinky).
4. Das Projekt ist fertig eingerichtet. Ich brauche nur übersetzen und 
kann direkt flashen und debuggen.

Voila, mein Board blinkt und ich habe eine lauffähige Umgebung um meine 
eigenen Versuche in C zu unternehmen.
Mein System programmiert sich fast wie ein PC. Keine für Anfänger 
unverstaendliche Integer Promotion oder Speichervehikel wie Paging.

[Jörg W. (dl8dtl) (Moderator)]

Lothar schrieb:
> In der Industrie gibt es aber 8-bit praktisch nur 8051
> und 32-bit praktisch nur ARM

Wenn dem so wäre, dürfte Microchip ja gar keine Controller verkaufen.

[Jörg W. (dl8dtl) (Moderator)]

Robert V. schrieb:
> Die XC Compiler von Microchip gibt es in einer Free-Variante ohne
> Größenbeschränkung. Lediglich die Optimierung ist ausgeschaltet.

Das würde ich dann allerdings als Spielzeug abtun.  Wenn man sich mal
so ansieht, was ein ordentlicher Compiler alles optimiert, dann wäre
das für mich das absolute Argument, einen derart kastrierten Compiler
gar nicht erst anzugucken.  Das ist ja wie Probefahren im Porsche mit
angezogener Handbremse ...

Dann eher noch eine Größenbeschränkung für den erzeugten Code.

Aber letztlich wurde es ja schon geschrieben: eine derartige
Demoversion sollte man nur dann benutzen, wenn man ggf. wirklich
bereit wäre, die Bezahlversion in Betracht zu ziehen.  Wenn man das
nicht mag und lieber komplett auf freie Toolchains setzt, dann
schränkt das eben einen Teil des Suchraums bei den Controllern ein,
aber das ist nicht wirklich tragisch.  Es bleiben trotzdem noch
genügend übrig. ;-)

[Peter D. (peda)]

Den PIC finde ich viel zu schwer in Assembler, da muß man oft ganz schön 
um die Ecke denken, z.B. 32Bit Addition:

; From: Regulus Berdin

        movf    twofour0,w
        addwf   prod0,f

        movf    twofour1,w
        btfsc   STATUS,c
         incfsz twofour1,w
          addwf prod1,f

        movf    twofour2,w
        btfsc   STATUS,c
         incfsz twofour2,w
          addwf prod2,f

        movf    twofour3,w
        btfsc   STATUS,c
         incfsz twofour3,w
          addwf prod3,f

Dagegen beim AVR:

  add r16, r20
  adc r17, r21
  adc r18, r22
  adc r19, r23

Assembler ist also auf dem AVR bedeutend einfacher. Und das nervige 
Paging/Banking-Geraffel fällt weg.

Wenn schon PIC, dann aber ausschließlich in C.

[Meine Fresse Deine Fresse (Gast)]

Jörg Wunsch schrieb:
> Robert V. schrieb:
>> Die XC Compiler von Microchip gibt es in einer Free-Variante ohne
>> Größenbeschränkung. Lediglich die Optimierung ist ausgeschaltet.
>
> Das würde ich dann allerdings als Spielzeug abtun.

Spielzeug ist das sicherlich keins.
Der Compiler ist auch in der Freeversion gut. Diese erzeugt lediglich 
den größten Code bei akzeptabler Geschwindigkeit, ist also auch eine der 
Einstelloptionen der Kaufversion!
Wie ein anderer Schreiber schon angemerkt hat, reicht das für 
Privatanwender immer, da die paar verbauten Controller auch mit dickem 
Speicher ausgestattet sein dürfen. Doch auch für prof. Anwendung bei 
kleinen bis mittleren Stückzahlen ist die Nutzung des Freeversion 
sinnvoll. Man kann sogar dann zu irgendeinem beliebigen Zeitpunkt die 
60Tage Test-Vollversion aktivieren und sehen, ob der Code soweit 
gedrückt werden kann, dass ein PIC mit kleinerem Speicher für das 
Projekt verwendet werden könnte.
Das ist mir allemal lieber als eine Codegrößenbeschränkung, da ich mit 
der Freeversion immer zum Ziel komme.

[W.S. (Gast)]

Peter Dannegger schrieb:
> Wenn schon PIC, dann aber ausschließlich in C.

Hihihi... deine Abneigung gegen Assembler ist inzwischen weit genug 
bekannt.

Nun ja, offenbar besteht die Welt der 8 Bit uC genau darin ständig nur 
32 Bit Variablen zu addieren... X-)

W.S.

[Frank M. (frank_m35)]

Jörg Wunsch schrieb:
> Wenn man sich mal
> so ansieht, was ein ordentlicher Compiler alles optimiert, dann wäre
> das für mich das absolute Argument, einen derart kastrierten Compiler
> gar nicht erst anzugucken.  Das ist ja wie Probefahren im Porsche mit
> angezogener Handbremse ...

du übertreibst hier. Die Optimierungen sind eingeschränkt, d.h. aber man 
hat immer noch welche, selbst in der Lite Version, welche aber zum 
Debuggen vorerst hinderlich sind, da durch Code-Zusammenfassen etc. es 
nicht mehr gut debuggbar bleibt, somit bleiben sie vorerst global 
deaktiviert.

Außerdem geht's hier um ein Hobby.

Zudem ist eine eingeschränkte Code-Größe wesentlich schlechter, niemals 
zu vergleichen mit fehlenden fortgeschrittenen! Optimierungen.

Hier empfehlen viele Assembler, ich empfehle C.
Wenn man das Bedürfnis hat spezielle Dinge zu optimieren, kann man immer 
noch Assembler einfügen. Aber die meisten Beispiele, Tutorials, 
modernere Bücher sind in C, mit gutem Grund. Und die Hobby-Projekte sind 
im Umfang meist so klein und so Zeitunkritisch, dass hier auf Assembler 
vermutlich nie zurückgegriffen werden muss.
Er wird ja kaum Zeitkritische Kostenkritische Projekte für sich daheim 
aufbauen.
Heutzutage schreibt auch niemand mehr eine normale! PC Software in 
Assembler.

[Matthias (Gast)]

Frank M. schrieb:
> Hier empfehlen viele Assembler, ich empfehle C.

Da stimme ich zu. Wer seine Applikation sinnvoll in Assembler erstellen 
kann hat eine triviale Aufgabenstellung.
Wer komplexe Software mit Assembler erstellt mäht seinen Rasen mit der 
Nagelschere. Moderne Compiler bzw. Linker erzeugen so viel besseren 
Code. Alleine Register- und Speichernutzung sinnvoll und global zu 
optimieren kann man so gut wie garnicht manuell. Von der Wartbarkeit 
sprechen wir lieber garnicht.

[Jörg W. (dl8dtl) (Moderator)]

Frank M. schrieb:
> Außerdem geht's hier um ein Hobby.

Ja, trotzdem sollte das ja auch Spaß machen.

Muss jeder selbst für sich entscheiden.  Für mich war ein Grund, dass
ich damals mit den AVRs angefangen habe, die Verfügbarkeit einer
GCC-Portierung.  Der war zwar noch lange nicht in dem Topf, wo er
heute ist (bezüglich des AVR), aber allemal besser, als jedes Bit
im Assemblercode mit der Hand umzudrehen, wie ich das beim davor
benutzten Controller tun musste.  Ja, das vorherige Projekt (in
Assembler) ist auch fertig geworden, aber mit einem vielfach höheren
Aufwand, verglichen mit den nächsten C-Projekten auf den AVRs dann.

Wenn ich mir heute ansehen, was GCC oder auch IAR so alles
optimieren, dann will ich das wirklich nicht mehr missen.  Auch
nicht im Hobbybereich.  (Und ja, man kann auch optimierten Code
debuggen.  Man muss sich halt an die Eigenheiten gewöhnen.)

W.S. schrieb:
> Nun ja, offenbar besteht die Welt der 8 Bit uC genau darin ständig nur
> 32 Bit Variablen zu addieren.

Durch die Akku-Architektur ist der (alte) PIC immer so umständlich
zu handhaben, nicht nur bei einer 32-bit-Addition.

[MCUA (Gast)]

>Den PIC finde ich viel zu schwer in Assembler...
Bsp.weise für BitTstSkipifClear / DecSkipifZero (je aus Speicher 
genommen)
braucht PIC (16,18,24) nur 1 Befehl ; AVR dagegen 3 / 4  (also 4 / 5 
Takte) brauchen).

[Peter D. (peda)]

MCUA schrieb:
>>Den PIC finde ich viel zu schwer in Assembler...
> Bsp.weise für BitTstSkipifClear / DecSkipifZero (je aus Speicher
> genommen)
> braucht PIC (16,18,24) nur 1 Befehl ; AVR dagegen 3 / 4  (also 4 / 5
> Takte) brauchen).

Mit viel schwerer meinte ich, schwer zu verstehen und nicht die Anzahl 
nötiger Befehle.
Also welche Befehle brauche ich, um etwas zu programmieren.
Und da finde ich ein "add with carry" deutlich leichter zu verstehen, 
als ein "incfsz". Bei "incfsz" kriege ich ja Knoten im Gehirn.

Weniger Befehle sind ja weniger Möglichkeiten, d.h. ich brauche mehr 
Gehirnschmalz, um diese für komplexe Aufgaben zusammen zu fügen.
Nur 35 Befehle beim PIC macht die Programmierung also nicht einfacher, 
sondern deutlich schwerer, im Vergleich zu Z80, 8051 oder AVR.

Und da ich mich zuerst mit dem 8051 verwöhnt habe, konnte es mir danach
nicht mehr gelingen, mit dem kargen PIC klar zu kommen, der war mir viel 
zu umständlich.


Ein Maler nimmt ja auch nicht nur 3 Farben, weil das reichen würde. 
Sondern er mischt sich viele verschiedene Farben zusammen, damit er 
besser malen kann.

[Fallobst (Gast)]

Matthias schrieb:
> Moderne Compiler bzw. Linker erzeugen so viel besseren
> Code.

Entweder alle, die das behaupten, sind miserable Assemblerprogrammierer 
oder glauben Compiler wären perfekt. Leider ärgere ich mich viel zu oft 
darüber, wie umständlich der Compiler manchen Code übersetzt. In 
Assembler zu programmieren ist durchaus mehr Aufwand, allerdings wird 
das Ergebnis deutlich kleiner und schneller. Es gibt genug 
Assembler-Projekte im Internet, die man in C nicht einmal ansatzweise 
implementieren könnte.

[Fallobst (Gast)]

MCUA schrieb:
> Bsp.weise für BitTstSkipifClear / DecSkipifZero (je aus Speicher
> genommen)
> braucht PIC (16,18,24) nur 1 Befehl ; AVR dagegen 3 / 4  (also 4 / 5
> Takte) brauchen).

Der AVR benötigt dafür nur 2 / 3 Befehle (3 / 4 Takte).

[Wilhelm F. (Gast)]

Aktuell bestellte ich mir gerade ein paar Winzlinge PIC12F nach, 
hauptsächlich auch fürs Steckbrett. Bisher hatte ich nur den einen aus 
dem Lieferumfang des PICkit1. Für winzige Hilfsaufgaben ist er sehr 
nützlich, und wenn es nur ein Taktgeber auf dem Steckbrett ist, an 
Stelle eines 555.

Ja, am ersten Tag Assembler bekommt man einen Kopf, das legt sich aber 
sehr schnell. Nach wie vor habe ich Spaß an PIC-Assembler. Meine 
Studienkommilitonen flüchteten damals zum großen Teil, als sie ins 
Wahlfach Mikroprozessor-Labor hinein schnupperten. Die kamen mit dem 
MPLAB und ersten Übungen nur am Simulator überhaupt nicht mehr klar, und 
es gab bei denen auch keine Aussicht auf Besserung. Nur eine Handvoll 
blieben übrig. Schon zuvor beim sehr schön überschaubaren 8051 waren 
viele ein hoffnungsloser Fall. Beim verbliebenen Rest, wo auch ich 
drunter war, waren fast alle Bastler, Hobbyisten.

[ich steh im Wald (Gast)]

90% der Antworten in diesem thread sind Experten, die es nicht verstehen 
einem Anfänger sinnvolle Tipps zu geben, sondern ihr "ich weis was" 
Wissen an den Mann zu bringen versuchen. Macht euren eigenen thread auf.

[Robert V. (Gast)]

ich steh im Wald schrieb:
> 90% der Antworten in diesem thread sind Experten, die es nicht verstehen
> einem Anfänger sinnvolle Tipps zu geben, sondern ihr "ich weis was"
> Wissen an den Mann zu bringen versuchen. Macht euren eigenen thread auf.

Vor allem hat sich hat sich Manu als TO ja auch schon längst entschieden 
und seine Gründe dargelegt:

Beitrag "Re: Atmel oder PIC"

[W.S. (Gast)]

ich steh im Wald schrieb:
> ...Experten, die es nicht verstehen
> einem Anfänger sinnvolle Tipps zu geben...

Ja. Die meisten Beiträge sind so etwas wie Grundsatz-Referate a la Erich 
Honecker. Falsch, aber in sich selbst logisch begründet.

Die einen sagen, AVR ist besser als PIC, weil sie die AVR's eben gerade 
verstanden haben und die PIC's nicht,

die nächsten sagen Jahaha, aber wenn du mal ein riesengroßes Projekt 
hast, jahaha dann wird's zu schwer in Assembler,

andere sagen Assembler ist ja SOOOOO!!! schwierig und deshalb mir ein 
Buch mit 7 Siegeln,

und der Rest sagt Ich will mich nicht mit der Hardware befassen 
sondern mich in einer möglichst maschinenunabhängigen Sprache ergehen - 
und für die Hardware erwarte ich Treiber vom Hersteller.

Das sind alles Aussagen von Leuten, die das Gesamt-Thema schlichtweg 
nicht überschauen. Kein Augenmaß erkennbar.

Leute, hört auf mit diesem Thread, es kommt ja doch bloß dasselbe dabei 
heraus wie in früheren Threads. Und für alle Neulinge bleibt nur übrig, 
sich ohne diese Weisheiten ihren eigenen Weg zu suchen.

W.S.

[Wilhelm F. (Gast)]

W.S. schrieb:

> Das sind alles Aussagen von Leuten, die das Gesamt-Thema schlichtweg
> nicht überschauen. Kein Augenmaß erkennbar.

Ja doch! Entscheide dich mal möglichst bald für irgendwas, und 
beginne es! Und wenn es ein PIC oder AVR ist. Danach kann man weiter 
sehen.

Von MIPS und Compileroptimierungen ist das noch ziemlich weit weg, das 
alles kann man später schauen, wenn einem was wirklich nicht mehr 
schnell oder optimal genug ist.

[Dennis S. (dspo)]

W.S. schrieb:
> Leute, hört auf mit diesem Thread, es kommt ja doch bloß dasselbe dabei
> heraus wie in früheren Threads. Und für alle Neulinge bleibt nur übrig,
> sich ohne diese Weisheiten ihren eigenen Weg zu suchen.
>
> W.S.

Aber woher denn. Nur muß sich der Einsteiger (mit klaren Vorstellungen 
im Hinterkopf was er eigentlich machen will) die Mühe machen und sich 
hier erst durch viele verschiedene Infos und Standpunkte wühlen. Gerade 
das Lieblingsthema dieses Forums AVR vs. PIC liefert genügend Material 
dafür.

[Anfänger (Gast)]

Hallo
Für mich sieht es so aus

8-Bit Bereich, Atmel
16-Bit Bereich, PIC
32-Bit keine Ahnung, gefällt mir nichts

PIC 8-Bit Assembler ist etwas schwieriger (weil umständlicher) und es 
führt zu voluminöseren Programmen. Aber wer es mal im Griff hat, hat 
keine Probleme damit. Atmel Assembler ist, weil einfacher, klar 
langweiliger.

[egal² (Gast)]

Anfänger schrieb:
> Gerade das Lieblingsthema dieses Forums AVR vs. PIC liefert genügend
> Material dafür.

Abwarten. Wenn Atmel nun endlich mal pleite geht und die Hälfte des 
Forums dann kollektiven Selbstmord begeht, dann wird es hier auch wieder 
ruhiger...

[Master S. (snowman)]

ich lese beiträge nicht mehr, die "Bank" oder "Bank-Switching" von PICs 
beinhalten. der verfasser solcher artikel ist 20 jahre hinterher und 
zeugt von einem niveau von pferderennen-beurteilung über wissen von 
eseln...

[Bastler² (Gast)]

Vor- und Nachteile hin- und her, ich fand das nun so interessant, dass 
ich mir doch gleich mal ein PicKit3 geordert habe und mir, zu den AVRs, 
mal noch die PICs anschaue. Nur aus Spass an der Freud ohne berufliche 
Ambitionen (dafür hab ich Entwickler, die machen ihre Sache besser als 
ich ;))

[Anfänger (Gast)]

Bastler² schrieb:
> Vor- und Nachteile hin- und her, ich fand das nun so interessant, dass
> ich mir doch gleich mal ein PicKit3 geordert habe

Geordert noch nicht, steht aber schon etwas länger auf meiner Liste. Der 
Thread hat mich darin bestätigt, insofern fand ich den schon nützlich.

[Maik W. (werner01)]

> Zyklus. Ein ueblicher 16-bitter etwa 8-12 und ein 8-bitter wie der 8051
> mindestens 45 (und das bei einem Bruchteil des Kerntaktest und im
> schlimmsten Fall 12Clocks/cycle).
  der Pic und AVR schaffen das in einem Zyclus Du 
Langsamprozessoraufzähler. Ich hab son Cortex nicht im DIL-Gehäuse 
gesehen. die kleinen 8-bitter so wie erweähnt sind auf jeden Fall 
einfacher beherschbar und wenn man will im kleineren Gehäuse verfügbar. 
wenn möglich würde ich einen kleinen einfachen 8-bitter einsetzen....PS 
ein DSPIC braucht für eine Multipli. 1 Zyclus (16*16)mul.... und 
mitlerweile sind die mit 70 mips zu haben

[(prx) A. K. (prx)]

Maik Werner schrieb:
> ein DSPIC braucht für eine Multipli. 1 Zyclus (16*16)mul.... und

Spass am Rande: Was ist bei einem 16-Bit PIC der kürzeste und schnellste 
Weg, ein Doppelregister mit 0 zu laden? Man multipliziert mit 0. Ich war 
dem im Compiler-Output begegnet und erst einmal geplättet.

[c-hater (Gast)]

MCUA schrieb:

> Bsp.weise für BitTstSkipifClear / DecSkipifZero (je aus Speicher
> genommen)
> braucht PIC (16,18,24) nur 1 Befehl ; AVR dagegen 3 / 4  (also 4 / 5
> Takte) brauchen).

Quatsch. Maximal braucht der Atmel dafür jeweils 2 Befehle und 2 bis 3 
Takte.

BitTstSkipifClear:

sbrc/sbic  ;1  2
rjmp       ;2
           ;-  -
            3  2

Für den Fall, daß der Nutzcode in einer der Verzweigungen nur eine 
Instruktion umfaßt, was relativ häufig vorkommt, dann braucht's nur 
einen Befehl und 1 bis 2 Takte.

sbrc/sbic  ;2  1
AnyInstr.  ;
           ;-  -
           ;2  1

DecSkipifZero:
dec        ;1  1
breq       ;2  1
           ;-  -
           ;3  2

Und bei der Taktezählerei darf man nie vergessen: Nur beim Atmel ist 
Takt wirklich Takt. Wenn da ein 10MHz-Quarz dranhängt, dauert ein Takt 
wirklich auch nur 100ns.

[(prx) A. K. (prx)]

Solche Erbsenzählerei, also Takte einzelner Befehle vergleichen und ob 
geteilte Takte oder nicht, ist in diesem Kontext oft ziemlich sinnarm. 
Denn in der hier betrachteten Klasse zählt meist nur, ob eine zu lösende 
Aufgabe in der erforderlichen Zeit erledigt werden kann. Und wenn es 
nicht grad um Sonderfälle wie exaktes Bitbanging oder präzise 
Interrupt-Latenzen geht, dann lässt sich die Leistung eines leidlich 
komplexen Programms meist nicht so einfach aus der Laufzeit einzelner 
völlig unterschiedlich arbeitender Befehle ableiten.

Das hängt dann auch in hohem Mass davon ab, wie das reale Programm 
aussieht. Akkumulator-Architekturen wie die 8-Bit PICs haben 
beispielsweise gewisse Probleme, Operationen mit Datentypen jenseits von 
8 Bits effizient umzusetzen, während das den AVRs weit leichter fällt. 
Inwieweit das in realen Programmen eine grosse Rolle spielt hängt aber 
stark vom Programm ab.

[HighSpeed (Gast)]

Fallobst schrieb:
> Außerdem unterliegen die 8bit PICs m.W. den Avrs, da sie den Takt nicht
> durch 4 teilen.

Na und? Dafür kann man die PICs deutlich höher takten. Während beim 
ATMEGA spätestens bei 16MHz Schluss ist, konnte man selbst die Uralt 
PIC16C5x im HS-Mode bis zu 40 Mhz Taktfrequenz betreiben. Ein 
schnelleres Quarz ist jetzt nicht unbedingt teuerer..

[(prx) A. K. (prx)]

HighSpeed schrieb:
> Ein schnelleres Quarz ist jetzt nicht unbedingt teuerer..

Schon mal versucht, einen 40MHz Grundwellenquarz aufzutreiben? Ist aber 
glücklicherweise nicht nötig.

Der PIC1650 konnte aber ohnehin nur 1MHz. Was zum umgekehrten Effekt 
führte: 1MHz Quarze waren damal viel grösser als 4MHz Quarze. ;-)

[Horstl (Gast)]

HighSpeed schrieb:
> Na und? Dafür kann man die PICs deutlich höher takten. Während beim
> ATMEGA spätestens bei 16MHz Schluss ist, konnte man selbst die Uralt
> PIC16C5x im HS-Mode bis zu 40 Mhz Taktfrequenz betreiben. Ein
> schnelleres Quarz ist jetzt nicht unbedingt teuerer..

Bist du dir beim PIC so sicher wie du beim ATMEGA bezüglich der 
Taktfrequenz bist?

[HighSpeed (Gast)]

A. K. schrieb:
> Schon mal versucht, einen 40MHz Grundwellenquarz aufzutreiben? Ist aber
> glücklicherweise nicht nötig.

Ja. Hat mich 2 Minuten gekostet.

http://www.digikey.de/product-detail/de/ECS-400-20-3X-EN-TR/XC1803TR-ND/2676633

[HighSpeed (Gast)]

Horstl schrieb:
> Bist du dir beim PIC so sicher wie du beim ATMEGA bezüglich der
> Taktfrequenz bist?

Ja!

[(prx) A. K. (prx)]

HighSpeed schrieb:
> Ja. Hat mich 2 Minuten gekostet.
>
> http://www.digikey.de/product-detail/de/ECS-400-20-3X-EN-TR/XC1803TR-ND/2676633

Eben. PIC von Reichelt aber Quarz von Digikey. Im Bastelhandel hören die 
Grundwellenquarze bei 24-25MHz auf.

[HighSpeed (Gast)]

A. K. schrieb:
> Eben. PIC von Reichelt aber Quarz von Digikey.

Wo steht denn geschrieben, dass der PIC bei Reichelt bestellt werden 
muss?

[(prx) A. K. (prx)]

HighSpeed schrieb:
> Wo steht denn geschrieben, dass der PIC bei Reichelt bestellt werden
> muss?

Gewissermassen im Titel des Threads. Denn sonst müsste man fairerweise 
die Frage auf sämtliche 8-Bitter ausdehnen, die Digikey im Programm hat. 
Und da dürfte manches zusammenkommen.

Eine Beschränkung auf AVR und PIC suggeriert den Bastelsektor. Und da 
ist Digikey der Exot.

[HighSpeed (Gast)]

A. K. schrieb:
> Gewissermassen im Titel des Threads.

"Atmel oder PIC" --> Schwachsinn!

A. K. schrieb:
> Eine Beschränkung auf AVR und PIC suggeriert den Bastelsektor. Und da
> ist Digikey der Exot.

Wie bitte? Wo lebst Du denn! Ich bestelle mitlerweile mehr bei Digigkey 
als bei Reichelt. Das geht mitlerweile so unproblemmatisch. Und genauso 
schnell wie Reichelt sind sie auch.

[HighSpeed (Gast)]

HighSpeed schrieb:
> Eine Beschränkung auf AVR und PIC suggeriert den Bastelsektor.

Das mag vielleicht für AVR gelten...

[Horstl (Gast)]

HighSpeed schrieb:
> Horstl schrieb:
>> Bist du dir beim PIC so sicher wie du beim ATMEGA bezüglich der
>> Taktfrequenz bist?
>
> Ja!

Wie kommst du da auf 16MHz?
http://www.atmel.com/images/doc2545.pdf

[HighSpeed (Gast)]

Horstl schrieb:
> Wie kommst du da auf 16MHz?
>
> http://www.atmel.com/images/doc2545.pdf
>
Na Gut. Dann haben sie es jetzt doch mal auf 20 Mhz geschafft. Dann 
halte
ich mit neueren 8-Bit PIC's dagegen (64 MHz):

http://ww1.microchip.com/downloads/en/DeviceDoc/41412F.pdf

[(prx) A. K. (prx)]

HighSpeed schrieb:
> Na Gut. Dann haben sie es jetzt doch mal auf 20 Mhz geschafft. Dann
> halte ich mit neueren 8-Bit PIC's dagegen (64 MHz):

[Popcorn-Mode ON]

Dann liegen sie also wieder gleichauf wie schon früher im Vergleich mit 
Atmel. Denn 64MHz PIC gegenüber 32MHz ATXmega ist das gleiche 2:1 
Taktverhältnis wie früher 40MHz PIC gegenüber 20MHz ATmega.

Es hat allerdings auch schon AVRs mit 48MHz CPU-Takt gegeben.

[Thomas_L (Gast)]

http://www.eevblog.com/2010/02/22/eevblog-63-microchip-pic-vs-atmel-avr/

[AVR (Gast)]

PIC macht 64MHz!
Stimmt und Microchip verschweigt nicht, daß daraus die 4 Phasen eines 
Instruktioncycles abgeleitet werden:
64 : 4 = 16   aber   20 : 1 = 20.  oder?

[Maik W. (werner01)]

A. K. schrieb:
> Maik Werner schrieb:
>> ein DSPIC braucht für eine Multipli. 1 Zyclus (16*16)mul.... und
>
> Spass am Rande: Was ist bei einem 16-Bit PIC der kürzeste und schnellste
> Weg, ein Doppelregister mit 0 zu laden? Man multipliziert mit 0. Ich war
> dem im Compiler-Output begegnet und erst einmal geplättet.

ja den Trick kenne ich auch noch nicht soo lange, habe ich beim Spannen 
eines ASM-Progs aus der micro...-BIbo gesehen....
Da dachte ich auch "Was für ein Fuchs"



mfg

[(prx) A. K. (prx)]

Maik Werner schrieb:
> Da dachte ich auch "Was für ein Fuchs"

Ich dachte eher an den Strom. Ein kombinatorischer Multiplizierer ist 
ein übles Gattergrab mit entsprechendem Stromverbrauch. Die alten 
dsPIC30 waren auch sonst Schluckspechte, die wurden bei Vollgas heiss. 
Die ganze 16-Bit PIC Architektur und ganz besonders die erste 
Implementierung als dsPIC30 wirkte nicht wirklich so, als ob da jemand 
beim Design den Stromverbrauch auf der Rechnung hatte.

[Tippgeber (Gast)]

Master Snowman schrieb:
> ich lese beiträge nicht mehr, die "Bank" oder "Bank-Switching" von PICs
>
> beinhalten. der verfasser solcher artikel ist 20 jahre hinterher und
>
> zeugt von einem niveau von pferderennen-beurteilung über wissen von
>
> eseln...

Für Leute, die mit sowas überhaupt nicht klarkommen, gibt es ja z.B. 
noch Arduino. Allerdings ist zu bezweifeln, das die damit erworbenen 
Kenntnisse wirklich so überlegen sind, wie du sie hier andeutest.

[MCUA (Gast)]

>> Bsp.weise für BitTstSkipifClear / DecSkipifZero (je aus Speicher
>> genommen) braucht PIC (16,18,24) nur 1 Befehl ;
>> AVR dagegen 3/4  (also 4/5 Takte).
>Der AVR benötigt dafür nur 2/3 Befehle (3/4 Takte).
Nö.
1. LD LSB-Adr in LSB-Indx, 2. damit Wert laden (2 Takte), 3.Skip-Bef.
(Bei DecSkipifZero kommt weiteres STore hinzu)
also sinds  3/4 Befehle mit 4/5 Takten!
    (ist bei ARM (wenn Offs>4kB) genauso)
(Annahme war schon dass MSB-Indx unverändert)

>Mit viel schwerer meinte ich, schwer zu verstehen..
Eine Schreibweise (bei der der OP-Typ direkt hintern Befehl angehängt 
wird) ist vielleicht seltsam, aber einen Knoten kriegt man deshalb 
nicht. Den könnte kriegen bei der extrem schlechten Speicher-Anbindung 
mancher CPUs (bsp. 8051, AVR).

>Und da ich mich zuerst mit dem 8051 verwöhnt habe, ...
s.o.

>... mit dem kargen PIC klar zu kommen, ...
So karg sind selbst die kleinen PICs nicht da einige Befehle mehr 
Optionen haben.

[MCUA (Gast)]

> ich lese beiträge nicht mehr, die "Bank" oder "Bank-Switching" .....
Ach Ne.
Bank-Switching ist die Schnellste Art mit grösserem Speicher umzugehen.

[(prx) A. K. (prx)]

MCUA schrieb:
> Bank-Switching ist die Schnellste Art mit grösserem Speicher umzugehen.

Und die umständlichste für Programmierer oder Compiler. Ich las mal, das 
eine Vorversion des AVR-Designs das auch enthielt, aber ein 
Compiler-Hersteller ihnen die Leviten las.

[Wilhelm F. (Gast)]

MCUA schrieb:

> Bank-Switching ist die Schnellste Art mit grösserem Speicher umzugehen.

Beim 8051 nannte man die Umschaltung der Registerbänke auch "Fast 
Context Switching", und ich finde es jedenfalls gut. Die Bänke dienen ja 
dort dazu, daß man in einem Interrupt die Register nicht retten muß, und 
nur mit zwei bits im PSW die Bank umschaltet.

Jetzt denkt man vielleicht: OK, dann hätte man doch Interrupts einfach 
einen anderen Speicherbereich zugeteilt. Aber die Registerbefehle sind 
doppelt so schnell und auch kurz im Code, gegenüber dem sonstigen RAM.

[(prx) A. K. (prx)]

Wilhelm Ferkes schrieb:
> Beim 8051 nannte man die Umschaltung der Registerbänke auch "Fast
> Context Switching", und ich finde es jedenfalls gut.

Trotz des gleichen Begriffs ist das eine gänzliche andere Baustelle. 
Hier ist die Adressierung von Code und/oder Datenspeicher mit einer aus 
2 Teilen zusammengesetzten Adresse gemeint, wobei der rechte Teil der 
Adresse aus dem Befehl und der linke Teil aus einem Bankregister kommt.

Atmel hatte das ursprünglich für Daten vor. LD/ST-Befehle, deren 
Adressteil im ersten Befehlswort Platz findet, die also nur 1 Wort lang 
sind. 64 Bytes Banks vielleicht, wie auch immer. Dummerweise muss der 
Programmierer oder Compiler entweder perfekt im Kopf haben, in welcher 
Bank das Teil grad liegt und was im Bankregister steht, oder in jedem 
Fall auf Verdacht die Bank setzen.

Nun kann man allerdings auf dem Standpunkt stehen, dass bei einer 
Load/Store Architektur wie AVR zwei 1-Wort Befehle, nämlich SetBank und 
Load(6bitAddress) weder länger noch langsamer als ein 2-Wort Befehl 
Load(16bitAddress) sein müssen. Für den Assembler-Programmierer aber 
umständlicher wirken.

Bei den PICs mit 12/14-Bit-Befehlsworten (z.B. PIC12/16) fehlt 
allerdings perfiderweise der geschlossene SetBank-Befehl, die Data-Bank 
ist in 2 einzeln zu manipulierenden Bits vergraben. Ein drittes kommt 
dann noch für die indirekte Adressierung hinzu.

Die PICs mit 16-Bit-Befehlsworten (PIC18) haben kein Code-Banking mehr, 
und im Dataspace ist das auch weitgehend behoben. Jedoch lässt sich in 
den Befehlen keine vollständige Datenadresse angeben - wie bei 8051 ja 
ebensowenig. Eine erste Version dieser Architektur verwendet dort wieder 
256 Byte Banks.

Eine compilerfreundlichere neue Version verwendet statt der gebankten 
Adressierung der Daten eine Adressierung relativ zu einem 
Stack/Frame-Pointer, wodurch diese PICs zum ersten Mal mit dem für C 
eigentlich typischen Daten-Stack gut umgehen können. Davor war es 
üblich, wie bei 8051 auch lokale Daten statisch zu adressieren, kriegte 
dafür aber Ärger und grauslichen Code wenn reentrant.

Für den Privatanwender des alten Compilers war das insofern etwas 
perfide, als dieser in der kostenlosen Version nur die alte 
PIC18-Architektur unterstützte, nicht aber die neue mit der 
Stack-Unterstützung. Wie das heute mit dem anderen Compiler ist weiss 
ich nicht.

> Die Bänke dienen ja
> dort dazu, daß man in einem Interrupt die Register nicht retten muß, und
> nur mit zwei bits im PSW die Bank umschaltet.

Solche Banks beeinflussen den Code in keiner Weise, beschleunigen nur 
die Interrupts.

[MCUA (Gast)]

LD/ST-Archi. mittels Bänken ist was Anderes als direktes Arbeiten mit 
umschaltbaren Bänken.


Wenn sich ein rel. grosser Teil vom Speicher (rsp Variablen-Adresse) so 
organisieren lässt, dass er für die einzelne BearbeitungsPhasen 
(Task-Teile, INTs, usw) jeweils rel. nah zusammen liegt (und dann 
jeweils in eine Bank rein passt) kann das extreme Vorteile bringen.
(Das sollte aber möglichst früh berücksichtigt werden, und hängt auch 
von der konkr. Appl. ab, ob es machbar ist)


>Beim 8051 nannte man die Umschaltung der Registerbänke auch "Fast
>Context Switching"...
Das bringt dem 8051 aber nichts, da er auch damit nicht über 256 Byte 
hinauskommt.

[(prx) A. K. (prx)]

Wenn man bös aufgelegt ist, dann kann man den nativen ARM (und alle 
anderen RISCs mit fixer Befehlslänge) auch als gebankte Architektur 
betrachten. Nur hat man da nicht 1 oder 2 sondern 16 Bank-Register und 
addiert die Adressen zusammen, statt sie zu ergänzen. ;-)

@MCUA: Da fällt dir doch bestimmt was dazu ein. ;-)

[Dieter W. (dds5)]

Maik Werner schrieb:
> A. K. schrieb:
>> Maik Werner schrieb:
>> ein DSPIC braucht für eine Multipli. 1 Zyclus (16*16)mul.... und
>>
>> Spass am Rande: Was ist bei einem 16-Bit PIC der kürzeste und schnellste
>> Weg, ein Doppelregister mit 0 zu laden? Man multipliziert mit 0. Ich war
>> dem im Compiler-Output begegnet und erst einmal geplättet.
>
> ja den Trick kenne ich auch noch nicht soo lange, habe ich beim Spannen
> eines ASM-Progs aus der micro...-BIbo gesehen....
> Da dachte ich auch "Was für ein Fuchs"
>
>
>
> mfg

Jup, aber dann bitteschön auch die 0 aus dem low word Register in das 
low word des RAM laden und das gleiche nochmal mit den high words.

Wehe wenn einer die beiden Nullen vertauscht!

[Wilhelm F. (Gast)]

A. K. schrieb:

> Trotz des gleichen Begriffs ist das eine gänzliche andere Baustelle.

Danke für die Klärung des Mißverständnisses.



MCUA schrieb:

>>Beim 8051 nannte man die Umschaltung der Registerbänke auch "Fast
>>Context Switching"...
> Das bringt dem 8051 aber nichts, da er auch damit nicht über 256 Byte
> hinauskommt.

Viele meiner Anwendungen brauchen noch nicht mal ein Viertel des 
internen RAMs. Und dann ist auch kein externes RAM dran, denn es ist ein 
Single-Chip-µC. Wobei man mit ein paar Byte RAM durchaus vieles machen 
kann.

[MCUA (Gast)]

>Bei den PICs mit 12/14-Bit-Befehlsworten (z.B. PIC12/16) fehlt
>allerdings perfiderweise der geschlossene SetBank-Befehl, die Data-Bank
>ist in 2 einzeln zu manipulierenden Bits vergraben.
Nö. Es gibt das BSR-Reg.

>Viele meiner Anwendungen brauchen noch nicht mal ein Viertel des
>internen RAMs.
Es ist aber nicht verkehrt eine (akzeptierbare) Möglichkeit für 
grösseren Mem zu haben, wenn mans mal braucht. Beim '251 war das mal 
besser.

[(prx) A. K. (prx)]

MCUA schrieb:
>>Bei den PICs mit 12/14-Bit-Befehlsworten (z.B. PIC12/16) fehlt
>>allerdings perfiderweise der geschlossene SetBank-Befehl, die Data-Bank
>>ist in 2 einzeln zu manipulierenden Bits vergraben.
> Nö. Es gibt das BSR-Reg.

Ich bin grad durch ein paar Datasheets von PCI16ern durch und in keinem 
davon hat der Reader ein BSR gefunden.

Gefunden hat er es in einem PIC18, aber von denen war an dieser Stelle 
ausdrücklich nicht die Rede. Und da gibts mit MOVLB auch den 
entsprechenden SetBank Befehl.

Dieses Manko bei den kleinen PICs war offenbar nicht nur mir 
aufgefallen: Der 100 MIPS Nachbau Ubicom SX hat die entsprechenden 
SetBank Befehle.

[(prx) A. K. (prx)]

Wilhelm Ferkes schrieb:
> Viele meiner Anwendungen brauchen noch nicht mal ein Viertel des
> internen RAMs.

Für genau diese Dimension war 8051/52 ja entworfen worden. 128 Bytes 
direkt adressiertes RAM für Register, Stack und Daten. Notfalls weitere 
128 indirekt adressiert für Puffer. Das war damals nicht wenig.

Hunderte KB grosse Programme mit zig KB Daten hatte Intel nicht im Auge. 
Intel hätte damals nicht in kühnsten Träumen dran gedacht, dass 51er 
derart weit über den ursprünglichen Einsatzzweck eingesetzt werden 
könnten. Sondern hat natürlich einen Nachfolger gebracht. Den 16-Bit 
Controller 8096 beispielsweise. Aber den kennt nicht mal mehr die 
Wikipedia wirklich.

[M. N. (Gast)]

A. K. schrieb:
> Sondern hat natürlich einen Nachfolger gebracht. Den 8096
> beispielsweise. Kennt den wer?

Der 80251 war das doch? Und Siemens kam mit dem 80166.
Auch alle mit dieser blöden Bankumschaltung.

[Jens (Gast)]

Ob Atmel oder PIC ist ziemlich egal. Ich kenn mich allerdings nur mit 
den PICs aus.

Vorteile der PICs:
- günstiges Debug Tool (PICkit3)
- kostenlose IDE (gibt's für Atmel aber auch)
- kostenlose C-Compiler (gibt's für Atmel aber auch)
- Moderne IDE (basiert auf Netbeans) und ist mittlerweile auch auf einem 
guten Weg ausgereift zu werden ;)
- PICs werden nicht abgekündigt
- Große Auswahl an Controllern:
-> 8-, 16- und 32-bitter
-> Signalcontroller und Standard-Mikrocontroller
-> 6-Pinner und aufwärts
-> Nochmal große Auswahl innerhalb der Familien, jenachdem was man an 
Peripherie braucht

Aber wie gesagt ist es ziemlich egal. Nimm einfach den Hersteller, der 
für deine Anwendung z.B. das passende Evalboard anbietet.

Aber bevor du eine Münze wirfst, würde ich PIC nehmen ;)

[(prx) A. K. (prx)]

M. N. schrieb:
> Der 80251 war das doch? Und Siemens kam mit dem 80166.
> Auch alle mit dieser blöden Bankumschaltung.

Die ähneln einander wie Tag und Nacht. MCS-96 war keine 
Akkumulator-Architektur, sondern blitzsauber registerorientiert mit 
teils 3-Adress-Operationen und ohne Banking.

Angesichts der "Fülle" von Information im Web ist das wohl schon wieder 
gestorben noch bevor das Web aufkam. Aber 1986 war das noch der 
Spitzenreiter in Intels Microcontroller Handbook, dem sonst nur die 48er 
und 51er Familien nebst Derivaten wie dem 8044 drin sind.

Ein 80C252 ist dort erwähnt, ist aber ein normaler 52er ohne 
nennenswerte Besonderheiten in der CPU.

[M. N. (Gast)]

A. K. schrieb:
> Aber 1986 war er aber noch
> Spitzenreiter in Intels Microcontroller Handbook.

Stimmt.
Aber auch 1995 war er noch dick beschrieben, wogegen der MCS251 auf nur 
4 Blättern erwähnt wurde.
Es war eine Zeit der 'Umstellung', die bei mir zum H8/3000 als Upgrade 
vom 68k führte.

@W.S.
Auch alles noch brav in Assembler programmiert - aber nicht mehr lange 
:-)

[Wilhelm F. (Gast)]

A. K. schrieb:

> Für genau diese Dimension war 8051/52 ja entworfen worden. 128 Bytes
> direkt adressiertes RAM für Register, Stack und Daten.

Ich entwickelte auch Anwendungen, die nur mit den 128 Byte internes RAM 
des 8051 klar kamen. Indirekt adressiertes RAM hatten diese gar nicht. 
Der Stack bewegt sich ja darinnen auch noch. Deswegen wählte ich gerne 
auch den 8052 und Derivate, die das doppelte interne RAM mit 256 Bytes 
haben. Und lege den Stack da gerne an den Anfang des indirekt 
adressierbaren RAM-Bereiches. Dann hat man den direkt adressierbaren 
Bereich auf jeden Fall ganz für sich. Das reichte immer noch für vieles.

Obwohl, es spielt nicht die Löwenrolle. Die Indirekt-Adressierung mit 
Registeradressierung arbeitet auch im direkt adressierbaren Bereich so 
effektiv, wie es nur geht.

Jetzt bestellte ich aber eine Handvoll PIC12F675. Kost nix mit 1,20 Euro 
pro Stück, ein halbes Pils in der Kneipe. Nicht, um den Hauptprozessor 
auf dem Motherboard des Notebooks zu ersetzen, sondern winzige 
Hilfsaufgaben, z.B. einen Takt auf dem Steckbrett. Einen PID-Regler 
schafft der übrigens auch, wenn man das möchte.

[Fallobst (Gast)]

Wilhelm Ferkes schrieb:
> Kost nix mit 1,20 Euro
> pro Stück

Das ist trotzdem teuer, wenn man bedenkt, dass man den 
leistungsstärkeren Attiny24 für ~50ct bekommt.

[MCUA (Gast)]

Die PIC(12/16)F1xxx (also 4 stell) sind neuer u etwas besser (ab ca 
0,50eu), haben ua BSR-Reg, 2x-16bit-FSRs, 32kByte grosse CodeBank.


Der '251 als '51-Nachfolger sollte es laut Intel ab Mitte der 90er 
geben.
  ...wurde aber nix draus.
Den '166 (nur 16-bit-PC) gabs schon viel früher.

[W.S. (Gast)]

M. N. schrieb:
> @W.S.
> Auch alles noch brav in Assembler programmiert - aber nicht mehr lange
> :-)

Ich hab den sehr bestimmten Eindruck, daß sich hier alle als Extremisten 
profilieren will - ein jeder auf seine Weise. Wenigstens einer (Peter 
Dannegger) hat mal klar gesagt, daß er die kleinen PIC's eben nicht 
wirklich versteht. Das wiederum kann ich verstehen, denn nicht jeder, 
der auf irgendeine Weise vorgespannt ist, schafft es oder will es, 
seine eingefahrenen "Denk-Gleise" zu verlassen.

Andere haben hier munter über die PIC's als Akkumulator-Architekturen 
geschrieben, was ja nun das Verkehrteste von allem ist und nur von 
Ahnungslosigkeit zeugt.

Und noch Andere räsonnierern hier endlos über Bankumschaltungen herum, 
obwohl das überhaupt kein wirklich wichtiges Thema bei den PIC's ist. 
Wer seine Programmieraufgabe einigermaßen sinnvoll plant und die 
Variablen sinnvoll in die vorhandenen Bänke verteilt, wird überhaupt 
keine Probleme mit den RAM-Bänken haben. Allerdings geht sowas eben 
wieder mal mit Assembler viel besser als mit C.

Und nochwas zu den Taktfrequnzen: Bei den kleinen PIC's sind 20, 10 und 
4 MHz ziemlich typische Werte und das aus gutem Grund: Sehr häufig 
braucht es für eine Aufgabe nicht den allerschnellsten Takt, sondern 
eher einen geringen Stromverbrauch - und da sind langsam getaktete uC 
generell im Vorteil. Abgesehen davon ist es wirklich wahr, daß man bei 
PIC's im Mittel für die gleiche Aufgabe deutlich weniger Befehle braucht 
als z.B. ein AVR - wenn man denn gut programmieren kann (was ich bei 
Leuten, die vor Assembler scheuen, bezweifele).

Also, streitet mal lustig weiter um des Kaisers Bart

W.S.

[Cyblord -. (cyblord)]

W.S. schrieb:

> Andere haben hier munter über die PIC's als Akkumulator-Architekturen
> geschrieben, was ja nun das Verkehrteste von allem ist und nur von
> Ahnungslosigkeit zeugt.
Nun das mag daher kommen dass der damals sehr verbreitete PIC16F84 eben 
jede Operation immer durch den einen Akku hat laufen lassen.

> Und noch Andere räsonnierern hier endlos über Bankumschaltungen herum,
> obwohl das überhaupt kein wirklich wichtiges Thema bei den PIC's ist.
> Wer seine Programmieraufgabe einigermaßen sinnvoll plant und die
> Variablen sinnvoll in die vorhandenen Bänke verteilt, wird überhaupt
> keine Probleme mit den RAM-Bänken haben. Allerdings geht sowas eben
> wieder mal mit Assembler viel besser als mit C.
Und das ist jetzt ein Argument pro PIC oder was? Gute Verträglichkeit 
mit C ist ja wohl wichtig.

> Sehr häufig
> braucht es für eine Aufgabe nicht den allerschnellsten Takt, sondern
> eher einen geringen Stromverbrauch -
Ah ja. Wie bei Apple. Was er nicht hat braucht er auch nicht. Soso.

> und da sind langsam getaktete uC
> generell im Vorteil.
Langsam Takten kann ich auch schnelle Controller ;-)

> Abgesehen davon ist es wirklich wahr, daß man bei
> PIC's im Mittel für die gleiche Aufgabe deutlich weniger Befehle braucht
> als z.B. ein AVR - wenn man denn gut programmieren kann (was ich bei
> Leuten, die vor Assembler scheuen, bezweifele).
Achso klar, C machen nur Deppen die kein Assembler können. Wäre dein 
Horizont so groß wie dein Ego wärst du wohl Einstein 2.0. So langts 
leider nur zum Schwätzer.

gruß cyblord

[Jörg W. (dl8dtl) (Moderator)]

cyblord ---- schrieb:
> Gute Verträglichkeit
> mit C ist ja wohl wichtig.

Aber nicht für W.S.

[M. N. (Gast)]

W.S. schrieb:
> M. N. schrieb:
>> @W.S.
>> Auch alles noch brav in Assembler programmiert - aber nicht mehr lange
>> :-)
>
> Ich hab den sehr bestimmten Eindruck, daß sich hier alle als Extremisten
> profilieren will - ein jeder auf seine Weise. Wenigstens einer (Peter
> Dannegger) hat mal klar gesagt, daß er die kleinen PIC's eben nicht
> wirklich versteht. Das wiederum kann ich verstehen, denn nicht jeder,
> der auf irgendeine Weise vorgespannt ist, schafft es oder will es,
> seine eingefahrenen "Denk-Gleise" zu verlassen.

Zurück in die späten 70er, da hatte ich mit dem IM6100 herumgespielt. 
Der ließ sich 'hervorragend' in Assembler programmieren. Lediglich der 
Kernspeicher war etwas klein geraten :-) Der Pluralbildung Deiner PICs 
zufolge, war das wohl vor Deiner Zeit.

Später dann in 68k-Assembler Crossassembler für 6502 und 8051 
geschrieben. Dank 'künstlerisch wertvoller' Programmierung waren diese 
richtig schnell.

Und heute: keinen Bock mehr auf Assembler, wenn es nicht unbedingt sein 
muß. Und ob man mit irgendeinem µC hier noch ein Bit und dort noch einen 
Taktzyklus sparen kann? Geschenkt, das interessiert mich nicht. Speicher 
ist immer mehr vorhanden, als ich brauche, und da ich mehr als einen 
Befehl/Programm verwende, interessiert mich nicht dessen 
Ausführungszeit, sondern die Ausführungszeit des gesammten Programmes.
Dank C-Programmierung kann ich mal einen H8SX, einen STM32F4 oder einen 
RX ausprobieren. Irgendeiner davon wird schon schnell genug sein.
Ein Trottel, wer das in Assembler machen möchte!

[Moby (Gast)]

M. N. schrieb:
> Dank C-Programmierung kann ich mal einen H8SX, einen STM32F4 oder einen
> RX ausprobieren. Irgendeiner davon wird schon schnell genug sein.

Dank...? Wegen der ressourcenfressenden C-Programmierung würd ich mal 
sagen! Die Effizienz von gutem Assembler ermöglicht Dir oft genug den 
Einsatz einer ganzen Controller-Leistungsklasse tiefer bzw. weiter jenes 
Controllers den Du besonders gut kennst. Mit den kleinen ASM Legosteinen 
lässt sich eine Problemstellung wesentlich flexibler angehen statt mit 
den unhandlichen C-Hohlblocksteinen zu hantieren :) Aber, wie im 
wirklichen Leben auch haben Vorteile ihren Preis, und der heißt in 
diesem Falle Entwicklungszeit. Mit der richtigen Vorbereitung, sprich 
einer Vorinvestition in ein Biotop guter Routinen kann man dem aber ganz 
gut begegnen.

Moby

[egal (Gast)]

Schade um die, die mit soviel Fachwissen ihren Standpunkt verteidigen 
und nicht flexibel sind.

[M. N. (Gast)]

Moby schrieb:
> Die Effizienz von gutem Assembler ermöglicht Dir oft genug den
> Einsatz einer ganzen Controller-Leistungsklasse tiefer bzw. weiter jenes
> Controllers den Du besonders gut kennst.

Zeig mir doch bitte ein Beispiel, wo das bei Dir so gewesen ist.
Oder zeige Dein größtes Assembler-Projekt. Es wird sich sicherlich 
jemand finden, der es Dir genauso kompakt in C schreibt.

> Mit den kleinen ASM Legosteinen
> lässt sich eine Problemstellung wesentlich flexibler angehen statt mit
> den unhandlichen C-Hohlblocksteinen zu hantieren :)

Das mit den Legosteinen erzähl mal einem Maurer Deiner Wahl. Und wenn er 
etwas verdutzt kuckt, nimm schon mal die Beine in die Hand :-)

> Mit der richtigen Vorbereitung, sprich
> einer Vorinvestition in ein Biotop guter Routinen kann man dem aber ganz
> gut begegnen.

Laß mich raten: Du programmierst in FORTH?

[Frank K. (fchk)]

Moby schrieb:

> Dank...? Wegen der ressourcenfressenden C-Programmierung würd ich mal
> sagen! Die Effizienz von gutem Assembler ermöglicht Dir oft genug den

Ich hatte mal ein AHA-Erlebnis. In einem Projekt hatte ich ein 
handcodiertes Assemblermodul eines Kollegen für eine 
Komprimierungsroutine - x86 Assembler. Ich habe dann verglichen, was das 
Visual C 9.0 aus dem äquivalenten C-Code gemacht hat, und ein paar 
Commandline Switches später war der Compileroutput besser.

> den unhandlichen C-Hohlblocksteinen zu hantieren :) Aber, wie im
> wirklichen Leben auch haben Vorteile ihren Preis, und der heißt in
> diesem Falle Entwicklungszeit.

Richtig, und in der Industrie ist die so teuer, dass das nur noch in 
wirklichen High-Volume Produkten gemacht wird, wo in Cent und 
Bruchteilen davon gerechnet wird. Wenn von einem Produkt nicht 
mindestens Millionenstückzahlen produziert werden, lohnt das nicht und 
wird dann auch nicht gemacht.

Und die Lebenswirklichkeit zeigt, dass im Durchschnitt 80% des 
Optimierungspotentials in maximal 20% des Codes stecken. Und dass 
intelligente Algorithmen viel mehr bewirken als lokale Optimierungen. 
Und dass man schon ein verdammt guter Assemblerprogrammierer sein muss, 
um einen guten C-Compiler auf lange Sicht zu schlagen - die meisten 
Hobbyfrickler überschätzen sich da maßlos.

fchk

[Ronald R. (Gast)]

Ob Assembler oder C Fan, ich kann beide Lager verstehen. In den 90ern 
war ich stolz ein Messgerät via RS232 auszulesen, die Ergebnisse 
formatiert auf einen Nadeldrucker auszugeben und das ganze in einen 
Atmel 8051 mit 2K Flash reinzupacken. Chef und Kunde waren schwer 
beeindruckt. Codiert war alles in Assembler und mehrfach handoptimiert 
um alles in den kleinen Controller zu bekommen.

Heute arbeite ich in einer Firma die Steuerungscomputer herstellt. Der 
Code ist zu 95% in C, nur ein paar Treiber sind in Assembler codiert. 
Die Codebasis wird seit ca. 8 Jahren kontinuierlich weiterentwickelt. Im 
der SW stecken ca. 100 Mannjahre und entsprechend umfangreich ist auch 
der Code. Seitdem die erste HW vor 9 Jahren geplant wurde, mussten wir 
wg. Abkündigung und aus wirtschaftlichen Gründen den Code auf 2 
verschiedene Prozessorarchitekturen portieren und innerhalb dieser 
werden auch jeweils unterschiedliche Typen eingesetzt. Ohne eine 
Hochsprache wären solche Projekt gar nicht wirtschaftlich realisierbar.

[Wilhelm F. (Gast)]

M. N. schrieb:

> Es wird sich sicherlich
> jemand finden, der es Dir genauso kompakt in C schreibt.

Das klappt fast, wenn man sich noch etwas mit Compilereinstellungen 
herum plagt. Sonst passiert es nämlich schon mal, daß er in Interrupts 
alle nötigen und auch die unnötigen Register pauschal sichert, was mir 
gerade spontan einfällt, bei geschachteteln Interrupts also schnell den 
Stack (8051) bis zum Überlauf bringt, wenn man nicht genau aufpaßt, und 
einige andere Kleinigkeiten. Bei vier Interruptschachteln ist man bei 
ungefähr 50 Bytes Stack nur für die (unnützen) Registersicherungen, und 
der kleine hat nur 128 Byte für das komplette interne RAM inklusive 
Stack.

Beim 8051, dessen Core ja heute immer noch oft eingesetzt wird, ist es 
z.B. der Timer 0, wenn man ihn für ein exaktes Timing nachladen will. 
Der hat keinen Autoreload-Mode im 16-bit-Betrieb, und ist da an dieser 
Stelle für C nicht ganz optimal. Weist man da einfach zur Nachladung den 
beiden Registern in C einen Wert zu, auch wenn dieser richtig berechnet 
ist, dann wird es falsch. Grob geschätzt was im Promillebereich des 
Codes muß man da noch in Inline-Assembler schreiben. Bei den neuesten 
Derivaten mit 8051-Core natürlich genau so, weil der ja mit dem alten 
Core kompatibel sein soll. Die Timersache schreibt man aber auch nur 
einmal, und fertig.

Beim modernen ARM z.B. in LPC2000 benötigt man hin und wieder auch noch 
ein kleines Stückchen Assembler. Nicht zum Scherz war dort auch der 
Startup-Code in Assembler geschrieben. Man mußte aber dort nur selten 
bis gar nicht dran. Es gab da noch ein paar andere Kleinigkeiten, z.B. 
einen Spurious-Interrupt-Handler, oder einen Surprise-Interrupt-Handler, 
was ich auch in Assembler machte. Auch erinnere ich mich an ein paar 
atomare Befehle zur Modeumschaltung bei speziellen Tricksereien, die C 
nicht in Assembler umsetzen konnte. Aber es war wenig, man macht das 
eben einmalig, und fertig. Die Dinge standen so auch im Tutorial von 
Trevor Martin von der Firma Rowley (Compiler), der es extra für 
LPC2000-Anwender erstellte.

Vergangenes Jahr nahm ich ein altes Eval-Board mit 80535 und nur 2k RAM 
und ROM wieder in Betrieb. Das Ding ist Retro, aus den 1980-er Jahren, 
da hatte man nicht mehr Speicher. Aber nett, es funktioniert ja noch. 
Ich überlegte wirklich zwei bis drei Tage, wie ich da mein ganzes 
Vorhaben hinein bekomme. C mußte ich letztendlich canceln, denn es hat 
doch einen höheren Codebedarf für die selbe Aufgabe. Mit Assembler kam 
ich auch bis auf wenige Bytes an den Anschlag.

Einen anderen µC, 80C517A mit Quarz 7,3728MHz, mußte ich auch in 
Assembler bis ins letzte Byte optimieren, damit er am PC und mit den 
FIFOs 115200 BAUD schafft, ohne sich zu verschlucken. Sonst wäre die 
doppelte Quarzfrequenz nötig gewesen, und damit hat das Board die 
doppelte Energieaufnahme. Es ging hier um den Programmdownload bis 32k 
Code auf das Board.

Auch Firmen wie Bosch programmierten Motorsteuergeräte noch nach dem 
Jahr 2000 rein in Assembler, wie ich von Exkursionsteilnehmern erfuhr, 
die dort waren, und es mir begeistert mit teilten. Teils Riesen-Code, wo 
Mannjahre Entwicklung drin steckten. Bei Millionenstückzahlen muß es 
sich also noch lohnen, nur ein halb so großes ROM und RAM zu gebrauchen.

Bei mir ist es nur Hobby, in einer Firma geht das alles natürlich nicht, 
und man muß mal z.B. einen STM32 und neuen Compiler bestellen.

[Peter D. (peda)]

Wilhelm Ferkes schrieb:
> bei geschachteteln Interrupts also schnell den
> Stack (8051) bis zum Überlauf bringt,

Was für nen komischen Compiler benutzt Du denn?
Der Keil C51 kann sogar über Unterfunktionen die Registerbenutzung 
optimieren.

Und wenn man weiß, welche Instruktionen das PWS nicht ändern, kann man 
oft sogar Interrupts ganz ohne PUSH/POP schreiben:

char var1, var2;

void t0_interrupt( void ) interrupt INT_T0
{
  if( --var1 == 0 ){
    P1 ^= 0x33;
    var2++;
  }
}

Das belegt nur 2 Byte Stack für die Returnadresse.

[Peter D. (peda)]

M. N. schrieb:
> Oder zeige Dein größtes Assembler-Projekt. Es wird sich sicherlich
> jemand finden, der es Dir genauso kompakt in C schreibt.

Bestimmt.
Die Compiler bleiben ja nicht stehen, sondern werden ständig 
weiterentwickelt.

Ich hab >10 Jahre Assembler programmiert. Und ich bin wahrlich nicht 
stolz darauf, erst so spät auf C umgestiegen zu sein.

Heutzutage hätte ich ein schlechtes Gewissen, Assembler zu 
programmieren. Ich würde damit Unmengen an Arbeitszeit verschwenden im 
Vergleich zu C, also würde ich ja meinen Arbeitgeber bestehlen.

[Michael S. (rbs_phoenix)]

Thomas_L schrieb:
> http://www.eevblog.com/2010/02/22/eevblog-63-micro...

Ich hab dieses Video vor ca einem oder 1,5 Jahren gesehen und mag es 
sehr^^ Ich bin in vielen Punkt auch 100% einer Meinung mit Dave (der im 
Video ;) ), unter anderem:
- Es ist für einen Anfänger ABSOLUT EGAL ob er einen AVR oder PIC nimmt.
- Wieso soll man einen 8-Bit-µC so hoch Takten, wie es geht und bis zum 
letzten bisschen ausreitzen? Wenn man denkt, es könnte eng werden, dann 
nimmt man eben nen 16bitter oder 32bitter. Wen juckt es denn?? So viel 
teurer sind die auch nich, wenn überhaupt. Ich möchte mal behaupten, 
dass dieser Fall eh für Anfänger eher nicht eintritt. Dann ist es egal, 
ob ich jetzt 50% Leistung vom AVR oder 53% vom PIC nutze (Vorrausgesetzt 
AVR sind stärker, obs so ist, who knows). Es geht ja hier um Hobby und 
nicht Industrie, wo jeder cent zählt und somit genau der passende µC 
genommen wird.

Es ist aber immer wieder schön zu sehen, dass ein Thread mit dem Betreff 
"AVR oder PIC" (o.ä.) in der Regel 150+ Beiträge hat. 80-90% vom 
AVR-/PIC-bezogenen Zeugen-Jehovas-ähnlichen Überzeugungskomitee oder von 
Leuten, wo man denkt, die bekommen vom Hersteller (Atmel oder MC) pro 
Lob einen gewissen Bonus.
Ganz abgesehen davon, das durch (veraltetes) Halbwissen vom feindlichen 
µC auch Streitstoff und/oder Verunsicherung entsteht.

Ich frag mich, ob man so ein Ausarten nicht mit einem passenden Artikel 
vorbeugen kann, also dass als erste (automatisch generierte? ;) ) 
Antwort der Artikel verlinkt wird und wenn weitere Fragen kommen, kann 
er ja noch speziellere Fragen stellen. Dafür kommt diese Frage einfach 
zu oft.
2 Artikel gibt es ja schon:
1. http://www.mikrocontroller.net/articles/Entscheidung_Mikrocontroller
2. http://www.mikrocontroller.net/articles/Mikrocontroller_Vergleich

Wobei (ohne den Autor angreifen zu wollen) der 2. Artikel m.E. schon 
etwas Überholungsbedürftig ist. Z.B.:
> PICs für 2-4V sind schlecht verfügbar.
oder
> PIC: 6-Pin/512B aufwärts. Im Prinzip großer Bereich, aber
> innerhalb der Familie deutlich verschiedene inkompatible
> Architekturen mit unterschiedlichen architekturbedingen
> Grenzen und unterschiedlichem Compiler-Support.

Dennoch besser als nichts. Im ersten Artikel hab ich gesehen, dass bei 
dem Vergleich der PIC16F84 genommen wurde. Da Dieser aber älter als alt 
ist (ich weiß aber auch nicht, wie alt der Artikel ist), sollte man da 
evtl mal Aktualisieren. Wobei solche direkten Vergleiche wieder 
Aufhänger sind, sich den "besten" raussuchen zu wollen.
Naja. Nur eine Idee.

PS: Auch wenn es vielen warscheinlich bereits total egal ist: Der TO hat 
sich schon entschieden und ließt ggf nichtmal mehr mit. Aber vielen geht 
(ging?) es ja augenscheinlich nicht darum.

PPS: Gibt es eigentlich auch eine AVR/PIC Bibel, wo man mit Handauflegen 
ewige Treue schwört? ;)

[Wilhelm F. (Gast)]

Peter Dannegger schrieb:

> Das belegt nur 2 Byte Stack für die Returnadresse.

Mit deinem Compiler vielleicht. Mit meinem nämlich so ohne weiteres 
nicht, ohne die Dinge im Manual zu erschnüffeln, und Switches zu setzen.

Ich habe SDCC. Keil ist mir zu limitiert, also fürs Hobby unbrauchbar.

[MCUA (Gast)]

>munter über die PIC's als Akkumulator-Architekturen
Die 8bitPICs haben (auch wenn sich das Ergeb ins RegFile zurückschreiben 
lässt) insbesondere keine rechnende Regs (unabh als Quell u Ziel), wie 
man das nennt ist doch wurscht. (die reine Akku-Archit. gibt es gar 
nicht)
Zudem ist ja für manche (PIC)Befehle nichtmal dieser Akku erforderlich.
(CPUs könnten ja auch direkt im Speicher rechnen, dann wäre weder Akku 
noch Register erforderlich)


>Dank C-Programmierung kann ich mal einen H8SX, einen STM32F4 oder einen
>RX ausprobieren.
Aber (sofern oder zusätzliche zeitverschlingende Treiber) ohne die 
Periferie, denn die ist anders.


>Auch Firmen wie Bosch programmierten Motorsteuergeräte noch nach dem
>Jahr 2000 rein in Assembler...
Das meiste davon ist auch Hard-Realtime, spricht daher für ASM.


Zu CPU vs CPU:
Da wo mans gut in ASM progr kann, kann man auch n benutzbaren Compliler 
dafür schreiben. Also steht die Compliler-Frage doch im Hintergrund.

[Davis (Gast)]

> - Es ist für einen Anfänger ABSOLUT EGAL ob er einen AVR oder PIC nimmt.

Das würde ich nicht unterschreiben.

Wenn dieser alberne 'down under' sagt, dass es egal ist, dann ist dies 
ein sicheres Zeichen dafür, dass es das nicht ist.

Allein die Verbreitung der AVR-Controller im professionellen - und 
Hobbybereich, die verfügbaren & günstigen (kostenlosen) Tools (Soft- & 
Hardware), das umfangreiche Hilfeangebot (mikrocontroller.net), das 
schier endlose Softwareangebot durch die Arduino.Plattform, usw, 
sprechen für sich.

[egal (Gast)]

Davis schrieb:
>> - Es ist für einen Anfänger ABSOLUT EGAL ob er einen AVR oder PIC nimmt.
> Wenn dieser alberne 'down under' sagt, dass es egal ist, dann ist dies
> ein sicheres Zeichen dafür, dass es das nicht ist.

Der sagt was er gemacht hat und was er tut ist für jedermann zu sehen. 
Er ist einzuschätzten. Du auch?

[Wilhelm F. (Gast)]

Michael Skropski schrieb:

> Es ist aber immer wieder schön zu sehen, dass ein Thread mit dem Betreff
> "AVR oder PIC" (o.ä.) in der Regel 150+ Beiträge hat. 80-90% vom
> AVR-/PIC-bezogenen Zeugen-Jehovas-ähnlichen Überzeugungskomitee oder von
> Leuten, wo man denkt, die bekommen vom Hersteller (Atmel oder MC) pro
> Lob einen gewissen Bonus.

Ach, es sind doch nicht alles Missionare hier. Den 8051 verwende ich 
noch, weil ich Boards habe, und ich kein guter Müllproduzent bin, wo 
alles wie am Fließband vorbei läuft: Von links neue Produkte, die ich 
kurz probiere, und nach rechts auf den Müll weiter laufen. Auch mal 8048 
oder 8085 als Retro, das macht doch Spaß.

Vergangene Woche bestellte ich sogar winzige PICs 12F675. Mir ist klar, 
daß das nicht der Löwe ist. Ein STM32F4DISCOVERY scheiterte daran, daß 
es bei einem Lieferanten für Privatleute mal nicht lieferbar war, und 
ich es einfach dann in dem Augenblick wieder verwarf. Das wird auch nach 
geholt, die Zeit drängt mich im Hobby aber nicht. Möglicherweise 
entdecke ich zwischenzeitlich was ganz anderes, z.B. ein Produkt von TI, 
wer weiß? Ich handhabe das genau so, wie ich im Augenblick noch nicht 
weiß, ob ich am Abend einen Döner holen gehe, oder raus essen gehe, oder 
ne Tiefkühlpizza mache oder noch koche. Irgend wo mit, was auch was 
taugt, werde ich schon satt werden.

[Michael S. (rbs_phoenix)]

Was macht denn ein Anfänger zuerst? Lauflicht, LEDs dimmen, 
7-Segmentanzeigen ansteuern, Char-LCD ansteuern, Relais schalten, 
Schrittmotor ansteuern, Töne erzeugen, Tasten abfragen und reagieren, 
Zeiten messen, Uhr programmieren, Datenübertragung via 
SPI/RS232/I²C/CAN/LIN, Spannung messen, Spannung generieren (DAC/PWM). 
Selbst kleine Server mit Ethernet, Steuerungen via USB oder ggf noch 
Touchscreen-Bedienpanels. Das alles ist mit nem 8bit PIC oder AVR 
machbar. Klar gibt es sicher auch Anfänger, die gleich 10 16bit ADCs 
haben wollen, dazu einen Server, der dazu noch DDR-RAM ansprechen können 
soll, was auch immer. Das ist von dem, was ich hier im Forum so gelesen 
habe aber eher die Ausnahme, und selbst wenn jemand als Anfänger was 
machen will, wofür ein 8bitter zu schwach ist, wird er sowieso fertig 
gemacht. Wenn irgendwas zu kritisch wird, dann geht man eben eine 
"Ebene" höher. Wenn ein PIC18 so gerade eben nicht mehr ausreicht, dann 
eben ein dsPIC/PIC24/PIC32. Das is meiner Meinung dann nicht der Grund 
zu sagen, ich geh Richtung Atmel, da ich da die 8bitter ein bisschen 
mehr ausreizen kann. Da spielen finde ich eher andere Kriterien eine 
Rolle.

Davis schrieb:
> Allein die Verbreitung der AVR-Controller im professionellen - und
> Hobbybereich, die verfügbaren & günstigen (kostenlosen) Tools (Soft- &
> Hardware), das umfangreiche Hilfeangebot (mikrocontroller.net), das
> schier endlose Softwareangebot durch die Arduino.Plattform, usw,
> sprechen für sich.

Also das kann man doch genau so für PICs schreiben. Statt "AVR" setzt 
man "PIC" ein und "Arduino" ersetzt man durch "Microchip" (Forum, ANs, 
CodeSnippets, Libs, etc).

Ich habe grade mal interesse halber geguckt:
Microchip.com sagt mir, wenn ich nach Beispielcode für PWM gucke: "Intro 
to PIC16 Lesson 8: Using the PWM to dim an LED". Eine Zip-Datei mit 
(kommentierter) C-Code-Datei und Projektdatei für MPLAB.
Arduino sagt mir: Du musst analogWrite(); benutzen
Atmel.com hat ne PDF, wo die PWM beschrieben wird, aber kein Code.

Zugegebener maßen war das eine Suche auf die Schnelle, aber ich kam da 
bei MC (schneller) ans Ziel.
Toll. Und dabei wollte ich unparteiisch bleiben.


Wilhelm Ferkes schrieb:
> Ach, es sind doch nicht alles Missionare hier. Den 8051 verwende ich
> noch, weil ich Boards habe, und ich kein guter Müllproduzent bin, wo
> alles wie am Fließband vorbei läuft

Klar, das was man noch hat, kann man grade im Hobbybereich noch gut 
verbauen. Wenn ich mir aber einen neuen µC kaufe, gucke ich aber schon 
nach neuen Vertretern. Anfänger haben aber ja kaum schon µCs zuhause 
liegen. Ansonsten: Wenn der Kumpel schon relativ viel Erfahrung mit AVR 
hat, dann nimmt man eben AVR (wegen Hilfe, vlt auch um Freunde zu 
bleiben;) ), wenn aber der Kumpel eher auf PICs ist oder man sich 
überlegt eine Ausbildung zum EGS zu machen, dann eher PICs (da diese in 
der Prüfung etc dran kommen, oder zumindest bisher kamen). Oder.. 
Einfach ausprobieren. Entweder einen Aussuchen, wenn man mit dem Klar 
kommt is alles gut, wenn nicht, kann man den anderen testen, oder 
parallel testen.

Ich hab an der Uni im moment µC-Programmierung von 8051, ASM und C. Und 
da meckern noch welche über den ASM oder die Teilung durch 4 der PICs? 
;)

PS: Eine Frage hätte ich noch zum Arduino. Ist es wirklich so, dass die 
PWM-Frequenz nicht eingestellt werden kann? Und ist es wirklich so, das 
die PWM nur 8 bit hat?

[Peter D. (peda)]

Michael Skropski schrieb:
> - Wieso soll man einen 8-Bit-µC so hoch Takten, wie es geht und bis zum
> letzten bisschen ausreitzen?

Das frage ich mich auch. Anfänger lassen ihren AVR ja immer mit den max 
16MHz laufen.
In den meisten Projekten läuft der AVR bei mir mit den 1MHz factory 
setting.
Ich laß mir lieber Reserven, falls es dochmal eng werden sollte, als von 
Anfang an mit 100% zu takten.

[Thomas_L (Gast)]

Michael Skropski schrieb:

> PS: Eine Frage hätte ich noch zum Arduino. Ist es wirklich so, dass die
> PWM-Frequenz nicht eingestellt werden kann? Und ist es wirklich so, das
> die PWM nur 8 bit hat?

Ja, ist in der Lib so eingestellt. Wenn du was anderes brauchst, musst 
du es halt "zu Fuss" machen und auf anologWrite() verzichten.

[Wilhelm F. (Gast)]

Michael Skropski schrieb:

> Klar, das was man noch hat, kann man grade im Hobbybereich noch gut
> verbauen.

Richtig. Ein fast 20 Jahre alter SAB80C517A tut hervorragende Dienste, 
alles was ich im Hobby brauche. Vor allem ist man gut in die 
Freeware-Tools wie den SDCC-Compiler eingearbeitet, und kann dann 
hervorragend damit arbeiten. Teuere Ready-To-Use-Tools wie einen 
wirklich ausgezeichnet guten Keil-Compiler hat man ja im Hobby eher 
nicht so. Da sind z.B. für die Spezialtypen Libraries aufzuarbeiten, 
auch von anderen Erstellern freie IDEs zu suchen und zu probieren, was 
aufwändig ist.

> Wenn ich mir aber einen neuen µC kaufe, gucke ich aber schon
> nach neuen Vertretern.

Wie gesagt, schaute ich ja auch nach einem Discovery-Board mit STM32. Es 
war nicht lieferbar, und ich verwarf es. Ein konkretes Bauziel habe ich 
im Augenblick nicht, und experimentiere mehr.

> Ich hab an der Uni im moment µC-Programmierung von 8051, ASM und C.

Der 8051 ist einer der schönsten, um zu lernen.

Günter Schmitt beschrieb das in seinem Buch auch schon mal über den 
8085.



Peter Dannegger schrieb:

> Das frage ich mich auch. Anfänger lassen ihren AVR ja immer mit den max
> 16MHz laufen.

Nicht nur Anfänger. Die denken alle, Zeit ist Geld, auch in der 
µC-Performance.

Ich ärgerte mich immer ein wenig darüber, daß die 8051 nicht voll 
statisch sind, und einen Mindesttakt von 3,5 MHz brauchen. Auch die 
ollen SAB80C515A und SAB80C517A. Tests mit unter 2 MHz überstanden sie, 
aber das ist eben nicht garantiert.

Im Augenblick habe ich die neu bestellten PICs 12F675, und werde damit 
auch was im Bereich Low Power und geringem Takt versuchen. Auch habe ich 
alte 8048-Derivate voll statisch und Low-Power. Die kommen auch noch 
dran. Das sind allerdings für den heutigen Geschmack riesige Klötze 
Bauteile.

[Anja (Gast)]

Wilhelm Ferkes schrieb:
> Vergangene Woche bestellte ich sogar winzige PICs 12F675. Mir ist klar,
> daß das nicht der Löwe ist.

Schöner Prozessor, den habe ich stückzahlmäßig am häufigsten eingesetzt.
Wobei ich mir für ein neues Design den 12F683 ausgesucht hätte.

Zum Thema Löwe : von den 8 Pins verwende ich
2 für die Versorgung.
2 für die RS232 Schnittstelle.
3 für die Programmierung.
3 für die Ansteuerung eines LTC2400
1 für die Temperaturmessung mittels NTC
2 für Erkennung verschiedener an die Leiterplatte anschließbarer 
Zusatzmodule
2 für den Anschluß eines externen 4:1 Multiplexers (in dem Fall muß ich 
allerdings den NTC über einen 1-poligen Schiebeschalter abschalten).

Ich wähle die Prozessoren meistens nach der benötigten Peripherie aus:

Wenn ich z.B. den ATMega168P und den PIC18F2520 vergleiche hat im 
28poligen Gehäuse der PIC 2 I/O Pins mehr. Dafür kann der AVR mehr Strom 
durch die I/O-Pins treiben da der Innenwiderstand der FETs (ca 25/23 Ohm 
anstelle 68/20 Ohm bei H/L) im High-Zustand geringfügig kleiner ist.
Bei meinem Relais-Multiplexer werkelt daher ein AVR da im worst case die 
Mindestspannung für die Relais nicht mehr garantiert werden kann.

Beim Standard 10 Bit ADC hat bei der Wandlungsrate meistens der PIC die 
Nase vorn. Der AVR schafft gerade mal 15kS/Sekunde bei voller Auflösung. 
Die Pics schaffen mindestens 40kS/Sekunde. Wobei der 18F2520 fast 
100kS/Sekunde schafft. Dafür haben AVRs häufig eine eingebaute 1.1V 
Referenz.

Gruß Anja

[Wilhelm F. (Gast)]

Anja schrieb:

> Wilhelm Ferkes schrieb:
>> Vergangene Woche bestellte ich sogar winzige PICs 12F675. Mir ist klar,
>> daß das nicht der Löwe ist.
>
> Schöner Prozessor, den habe ich stückzahlmäßig am häufigsten eingesetzt.
> Wobei ich mir für ein neues Design den 12F683 ausgesucht hätte.
>
> Zum Thema Löwe : von den 8 Pins verwende ich
> 2 für die Versorgung.
> 2 für die RS232 Schnittstelle.
> 3 für die Programmierung.
> 3 für die Ansteuerung eines LTC2400
> 1 für die Temperaturmessung mittels NTC
> 2 für Erkennung verschiedener an die Leiterplatte anschließbarer
> Zusatzmodule
> 2 für den Anschluß eines externen 4:1 Multiplexers (in dem Fall muß ich
> allerdings den NTC über einen 1-poligen Schiebeschalter abschalten).

Na bitte, einiges geht doch!

> Ich wähle die Prozessoren meistens nach der benötigten Peripherie aus:
>
> Wenn ich z.B. den ATMega168P und den PIC18F2520 vergleiche hat im
> 28poligen Gehäuse der PIC 2 I/O Pins mehr. Dafür kann der AVR mehr Strom
> durch die I/O-Pins treiben da der Innenwiderstand der FETs (ca 25/23 Ohm
> anstelle 68/20 Ohm bei H/L) im High-Zustand geringfügig kleiner ist.
> Bei meinem Relais-Multiplexer werkelt daher ein AVR da im worst case die
> Mindestspannung für die Relais nicht mehr garantiert werden kann.
>
> Beim Standard 10 Bit ADC hat bei der Wandlungsrate meistens der PIC die
> Nase vorn. Der AVR schafft gerade mal 15kS/Sekunde bei voller Auflösung.
> Die Pics schaffen mindestens 40kS/Sekunde. Wobei der 18F2520 fast
> 100kS/Sekunde schafft. Dafür haben AVRs häufig eine eingebaute 1.1V
> Referenz.
>
> Gruß Anja

In der letzten Firma war ich als Neuling nur mal behelligt, einen 
leistungsfähigeren µC zum 8051 zu suchen, zu evaluieren, und zu 
implantieren. Die kannten nur ihre 8051, sonst gar nichts. Sogar mit 
einem SiLabs-Derivat mit 100 MHz waren sie schon an der Obergrenze. Sie 
probierten erst alle 8051-er aus, bis zum Erbrechen, wahrscheinlich 
wegen der Compiler-Lizenz, und weil man Portierungen scheute. Ziel war 
ja, mehrere kopierte Funktionalitäten eines Einzelgerätes auf einer 
einzigen Platine unter zu bringen, z.B. vier oder gar acht gleiche 
Geräte, aber nur mit einem einzigen µC. Dann kam ich frisch rein, der 
mal was von ARM hörte, und dann wurde so einer evaluiert und eingesetzt. 
Der Knackpunkt war die Capture-Unit. Dafür hatte man früher unter dem 
8051 richtig große TTL-Gräber, um feine Zeitraster zu empfangen.

Der technische Fortschritt schreitet voran, aber ich bin im Augenblick 
nur aufs Hobby degradiert. Habe aber immer ein Auge auf Neues.

[A20GATE (Gast)]

Cooler Thread oder Threat ?
Ich sage nur A20 gate und Wintel und mist Amiga gibt's nicht mehr und 
Apfel ist nicht mehr PowerPC und was ist mit ATARI oder CDC oder 
COMMODORE64 :-P
Wie schon öfter erwähnt wurde ist es total egal welche 
Architektur/Hersteller man nimmt, solange man weiß was man machen will 
und wie das Umfeld aussieht.
Ob ich für einen PIC eine ISR anders in C schreiben muß als für einen 
AVR bleibt sich gleich, solange ich weiß was ICH tun will und WIE es 
geht.
Und wie auch schon erwähnt sind ARM Boards die "wesentlich" mehr können 
als die "dicksten" AVR oder PIC auch nicht teurer um sie einem 
Hobbyisten zu vergraulen.
Was man als erstes braucht für jedes Projekt ist ein Projektmanagement, 
also erstmal ein Lastenheft erstellen und wenn man alle Anforderungen 
erfaßt hat das in ein Pflichtenheft umsetzen und da kann's halt sein das 
ein ATTiny sinnvoller ist als ein STM8888888 oder halt ein DSPic5000 das 
kann was man braucht und NUR darum geht es.
Wer als Hobby Regelungen aufbauen will die z.B. eine Ampel in der 
Modelleisenbahn steuern nimmt einfach das günstigste oder das was ihm 
persönlich am besten gefällt und wenn's ein µC als HelloKitty ist dann 
nimmt "sie" halt den und freut sich über die Farbe, ein "Goth" nimmt 
halt die "normale" Version im schwarzen Gehäuse ;-)
ROFL

[Peter D. (peda)]

Wilhelm Ferkes schrieb:
> Ich ärgerte mich immer ein wenig darüber, daß die 8051 nicht voll
> statisch sind, und einen Mindesttakt von 3,5 MHz brauchen.

Das muß wohl ne Siemens Macke sein, die habe ich noch nie benutzt.

Alle anderen 8051-er (Atmel, Silabs, Maxim, Microchip, TI, NXP usw.) 
laufen ab 0Hz.

[Anja (Gast)]

Peter Dannegger schrieb:
> Alle anderen 8051-er (Atmel, Silabs, Maxim, Microchip, TI, NXP usw.)
> laufen ab 0Hz.

Aber erst die C-MOS Versionen.

Die ursprünglichen NMOS brauchten auch bei Intel einen Mindesttakt.

Gruß Anja

[Jdelphi (Gast)]

Ob PIC oder Atmel ist Geschmackssache.

Angefangen hatte ich mit MCS Familie.
Dan schnell auf den Atmel 89S8252 umgestiegen.
Zwichenzeitlich ein wenig 8085 rumgespielt zwecks ausbildung.
Nach meiner Ausbildung hatte ich mich mit den Atmels als erstes 
beschäftigt.

In der neuen Firma wurde ich dann zum PIC gezwungen. Ich hatte zu der 
Zeitviel verwirrendes über den PIC gehört. Aber das hat sich alles 
gelegt.

Nun zu der Frage Atmel oder PIC aus meiner Sicht.

Atmel:
Wenn du es einfach nur Billig haben willst und Zeit hast, nimm den 
Atmel.
Den benutzen viele Hobbybastler und man findet den einen oder anderen 
Code im Internet.

Nachteile über die ich immer wieder Stolpere:

Welchen Programmer habe ich überhaupt. USB Serielle, oder Serielle über 
USB.
Alleine beim einstellen des Billigprogrammers kann man einen Tag 
verplempern.
Wenn dan noch ein 64 Bit System hinzukommt, hat man Treiberspaß ohne 
ende.

Sind erstmals die Programmerhürden überwunden (Ich greife auf den Galep 
zurück, der Funktioniert wenigstens) . Kommen die noch verwirrenderen 
Konfigbits.

Bei den meisten Hobbyprojekten im Internet, sind diese nicht mit 
angegeben. Da heißt es dann Probieren.

Nach 2 Tagen kann man glücklich sein, wen er erste Lebenszeichen von 
sich gibt.


PIC:

Besorg dir nene PicKit3 mit Demoboard. Gab es letztens für schlappe 33 
Euro.
Lade dir MplabX mit dem XC8 herunter.
Lade dir noch die Aktuelle MAL herunter.  (Microchip Libraries for 
Applications )

Schaue dir die Quellcodes von derMAL an, die sind sehr schön 
Programmiert und übersichtlich.
Man findet immer was interessantes in der MAL und lernt auch immer dazu.

Wenn der Geldbeutel ein wenig mehr hergibt, kauf dir das Explorer16 
Board mit zusätzlicher Netzwerkkarte. Das Kostet zwar ein par Euro, ich 
habs aber bis heute nicht bereut.

Der ICD3 und das Real ICE sind nach meiner Meinung überzogen.