Forum: Mikrocontroller und Digitale Elektronik Wie steige ich am besten von AVR auf PIC um?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Thomas Roll (Gast)


Lesenswert?

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?

von AVR rules (Gast)


Lesenswert?

>Meine Bekannter schwört total auf die PICs.

Warum fragst du nicht den?

von Falk B. (falk)


Lesenswert?

@ 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.

von regnerischer Samstag (Gast)


Lesenswert?

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

T(homas) Roll ---> Troll?

Chips und Bier steht bereit!

von Sean G. (atmega318)


Lesenswert?

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

von Thomas Roll (Gast)


Lesenswert?

AVR rules schrieb im Beitrag #3482409:
> Warum fragst du nicht den?

Weil ich den nicht so häufig sehe.

Falk Brunner schrieb:
> Und warst du damit zufrieden?

Ein bischen langsam war es schon, besonders mit flieskommazahlen.


Falk Brunner schrieb:
> Selten so gelacht ;-)

Warum?

regnerischer Samstag schrieb:
> T(homas) Roll ---> Troll?

Witzig.

von Ingo (Gast)


Lesenswert?

Dummerweise benötigt ein PIC aber auch 4 Takte für eine Anweisung! Also 
muss ein PIC 4x höher gestaltet werden um auf die selbe Rechenleistung 
wie ein AVR zu kommen!

Und warum ist der eine Assembler besser als der andere? Häää?!

von Thomas Roll (Gast)


Lesenswert?

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

Lassen die sich auch gut in assembler progammieren?

von Max D. (max_d)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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

warum hast du es dann verwendet? Meist braucht man es überhaupt nicht 
oder kann es vermeiden.

Und flieskomma, willst du bestimmt nicht in ASM programmieren.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

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.

von Max H. (hartl192)


Lesenswert?

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

von Udo (Gast)


Lesenswert?

PICKit 3 zum Brennen, sollte reichen
um ein zu steigen.

von Max H. (hartl192)


Lesenswert?

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

von Capsaicin-Lutscher (Gast)


Lesenswert?

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

Die wenigen Maschinenbefehle von PICs sind höchst "simple 
mind"-freundlich - und entsprechend beliebt beim harten Kern der Jungs 
mit der weichen Birne...

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Max H. (hartl192)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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 ???

: Bearbeitet durch User
von Carsten S. (dg3ycs)


Lesenswert?

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

von Harald W. (wilhelms)


Lesenswert?

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

von Thomas Roll (Gast)


Lesenswert?

Carsten Sch. schrieb:
>> 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)

Krass. Solche komplexen Befehle kann der AVR nicht. Ich bin schon 
gespannt.

von AVR rules (Gast)


Lesenswert?

>Weil ich den nicht so häufig sehe.

Googel mal nach Email oder Telefon.

von Max H. (hartl192)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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

: Bearbeitet durch User
von Falk B. (falk)


Lesenswert?

@ 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.

von Frank K. (fchk)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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. ;-)

von Peter D. (peda)


Lesenswert?

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.

von Ulrich (Gast)


Lesenswert?

Ein Umstieg vom AVR zum PIC16 oder PIC18 lohnt normalerweise nicht. Die 
Leistung dieser PICs ist fast immer geringer als bei den AVRs, schon 
weil es je 4 Taktzyklen für einen Befehlstakt braucht. Der höhere Takt 
täuscht da also.

Bei der ASM Programmierung gilt eher der AVR als einfacher, auch wenn da 
die Geschmäcker verschieden sind, je nachdem welche Type man gut kennt. 
Fließkommazahlen will man aber freiwillig mit keinem der beiden in ASM 
machen.

Wenn schon ein Umstieg dann ARM oder eventuell noch dsPIC33 oder PIC32. 
Die sind tatsächlich schneller und bieten oft auch mehr Peripherie - oft 
wichtiger als die CPU. Wobei da die ARMs weiter verbreitet sind. Die 
Programmierung ist ASM wird dabei aber auch eher nicht einfacher. Mit 
dem mehr an Leistungsfähigkeit braucht man ASM aber auch nur noch 
selten.

von Peter D. (peda)


Lesenswert?

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.

von Helmut S. (helmuts)


Lesenswert?

> 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

von Achim M. (minifloat)


Lesenswert?

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

von Peter II (Gast)


Lesenswert?

Joachim K. schrieb:
> Ich mutmaße jetzt mal, dass du hauptsächlich in Assembler programmierst.

deswegen wird er ja

> Ich habe bisher nur mit dem AVR in Bascom gearbeitet
geschrieben haben

von Carsten S. (dg3ycs)


Lesenswert?

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

: Bearbeitet durch User
von Moby (Gast)


Lesenswert?

Au weia. Da wurde aber ordentlich auf den Pic Schlips getreten.

von Dieter W. (dds5)


Lesenswert?

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.

von Der Rächer der Transistormorde (Gast)


Lesenswert?

Thomas Roll schrieb:
> Deswegen will ich jetzt auch umsteigen.

Finde ich gut, das Logo ist auch hübscher und außerdem kommt Chip im 
Firmennamen vor, da muss man nicht lange Rätseln was die so machen.

Atmel ist natürlich die Abkürzung für Assembeler Trottel Meiden Elegante 
Lösungen, aber das hat die der Kollege sicher auch verraten. Deshalb 
übrigens die herumreiterei auf Akronymen für Maschinenbefehle hier. 
Wahre Progger merken sich jedes Mnemonic, Atmelisierte können nur wenige 
Buchstabencodes und das Wort Bankswitch ist für Sie auch viel zu lang, 
geschweige denn verständlich.

Sie müssen auch einen Taktzyklus haben in dem alles stattfindet. 
Konzepte wie Prefetch Ext. memmory Sync und Pipelining sind ihnen fremd 
von Intel haben Sie auch so gut wie noch nie was gehört.

Aber ansonsten bin ich der Meinung das du nicht umsteigen solltest. Das 
Hobbyistenrauschen ist bei ProfiIntelligenzControllern wesentlich 
kleiner als bei ...

Wer Ironie findet darf Sie behalten

von Ulrich (Gast)


Lesenswert?

Statt den µC zu wechseln würde es ggf. schon reichen den Compiler bzw. 
die Sprache zu wechseln. BASCOM ist relativ einfach, aber auch relativ 
langsam. Dafür gibt es halt einige relativ spezielle vorgefertigte 
Teile. Die Kombination BASIC mit Teilen in ASM funktioniert wegen der 
einfachen Struktur des Compilers noch recht gut. Das kann durchaus eine 
Alternative sein, nur den Zeitkritischen Teil in ASM zu schreiben, den 
Rest weiter in Basic.

Ein C Programm etwa mit GCC (AVRStudio) kann durchaus doppelt so schnell 
sein wie BASIC, auf dem gleichen µC. Wie groß der Vorteil ausfällt hängt 
aber vom Problem ab. Ein Anfänger wird mit ASM oft auch nicht schneller 
als GCC.

Beim PIC gibt es den BASIC Compiler sowieso nicht - man müsste also da 
den µC und den Compiler wechseln.

von Chris B. (dekatz)


Lesenswert?

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!

von Carsten S. (dg3ycs)


Lesenswert?

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

von Der Rächer der Transistormorde (Gast)


Lesenswert?

Chris B. schrieb:

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


Ein etwas sinnloser Geschichtsunterricht da das auftauchen neuer 
Maschinenbefehle in der Branche immer schnell von allen Herstellern 
übernommen wurde.

Das kommt noch aus der Zeit wo die Habgier in Form von Intellectual 
Property so gut wie unbekannt war und sich daher die Branche schnell 
weiterentwickeln konnte. Das geht natürlich nicht wenn man mit dem lesen 
von Schutzansprüchen ausgelastet ist wie heutzutage.

Diesen Markenfetischismus halte ich im übrigen für typisches 
Amateurgehabe. Prozessoren die ich nutze nutze ich weil weil ich in Sie 
Lernaufwand  investiert habe. Von einer Generation zur anderen nutze ich 
eine andere Marke, auf einem Bein steht es sich schlecht.

Im Bereich Produkte sollten sich Fanclubs die Frage stellen ob ihr 
Fetischobjekt sich denn auch für Sie interessiert.

von Max H. (hartl192)


Lesenswert?

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.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Ulrich schrieb:
> Ein Umstieg vom AVR zum PIC16 oder PIC18 lohnt normalerweise nicht. Die
> Leistung dieser PICs ist fast immer geringer als bei den AVRs, schon
> weil es je 4 Taktzyklen für einen Befehlstakt braucht. Der höhere Takt
> täuscht da also.
>
> Bei der ASM Programmierung gilt eher der AVR als einfacher,


So sieht das aus, wenn jemand nicht wirklich Bescheid weiß.

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. Abhilfe gibt's nur für Dinge, die bereits 
in den CPU-Registern stehen. Bei den PIC's kann man sich das Load und 
Store klemmen, das wird nicht benötigt, weil die Operation direkt in der 
RAM-Zelle stattfindet. 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.

Bei der Assemblerprogrammierung muß man deshalb die Arbeitsweise der 
PIC's erstmal verstehen, um effizient zu werden. Die AVR's hingegen sind 
mit ihrer altbackenen Load-Modify-Store-Architektur deutlich einfacher 
für simple Gemüter zu verstehen.

Der Umstieg von AVR zu PIC oder umgekehrt lohnt zumeist dann, wenn man 
Eigenschaften der Peripherie braucht, die der jeweils andere Typ eben 
nicht aufweist. Ein prima Beispiel hierzu sind die asynchronen Vorteiler 
vor den Timern 0 und 1 der PIC's. Das ist ein Merkmal, was man woanders 
vergeblich sucht. Sowas isz z.B. prächtig für Frequenzzähler geeignet. 
Wenn man dagegen die Krämpfe von verbissenen AVR-Leuten sich hier im 
Forum mal anschaut, wenn sie einen Frequenzzähler bauen wollen, o je.

W.S.

von (prx) A. K. (prx)


Lesenswert?

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".

von Max H. (hartl192)


Lesenswert?

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.

von Michael L. (michaelx)


Lesenswert?

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.


;-)

von Max H. (hartl192)


Lesenswert?

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?

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

A. K. schrieb:
> das jedenfalls "Programmable Intelligent Computer".

Wieder einer von der oberschlauen Sorte, der wieder mal falsch liegt..

Nein, es hieß "Programmable Interface Controller". Ursprünglich war das 
nämlich nur ein Peripherie-Baustein zu einem "richtigen" Prozessor. 
Ironie der Zeit ist, daß eben nur der Peripherie-IC überlebt hat, nicht 
jedoch der eigentliche Prozessor.

W.S.

von PittyJ (Gast)


Lesenswert?

Also wenn du wirklich auf bizarre Prozessoren stehts, dann besorge dir 
lieber einen FPGA. Auf Opencore gibt es dafür
Mips
AVR
Z80
PDP-11
6502
und noch viele mehr. Da ist für jeden Liebhaber kruder Assembler-Befehle 
bestimmt noch etwas nettes dabei.

Also 1 FPGA -> 100 verschiedene Architekturen.


Und wenn noch etwas fehlt, dann baut man sich den passenden Befehl 
selbst

SB17C A2,A5 -> Subtrahiere 17 von A2 und addiere das Carry nach A5.

Ja, selbst sowas geht.

von Max H. (hartl192)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

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.

von Bastler (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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

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

von Max H. (hartl192)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Max H. (hartl192)


Lesenswert?

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

von F. F. (foldi)


Lesenswert?

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.

von K. J. (Gast)


Lesenswert?

Hm PIC & AVR schenken sich beide nichts der Pic hat zwar Fsoc/4 aber 
braucht weniger takte pro befehlt es kommt zimlich das gleiche raus wen 
man die pic16f mit den Atmega8 vergleicht beim pic18f ist es etwas 
anders aber den möchte man nicht in ASM Programieren jedenfals wen man 
usb und eth nutzen will.

von (prx) A. K. (prx)


Lesenswert?

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).

: Bearbeitet durch User
von Max H. (hartl192)


Lesenswert?

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.

: Bearbeitet durch User
von Michael L. (michaelx)


Lesenswert?

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. ;-)

von (prx) A. K. (prx)


Lesenswert?


: Bearbeitet durch User
von Michael L. (michaelx)


Lesenswert?

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.

;-)

von Hans-Georg L. (h-g-l)


Lesenswert?

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.

von Hans-Georg L. (h-g-l)


Lesenswert?

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;)

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Norbert M. (Gast)


Lesenswert?

A. K. schrieb:
> Kennt jemand die Befehle BCWZ, SBBRRPF, TRANS und ADJBA? Nein?

Nein, aber erzähl's uns.

BCWZ sieht aus wie "Branch if Carry=Zero". Aber was bedeutet W?
SBBRRPF sagt mir gar nix.
TRANS wird was mit dem Akku zu tun haben. Oder gar was vom Transputer?
ADJBA koennte was mit BCD-Arithmetik zu tun haben. "Adjust BCD in 
Accumulator" vielleicht.

Ich weiss es nicht, find's aber interessant.

LG, N0R

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von DerTroll (Gast)


Lesenswert?

Ich glaube ihr habt T.Roll genug geholfen, oder?

von (prx) A. K. (prx)


Lesenswert?

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

von Hans-Georg L. (h-g-l)


Lesenswert?

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

: Bearbeitet durch User
von Nubi (Gast)


Lesenswert?

Hans-Georg Lehnard schrieb:
> Mit Assembler legst du dich immer
> wieder fest.

Na und? Die Kunst ist nur seinen Controller anfangs für alle 
Anwendungsfälle richtig festzulegen. Dann kann man dem auch treu 
bleiben. Meine Empfehlung: Xmega!

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Norbert M. (Gast)


Lesenswert?

A. K. schrieb:
> Zu finden in der Doku der NEC V20 Familie x86 kompatibler Prozessoren.

Danke für die Auführungen, A.K.

> Da blieb kein Stein auf dem anderen, was die Namen angeht. Den
> Programmen wars egal, den Programmierern auch.

Profis halt. Ich bin froh, wenn ich irgendwann den HCS8 komplett 
verstehe. Wird mein erster und wohl auch letzter sein. Ist irgendwie 
nicht so mein Primärhobby, das Elektronikzeugs.

Trotzdem finde ich die Thematik "Architekturen" ziemlich interessant.
Und ein bisschen bewundere ich diese alten Profis ja doch.

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

Zum Z80 fällt mir nur die Geschichte ein, daß der auch mit Kopien der 
Originalmasken in der DDR gefertigt worden sein soll, aber die kennst Du 
dann ja bestimmt auch. Das nenne ich mal Kompatiblität :)

Schade nur, daß solche Threads meistens im Fanboytum untergehen. Gut, 
bei diesem hier war's ja Anhand des Starting Posts und des Namen des 
Autors eh klar, daß es in einem "AVR vs. PIC"-Krieg ausarten würde.

LG, N0R

von greg (Gast)


Lesenswert?

W.S. schrieb:
> Die AVR's hingegen sind
> mit ihrer altbackenen Load-Modify-Store-Architektur deutlich einfacher
> für simple Gemüter zu verstehen.

Load-Store-Architekturen sind altbacken? Mutige Aussage. Und die PICs 
sind dann aus der Steinzeit, oder wie? ;)

von (prx) A. K. (prx)


Lesenswert?

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. ;-)

: Bearbeitet durch User
von Ulrich (Gast)


Lesenswert?

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.
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.

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


Der BASCOM Compiler ist vor allem schön einfach, aber halt nicht gerade 
der schnellste. Den sollte man nicht unbedingt als Vergleich nutzen - 
außer ggf. zum 8051 - da gibt es den Compiler auch für.

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.

von Carsten S. (dg3ycs)


Lesenswert?

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

: Bearbeitet durch User
von F. F. (foldi)


Lesenswert?

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.

von Max H. (hartl192)


Lesenswert?

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.

von Ulrich (Gast)


Lesenswert?

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

Der AVR bräuchte da 4 Zyklen je Schleifendurchlauf.

Ein wirklich neutrales Beispiel ist das aber auch nicht - mehr genau auf 
den PIC Befehl decfsz PORTB, f  zugeschnitten. Trotzdem braucht es da 
wohl 3 Befehlszyklen bzw. 12 Taktzyklen.

In der Regel lohnt es für so einen kleinen Unterschied nicht den µC zu 
wechseln und dann auch noch gleich den Compiler / Sprache dazu.

Das Problem für den TO ist viel mehr das er einen eher langsamen 
Compiler nutzt und dann womöglich auch noch Fließkommazahlen. Möglich 
ist da halt ein schnellerer Compiler und etwas mehr Übung beim 
Programmieren.

von Dave (Gast)


Lesenswert?

Ein AVR macht bis zu 20MHz. ein PIC18 bis zu 64MHz (16MIPS)
20/4=5
16/3=5.333333

von Axel S. (a-za-z0-9)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Mehmet K. (mkmk)


Lesenswert?

@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.

von F. F. (foldi)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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.

von A.S.M. (Gast)


Lesenswert?

Tim    schrieb:
> Da kann man aber noch einen Befehle wegoptimieren.

Aber nicht in der Schleife, und um die ging es hier.

von Huebi H. (huebi)


Lesenswert?

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

von F. F. (foldi)


Lesenswert?

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.

von Dingens23 (Gast)


Lesenswert?

Hallo,

ich verwende gerne PIC24, wenn es batteriebetriebene Projekte sein 
sollen. Speziell dafür gibt es sehr gut geeignete Typen (Stichwort 
Nanowatt).

Ich kann zum anfangen folgendes Empfehlen:
 - Ein PICkit3
 - Ein Breadboard und ein paar Steckbrücken  Kerkos  LEDs
 - Zum Anfangen einen PIC24Fxxx
Den PIC24FJ32KA304 gibt es im Bastlerfreundlichen DIP-Gehäuse, man kann 
ihn auch mit 5V betreiben, von der Peripherie hat der schon fast alles 
was man üblicherweise braucht.

Ein recht brauchbares Tutorial (allerdings für C) gibt es auf folgender 
Seite:
http://www.engscope.com/pic24-tutorial/

Ansonsten gibt es von der Peripherie her in der Serie alles was man 
braucht, von Ethernet bis USB.
Nettes Beispiel: PIC24FJ128GC010:
- USB OTG, USB2.0 ohne Quarz
- 10MSPS ADC
- 16Bit Sigma-Delta-Wandler
- LCD Controller
- CTMU
- remappable peripherals, mein absoluter Favorit

von Max H. (hartl192)


Lesenswert?

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"

von (prx) A. K. (prx)


Lesenswert?

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? ;-)

: Bearbeitet durch User
von Max H. (hartl192)


Lesenswert?

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

: Bearbeitet durch User
von Dingens23 (Gast)


Lesenswert?

Hallo,

danke für die Korrektur. Natürlich ist der PIC24FV32KA304 gemeint.

Das mit den Bezeichnungen ist halt branchenüblich: STM32F030R8T6 oder 
MK10DN128VFM5 sind auch nicht gerade selbsterklärend. Und wehe man 
verwechselt beim Bestellen einen Buchstaben...

von (prx) A. K. (prx)


Lesenswert?

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. ;-)

: Bearbeitet durch User
von Max H. (hartl192)


Lesenswert?

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…

: Bearbeitet durch User
von Falk B. (falk)


Lesenswert?

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

von Tim  . (cpldcpu)


Lesenswert?

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.

von Max H. (hartl192)


Lesenswert?

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

: Bearbeitet durch User
von Max H. (hartl192)


Lesenswert?

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?

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Max H. (hartl192)


Lesenswert?

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…

von (prx) A. K. (prx)


Lesenswert?

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.

von H.Joachim S. (crazyhorse)


Lesenswert?

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).

von Timm T. (Gast)


Lesenswert?

Carsten Sch. schrieb:
> Beim PIC wäre das im übrigen folgender Code:
>   movlw 250
>   movwf PORTB
> LOOPCOUNTER:
>   decfsz PORTB, f
>   goto LOOPCOUNTER

Der zählt aber bis Null runter. Und nun nochmal für "bis 1".

von Max H. (hartl192)


Lesenswert?

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

: Bearbeitet durch User
von Timm T. (Gast)


Lesenswert?

Max H. schrieb:
> Und jetzt bitte für den AVR...

Steht doch oben, must nur das letzte out PORT weglassen.

Max H. schrieb:
> Und wie würde man auf dem AVR z.B. eine 16bit Zahl aus dem RAM
> inkrementieren?

Macht man wie oft?

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. Es sei denn, ich nehme immer die 
gleichen RAM-Zellen als Zwischenspeicher, dann muss ich aber die 
Ausgangswerte auch rein und die Ergebnisse rausschaufeln.

von Max H. (hartl192)


Lesenswert?

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

von Chris B. (dekatz)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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.

von SE (Gast)


Lesenswert?

Ich nutze zz. nur AVR Controller. Für meine Abschlussprüfung musste ich 
mich damals(tm) mit einem PIC auseinandersetzen.

Ich fand den AVR bequemer zu Programmieren, da er einen größeren 
Befehlssatz hat und keine Page-Umschaltung.

Aber sobald man mit C Anfängt spielt das keine Rolle mehr. Dann nimmt 
man den, den man hat oder den der eine spezielle Anforderung erfüllt.

von Max H. (hartl192)


Lesenswert?

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.

von Timm T. (Gast)


Lesenswert?

Max H. schrieb:
> Und immer wenn du zwei 16bit Zahlen Addieren musst sind die Zahlen schon
> in den Arbeitsregistern?

Ja, natürlich. Im Ram addieren geht ja nicht. ;-)

von Max H. (hartl192)


Lesenswert?

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
}

: Bearbeitet durch User
von Falk B. (falk)


Lesenswert?

@ 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.

von Max H. (hartl192)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

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.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

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).

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

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.

: Bearbeitet durch User
von Michael S. (rbs_phoenix)


Lesenswert?

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

: Bearbeitet durch User
von tbk (Gast)


Lesenswert?

H.Joachim Seifert schrieb:
> 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).

kann man nicht oft genug betonen

von Reiner G. (reinerg)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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. :)

von (Gast) (Gast)


Lesenswert?

Wie ist das beim AVR eigentlich wenn ich einen Pin setzen/löschen will? 
Muss ich dann den Port in ein Arbeitsregister einlesen, das bit 
verändern und wider zurückschreiben?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

(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.

von (Gast) (Gast)


Lesenswert?

Jörg Wunsch schrieb:
> kann man mit speziellen Befehlen
Also so etwas wie das bsf/bcf PORTA,5 beim PIC...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

(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.

von MCUA (Gast)


Lesenswert?

>Nein, es hieß "Programmable Interface Controller"
So war die (offiz., von den meisten benutzte) Bezeichnung.
(mit etwas verwirrender (wie man hier lesen konnte) Befehls-Nomenklatur, 
bei der ua die Operanden direkt angehängt werden, oder dem ominösen 
d-bit)


>Und bei den 16Bit PICs gibt es ein paar Sachen, da kann
>Atmel nur davon träumen;)
Ja, vom progr. her viel besser.
Jedoch haben (alle!) PIC24's im Gegensatz zu AVR eine grässliche 
Pinbelegung!!!. Sehr wenige 8-Bit-Ports vorhanden, die Pins davon kreuz 
und quer verteilt!!!
Zudem (E)PMP-Pins völlig unsystematisch auf einzelne Ports verteilt 
(nicht 8-Bit-weise, so dass Betrieb mit mehrere Modes faktisch unmöglich 
ist)
Aufteilung von 5-V-toleranten-Pins ebenso total durcheinanden !!!
So ein Durcheinander hab ich bisher noch nirgentwo gesehen.
AVR ist Gold dagegen.
Die Leute, die diese Pin-Zuweisungen gemacht haben, hatten wohl jeden 
Tag eine Flasche Whiskey genommen.


>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.
offensichtlich?
Aktuell gibt es immer noch RISC, CISC (auch Akku-Archit.) -und auch 
Mischformen- davon.
(Bei manchen Anwendungen (zugegeben nicht bei allen) ist gar eine 
Akku-Archit. (bsp HC11,STM8) vs RISC von Vorteil (bsp. weil Mem-Werte 
binnen nur 1 Befehl mit Akku verrechnet/abgefragt werden können)
So haben typ RISC (wegen LD/ST) Nachteile, wegen uneffizienterem 
Befehlssatz, der gerade bei rel. kostengünstigen Controllern zu Tragen 
kommt.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.