Wie steige ich am besten von AVR auf PIC um?

@ Thomas Roll (Gast)

>Ich habe bisher nur mit dem AVR in Bascom gearbeitet (90S1200, 90S8515,
>MEGA8).

Und warst du damit zufrieden?

> Meine Bekannter schwört total auf die PICs. Die haben eine
>höhere Taktfrequenz und lassen sich besser in Assembler programmieren.

Selten so gelacht ;-)

>Deswegen will ich jetzt auch umsteigen.

Aha, weil du immer das machst, was andere einfach so sagen?

Flameware ON.

Wenn du schon den Schritt von AVR weg wagst, überleg dir gut ob du nicht 
gleich auf ARM umsteigen willst.

Thomas Roll schrieb:
> höhere Taktfrequenz

Zumindest diese "standard" PICs haben zwar eine höhere Taktfrequenz, 
arbeiten aber an jedem Befehl mehrere Takte lang. Ein AVR braucht für 
viele Befehle nur einen Takt und ist damit im Endeffekt schneller (nur 
für AVRs gibts Soft-USB). Die neuen PICs mit 16 und 32 bit sind da eine 
andere Liga und sind intern auch anders strukturiert.

Thomas Roll schrieb:
> besser in Assembler programmieren

Das ist einfach falsch. AVRs sind vom Befehlssatz her optimiert, dass 
sich der Assembler sehr "wie C anfühlt" (wie Atmel das in 
ingenieur-sprache verpackt hat weiß ich nichtmehr). Ich kann auf jeden 
Fall sagen, dass wenn man C kann auf den AVRs sehr gut zurande kommt 
(v.a. die 32 regs helfen da sehr gut)


Wenn du unbedingt umsteigen willst kannst du das machen, aber es wird 
dir nicht viel bringen.
Solltest unbedingt irgendwohin wechseln wollen hol dir ein 
ARM-Dev-Board. NXP hat LPCXpresso und ST die STM-Boards. Da ist alles 
was der Chip macht hinter der IDE versteckt, das ist (fast) wie C auf 
nem PC und damit das proggi auch genug tempo macht haben die ARMs halt 
Clocks im mittleren zweistelligen MHz Bereich.

Thomas Roll schrieb:
> Ein bischen langsam war es schon, besonders mit flieskommazahlen.

Vermutlich hast Du nur schlecht programmiert oder für was brauchst Du 
Fließkommazahlen? Andere µC haben einen Cortex-M4F Kern - der kann 
direkt Fließkommazahlen rechnen, innerhalb weniger Taktzyklen!
Beispiel: STM32F407 - den gibt es auf dem STM32F4DISCOVERY Board für 20€

>> gleich auf ARM umsteigen willst.
>
> Lassen die sich auch gut in assembler progammieren?

Ja, natürlich, aber nicht gut! Besser eine Hochsprache wie C nehmen.

Thomas Roll schrieb:
> Deswegen will ich jetzt auch umsteigen.
Ich würde mit ein PICkit3[1]und einen PIC18 (z.B. 18F45k22) kaufen und 
ein Demo-Board wie das von Sprut[2] bauen. Auf dieser Seite gibt es auch 
PICasm Tutorials. Weil die Seite sich vor allem mit PIC16 beschäftigt, 
konntest du auch eine 16F877A verwenden. Aber bis auf ein paar 
Änderungen (rrf - rrncf/rrcf) und Zusätzliche Befehle sind die Befehle 
für PIC16 - PIC18 die gleichen.

[1] Laut einigen hier im Forum sollen die billigeren Clones aus China 
100% kompatibel sein.
[2] http://www.sprut.de/electronic/pic/test/index.htm#40pin

Udo schrieb:
> PICKit 3 zum Brennen
und zum Debuggen
>, sollte reichen um ein zu steigen.

Thomas Roll schrieb:
> Lassen die sich auch gut in assembler progammieren?

Wenns darum geht würde ich dir MaxQ2000 empfehlen. Muss man sich nicht 
so viele Befehle merken.

Thomas Roll schrieb:
> lassen sich besser in Assembler programmieren.
Bleibt auch noch die Frage, wie man "gut in ASM programmieren" 
definiert...

Thomas Roll schrieb:
> Meine Bekannter schwört total auf die PICs. Die haben eine
> höhere Taktfrequenz und lassen sich besser in Assembler programmieren.

Der wollte Dich einfach nur veräppeln.

Die PIC haben so einen derart kruden Befehlssatz, da darf man vorher 
keinen anderen Assembler gekannt haben, um die zu mögen.

Z.B. was könnte "incfsz A2,W" bedeuten ???

Peter Dannegger schrieb:
> Die PIC haben so einen derart kruden Befehlssatz, da darf man vorher
> keinen anderen Assembler gekannt haben, um die zu mögen.

SCHWACHSINN!!!


>
> Z.B. was könnte "incfsz A2,W" bedeuten ???

Das wäre zuallererst eine zwar zulässige, aber recht unübersichtliche 
und auch meist sinnfreie Anwendung des Befehls "Increment F, Store and 
Jump if Zero"
Incrementiere den Inhalt des Registers (A2), Speichere das Ergebniss im 
W(orkregister) und überspringe den nächsten Befehl wenn das Ergebniss 
Null ist)

Statt A2 sollte man einen Ausdrucksvolleren Registernamen wählen 
beispielsweise "Loopcounter" und das Ergebniss gehört natürlich zurück 
ins Urregister, sonst wird ja gar nicht runtergezählt
Also in einem Programm von mir würdest du finden:
"   incfsz Loopconter, f"

Es ist zwar "richtig" das einige der Mnemonics der PIC Assemblersprache 
auf den ersten Blick etwas krude aussehen. Aber das sind doch nur 
Vokabeln von denen es nicht einmal besonders viele gibt. (rund 30-40).
DAS ist Lernaufwand von einem Nachmittag.

VIEL VIEL VIEL Wichtiger als die paar Mnemonics ist für das verständniss 
aber die dahinterstehende Programmierphilosophie. DAS ist der 
Lernaufwand bis man das richtig versteht. Und da finde ich persöhnlich 
den PIC beispielsweise viel näher an dem 8051 als den AVR.

Und ich finde es ehrlich gesagt erschreckend das Leute von denen ich 
bisher eigendlich dachte das die dies verstanden hätten mit solch 
dämlichen platten Argumenten daher kommen.

Klar - Der Pic steht mit seiner Struktur für eine (ASM) 
Programmierphilosophie und der AVR mit seiner Struktur für eine andere. 
Beide Philosophieen hatt es schon vor den beiden µC Familien gegeben und 
es wird die auch weiterhin geben.

Und da die Menschen verschieden sind liegt dem einen die für den PIC 
nötige Denkweise näher, dem anderen die für den AVR. Das kann etwas 
damit zu tun haben welche Familie man vorher bearbeitet hat, aber auch 
jemand der vrher viel mit Z80 gearbeitet hat MUSS nicht gleich deshalb 
den AVR besser finden bloß weil der ähnlicher zu Programmieren ist. Ich 
kenne auch genügend Beispiele wo ehemalige Z80 bzw. NSC800 Programmierer 
den Umstieg auf den PIC als enorme verbesserung erlebt haben.

Wobei die Frage nach der Assemblersprache heute sowieso eher zweit- wenn 
nicht gar drittrangig sein sollte. Ich mag die AVR Assemblersyntax z.b. 
gar nicht, trotzdem ist das für mich kein Argument gegen AVR da man die 
üblicherweise heute in C Programmiert und wenn doch mal einige Zeilen 
AVR ASM nötig sind dann mache ich das halt.
Wichtigere Kriterien sind für den Hobbyisten doch die verfügbarkeit 
einer freien IDE, eines freien Compilers, der µC selbst sowie günstiger 
Entwicklugnswerkzeuge. Und da ist der Unteschied zwischen AVR und PIC 
nun einmal nicht wirklich nennenswert... (Bei Hardware liegt der PIC ja 
sogar leicht vorne)

Warum fällt es einigen bloß so schwer zu verstehen das beispielsweise 
der AVR für sie selbst und viele andere die Ideale Wahls ein kann - aber 
für genausoviele andere es dann eben die PIC Familie oder eines der ARM 
derrivate ist.
Und für jemanden mit beruflichen Hintergrund in der Richtung sollte die 
ganze Diskussion eh lächerlich anmuten da genug Hintergrundwissen da 
sein sollte um zu verstehen wie Abstraktion funktioniert und das heute 
die eine, morgen aber schon eine völlig andere Familie das Mittel der 
Wahl ist.

Gruß
Carsten

Thomas Roll schrieb:

> Ich habe bisher nur mit dem AVR gearbeitet
> Meine Bekannter schwört total auf die PICs.

Es gibt für beide Familien Vor- und Nachteile. Am Besten ist aber
immer der Prozessor, den man kennt. Ein Wechsel macht meist nur
dann Sinn, wenn man bei Industriegeräten einige Cent pro Stück
sparen kann.
Gruss
Harald

Peter Dannegger schrieb:
> Z.B. was könnte "incfsz A2,W" bedeuten ???
"Increment File Skip if Zero"
Die Zahl im Register A2 wird inkrementiert, das Ergebnis wird ins 
Work-Register geschrieben und wenn das Ergebnis null ist, wird der 
nächste Befehl überspringen.

Namen... Kennt jemand die Befehle BCWZ, SBBRRPF, TRANS und ADJBA? Nein? 
Immerhin verwendet ihr sie alle, zumindest als Anwender von Prozessoren, 
die sie verstehen.

@ Thomas Roll (Gast)

>Ein bischen langsam war es schon, besonders mit flieskommazahlen.

Was hast du denn programmiert? Welche Programmierkenntnisse hast du 
denn?
Wozu brauchst du Fließkommazahlen?
Oft reicht Festkommaarithmetik.
Fließkomma nutzt man praktisch nur in einer Hochsprache wie C oder 
BASCOM.

Thomas Roll schrieb:
> Ich habe bisher nur mit dem AVR in Bascom gearbeitet (90S1200, 90S8515,
> MEGA8). Meine Bekannter schwört total auf die PICs. Die haben eine
> höhere Taktfrequenz und lassen sich besser in Assembler programmieren.
> Deswegen will ich jetzt auch umsteigen. Mit welchem Chip fange ich am
> besten an? Ich habe hier PonyProg, ist das ok? Welche Software brauche
> ich?

Du besorgst Dir ein PICKIT3 und lädtst Dir von Mcrochip das MPLABX und 
den für die Architektur (8, 16, 32 Bit) passenden C-Compiler runter. 
Damit hast Du alles erforderliche.

Ich empfehle Dir übrigens für den Einstieg einen PIC24 oder dsPIC. Das 
ist die einfachste Architektur für den Umstieg.

Die Idioten, die über die krude Assemblerprogrammierung lästern, kennen 
nur die alten PICs. Die PIC24 haben eine komplett andere Architektur.

fchk

Frank K. schrieb:
> Die PIC24 haben eine komplett andere Architektur.

Die wohl weltweit einzige Architektur, bei der die bevorzuge Strategie, 
zwei Register zu nullen, in der in Chipfläche und Stromverbrauch 
teuersten Integer-Operation besteht, der Multiplikation. ;-)

Thomas Roll schrieb:
> Krass. Solche komplexen Befehle kann der AVR nicht.

Weil er sie nicht braucht.

Der Befehl ist ein Würg-Around, um Multibyte rechnen zu können, da die 
PIC <18 kein Add/Sub with Carry können.

Beim PIC sind deutlich mehr Tricks nötig, um sich grundlegende Befehle 
zu basteln, die auf anderen MC einfach selbstverständlich sind.

Und manche Befehle sind als Memoryzugriffe getarnt, was das Verstehen 
fremden Codes nicht gerade einfach macht, z.B. Autoincrement bei 
indirekter Adressierung.
Im C-Listing steht z.B. nur, lese von Adresse 75, was das bewirkt, mußt 
Du dann erst im Datenblatt nachlesen.

Carsten Sch. schrieb:
> Und da finde ich persöhnlich
> den PIC beispielsweise viel näher an dem 8051 als den AVR.

Ich fand den Übergang 8051 nach AVR recht einfach.
Die größte Umstellung waren nur die vielen MOV-Befehle.
Beim 8051 heißt alles einfach nur MOV, beim AVR IN,OUT,MOV,LD,ST,LDI,LPM 
usw.

> Die haben eine höhere Taktfrequenz und lassen sich besser in Assembler 
programmieren.

Die Taktfrequenz musst du durch 4 teilen um auf die "Befehlsfrequenz" zu 
kommen. Dann stellt man schnell fest, dass die eher langsamer als die 
8bit AVRs von Atmel sind.

Mir scheint dass alle die von Anfang an nur PIC10,12,16,18 hatten, damit 
zufrieden sind.
Wer allerdings jemals mit dem 6502, 680x, 808x, Z80 oder dem AVR 
programmiert hat, dem wird die CPU-Architektur der 8bit-PICs nie mehr 
gefallen. Das liegt daran, dass Microchip mit ganz primitiver CPU 
begonnen hat (kleiner  Silizumflächenbedarf->billig) um damit Logik zu 
ersetzen. PIC steht für Programmable Integrated Circuit. Die ganzen 
8bit-Nachfolger wurden dann auf dieser "Primitiv"-CPU aufgebaut.
Allerdings ist die Peripherie der PICs sicherlich genau so gut wie die 
der anderen Prozessorhersteller.
Schlaue Anwender programmieren gleich in C. Dadurch kann einem die 
Architektur der CPU fast egal sein.

Wie schon erwähnt hat die PIC24 und die PIC32 Serie eine ganz andere und 
sehr moderne Prozessor Architektur. Die programmiert man aber fast nur 
noch in C/C++.

Lehrbuch für PIC10,12,16,18
PIC-Microcontroller, 2. Auflage
Günter Schmitt
Oldenburg

Ich mutmaße jetzt mal, dass du hauptsächlich in Assembler programmierst.

Wurde schon MSP430 genannt? Muss ja nicht gleich ein ARM sein...
Vorteil: Alle Befehle sind beim MSP430 orthogonal.

Lutz Bierl* schrieb:
> Was ist Orthogonalität? Dieser Begriff aus der Computerwissenschaft
> bedeutet nichts Anderes, als dass jeder Ein-Operandenbefehl jede
> Adressierungsart verwenden kann, und, dass jeder Zwei- Operandenbefehl jede
> Kombination aus Source- und Destination-Adressierung verwenden kann.

Man muss sich keine Gedanken um spezielle Pointerregister, STORE/LOAD 
hier und IN/OUT dort und was weiß ich noch alles machen. Darum soll sich 
das Maschinchen auch so gut in ASM bedienen lassen.

mfg mf

* Das große MSP430 Microcontroller-Praxisbuch, Version 1.0.0, Lutz 
Bierl, TI Deutschland, Erding, 2003

Peter Dannegger schrieb:
> Thomas Roll schrieb:
>> Krass. Solche komplexen Befehle kann der AVR nicht.
>
> Weil er sie nicht braucht.
>
> Der Befehl ist ein Würg-Around, um Multibyte rechnen zu können, da die
> PIC <18 kein Add/Sub with Carry können.

Au MANN!
Bisher habe ich dich für durchaus kompetennt gehalten, aber so langsam 
muss ich das doch deutlich revidieren, denn was du da von dir gibst ist 
wirklich ABSOLUTER SCHWACHSINN!!!

1.) Der Befehl DECFSZ ist genauso wie sein gegenstück INCFSZ nichts 
weiter als ein bedingter Sprungbefehl dessen häufigtes Anwendung wohl in 
der Schleifensteuerung liegt...

Mit hilfe dieses Befehls lässt sich die Ablaufsteuerung einer For 
Schleife in ASM mit insgesamt vier Befehlen Realisieren. (Randbedingung 
für die drei BEfehle: max. 256 Iterationen)

Aus dem C Konstrukt:
for (unsigned char Loopcounter = 25; Loopcounter > 0; Loopcounter--)
{
[...Schleifenkörper...]
}

wird:

  movlw 25
  movwf LOOPCOUNTER
LOOPMARKE:
[...Schleifenkörper...]
  decfsz LOOPCOUNTER, f
  goto LOOPMARKE
  (Ab hier weiterer Programmablauf)

Das hat erst einmal GAR NICHTS mit Multibyteadditionen zu tun.

2. NAtürlich haben auch die kleinen PICs wie PIC12 & PIC16 einen 
Additionsbefehl und Subtraktionsbefehl mit Carry. Und zwar schon seit 
den PIC16C54 (wenn nicht sogar noch früher). Also an die AVR noch nicht 
mal zu denken war gab es diese Befehle also schon!

Ja, die haben sogar ZWEI CarryBits, das normale Carrybit was bei über- 
oder Unterlauf der Bytegrenze gesetzt wird UND ein weiteres 
Hilfscarrybit welches einen Über- oder Unterlauf der 4Bit Grenze 
(Nibble) anzeigt wenn man dies brauchen sollte!

Nur der Vollständigkeit halber: Die Befehle Lauten ADDWF und SUBWF.


> Beim PIC sind deutlich mehr Tricks nötig, um sich grundlegende Befehle
> zu basteln, die auf anderen MC einfach selbstverständlich sind.

Gebe dazu doch mal aussagekräftige Beispiele...
JA - es gibt bei allen Familien Dinge die sich leichter oder schwerer in 
ASM abbilden lassen. Aber der einzige Nachteil den ich tatsächlich bei 
den KLEINEN Pics gelten Lasse ist die historisch bedingte kleine 
Seitengröße beim Speicher und das damit verbundene Paging und Banking...
Aber auch das lernt man recht schnell - Wenn man aber schon am 
verständniss der Grundlegendsten Befehle scheitert so ist das natürlich 
wirklich ein unüberwindbares Hinderniss - das verstehe ich schon...

Davon abgesehen ahbe ich die Notwendigkeit von "Würg-Arrounds" nur dann 
wenn jemand absolut nicht versteht was er da macht und auf biegen und 
brechen seine für AVR geschriebenen Programme 1-1 auf PIC umsetzen will.

Aber noch einmal:
PIC (die kleineren) und AVR unterscheiden sich schon in den Grundzügen 
ihrer Struktur. Die PIC haben EIN Arbeitsregister wobei es Operationen 
gibt die NUR auf das Arbeitsregister zugreifen, Operationen die mit dem 
Arbeitsregister und einer BELIEBIGEN Ramzelle arbeiten und sogar 
Operationen die direkt mit einer Ramzelle arbeiten können.
Das Arbeitsregister ist immer nur ein sehr Temporärer Speicherort für 
einen Wert, maximal für die dauer zwischen zwei mit dem W register 
arbeitenden Befehle. Alle Wiederbenötigten Werte liegen immer direkt im 
normalen RAM und können direkt bei der Operation wieder im RAM abgelgt 
werden.

Beim AVR gibt es mehrere Arbeitsregister wobei der Großteil der 
Operationen aber nur mit den Arbeitsregistern untereinander möglich ist.

Beides hat vor und Nateile und für ein effektives Arbeiten muss der code 
auf beiden Systemen auch unterschiedlich Strukturiert sein.
Was einem aber mehr liegt ist individuelle Geschmackssache. Dies nicht 
zu akzeptieren ist nichts weiter als ein Paradebesispiel von 
Inkompetenz!


Gruß
Carsten

Carsten Sch. schrieb:
> 2. NAtürlich haben auch die kleinen PICs wie PIC12 & PIC16 einen
> Additionsbefehl und Subtraktionsbefehl mit Carry. Und zwar schon seit
> den PIC16C54 (wenn nicht sogar noch früher). Also an die AVR noch nicht
> mal zu denken war gab es diese Befehle also schon!

Sorry Carsten, aber da muss ich vehement widersprechen.

Die Befehle ADDWFC und SUBWFB kennen die PIC bis einschließlich 16er 
noch nicht.

Dieter Werner schrieb:
> Carsten Sch. schrieb:
>> 2. NAtürlich haben auch die kleinen PICs wie PIC12 & PIC16 einen
>> Additionsbefehl und Subtraktionsbefehl mit Carry. Und zwar schon seit
>> den PIC16C54 (wenn nicht sogar noch früher). Also an die AVR noch nicht
>> mal zu denken war gab es diese Befehle also schon!
>
> Sorry Carsten, aber da muss ich vehement widersprechen.
>
> Die Befehle ADDWFC und SUBWFB kennen die PIC bis einschließlich 16er
> noch nicht.

Die uralten PIC12/16 nicht, die neueren (z.B. 12F1xxx, 16F1xxx,.....) 
sehr wohl!

Dieter Werner schrieb:
> Carsten Sch. schrieb:
>> 2. NAtürlich haben auch die kleinen PICs wie PIC12 & PIC16 einen
>> Additionsbefehl und Subtraktionsbefehl mit Carry. Und zwar schon seit
>> den PIC16C54 (wenn nicht sogar noch früher). Also an die AVR noch nicht
>> mal zu denken war gab es diese Befehle also schon!
>
> Sorry Carsten, aber da muss ich vehement widersprechen.
>
> Die Befehle ADDWFC und SUBWFB kennen die PIC bis einschließlich 16er
> noch nicht.

Die Befehle ADDWFC und SUBWFB kennen die noch nicht, ich schrieb ja auch 
ADDWF und SUBWF. Aber OK, man könnte jetzt über die Begriffsdefinition 
streiten ob "mit Carry" meint das der Carry Wert bereits in die Rechnung 
einbezogen wird oder ob man damit meint das der Überlauf gesetzt wird.

Ändert aber nichts an der Tatsache das DECFSZ mitnichten ein 
Hilfskonstrukt für die MultibyteAddition ist. Man kann es zwar für 
solche Algorythmen einsetzen, aber das ist nur eine von vielen möglichen 
Anwendungen...

Gruß
Carsten

Frank K. schrieb:
> Die Idioten, die über die krude Assemblerprogrammierung lästern, kennen
> nur die alten PICs. Die PIC24 haben eine komplett andere Architektur.
Das kann ich bestätigen, habe gester angefangen PIC24 in ASM zu 
programmieren.

Helmut S. schrieb:
> PIC steht für Programmable Integrated Circuit.
PIC steht für "Programmable Intelligent Computer"

Carsten Sch. schrieb:
> Seitengröße beim Speicher und das damit verbundene Paging und Banking...
> Aber auch das lernt man recht schnell
Das Problem, das die Leute hier mit dem Paging/Banking haben verstehe 
ich nicht. Wenn man es einmal begriffen hat, dann ist es für mich kein 
wirkliches Problem mehr.
Der PIC18 hat das Paging nicht.

Helmut S. schrieb:
> PIC steht für Programmable Integrated Circuit.

Beim PIC1654, dem Urvater von General Instruments in den 70ern, hiess 
das jedenfalls "Programmable Intelligent Computer".

Zitat Wikipedia (http://de.wikipedia.org/wiki/PICmicro#Geschichte):
>Die Mikrocontrollerfamilie wurde von dem PIC1650 abgeleitet, der
>ursprünglich von der Mikroelektronik-Abteilung bei General Instrument (GI)
>entwickelt worden war. Die Bezeichnung PIC wird von Microchip nicht mehr
>als Abkürzung verwendet, beim PIC1650 stand es für Programmable Intelligent 
>Computer.

Max D. schrieb:
> ... (nur
> für AVRs gibts Soft-USB).

Das ist wohl die dämlichste Begründung pro AVR, die man in einer 
AVR-vs-PIC-Diskussion abgeben kann.

1. Soft-USB ist bei aller Anerkennung der Fähigkeiten des "Erfinders", 
trotz dem grenzwertiges Gefrickel, und nicht wirklich zu empfehlen.

2. Es gibt einige PIC mit Hardware-USB ab 18F aufwärts.


;-)

Michael L. schrieb:
> 2. Es gibt einige PIC mit Hardware-USB ab 18F aufwärts.
Es gibt auch neue 16F mit USB

Wie viele MIPS hat so ein 8bit AVR?

Und noch etwas zum Thema:
Hier gibt es ein Tutorial für PICasm: 
http://www.rn-wissen.de/index.php/PIC_Assembler


W.S. schrieb:
> Also: Die AVR's sind typische Load-Modify-Store-Maschinen. Um ein Byte
> im RAM zu ändern, muß man es erst in ein Arbeitsregister laden und nach
> Modifikation zurückspeichern.
Das wirkt für mich als PIC Programmierer ein bisschen umständlich.

W.S. schrieb:
> Dadurch brauchen die PIC's im Durchschnitt (bei
> vernünftiger Assemblerprogrammierung) weniger Maschinenbefehle als die
> AVR's. Ja, ich weiß, das gilt NICHT für ALLE Fälle.

Der Schlüssel zu Load/Store-Architekturen ist die effektive Nutzung von 
Registern. Deshalb ist der Begriff Load-Modify-Store auch etwas 
irreführend, weil das Ziel gerade darin besteht, genau diese Sequenz zu 
vermeiden.

Dazu Takte zu vergleichen ist Unfug. Den PICs rundum ihren Faktor 4 
anzulasten bringt nichts, weil in diesen 4 Takten manchmal mehr Arbeit 
geschieht als in einem AVR-Takt. Seltsamerweise zählt von den 
Taktvergleichern kaum jemand die Anzahl Befehle, die für den Job 
benötigt werden. Was so und mal so ausfallen kann (16/32-Bit Rechnung 
macht bei AVR mehr Spass).

> mit ihrer altbackenen Load-Modify-Store-Architektur

Die 8-Bit PIC Architektur, d.h. die Variante mit 12 Bit Befehlswort, 
entstand als PIC1650 Familie Mitte der 70er (Datasheet gibts). RISCs der 
Arbeisweise wie AVR entstanden (32-bittig) erst Anfang der 80er, 
jedenfalls öffentlich. Also nach Jahren gerechnet sind die PICs die 
älteren. ;-)

Architekturen mit sparsamem Prozessorkontext, meist auf Basis eines oder 
weniger Akkumulatoren, entstanden in einer Zeit, als Register aus Röhren 
oder Einzeltransistoren viel grösser und teuerer als Kernspeicher waren. 
Später bei Mikroprozessoren wars nicht so krass, aber ähnlich. Ein 
billiger 6502 hatte kaum was an Bord.

Seit interne Register bezahlbar sind, neigt man dazu, ihnen der Vorrang 
vor speicherorientierter Arbeitsweise einzuräumen. Das muss bei 
Controllern I/O kein Vorteil sein, so lange jener Code-Anteil, der 
direkt mit I/O-Modulen zu tun hat, im Vordergrund steht.

Je mehr Code man aber hat, desto eher verwendet man Compiler und desto 
näher kommt man Codestrukturen, die nur in sehr geringem Anteil I/O 
ansprechen. Dafür aber dank guter Compiler ganz gut mit Registern 
umgehen können, und auf Adressregister bezogene Speicheradressierungen 
statt statischer Adressierung bevorzugen.

Michael L. schrieb:
> Max D. schrieb:
>> ... (nur
>> für AVRs gibts Soft-USB).
>
> Das ist wohl die dämlichste Begründung pro AVR, die man in einer
> AVR-vs-PIC-Diskussion abgeben kann.

Ich gehe eher davon aus, dass Max etwas anderes meint.
Nur mir schnellen kurzen Befehlen kann man Soft-USB hinbekommen.
PIC können halt keinen Soft-USB.

> 2. Es gibt einige PIC mit Hardware-USB ab 18F aufwärts.
Es gibt auch einige AVR mit Hardware-USB ab 8 aufwärts.

W.S. schrieb:
> Wieder einer von der oberschlauen Sorte, der wieder mal falsch liegt.

Dann bin ich offenbar dem gleichen Irrtum erlegen, wie der Hersteller 
General Instruments. Der hat das nämlich exakt so ins Datasheet des 
PIC1650 von 1977 gedruckt (nicht das PIC1654, wie ich oben schrieb). 
Oder hatte er das zu dem Zeitpunkt bereits umbenannt?

http://www3.telus.net/danpeirce/robot/pic16xx.pdf

Max H. schrieb:
> Wie viele MIPS hat so ein 8bit AVR?

War für MIPS? NOP-MIPS? VAX-MIPS? Dhrystone-MIPS?

A. K. schrieb:
> War für MIPS? NOP-MIPS? VAX-MIPS? Dhrystone-MIPS?
Das sagt mit jetzt nichts... Aber da wie ich oben gelesen habe einen 
Befehl einen Taktzyklus braucht:
Mit wie vielen MHz läuft so ein 8bit ARV?

Max H. schrieb:
> Mit wie vielen MHz läuft so ein 8bit ARV?

Die Tinys und Megas mit maximal 20MHz. Die Xmegas habe ich nicht parat. 
Ob das nun schneller oder langsamer als ein 40MHz PIC18 ist, das hängt 
stark von der Aufgabe und der Art der Programmierung ab.

> Ob das nun schneller oder langsamer als ein 40MHz PIC18 ist, das hängt
PIC18 gehen bis max. 64MHz --> 16MIPS

Falk Brunner schrieb:
> @ Thomas Roll (Gast)
>
>>Ich habe bisher nur mit dem AVR in Bascom gearbeitet (90S1200, 90S8515,
>>MEGA8).
>
> Und warst du damit zufrieden?
>
>> Meine Bekannter schwört total auf die PICs. Die haben eine
>>höhere Taktfrequenz und lassen sich besser in Assembler programmieren.
>
> Selten so gelacht ;-)
>
>>Deswegen will ich jetzt auch umsteigen.
>
> Aha, weil du immer das machst, was andere einfach so sagen?
>
> Flameware ON.

Na ja, Falk, dann schau dir mal EEVblog an, was Dave so über AVR und PIC 
so sagt.

Aber das ist nur eine neutrale Stellungnahme, ich möchte auch keinen 
PIC.

Bastler schrieb:
> Nur warum man das alte Zeug als "genial simple" verherrlicht, verstehe
> ich nicht.

Zum Begriff "Microcode" gibts zwei recht verschiedene Bedeutungen:

(1) Wie Du schreibst kann das einen Teil der Mikroarchitektur 
darstellen, also der Implementierung von Prozessoren. Das ist die 
gängige Variante.

(2) Er kann aber verallgemeinert auch für Firmware stehen. Vom 
Startup-Code eines Rechners (BIOS/UEFI) über den Code im µC einer 
Festplatte bis zum Code auf einer PCI-Karte. Diese Bedeutung ist typisch 
für die IBM Welt, die seit jeher etwas anders gewickelte Bezeichnungen 
pflegt. Der Inhalt vom Controller-Flash ist für IBM immer Microcode, 
egal wie der µC intern arbeitet.

Der Wikipedia-Text passt ziemlich gut zu (2).

K. J. schrieb:
> Hm PIC & AVR schenken sich beide nichts der Pic hat zwar Fsoc/4 aber
> braucht weniger takte pro befehlt
Ich weiß nicht wie es beim AVR aussieht (würde es aber gerne wissen) 
aber beim PIC sind alle Befehle, außer Sprungbefehle "single cycle", 
inkl. der 8x8 unsigned Multiplikation beim PIC18.

Max H. schrieb:
> Michael L. schrieb:
>> 2. Es gibt einige PIC mit Hardware-USB ab 18F aufwärts.
> Es gibt auch neue 16F mit USB

Richtig, die 18F waren gewohnheitsmäßig hingeschrieben.

> Wie viele MIPS hat so ein 8bit AVR?

Kann ich dir leider nicht sagen. Heutzutage wird doch alles in 
Fußballfeldern, Jumbojets oder ähnlichem berechnet. ;-)

http://www.ecrostech.com/Other/Resources/Dhrystone.htm
https://en.wikipedia.org/wiki/Instructions_per_second

Christian H. schrieb:

> Nur mir schnellen kurzen Befehlen kann man Soft-USB hinbekommen.
> PIC können halt keinen Soft-USB.

Wenn du das so genau weißt, rechne doch mal vor ...

Ich denke eher, dass sich keiner die Mühe gemacht hat, weil USB bei PICs 
schon ewig verfügbar ist.

;-)

Bastler schrieb:
> Und weiter in Wkipedia:
> "Als Befehlsformat kam ein simpler Mikrocode zum Einsatz, der in einem
> ROM abgelegt war."
> Für alle, die nicht wissen, was Microcode ist: Das bringt man Hardware
> dazu eine bestimmte abstrakte Maschine für den Assembler-Programmieren
> zu simulieren. Damit sorgt man bei Mainframes seit 45 Jahren dafür, daß
> die auch heute noch die Assembler-Befehle aus der Anfangszeit verstehen.
> Ob ein Rechenwerk seriel Bits addieren muß, oder das per Gattergrab
> parallel, interessiert den ASM-Programmieren dann nicht.
> Und genau das schreibt man bei den PICs <24. Weil das ganze so "viel
> besser" war, als der AVR-Befehlssatz (der zwar neue Befehle dazubekam,
> aber nie geändert wurde), hat man sie ab 24er die gute alte PDP11
> Architektur übernommen (wie auch MSP430).
> Nur warum man das alte Zeug als "genial simple" verherrlicht, verstehe
> ich nicht.

Praktisch hat jeder Micrcontroller und Prozessor, für die interne 
Ablaufsteuerung einen Microcode denn irgenwie müssen ja die 
Assemblerbefehle auf die Hardware (Register, Accu, Multiplexer, 
Befehlszähler usw.) abgebildet werden, denn wer soll sonst den nächsten 
Befehl aus dem Befehlsspeicher holen. Bei manchen ist der Microcode als 
Maske festverdrahtet oder wie bei Intel kann der auch geladen werden.

Bei meinen ersten Rechner aus TTL Bausteinen mit dem 74181 war der 
Microcode mit Dioden auf Lochrasterplatten verdrahtet und er kannte 
dadurch sogar einen MULT Befehl.

Und noch was zum Thema ..

Ich programmiere in C++ bzw C und von daher habe ich keine Probleme mit 
dem Wechsel zu irgendeinem neue MC. Mit Assembler legst du dich immer 
wieder fest. Und bei den 16Bit PICs gibt es ein paar Sachen, da kann 
Atmel nur davon träumen;)

Hans-Georg Lehnard schrieb:
> Praktisch hat jeder Micrcontroller und Prozessor, für die interne
> Ablaufsteuerung einen Microcode

AVR, ARM, PIC32 tun dies nicht. Generell kommen alle RISC ohne aus.

Bei x86 kommen die aktuellen Implementierungen in >90% der ausgeführten 
Befehle ebenfalls ohne Ablaufsteuerung per Microcode aus.

> denn irgenwie müssen ja die
> Assemblerbefehle auf die Hardware (Register, Accu, Multiplexer,
> Befehlszähler usw.) abgebildet werden,

Das muss aber nicht in Form von Microcode stattfinden.

> Maske festverdrahtet oder wie bei Intel kann der auch geladen werden.

Es kann zusätzlicher Microcode geladen werden, um Probleme zu patchen.

Norbert M. schrieb:
> Nein, aber erzähl's uns.

BCWZ    = JCXZ
SBBRRPF = FSUBirgendwas
TRANS   = XLAT
ADJBA   = DAA

Zu finden in der Doku der NEC V20 Familie x86 kompatibler Prozessoren. 
Da blieb kein Stein auf dem anderen, was die Namen angeht. Den 
Programmen wars egal, den Programmierern auch.

PS: Zilog hatte Intels 8080 Befehle beim Z80 ja auch systematisch 
umbenannt. Nur erinnert sich da kaum noch jemand an Intels Version.

A. K. schrieb:
>
> AVR, ARM, PIC32 tun dies nicht. Generell kommen alle RISC ohne aus.
>

Das ist Geschmacksache, wo man die Grenzen zieht ...

oder wie man es nennt

Hans-Georg Lehnard schrieb:
> Das ist Geschmacksache, wo man die Grenzen zieht ...

Ablaufsteuerung per Microcode ist ein ziemlich klar definiertes 
Konzept bei Rechnerarchitekturen. Und nach dieser landläufigen 
Definition ist es bei den RISCs nicht Geschmacksache, sondern eindeutig.

IBM erste Power-Generationen hatten noch Microcode, weils ein paar für 
RISC untypisch komplexe Befehle gab. Die flogen aber mit PowerPC raus.

Komplizierter ist der Fall bei x86. Denn kommen zwar die meisten Befehle 
ohne Microcode-ROM aus. Aber es entstehen auch bei Befehlen, die nicht 
per Microcode-ROM decodiert werden, interne Microbefehle 
(macro/microops). Ein Microcode Sequencing findet da aber nicht statt, 
weshalb das auch niemand als Microcoding bezeichnet.

Natürlich verwenden alle Prozessoren irgendeine Form von 
Ablaufsteuerung. Aber eben nicht notwendigerweise per Microcode.

greg schrieb:
> Load-Store-Architekturen sind altbacken?

Ich frag mich ausserdem, was er von einer von der Arbeitsweise her 
ziemlich an RISCs erinnernden Architektur hält, die im Kern der Sache 
weder Load- noch Store-Befehle hatte. Also eine Load-Store-Architektur 
ohne Load und Store. Aber die ist immerhin älter als PIC, dafür wars für 
lange Zeit die schnellste überhaupt. ;-)

Hi,

Ulrich schrieb:
> Bei den AVRs kommen etwa 80% der Befehle mit 1 Zyklus aus. Ausnahmen
> sind z.B. Sprünge, und direkte Zugriff auf das RAM (ohne Zeiger),
> Multiplikation. Gerade so etwas wie Arithmetik geht mit 1 Zyklus
> Befehlen und auch 16 Bit / 32 Bit Zahlen sind nicht so umständlich, weil
> man halt genug Register hat und nicht mit allem durch den Akkumulator
> muss. Das load/store aus dem RAM braucht man in zeitkritischen Schleifen
> eher selten. Insgesamt nimmt sich die Zahl der Befehle für eine Aufgabe
> nicht viel - es hängt halt von der Aufgabe ab. Es braucht aber schon
> etwas Umstellung von einer CPU zur anderen.

Dem kann ich soweit erst einmal zustimmen...
Wobei du genau den Punkt hervorgehoben hast wo der AVR den PIC16 
wirklich überlegen ist. Die Arithmetik mit "großen" Zahlen.
Da können die kleinen PICs ihren Ursprung als universelle 
Interfacebausteine leider nicht ganz verbergen. Im tiefsten Inneren 
ihres Herzens sind die kleinen halt in erster Linie noch Bausteine für 
universelle Steuerzwecke und keine Rechenmonster.
Für Rechenintensive aufgaben holen die dann ihre großen Brüder ;-)

> Von daher kann man schon sagen, das ein AVR mit 20 MHz etwa doppelt so
> schnell ist wie ein PIC16 mit 40 MHz - vielleicht etwas weniger beim
> PIC18.
Dem würde ich wieder nicht so zustimmen. Denn es hängt mitnichten "nur 
ein wenig" von der Aufgabe ab. Die Aufgabe ist sogar ein entscheidendes 
Kriterium bei der Frage nach der Geschwindigkeit. Bei Rechenintensiven 
Aufgaben sind die AVR den älteren 16er PICs ganz klar überlegen, 
meinetwegen bis zu faktor zwei und mehr im Extremfall.

Bei Steueraufgaben sieht es wieder ganz anders aus. Und wenn man dann 
die Peripherieoptionen noch mit Einbezieht wandelt sich das Bild noch 
einmal.

> Einen einigermaßen neutralen (von einem 3. Hersteller) Vergleich findet
> man z.B. hier :
> http://www.maximintegrated.com/app-notes/index.mvp/id/3221

Also Neutral ist der Vergleich ganz und gar nicht!
Hier hat maxim sehr fein nur solche Aufgaben als Beispiel herausgesucht 
wo es um die verarbeitung von 16Bit und 32Bit Zahlen geht. Da genau das 
wunderbar zu ihrem angepriesenen Produkt passt.
Und als PIC Referenz haben die einen "damals" schon alten PIC16C 
genommen der genau da seine Schwäche hat weil ursprünglich mit anderer 
Intention entwickelt. (siehe Oben)
Der AVR schneidet besser ab weil es -wie ja oben schon geschrieben- in 
diesem Bereich tatsächlich den 16er Pic überlegen ist.
Natürlich hätte Maxim auch die für diese Zwecke gedachten PIC verwenden 
können und nicht genau die Serie deren Stärke in der Peripherie und beim 
Stromverbrauch, aber nicht bei HighEnd Rechenaufgaben liegt. Aber dann 
würden die eigenen µC ja nicht mehr "so gut" aussehen...

Mit der Wahl der Aufgaben kann man verdammt viel beeinflussen. Aber 
andererseits bekommt man nur durch vergleich von Zeiten für 
Referenzaufgaben überhaut ein vergleichbares Bild, denn weder die Zahl 
der Takte pro Befehl noch irgendwelche die der Oszillatortakte pro 
Befehlstakt alleine ist ausreichend.
Was bringt es wenn man weiß das µC A bei 10Mhz Oszialltorfrequenz im 
Schnitt 9 Millionen Befehle/sekunde ausführt während µC B nur 
2,2Millionen Befehle pro Sekunde schafft - Ohne das man berücksichtigt 
wieviele Befehle überhaupt für eine Aufgabe gebraucht werden. Wenn µC B 
mit 20 Befehlen auskommt wo µC A 80 benötigt ist trotzdem µC B 
schneller.

Oder um mal ein Beispiel für solch eine -zu werbezwecken Optimierte 
Funktion- zu bringen:

Die Aufgabe soll sein die Konstante "250" aus dem Programmspeicher zu 
holen und am Port B von 250 ausgehend bis auf 1 runterzuzählen.
Annahme: Der µC ist fertig konfiguriert

Beim ersten Anschauen erscheint das wie eine "neutrale" Aufgabe, für 
jemanden der sich aber etwas näher damit beschäftigt hat wird schnell 
klar welche Intention hinter genau dieser Aufgabe steht.

Beim PIC wäre das im übrigen folgender Code:
  movlw 250
  movwf PORTB
LOOPCOUNTER:
  decfsz PORTB, f
  goto LOOPCOUNTER
  (...Weiteres Programm...)

Wie sähe der entsprechende Code auf einem AVR aus?

> Für die aller meisten Fälle ist die Geschwindigkeit aber auch recht
> nebensächlich. Der µC wird auch nur eher selten mit dem maximalen Takt
> genutzt.
Da stimme ich wieder zu.
Für Fälle wo es dann doch um die Maximale Geschwindigkeit geht, 
zumindest wenn es um mehr als ein paar Befehle in der Interruptroutine 
geht, greift man üblicherweise sowieso weder zu einem AVR noch zu einem 
PIC16...

Gruß
Carsten

Frank K. schrieb:
> Thomas Roll schrieb:
>> Ich habe bisher nur mit dem AVR in Bascom gearbeitet (90S1200, 90S8515,
>> MEGA8). Meine Bekannter schwört total auf die PICs. Die haben eine
>> höhere Taktfrequenz und lassen sich besser in Assembler programmieren.
>> Deswegen will ich jetzt auch umsteigen. Mit welchem Chip fange ich am
>> besten an? Ich habe hier PonyProg, ist das ok? Welche Software brauche
>> ich?
>
> Du besorgst Dir ein PICKIT3 und lädtst Dir von Mcrochip das MPLABX und
> den für die Architektur (8, 16, 32 Bit) passenden C-Compiler runter.
> Damit hast Du alles erforderliche.
>
> Ich empfehle Dir übrigens für den Einstieg einen PIC24 oder dsPIC. Das
> ist die einfachste Architektur für den Umstieg.
>
> Die Idioten, die über die krude Assemblerprogrammierung lästern, kennen
> nur die alten PICs. Die PIC24 haben eine komplett andere Architektur.
>
> fchk

Hatte mir das gerade mal runter geladen und die IDE macht einen guten 
Eindruck. Da gibt es ja wohl einige PIC's die in C zu programmieren 
sind. Damit dürfte das ja nun auch nicht so ein Problem sein.
Die Unterstützung auf auf deren HP ist auch toll, viele Videos.
Das PIC Kit finde ich auch nicht übel.
Denke es ist einfach das womit man angefangen hat. Das geht einem leicht 
von der Hand und dann mag man das sicher mehr als andere Sachen.

Einen Vorteil des PICs sehe ich im PICkit. Man bekommt für 35€ (aus 
China) das originale PICkit 3 und hat damit einen HV-Programmer der 
alle(?) PICs programmieren kann, verfusen ausgeschlossen.

Traumhaft.

Wenn ich es nicht gerade gesehen (gelesen) hätte, dann würde ich nicht 
glauben wie viele Regulars (und Mods) auf einen derart offensichtlichen 
T.Roll hereinfallen. Und dabei ist noch nicht mal Februar. Was mag da 
erst Anfang April abgehen!?


XL

Axel Schwenke schrieb:
> Wenn ich es nicht gerade gesehen (gelesen) hätte, dann würde ich nicht
> glauben wie viele Regulars (und Mods) auf einen derart offensichtlichen
> T.Roll hereinfallen.

Mit diesem Thema ist es wie mit den Dorf-Prügeleien bei Asterix. Das 
gehört einfach zur Kultur, der Anlass ist unwichtig.

@Axel Schwenke
Ich glaube, jeder wusste von Anfang an, dass es ein Troll war. Aber die 
Thematik hat sich in eine interassante Richtung entwickelt. Zumindest 
hat es mir Spass gemacht, all die verschiedenen Standpunkte zu lesen. 
Und bei einem und anderen Beitrag habe ich auch noch was gelernt.

Summa summarum: Die Absicht des Trolls ging in die Hose.

Mehmet Kendi schrieb:

> Summa summarum: Die Absicht des Trolls ging in die Hose.

Jau, war eine interessante Diskussion und so ein PICkit werde ich mir 
auch mal zulegen (irgendwann mal) und auch mal die PIC's anschauen.

Ulrich schrieb:
> Beim AVR wäre der Code für das komische runter zählen etwa so:
>
>       LDI  R20,250
> loop: OUT PORTB, R20
>       DEC R20               oder SUBI R20,1
>       BRNE loop
>       OUT PORTB, R20
>

Da kann man aber noch einen Befehle wegoptimieren.

Moin zusammen.

Dieser Thread hat sich wirklich in eine informative und schoene Richtung 
entwickelt.
Ich habe erst vor etwa wenigen Monaten angefangen mich mit 
Microcontrollern auseinander zu setzen.
Das Ziel meines Projektes war urspruenglich nur die Ladedruckregelung 
eines VTG-Turboladers (VTG = Variable Turbinen Geometrie) mit 
elektrischen Stellmotor. Dazu wollte ich nur den Ladedruck und die 
Abgastemperatur vor der Turbine messen. Aus diesen Ausgangswerten wird 
dann das PWM-Signal fuer den Stellmotor generiert. Eventuell soll dann 
spaeter noch ein LC-Display angesteuert werden, nur das ist eher eine 
sekundaere Forderung.
Die Hardwareanforderungen waren soweit also schon mal klar.

Im Assembler habe ich das letzte Mal um 1993 ein GUI-Programm unter RISC 
OS 3.0 auf dem ARM-2 programmiert. Da ich von einem Freund, der sehr 
viel Microcontrolerentwicklung macht, mal gezeigt bekommen habe, wie gut 
aktuelle C/C++ Compiler optimieren, wollte ich nicht unbedingt wieder in 
Assembler programmieren. Lieber einen etwas schnelleren Microcontroller, 
der eventuell schlechteren Code immer noch schnell genug verarbeiten 
kann
Mit diesem Wissen stand ich nun vor der Wahl des Microcontrollers.

Unter Abwaegung der obigen Forderungen habe ich mich dann nicht fuer 
einen einzelnen Microcontroller, sondern fuer ein komplettes 
Entwicklungsboard, einen Arduino MEGA 2560 entschieden. Der hat sogar 
programmierbare PWM-Ausgaenge, so dass ich es mit dem PWM-Ausgangssignal 
sehr einfach haben werde.

Auch gibt es eine einfach zu bedienende Entwicklungsumgebung in C++ mit 
vielen Libraries fuer alle moeglichen Standardaufgaben. Damit ist der 
Weg fuer eine schnelle Entwicklung schon mal sehr gut geebnet.

Naa, jaaa... so weit so gut...
Nach naeherem Beschaeftigen mit der Materie stellte sich schnell heraus, 
dass nur Ladedruck und Abgastemperatur fuer die gewuenschte 
Regelqualitaet nicht ausreichen.
Es werden noch Motordrehzahl und Ladelufttemperatur nach dem 
Ladeluftkuehler gebraucht.
Auch werden die Regelparameter fuer eine hohe Regelguete dann am besten 
auch noch in einem Kennfeld abgelegt.

Es war also ganz gut, nicht mit dem kleinsten Arduino anzufangen.

Jetzt fehlten eigentlich nur noch die Aufnahme und Auswertung der 
Signale vom Kuehlwassertemperatursensor, vom Nadelhubgeber (das ist der 
Sensor fuer den Einspritzfoerderbeginn), dem Positionssensor vom 
Mengenstellwerk, einem Halbdifferentialkurzschlussringgeber (HDK) der 
Einspritzpumpe (BOSCH, ein spaetes Modell der VP37) und ein PWM-Signal 
zum Verstellen des Mengenstellwerks, um ein vollstaendiges 
Motorsteuergeraet zusammen zu bekommen. Ein paar Schalter fuer Kupplung, 
Bremse und Tempomat fallen dann auch nicht mehr ins Gewicht. ;)

Bis auf dar Auswerten des HDKs sind alle Aufgaben jetzt schon mal 
grundsaetzlich geloest. Das Funktionsprinzip und der Loesungsansatz sind 
jetzt auch schon klar, naechste Woche gibt's noch ein paar Bauteile und 
dann sollte nicht mehr viel im Weg zum fertigen Projekt stehen.


Zwischenbilanz
--------------

Die Wahl des Arduinos war fuer den schnellen Erkenntnisgewinn ueber den 
Microcontroller und die eigentliche Aufgabenstellung genau die richtige 
gewesen.
Dadurch, dass sich der Arduino quasi ohne Aufwand mit einem Proto-Shield 
leicht um zusaetzliche Hardware erweitern laesst und dadurch, dass sich 
die Entwicklung ohne viel Einarbeitungsaufwand in einen spezifischen 
Assembler schnell voran bringen laesst, war der Arduino die perfekte 
Wahl fuer mich.
Allerdings ist es jetzt schon recht eng mit den Resourcen des Arduinos 
geworden.


Wie geht's weiter?
------------------

Da auf mittlere Sicht noch ein Anschluss an einen CAN-Bus gebraucht 
wird, sechs Common-Rail-Injektoren, eine Hochdruckpumpe und auch noch 
ein Automatikgetriebe angesteuert werden sollen, ist fuer mich jetzt 
klar geworden, dass ich fuer das naechste Projekt auf einen 
ARM-basierten Mircrokontoller umsteigen werde.
Auch da werde ich auf ein fertiges Entwicklungsboard zurueckgreifen und 
habe den BeagleBone Black mit seinem XAM3359AZCZ100 ins Auge gefasst.
Mit einem Real Time Kernel, den ich auch schon zum Laufen bekommen habe, 
dem "Programmable Real-Time Unit" (PRU) und dem "Industrial 
Communication Subsystem" (ICSS), zweier zusaetzlicher on-chip 
I/O-Controller mit 200 MHz sind dann die Hardware-Resourcen auf jeden 
Fall ausreichend.
Mit dem Linux oben drueber laesst sich dann noch eine schoene GUI und 
eventuell etwas Infotainment nutzen.


Fazit
-----

Viele Wege (und auch Irrwege) fuehren zur Wahl des "richtigen" 
Microcontrollers. Und "richtig" ist dabei ueber die Zeit, und den damit 
verbundenen Kenntnisgewinn, variabel. Es gibt eine Lernkurve, die, je 
nach Vorgehensweise, steiler oder flacher ausfallen kann.



Viele Gruesse,
huebi

huebi h. schrieb:
> Das Ziel meines Projektes war urspruenglich nur die Ladedruckregelung
> eines VTG-Turboladers

Toll! Wenn das nicht geheim ist, dann würde mich das auch interessieren.
Die VW Motoren in unseren Gabelstaplern haben das alles mit Unterdruck.
Ich habe vor kurzem zum ersten Mal einen defekten Turbolader gehabt und 
mich dementsprechend damit auseinander setzten müssen.
Man könnte ne Menge "Gezumpel" dabei einsparen und hätte diesen ganzen 
Unterdruckkram da raus.
Könnte auch für meine Firma interessant sein.

Dingens23 schrieb:
> PIC24FJ32KA304
Diesen muss Microchip noch erfinden. Ich glaube du meinst den 
PIC24FV32KA304.

Dingens23 schrieb:
> Ein recht brauchbares Tutorial (allerdings für C) gibt es auf folgender
> Seite:
> http://www.engscope.com/pic24-tutorial/
Für ASM habe ich auch kein brauchbares Tutorial gefunden. Bei meiner 
Frage nach einem Tut ist das hier entstanden: 
Beitrag "Re: PIC24 ASM Tutorial"

Max H. schrieb:
> Diesen muss Microchip noch erfinden. Ich glaube du meinst den
> PIC24FV32KA304.

Ein kleiner Nachteil der PIC24/33 sind ebendiese Bezeichnungen.
Jeder meckert über die IBAN, aber hier? ;-)

A. K. schrieb:
> Ein kleiner Nachteil der PIC24/33 sind ebendiese Bezeichnungen.
Darf ich fragen, welchen Nachteil du darin siehst?


Dingens23 schrieb:
> PIC24FJ32KA304
Diesen gibt es nur im 44/48 Pin SMD Gehäuse. Den PIC24FV32KA302 gibt es 
im DIP-28

Dingens23 schrieb:
> PIC24FV32KA304
> STM32F030R8T6
> MK10DN128VFM5
Dingens23 schrieb:
> PIC24FJ128GC010
huebi h. schrieb:
> XAM3359AZCZ100

Wundert sich immer noch jemand, weshalb der ATmega8 bei Anfängern 
weiterhin so beliebt ist. ;-)

Und wenn man sich mit mehreren Menschen trifft wir es komplizier, da 
alle verschiedene Namen habe und nicht einfach Mensch8, Mensch16, 
Mensch32, Mensch328 heißen…

Ausser in China, da heißen alle Li  . . . ;-)

A. K. schrieb:
>> PIC24FV32KA304
>> STM32F030R8T6
>> MK10DN128VFM5
> Dingens23 schrieb:
>> PIC24FJ128GC010
> huebi h. schrieb:
>> XAM3359AZCZ100

Am schlimmsten finde ich hier immer noch Freescale. Ironischerweise ist 
deren Website garade down, so dass ich keine der kryptischen Namen der 
Kinetis-Serie herauskopieren kann.

So kryptisch sind die Namen der PIC24 nicht:
PIC24FV 32 KA302
  │   │  │   │
  │   │  │   └── Vorname des µC
  │   │  └────── 32kB Flash
  │   └───────── V: 5V Typ
  └───────────── Familienname

Eine kurze Frage zum AVR:
Man liest immer wieder, dass ein AVR den Kompletten RAM und Flash linear 
Adressieren kann. Wie breit ist dann ein Befehl, dass die gesamte 
RAM/Flash-Adresse in einem Befehlswort Platz hat?

Max H. schrieb:
> Wie breit ist dann ein Befehl, dass die gesamte
> RAM/Flash-Adresse in einem Befehlswort Platz hat?

Passt in zwei 16-Bit Worte. 16 Bits für Daten-Adressierung und ~22 Bits 
für Code-Adressierung.

Abgesehen davon ist lineare Adressierbarkeit nicht an Befehlsworte 
gekoppelt. 32-Bit RISCs wie ARM oder MIPS können 4GB linear adressieren, 
besitzen aber keine Befehle, die eine 32-Bit Adresse enthalten.

A. K. schrieb:
> Passt in zwei 16-Bit Worte
Bei ROM macht es der PIC18 auch so. Beim RAM wäre das auch ungünstig, 
weil dann die meisten Befehle 2 Programmworte belegen würden.
Da hat die Load-Modify-Store Architektur den Vorteil, dass die ganzen 
Befehle zum Rechnen nur eine 5 bit Adresse fürs Arbeitsregister 
enthalten...

Wieder etwas dazugelernt…

Max H. schrieb:
> Da hat die Load-Modify-Store Architektur

Nur fürs Protokoll: Was immer das sein soll, Fachjargon ist es nicht.
Da ist nur der Begriff Load/Store-Architektur gebräuchlich.

Ich steige nicht auf PIC um.
Allein die Anzahl existierender PICs macht mich völlig irre. Die 
Entscheidung gegen PIC liegt schon viele Jahre zurück, als 
Assemblerprogrammierung noch an der Tagesordung war, da ordentliche 
Compiler unbezahlbar waren)
Brauch ich Rechenpower, nehm ich STM32.
Gelegentlich Renesas M16, gerade die EX-Fuzzies mögen den.
Der Rest bleibt AVR (ohne X). Den kenne ich am besten. Und wenn die 
Leistung reicht, komme ich damit am schnellsten zum Ziel (ne 
funktionierende Applikation).

H.Joachim Seifert schrieb:
> Allein die Anzahl existierender PICs macht mich völlig irre.
Ist doch gut wenn man viel Auswahl hat.

Timm Thaler schrieb:
> Und nun nochmal für "bis 1"
decf PORTB,f
decfsz PORTB,w
goto $-2

Und jetzt bitte für den AVR...


Und wie würde man auf dem AVR z.B. eine 16bit Zahl aus dem RAM 
inkrementieren?
Beim PIC z.B. so:

incf zahl_l,f
btfsc STATUT,C
incf zahl_h,f

Und beim PIC12/18 eventuell so (Ist nicht kürzer, außer man hat aus 
irgendeinem Grund an Anfang 0x00 im WREG):
movlw 0x00
incf zahl_l,f
addwfc zahl_h,f

Dann addieren wir 2 16bit zahlen:
movf Al,w
addwf Bl,f
movf Ah,w
addwfc Bh,f

Timm Thaler schrieb:
>
> Ich hab mal eine Sqrt-Routine für Ganzzahl vom Pic auf Avr übertragen.
> War dort deutlich angenehmer zu handhaben, die Werte in die Register
> übernehmen und dann in den Registern rechnen.
>
> Und das ist auch sinnvoll: Wenn ich die Routine habe, will ich die
> universell einsetzen. Eine Routine, die fest auf bestimmte RAM-Zellen
> eingestellt ist, nützt mit gar nichts.

??????????
Wo steht das ICH! RAM-Adressen festlegen muss? Den Assembler 
Relocatablen Code erzeugen lassen und der Linker soll das dann auflösen.

Max H. schrieb:
> Dann addieren wir 2 16bit zahlen:
> movf Al,w
> addwf Bl,f
> movf Ah,w
> addwfc Bh,f

AVR:

add  rAL,rBL
adc  rAH,rBH

Dass die Variablen nicht aus dem Speicher kommen ist irrelevant, da man 
selten direkt aus dem Speicher zwei 16 Bit Zahlen addieren muss. Beim 
PIC ersetzt das lokale RAM die Register.

Tim    schrieb:
> Dass die Variablen nicht aus dem Speicher kommen ist irrelevant
Und immer wenn du zwei 16bit Zahlen Addieren musst sind die Zahlen schon 
in den Arbeitsregistern?

SE schrieb:
> da er einen größeren
> Befehlssatz hat und keine Page-Umschaltung.
Dagegen hat Microchip vor einiger Zeit den PIC18 erfunden.

Timm Thaler schrieb:
> Ja, natürlich. Im Ram addieren geht ja nicht. ;-)
Vom RAM in die Arbeitsregister verschieben, dauert auch Zeit...

Tim    schrieb:
> AVR:
>
> add  rAL,rBL
> adc  rAH,rBH
Wie würde das dann aussehen, wenn die Zahlen nicht zufällig schon in den 
Arbeitsregistern stehen?

Vemutlich so oder so ahänlich:

1

lds rAL,zahlAl

2

lds rAH,zahlAh

3

lds rBL,zahlBl

4

lds rBH,zahlBh

5

add rAL,rBL

6

adc rAH,rBH

7

sts zahlBl,rBL

8

sts zahlBh,rBH

if(AVRASM_CODE==richtig)
{
  Gar nicht so schwer das AVRasm.
  Das wären dann 8 Befehle die bei 20 MHz 0.4µs brauchen, bei PIC sind 4
  die bei 64MHz (16MIPS) 0.25µs brauchen...
}
else
{
  Korrigiert mich, wenn ich flasch liege
}

@ Max H. (hartl192)

>Vemutlich so oder so ahänlich:

ja, so ähnlich, die Namen der Befehle sind anders

1

lds rAL,zahlAl

2

lds rAH,zahlAh

3

lds rBL,zahlBl

4

lds rBH,zahlBh

5

add rAL,rBL

6

adc rAH,rBH

7

sts zahlBl,rBL

8

sts zahlBh,rBH

>  Das wären dann 8 befehle die bei 20 MHz 0.4µs brauchen, bei PIC sind 4
>  die bei 64MHz 16MIPS) 0.25µs brauchen...

Nur dass das nicht mal die halbe Wahrheit ist. Sinnvollerweise behält 
man bei größeren Algorithmen die Daten so lange wie möglich in den 
Registern und schreibt nicht dauernd auf den RAM.

Falk Brunner schrieb:
> Nur dass das nicht mal die halbe Wahrheit ist. Sinnvollerweise behält
> man bei größeren Algorithmen die Daten so lange wie möglich in den
> Registern und schreibt nicht dauernd auf den RAM.
Wer hat etwas von einem größeren Algorithmus gesagt. Sinnvollerweise 
nimmt man bei großen Algorithmen mit 16bi zahlen auch einen 16bit µC.

So eine Unsinnsdiskussion. Findet hier wirklich, 2014, gerade eine 
Diskussion über Akkumulator- vs. CISC vs. Load/Store statt? Die wurde in 
der Industrie Anfang der 80er Jahre geführt, wenn sie überhaupt 
stattgefunden hat. Was besser ist, und sich durchgesetzt hat, ist 
offensichtlich.

Die Akkumulatorarchitektur ist übrigens ein Hilfskonstrukt, welches in 
den 70er Jahren entstand als man noch nicht genug Transistoren für ein 
Registerfile auf einem Chip unterbringen konnte. Neben dem PIC gab es da 
noch 6502 und Z80. Die diskreten CPUs davor, und die höher integrierten 
CPUs danach haben alle auf registerbasierte Architekturen gesetzt.

Tim    schrieb:
> So eine Unsinnsdiskussion. Findet hier wirklich, 2014, gerade eine
> Diskussion über Akkumulator- vs. CISC vs. Load/Store statt?

Wär dir eine Diskussion über die beste Byteorder lieber? ;-)

> Was besser ist, und sich durchgesetzt hat, ist offensichtlich.

Bei den 8-Bittern eben nicht. Interessanterweise gibts da mit STM8 sogar 
eine neue Familie auf Akku-Basis, so dass nicht allein weiterentwickelte 
Kisten aus den 70ern einen Akku verwenden (wie 68xx, PIC).

> Die diskreten CPUs davor, und die höher integrierten
> CPUs danach haben alle auf registerbasierte Architekturen gesetzt.

Keineswegs. Die IBM Rechenknechte vor den 360ern (z.B. 7094, 60er Jahre) 
waren Akku-basiert. Ebenfalls die deutsche TR440 von 1969, die immerhin 
schon mit ECL ICs arbeitete.

Richtig durchgesetzt haben sich grössere Registersätze bei den dicken 
Kisten eigentlich erst im Gefolge von IBM 360 und CDC 6600.

A. K. schrieb:
> Keineswegs. Die IBM Rechenknechte vor den 360ern (z.B. 7094, 60er Jahre)
> waren Akku-basiert. Ebenfalls die deutsche TR440 von 1969, die immerhin
> schon mit ECL ICs arbeitete.
>
> Richtig durchgesetzt haben sich grössere Registersätze bei den dicken
> Kisten eigentlich erst im Gefolge von IBM 360 und CDC 6600.

Tja, man sollte sich nur Fragen, warum heute in den 
Computerarchitektur-Vorlesungen von "Tomasulo" und "Scoreboard" gelehrt 
wird.

Zu den alten IBM-Maschinen kann ich sonst nur dieses beitragen:
http://www.computerhistory.org/revolution/supercomputers/10/33/62

Der TR440 war halt eine Rechenmaschine.

Tim    schrieb:
> Tja, man sollte sich nur Fragen, warum heute in den
> Computerarchitektur-Vorlesungen von "Tomasulo" und "Scoreboard" gelehrt
> wird.

... und dass der Herr Tomasulo ebendieses Verfahren erst in die IBM 
360/91 eingebaut hat. Davor gabs aber auch schon Grosscomputer.

Wenn man Register in Einzeltransistoren aufbauen muss, dann neigt man 
zur Knausrigkeit. Oder man hat gewaltigem Aufwand, wie bei der CDC 6600, 
in der immerhin eines von maximal 15 Chassis nur für die Register 
zuständig war.

A. K. schrieb:
> Tim    schrieb:
>> Tja, man sollte sich nur Fragen, warum heute in den
>> Computerarchitektur-Vorlesungen von "Tomasulo" und "Scoreboard" gelehrt
>> wird.
>
> ... und dass der Herr Tomasulo ebendieses Verfahren erst in die IBM
> 360/91 eingebaut hat.

Ne, Scoreboard ist CDC6600. Tomasulo ist ein anderer Scheduling-Ansatz.

Sicher ist auf jeden Fall, dass Superscalarität und OOO mit einer 
Akku-basierenden Architektur schwierig bis unmöglich sind.

>Wenn man Register in Einzeltransistoren aufbauen muss, dann neigt man
>zur Knausrigkeit. Oder man hat gewaltigem Aufwand, wie bei der CDC 6600,
>in der immerhin eines von maximal 15 Chassis nur für die Register
>zuständig war.

Ja, in der Zeit war die Problematik ähnlich wie in der Anfangszeit des 
Mikroprozessors.

Dann gab es wohl zwei Wellen:

Akku (Transistor) - Register (Transistor) -  Akku (Integriert) - 
Register (integriert) - Load/Store (Integriert).

Tim    schrieb:
>> ... und dass der Herr Tomasulo ebendieses Verfahren erst in die IBM
>> 360/91 eingebaut hat.

> Ne, Scoreboard ist CDC6600.

Missverständnis. Ich meinte, dass Tomasulo das damals nach ihm benannte 
Renaming in die IBM 360/91 einbaute und du schreibst, dass die CDC6600 
Scoreboarding verwendete. Was nichts miteinander zu tun hat, richtig.

> Sicher ist auf jeden Fall, dass Superscalarität und OOO mit einer
> Akku-basierenden Architektur schwierig bis unmöglich sind.

Die Durststrecke waren die 90er, wo die OOO-Tiefe nicht gross genug war, 
um Parallelität aus dafür herzlich ungeeignetem Akku-Code zu kitzeln. 
Heute wäre das sogar möglich - wenngleich völlig sinnlos.

Nur ist sowas für Microcontroller der hier betrachteten Gattung herzlich 
uninteressant. Nicht mal der RPi mit seinem ARM11 kann damit aufwarten, 
erst die Cortex A.

Da kann es im Gegenteil interessant sein, im Cortex M0+ die Pipeline 
möglichst kurz zu halten um Sprünge zu beschleunigen. Spart summarum 
Taktfrequenz und damit Strom. Das gabs übrigens auch schon in dickeren 
Sphären in der Zeit als IBM sowohl die Power3/4 mit tiefer Pipeline für 
FPU-Kram und gleichzeitig die kurz gepipelineten RS64 für Kommerz-DV im 
Angebot hatte.

A. K. schrieb:
> Tim    schrieb:
>>> ... und dass der Herr Tomasulo ebendieses Verfahren erst in die IBM
>>> 360/91 eingebaut hat.
>
>> Ne, Scoreboard ist CDC6600.
>
> Ich schrieb, dass Tomasulo das damals nach ibm benannte Renaming in die
> IBM 360/91 einbaute und du schreibst, dass die CDC6600 Scoreboarding
> verwendet. Was nichts miteinander zu tun hat, richtig. Also weshalb
> "Ne"?

Dann habe ich Deine Aussage missverstanden. Ich dachte Du würdest 
implizieren, dass Tomasulo das Scorboard in den IBM360/91 eingebaut hat.

>
>> Sicher ist auf jeden Fall, dass Superscalarität und OOO mit einer
>> Akku-basierenden Architektur schwierig bis unmöglich sind.
>
> Die Durststrecke waren die 90er, wo die OOO-Tiefe nicht gross genug war,
> um Parallelität aus dafür herzlich ungeeignetem Akku-Code zu kitzeln.
> Heute wäre das sogar möglich - wenngleich völlig sinnlos.

Naja, das ist schon etwas hypothetisch. Auch in den 90ern gab es nur 
noch wenig neue Software für Akku-basierende Architekturen.

Aber sicher, mit Hyperthreading und steigender Speicherabtraktionstiefe 
könnte man noch einiges aus einer Akku-Architektur herausholen. Immerhin 
wäre eine Akku-Architektur ja auch ein Ansatz, um die Logiktiefe in den 
ersten Pipelinestufen noch weiter zu verringern. Inzwischen hat man aber 
auch eingesehen, dass der P4 eine Fehlentwicklung war (Der hat m.W. eine 
kombinatorische Tiefe von 6 NAND Äquivalenten). Noch weiter muss man in 
die Richtung nicht gehen.

> Nur ist sowas für Microcontroller der hier betrachteten Gattung herzlich
> uninteressant. Nicht mal der RPi mit seinem ARM11 kann damit aufwarten,
> erst die Cortex A.

Eben. Der PIC hat überlebt, da man auf einem Microcontroller für viele 
Anwendungen einfach nicht mehr Speicher braucht und da er einfach nicht 
schneller sein muss.

Das ist alles.

Schon bemerkenswert wie nahezu jeder Thread, in dem die Namen AVR und 
PIC vorkommen, immer sehr lang und viele ohne Ahnung zu haben posten, 
was das Zeug hält. Ich nutze bisher ausschließlich PICs. Und genau aus 
diesem Grund bin ich ganz ruhig, was Fakten über andere Microcontroller 
angeht.

Ich möchte diesen Post aber etwas konstruktiv gestalten, daher:
- Ich hatte etwas gelesen, wie "man kann ja nahezu alle PICs in C 
programmieren" -> man kann jeden einzelnen PIC in C programmieren!

- Für mich ist das gute am PICKIT3 nicht nur, dass er alle PICs flashen 
kann, sondern auch Debuggen.

- Die Bezeichnung von PICs ist, wenn man sich damit etwas beschäftigt 
hat, relativ übersichtlich. Außerdem muss man etwas komplexere 
Bezeichnungen nehmen, bei insgesamt >600 PICs. Größere Auswahl -> 
passenderen Chip -> so günstig wie möglich.

Bei den 16bittern z.B.: dsPIC ist wie der PIC24, nur mit DSP-Einheit. 
Nach der Familie kommt der Flashspeicher in KB. Danach kommt der 
zugeschnittene Verwendungszweck. MC steht für Motor Control, GP für 
General Purpose, GS für Digital Power and Lighting...

ww1.microchip.com/downloads/en/DeviceDoc/00001032m.pdf

edit: Was die Frage vom TO angeht, ob sie ernst gemeint ist oder nicht, 
finde ich, das es für Hobbyisten nur den einen Grund gibt zu wechseln: 
neugier. Im Beruflichen kommt warscheinlich noch der Zwang dazu. Solche 
Fragen könnte man eigentlich mit < 10 Posts beantworten

Wenn man nur die Frage beantworten will:
Wie steige ich am besten von AVR auf PIC um?

MPLAB-X anstatt AVR-Studio downloaden (kostet nix)
Passenden C-Compiler downloaden (kostet prinzipiell ersmal auch nix)

PICKIT3 anstatt AVRDragon kaufen (kostet so um €35,-)

Und dann kanns losgehen.

Reiner Geiger schrieb:
> Wenn man nur die Frage beantworten will

Das wolle der TO allerdings gar nicht … schau dir den Namen an, dann
weißt du's. :)

(Gast) schrieb:
> Muss ich dann den Port in ein Arbeitsregister einlesen, das bit
> verändern und wider zurückschreiben?

Bei den höher nummerierten Ports der "großen" AVRs muss man das so
machen, aber bei den "kleinen" Ports (alles bis einschließlich Port G)
kann man mit speziellen Befehlen (die der Compiler aber kennt) ein
einzelnes Bit mit einem einzigen Befehl in 2 CPU-Takten ändern.

Bit-Banging auf den IOs ist eher eine Stärke der AVRs.

Bei den Xmegas sind zwar die Sonderbefehle aufgrund des viel größeren
Adressraums der IO-Register kaum noch (sinnvoll) nutzbar, aber dafür hat
man das dort so aufgebaut wie auch bei vielen ARMs, also mit einem
Register, über das man Bits setzen kann, einem weiteren, über das man
sie löschen kann usw. usf.

(Gast) schrieb:

>> kann man mit speziellen Befehlen
> Also so etwas wie das bsf/bcf PORTA,5 beim PIC...

Yep, heißen dort SBI und CBI.