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?
@ 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.
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!
Wenn du schon den Schritt von AVR weg wagst, überleg dir gut ob du nicht gleich auf ARM umsteigen willst.
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.
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äää?!
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?
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. 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.
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
PICKit 3 zum Brennen, sollte reichen um ein zu steigen.
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...
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
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 ???
:
Bearbeitet durch User
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
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.
>Weil ich den nicht so häufig sehe.
Googel mal nach Email oder Telefon.
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.
:
Bearbeitet durch User
@ 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.
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.
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
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
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
Au weia. Da wurde aber ordentlich auf den Pic Schlips getreten.
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.
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
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.
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
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.
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
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.
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?
:
Bearbeitet durch User
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.
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.
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.
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.
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
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.
:
Bearbeitet durch User
> 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.
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.
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
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
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
:
Bearbeitet durch User
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;)
:
Bearbeitet durch User
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
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
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
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
:
Bearbeitet durch User
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!
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
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
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? ;)
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
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.
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
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.
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.
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.
:
Bearbeitet durch User
@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.
Tim schrieb: > Da kann man aber noch einen Befehle wegoptimieren. Aber nicht in der Schleife, und um die ging es hier.
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.
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
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? ;-)
:
Bearbeitet durch User
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
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...
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
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
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
:
Bearbeitet durch User
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
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
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).
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".
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
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.
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.
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.
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.
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. ;-)
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
@ 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.
:
Bearbeitet durch User
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
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
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
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
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
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
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
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
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. :)
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?
(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.
Jörg Wunsch schrieb: > kann man mit speziellen Befehlen Also so etwas wie das bsf/bcf PORTA,5 beim PIC...
(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.
>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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.