hallo zusammen, Ich wollte bitte nur fragen!!!wo ist die unterschied zwischen Assembler Und C ?? Da ich MPlab v8.60 benutzen und ich muss Pic programiern!!und ob es egal ist welche Progamier sprache benutz ich?? Danke Juan
:
Verschoben durch User
Oh Graus Oh Graus... Juan schrieb: > Ich wollte bitte nur fragen!!! Dann tu das... > wo ist die unterschied zwischen Assembler Und C ?? Das eine ist eine Hochsprache, das andere nicht. Sehr sinnvolle Frage, hast du mal Google/Wikipedia/Forensuche bemüht? Oder willst du nur trollen? > und ob es egal > ist welche Progamier sprache benutz ich?? Beide sind turingvollständig --> Ja.
Juan schrieb: > Ich wollte bitte nur fragen!!!wo ist die unterschied zwischen Assembler > Und C ?? Ok. Irgendwas ist wohl mit deiner Tastatur nicht in Ordnung. Juan schrieb: > Da ich MPlab v8.60 benutzen und ich muss Pic programiern!!und ob es egal > ist welche Progamier sprache benutz ich?? Wenn du C programmieren möchtest, musst du den C18 oder den HiTech-Compiler zusätzlich installieren. Ansonsten bleibt dir nur Assembler. Gruß, Edson
Also beim PIC sollte man Assembler unbedingt meiden. Es ist sehr schwer, mit den wenigen Befehlen zurecht zu kommen. Hier mal ein Beispiel für 32Bit-Addition: http://www.pic-projects.net/index.php?option=com_content&view=article&id=57:multi-byte-addition-a-subtraction&catid=38:arithmetic&Itemid=57 Man braucht lange, um das überhaupt zu verstehen. Von selber würde man darauf nie kommen. Fremde PIC-Programme sind daher in der Regel auch nur schwer zu verstehen. Andere Architekturen haben da um Längen bessere Befehle. Beim PIC sollte man daher nur in C programmieren. Da sind dann die ganzen trickreichen Bibliotheken bereits enthalten und man braucht nur die Berechnungen einfach hinzuschreiben. Und man muß sich nicht mit der lästigen Unterteilung des RAM und Flash in mehrere Bänke rumärgern. Es sind dann nämlich auch sehr trickreiche Adreßberechnungen notwendig. Peter
Peter hat absolut recht. Diese PIC's sind so RISC, das man fast ein Mikroprogramm vermuten würde, wenn man Assemblercode sieht. Ich hatte im Studium noch eine Prof, der die bedeutung der einzelnen Bit's einer alten (Transistor-) PDP11 kannte. Das war in etwa das selbe.
wie war das beim pic 16 stack tife von 2? und dann mit C? In wie weit der Compiler da noch ANSI C conform ist mag ich bezweifeln.
Außerdem programieren echte Männer (tm) alles in Assembler und überlassen die Hochsprachen den Pantoffelhelden und Müslifressern ;-) Lächenzungen spitze Steine, runde Steine alles heute günstig abzugeben... duck und wech Michael
@Peda So viel unqualifizierten Quark wie in deinem Beitrag habe ich schon lange nicht mehr zum Thema PIC lesen müssen. Peter Dannegger schrieb: > Also beim PIC sollte man Assembler unbedingt meiden. Es ist sehr schwer, > mit den wenigen Befehlen zurecht zu kommen. Das gilt vielleicht für dich. Ich habe damit keinerlei Probleme. > Man braucht lange, um das überhaupt zu verstehen. Von selber würde man > darauf nie kommen. Fremde PIC-Programme sind daher in der Regel auch nur > schwer zu verstehen. "Man" bist du selbst, der offensichtlich keine Ahnung von PIC und deren Befehlssätzen hat. Ich würde mich schämen, solchen Unsinn öffentlich zu verzapfen. > Andere Architekturen haben da um Längen bessere Befehle. Die Aussage ist für einen erwachsenen Menschen, der auch noch vom Fach sein will, geradezu beschämend naiv. > > Beim PIC sollte man daher nur in C programmieren. Da sind dann die > ganzen trickreichen Bibliotheken bereits enthalten und man braucht nur > die Berechnungen einfach hinzuschreiben. > Und man muß sich nicht mit der lästigen Unterteilung des RAM und Flash > in mehrere Bänke rumärgern. Es sind dann nämlich auch sehr trickreiche > Adreßberechnungen notwendig. Wovon träumst du eigentlich nachts? Ach ja, wahrscheinlich vom 8051... Gruß, Edson
pig schrieb: > Peter hat absolut recht. Diese PIC's sind so RISC, das man fast ein > Mikroprogramm vermuten würde, wenn man Assemblercode sieht. Ich hatte im > Studium noch eine Prof, der die bedeutung der einzelnen Bit's einer > alten (Transistor-) PDP11 kannte. Hat er nicht. Wenn du jetzt mit Kamellen aus deinem Studium kommst, beweist das gerade, dass du genau so wenig Ahnung hast wie Peda selbst. michael_ohl schrieb: > Außerdem programieren echte Männer (tm) alles in Assembler und > überlassen die Hochsprachen den Pantoffelhelden und Müslifressern ;-) Dieser Sprech wurde doch hier im Forum erfunden. Es ist immer wieder erbärmlich zu sehen, wie die Leute zu PIC/AVR oder Assembler/C solche Binsenweisheiten postulieren. Also nochmal zum Mitschreiben: In programming, there is a time and place for everything. Gruß, Edson
Würde beim Einstieg empfehlen mit Assembler zu arbeiten. Die Hardwarenähe öffnet den Blick für das Thema. Kommt aber drauf an, was du erreichen willst. Musst du nur für einen Langzeittest in deiner Firma eine kleine Steuerung entwerfen und hast danach nie wieder etwas damit zu tun? Oder musst du dich auf eine Prüfung vorbereiten? (wenns nach mit geht kannst dann auch bei Assembler bleiben. Nachteil ist nur, wenn du zwischen µControllern wechselst. Du wirst dann jedes mal das Datenblatt nutzen müssen um die Unterschiede im Befehlssatz etc zu suchen. Bei C ist das etwas angenehmer) Wo "musst" du denn Pic programmieren? In der Schule/Uni? Auf der Arbeit? Hättest du denn den Compiler? Welchen Pic? Auf welchem Niveau?
Peter Dannegger schrieb: > Hier mal ein Beispiel für 32Bit-Addition: > > http://www.pic-projects.net/index.php?option=com_c... > > Man braucht lange, um das überhaupt zu verstehen. Von selber würde man > darauf nie kommen. Wenn irgendein Hobby-Programmierer in einem Forum sowas von sich gibt, ist das o.k. Wenn es ein professioneller Senior-Entwickler tut, ist es einfach nur erschreckend. Zu welcher Kategorie du dich zaehlst, weiss ich nicht - aber mir ist es tatsaechlich schon passiert, dass Leute aus letzterer Kategorie sowas erzaehlt haben. Schlimm wird's, wenn solche Leute in Fuehrungspositionen kommen. Denn dann fuehrt so eine Denkweise dazu, dass sie alles, was sie selbst fuer kompliziert halten auslagern, "weil wir sowas nicht selbst koennen, da muessen Profis ran". Und bald koennen dann "sowas" wirklich nur noch die Anderen. Um es noch mal klar zu sagen: Jeder, der sich selbst fuer einen Software-Entwickler haelt, muss sich sowas ausdenken koennen. Das ist der Job.
Oo0 schrieb: > Jeder, der sich selbst fuer einen > Software-Entwickler haelt, muss sich sowas ausdenken koennen. Na klar, Du hättest für diese Lösung maximal 10min gebraucht. Es ist ja so offensichtlich, daß man dafür den INCFSZ-Befehl braucht. Selbsteinschätzung ist wohl nicht Deine Stärke? Ich hab damals für das Verstehen etwa 1h gebraucht. Ich kann die genaue Funktion aber jetzt nicht mehr erklären, müßte mich da erst wieder reindenken. Peter
inzwischen mag's ja andere PICs geben, aber ich habe mich damals in Assembler mit dem grausigen Banking herumgeplagt, das hat mich (wie vermutlich auch Peter) geprägt, aber auch auf modernen PICs oder AVRs würde ich für Anfänger immer C empfehlen (vorher allerdings C am PC lernen)
Peter Dannegger schrieb: > Ich hab damals für das Verstehen etwa 1h gebraucht. Ich kann die genaue > Funktion aber jetzt nicht mehr erklären, müßte mich da erst wieder > reindenken. Eine Stunde ist doch ok und absolut keine Schande. Um so eine Funktion anzuwenden muss man sie ja nicht haarklein erklären können, solange man sie im Prinzip mal verstanden hat. Mit "Tricksereien" hat es jedenfalls nichts zu tun, das Carry-Flag wird zum aktivieren des INCFSZ-Befehl abgefragt statt einem ADDC (den es ja bei PIC10..16 gar nicht gibt). Wenn man zwei Bytes addiert, kann nunmal nur eine Stelle überlaufen, so kompliziert ist das nicht. Gruß, Edson
> Beim PIC sollte man daher nur in C programmieren. Da sind dann die > ganzen trickreichen Bibliotheken bereits enthalten und man braucht nur > die Berechnungen einfach hinzuschreiben. > Und man muß sich nicht mit der lästigen Unterteilung des RAM und Flash > in mehrere Bänke rumärgern. Es sind dann nämlich auch sehr trickreiche > Adreßberechnungen notwendig. Ich kann dieser Meinung nur zustimmen. Ausschließlich C verwenden. Dies hat inzwischen sogar Microchip selbst eingesehen, und daher sind deren Application Notes für modernere PIC16 wie dem PIC16F1827 inzwischen nur noch in C, und auch der Compiler ist frei erhältlich. http://ww1.microchip.com/downloads/en/AppNotes/01303A.pdf http://ww1.microchip.com/downloads/en/AppNotes/Real%20Time%20Clock.zip
Rüttiger schrieb: > inzwischen mag's ja andere PICs geben, > aber ich habe mich damals in Assembler mit dem grausigen Banking > herumgeplagt, das hat mich (wie vermutlich auch Peter) geprägt, Das müssen ja wirklich furchtbare Erlebnisse gewesen sein. ;) Nein, das Banking ist nunmal Architektur-Bedingt und man kann es lieben oder auch hassen, man hat es in jedem Fall hinzunehmen wenn man einen solchen Controller für eine bestimmte Aufgabe ausgewählt hat. Ist ja nicht so, dass das Datenblatt nicht ausführlich über diesen Umstand Auskunft gäbe... Auch die kleineren PICs kann man natürlich in C programmieren, allerdings ist ein Compiler-Handbuch deutlich umfangreicher als beispielsweise ein PIC10F2xx-Datenblatt und 33 RISC-Befehle sind schnell erlernt. Da man ohne Assembler-Kenntnisse nie seinen Compiler wirklich verstehen kann, ist es sicher kein Fehler zunächst mit Assembler anzufangen. Gruß, Edson
Erich schrieb: > Dies hat inzwischen sogar Microchip selbst eingesehen, und daher sind > deren Application Notes für modernere PIC16 wie dem PIC16F1827 > inzwischen nur noch in C, und auch der Compiler ist frei erhältlich. Da würde ich nicht zuviel hinein interpretieren. Es gab immer schon AppNotes in C von Microchip, es wird auch immer wieder welche mit Assembler-Beispielen geben. Was es so gut wie nie gab, sind dieselben Beispiele in beiden Sprachen. Gruß, Edson
Naja, ich dachte PIC (zumindest die kleinen 12/16/18) sind sogesehen auf Assembler optimiert, als dass sie als C-Maschine einen 8051 optimal aussehen lassen?
123 schrieb: > wie war das beim pic 16 stack tife von 2? und dann mit C? > In wie weit der Compiler da noch ANSI C conform ist mag ich bezweifeln. Ich weiß ja nicht von welchem PIC du redest aber selbst der Steinzeitliche PIC16F84 hat einen 8 Level Stack, tendenz steigend (bei den neueren PICs). Peter Dannegger schrieb: > Man braucht lange, um das überhaupt zu verstehen. klar, der eine hat mit den Befehlen mehr zutun und der andere weniger. Aber ich z.B. (und ich hab länger [~3 Jahre] nichts mehr mit PIC-ASM gemacht) hab den Code da gelesen und habs auch gleich verstanden. Soll ja nichts heißen, ich z.B. komme mit dem AVR-ASM nicht klar, habs allerdings auch nie gelernt und/oder mich damit auseinander gesetzt. Peter Dannegger schrieb: > Es sind dann nämlich auch sehr trickreiche > Adreßberechnungen notwendig. Naja.. Trickreich is das nich soooo finde ich. die Brankadressierung sind die MSBs der Adressen. Das letzte bit in Bank 0 in einem kleine Speicher sind z.b. 0x7F und in Bank 1 0xFF usw. Man braucht nur eine Tabelle wo drin steht, welche Register welche Adresse hat. Demnach hat z.B. bei dem PIC16F84 PORTA das Register 0x05 und TRISA ist 0x85. Meister Eder schrieb: > Nein, das Banking ist nunmal Architektur-Bedingt und man kann es lieben > oder auch hassen, man hat es in jedem Fall hinzunehmen wenn man einen > solchen Controller für eine bestimmte Aufgabe ausgewählt hat. Ist ja > nicht so, dass das Datenblatt nicht ausführlich über diesen Umstand > Auskunft gäbe... Es ist ja auch nicht so, dass es ein Weltuntergang ist. Ohne ein PIC vs AVR-Krieg starten zu wollen: Mich stört es mehr einen µC "verfusen" zu können, als wenige male ne Bank umzuschalten. Ich will damit nur sagen, dass jeder µC irgendwo seine Stärken und Schwächen hat, manche mehr und manche weniger. Welchen Schwächen man akzeptieren kann/will und welche Stärken man braucht/will muss jeder für sich entscheiden.
Also mal direkt an den Meister Eder: Denkst du wirklich das du in der Lage bist, in vertretbarer Zeit, ein sinnvolles Assemblerprogramm auf dem PIC zu schreiben das in einer belibigen Kategorie (Größe, Geschwindigkeit, Übersichtlichkeit, etc.) gegen ein in C geschriebenes ankommt?
ich schrieb: > Mich stört es mehr einen µC "verfusen" zu > können, als wenige male ne Bank umzuschalten. Ja, aber sobald man aus Blödheit einmal auf die Schnauze gefallen ist, tritt das Problem nicht mehr auf. Das Bankumschalten bleibt.
Pumuckel schrieb: > Also mal direkt an den Meister Eder: > > Denkst du wirklich das du in der Lage bist, in vertretbarer Zeit, ein > sinnvolles Assemblerprogramm auf dem PIC zu schreiben das in einer > belibigen Kategorie (Größe, Geschwindigkeit, Übersichtlichkeit, etc.) > gegen ein in C geschriebenes ankommt? Das habe ich nirgends behauptet. Aber wenn du schon fragst, lass mich zurückfragen: 1. Welchen meinst du mit "dem PIC" konkret? 2. Man schreibt nicht einfach C, sondern man benutzt einen spezifischen Compiler. Welchen meinst du? 3. Deine Kategorien sind nicht sinnvoll. Geschwindigkeit ist nicht alles, ich schreib dort Assembler wo es schnell und vor allem zyklengenau gehen muss. Der Punkt "Übersichtlichkeit" zählt nicht, weil Programme in der Regel nicht fürs Tutorium geschrieben werden sondern fürs echte Leben. Kann C für sich beanspruchen, in dem Punkt "das Gelbe vom Ei" zu repräsentieren? 4. Zeit: In Assembler werde ich etwas länger brauchen, weil ich mehr tippen muss ;) Noch Fragen? Gruß, Edson
Pumuckel schrieb: > Denkst du wirklich das du in der Lage bist, in vertretbarer Zeit, ein > sinnvolles Assemblerprogramm auf dem PIC zu schreiben das in einer > belibigen Kategorie (Größe, Geschwindigkeit, Übersichtlichkeit, etc.) > gegen ein in C geschriebenes ankommt? Was manche in ASM für AVR können, können manche auch bei PICs. Doch ich glaub nich, das sich was im zusammenhang mit C und ASM was ändert, wenn es für PIC oder für eine anderen µC der ASM-Code ist. Das C eine Daseinsberechtigung hat, hat auch niemand bestritten. Pumuckel schrieb: > Ja, aber sobald man aus Blödheit einmal auf die Schnauze gefallen ist, > tritt das Problem nicht mehr auf. Das Bankumschalten bleibt. Joa. Wenn man aus "Blödheit" seinen µC verfused oder aus "Blödheit" den Bankwechsel vergisst und einfach nochmal neu Programmiert, was ist wohl schlimmer. Und ja, ans Bankwechseln muss man denken, genauso wie dass man das eine bit in den Fuses nicht setzen (oder löschen, kp) darf. Und wen die 2 oder 4 Zeilen mehr im ASM-Code so stören, dass das Bankwechseln der scheinbar größte Nachteil is.. naja.. der hat halt Pech und brauch nichts mit PICs machen. Jeder wie er will, wie ich sagte.
Meister Eder schrieb: > Das habe ich nirgends behauptet. Also was spricht dann für Assembler? > Aber wenn du schon fragst, lass mich zurückfragen: > > 1. Welchen meinst du mit "dem PIC" konkret? Beliebig. > 2. Man schreibt nicht einfach C, sondern man benutzt einen spezifischen > Compiler. Welchen meinst du? Beliebig, oder bessergesagt, die Gängigen, damit du nicht einen Exoten findest der nicht oder extrem schlecht optimiert. > 3. Deine Kategorien sind nicht sinnvoll. Kennst du bessere? > Geschwindigkeit ist nicht alles, ich schreib dort Assembler wo es > schnell und vor allem zyklengenau gehen muss. Was wie oft wirklich nötig ist? > Der Punkt "Übersichtlichkeit" zählt nicht, weil Programme in der Regel > nicht fürs Tutorium geschrieben werden sondern fürs echte Leben. Und Programme werden natürlich nie weiterentwickelt oder weitergegeben. Wenn ich irgendwas von vor einem Jahr in Assembler rauskram brauche ich deutlich länger als bei einem C Programm. > Kann C für sich beanspruchen, in dem Punkt "das Gelbe vom Ei" zu > repräsentieren? Von dem was zur Verfügung steht, eindeutig ja. > 4. Zeit: In Assembler werde ich etwas länger brauchen, weil ich mehr > tippen muss ;) Noch Fragen? Stimmt und weil du mehr Denken/Planen muss.
ich schrieb: > Joa. Wenn man aus "Blödheit" seinen µC verfused oder aus "Blödheit" den > Bankwechsel vergisst und einfach nochmal neu Programmiert, was ist wohl > schlimmer. Das "verfusen" scheint ja bei manchen Leuten echt häufig zu passieren. Wenn du die orginal Atmel-Programmer mit dem Studio benutzt kannst du das eigentlich ausschließen, mir zumindest ist es noch nicht passiert. Ansonsten gäbe es noch das HV-programming.
Wer heutzutage noch normale Anwendungen (ohne zwingende Notwendigkeit) in Assembler codiert, der fährt wahrscheinlich auch einen Holzvergaser. http://www.holzgas.ch/573.html Es sind möglicherweise geniale Einzellösungen, aber nix für Normalos. Vor Portierbarkeit gar nicht zu reden... Gruss
Pumuckel schrieb: > Das "verfusen" scheint ja bei manchen Leuten echt häufig zu passieren. > Wenn du die orginal Atmel-Programmer mit dem Studio benutzt kannst du > das eigentlich ausschließen, mir zumindest ist es noch nicht passiert. > Ansonsten gäbe es noch das HV-programming. Keine Ahnung. Ich hab noch nie wirklich AVRs programmiert. Und das verfusen ist nicht der Grund, ich hab PICs gelernt und bin da einfach geblieben. Allerdings versteh ich nich was du mit dem Beitrag davor sagen willst. Es hat keiner Bestritten, dass C übersichtlicher ist, dass es verständlicher ist, sich schneller programmieren lässt oder ähnliches. Es war nur gesagt, dass ASM speziell für PICs eine Katastrophe sein soll, was Meister Eder und ich eben nicht so sehen. Was anderes wurde nicht gesagt, es sei denn ich habs überlesen.
Pumuckel schrieb: >> Das habe ich nirgends behauptet. > Also was spricht dann für Assembler? Du überhöhst meine Position aber beträchtlich, wenn du meine Meinung als letztes Wort zum Thema C/ASM stilisierst. Pumuckel schrieb: > Beliebig, oder bessergesagt, die Gängigen, damit du nicht einen Exoten > findest der nicht oder extrem schlecht optimiert. Die gängigen C-Compiler für PIC10 bis PIC18 sind allesamt Exoten. Ausserdem implizierst du gerade dass ich meine Zeit für dein C vs. ASM-Spielchen opfere, wofür sie mir allerdings zu schade ist. Pumuckel schrieb: >> Geschwindigkeit ist nicht alles, ich schreib dort Assembler wo es >> schnell und vor allem zyklengenau gehen muss. > Was wie oft wirklich nötig ist? Die polemische Fragerei hat doch keinen Sinn. Wenn es dich wirklich interessiert findest du im Netz zahlreiche Quellen wo du dich informieren kannst. Soweit kommts noch, dass ich jetzt Anwendungen aufzählen muss, damit der gnä Herr in seiner Mittagspause was zu lesen hat... Gruß, Edson
als alter Pic-Anwender lese ich mit Interesse Eure Kommentare!
Ich kann Peter Dannegger nur Recht geben.
Es war für mich erstmals als Anfänger für Tage eine Herausforderung,
die Wahnsinns-Konfiguration in ihren Einzelheiten zu verstehen.
So sah sie aus:
#include<P16F627A.INC>
__config _BODEN_ON & _CP_OFF & _DATA_CP_OFF & _PWRTE_ON & _WDT_OFF
& _LVP_OFF & _MCLRE_ON & _INTRC_OSC_NOCLKOUT
;interner Quarz
radix dec ;alle nicht defin. Werte dezimal
;Configurationsergebnis =
;***********************************************************************
************
;Variable Definition (nach Anwendung anpassen)
CBLOCK 0x20 ;erste RAM Adresse = 20h anwählen
loop1 ;20h
loop2 ;21h
loop3 ;22h
ENDC ;mit ENDC unbedingt abschließen
;***********************************************************************
************
org 0x00 ;Reset ab Adresse 0
goto reset
;Vorbereitungen
reset movlw B'00111111' ;3F ins W-Register
movwf CMCON ;A0 bis A5 = digital setzen (Bank0)
clrf PORTB ;Wichtig, Register definitiv auf Null
setzen!
bsf STATUS,RP0 ;Bank 1 aktiviert
errorlevel -302
movlw B'11111111' ;alle RA auf Inputs
movwf TRISA ;Register in Bank1
movlw B'11000000' ;RB0-RB5 = Outp. RB6-RB7 = Inp.
movwf TRISB ;Register in Bank1
movlw B'11010111'
movwf OPTION_REG ;Register in Bank1
bcf STATUS,RP0 ;Bank 0 aktiviert
bsf PORTB,4 ;Kontroll-LED = AUS (Output = High)
errorlevel +302
goto start
Dank eines guten Lehrmeisters hatte ich es dann doch geschafft.
Nun hackt jetzt nicht auf mich herum, ich finde die AVRs leicht zu
erlernen,auch in Assembler UND BLEIBE DABEI
Grüße
Rolf
Hallo, Ich enpfand den ersten PIC als nicht wirklich schwer in Assembler zu programieren. Die Herrausforderungen vom 8085 auf den 8051 den 80286 und den 80386 fand ich wirklich deutlich schwiriger. Früher(tm) stellte sich das Problem eigentlich nicht. Dewn Assembler gab meist kostenlos und der Rest fing irgendwo bei 1KDM an und war daher einfach icht verfügbar. Darum habe ich Assembler gelernt und benutze ihn gern und intensiev. Mit C konnte ich mich nie richtig anfreunden weil bei allem was ich mache es immer nur aufs bitpuhlen ankahm. UNd neben meinen eigenen Fehlern noch die vom Compiler ertragen zu müssen fand ich eigentlich immer zu viel des bösen. Das bischen Banking bei den 12F und 16F Typen wird mich nicht davon abhalten - beim 80286 fand ichs echt ätzend. mfG Michael
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.