Hallo zusammen, ich arbeite mich gerade gerade in ein von Microchi erstelltes Tutorial ein (PICKit3 Starterkit). Das Tutorial deckt Assembler und C ab. Für mich zeigt sich, dass Assembler relativ aufwändig ist im vergleich zu C. Allerdings, wenn ich die Datenblätter der PIC18F ansehe, sind diese in Assembler gehalten. Wenn ich also wissen will die ich den PIC nutze, muss ich Assembler können. Meine Frage, wenn es schon einen Compiler für PIC18F gibt (C18 oder XC8), dann muss es doch dasselbe auch für die Sprache C geben oder? Also ein Datenblatt in dem genauso beschrieben wird wie man einen PIC in C programmiert. Könnt ihr mir da weiterhelfen?
Fuer die 16F habe ich das noch nicht vermisst. Statt: MOVLW 255 MOVWF ADCON1 in C (XC8) einfach: ADCON1 = 255; zu schreiben, brauche ich kein Tutorial.
Kein Tutorial. Eine Überischt in Form eines Datenblattes des Sprachumfangs in C für die Peripherie der PICs. Das habe ich gemeint.
Hano Glahr schrieb: > Kein Tutorial. Eine Überischt in Form eines Datenblattes des > Sprachumfangs in C für die Peripherie der PICs. Das habe ich gemeint. Ergänzung, es stellt sich für mich überdies die Frage ob es überhaupt Sinn macht sich mit Assembler beim PIC zu beschäftigen wenn es doch offiziell C-Compiler dafür gibt. Was meint ihr?
Hi, ich gehe mal schwer davon aus, dass der c-Compiler die selben Registernamen wie der Assembler von microchip definiert hat. Was die Perepherie angeht sollte das also wirklich egal sein. Obs Sinn macht, asm Beispiele und üben? Musst du selbst entscheiden. MMn schadet es sicher nicht wenigstens in Grundzügen eingestiegen zu sein. Es ist doch hilfreich bei vielem, bis hin zu schauen, was der compiler wann macht etc... Zudem ist als Hobby auch der Weg das Ziel. Bzw. so war es. Das Extrem möglichst ohne Weg am Ziel zu sein existiert auch. So musst du selber entscheiden.
Hano Glahr schrieb: > Kein Tutorial. Eine Überischt in Form eines Datenblattes des > Sprachumfangs in C für die Peripherie der PICs. Das habe ich gemeint. Diese Übersicht gibt es sehr wahrscheinlich nicht. Schon alleine deshalb, weil es in C normalerweise dafür keine 'Spezialbefehle' gibt, sondern man versucht, das alles mit Standard-C Mitteln abzudecken. Manchmal bieten Compiler Hersteller Erweiterungen an. Die sind aber auch so: hat man das Prinzip erst mal verstanden, dann funktioniert das an allen Ecken und Enden gleich. Was steht denn im Datenblatt? Da steht im wesentlichen, welche Bits in welchem Register zu setzen sind, damit sich welche Funktion aktiviert. Schön. Wenn du also die Register in C namentlich zur Benutzung hast UND dann auch noch die Bits als Namen zur Verfügung hast (wobei die höchst wahrscheinlich mit dem im Datenblatt verwendeten Namen übereinstimmen), dann hast du alles was du brauchst. Denn letzten Endes ist es der Sinn, der hinter dem Setzen oder Löschen eines Bits in einem Register steht, der zählt. Und natürlich alle Zusammenhänge die sich da rundum noch abspielen und die im Kapitel erläutert werden. Welche Sprache du benutzt ist dann völlig untergeordnet. Was zählt, dass ist das du verstanden hast, was zu tun ist. Wenn du der Ansicht bist, du bräuchtest nur Code-Schnipsel von irgendwo her zu kopieren und dann passt das schon, dann muss dir leider sagen, dass du mit Zitronen gehandelt hast. Code Schnipsel sind manchmal hilfreich, aber letzten Endes führt am Verständnis kein Weg vorbei.
:
Bearbeitet durch User
Hano Glahr schrieb: > Kein Tutorial. Eine Überischt in Form eines Datenblattes des > Sprachumfangs in C für die Peripherie der PICs. Das habe ich gemeint. Ein Datenblatt kenne ich im dem Zusammenhang zwar nicht, aber die Seiten von Sprut sind hier vielleicht ganz hilfreich: http://sprut.de/electronic/pic/c/pic_c/pic_c90_pic_spezifisches.html
Assemblerschnipsel im Datenblatt bzw. User Manual sind doch reine Extras, Luxus pur, das müßten sie eigentlich gar nicht tun. Andere Datenblätter sind dementsprechend eben sehr spartanisch minimalistisch. Sei doch deshalb froh, daß da überhaupt was steht. Die Programmiersprache möchten die da auch überhaupt gar nicht behandeln. Dafür sind andere zuständig. Assembler ist auch das neutralste gegenüber einer Hochsprache, weshalb man es für Beispiele wohl wählte. Der jenige der Basic kann, kann mit Pascal oder Fortran weniger anfangen, und umgekehrt. Assembler ist aber für diesen µC die gemeinsame Schnittmenge. Der Code, den jeder Hochsprachencompiler als unterste Schicht vor dem reinen Maschinencode auch erzeugt. Und es ist nicht schlecht, wenn man vom Assembler seines verwendeten µC ein klein wenig versteht. Spätestens bei Programmfehlern muß man sowieso auch mal einen Blick in den Assemblercode werfen, was der Hochsprachencompiler für einen Assemblercode erzeugte. Da gibt es durchaus schon mal Fehler oder Dinge, die nicht so laufen wie man es sich vorstellt.
Ob Assembler Sinn macht, ist nur für dich allein entscheidend. Frag so was hier besser nicht ;-) Der Sprachumfang in C sind erst mal die Register, die in C genau die selben Namen haben. Dann kommen noch die ganzen Bitfeld Unions dazu. Das ganze ist in den Prozessorheadern deklariert. (Beim XC8 z.B im include des Compiler Installationsverzeichnisses)
1 | ...
|
2 | #ifndef __XC8
|
3 | #warning Header file pic18f25k22.h included directly. Use #include <xc.h> instead.
|
4 | #endif
|
5 | |
6 | /*
|
7 | * Register Definitions
|
8 | * */
|
9 | |
10 | // Register: ANSELA
|
11 | extern volatile unsigned char ANSELA @ 0xF38; |
12 | #ifndef _LIB_BUILD
|
13 | asm("ANSELA equ 0F38h"); |
14 | #endif
|
15 | // bitfield definitions
|
16 | typedef union { |
17 | struct { |
18 | unsigned ANSA0 :1; |
19 | unsigned ANSA1 :1; |
20 | unsigned ANSA2 :1; |
21 | unsigned ANSA3 :1; |
22 | unsigned :1; |
23 | unsigned ANSA5 :1; |
24 | };
|
25 | } ANSELAbits_t; |
26 | extern volatile ANSELAbits_t ANSELAbits @ 0xF38; |
27 | ...
|
Weil das alles genau so heist, brauchst du also wenn du es erst mal weißt, kein extra C-Datenblatt. Für die allgemeinen C-Sachen speziell für den enztsprechenden Compiler gibt es den User Guide im docs Verzeichnis. Dann gibt es für PIC18 noch die Peripheral libraries, die allerdings seit der neuesten XC8 Version (1.35) nicht mehr automatisch installiert werden, sondern extra heruntergeladen und installiert werden müssen. Für die Bibliotheken gibt es natürlich auch eine Doku (docs) Der neueste Schrei ist der MCC (microchip code creator). Gefällt mir bisher aber nicht :-( Also was brauchst du nochmal?
@ Hano Glahr (Gast) Hier sind die User Guides fur XC8 und C18 - die wirst Du benoetigen wenn Du in C programmieren willst und sie beantworten moeglicherweise deine Frage: https://www.google.ie/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CCkQFjABahUKEwj-8aX128THAhXLFtsKHb3sB-s&url=http%3A%2F%2Fww1.microchip.com%2Fdownloads%2Fen%2FDeviceDoc%2F50002053E.pdf&ei=aKDcVf6dOsut7Aa92Z_YDg&usg=AFQjCNHlOYNwvR0KPhhFb8VH7Ry9Rl4ZUg&cad=rja https://www.google.ie/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCEQFjAAahUKEwiKxOWR3MTHAhUjStsKHcy5BDU&url=http%3A%2F%2Fww1.microchip.com%2Fdownloads%2Fen%2FDeviceDoc%2F51288c.pdf&ei=pKDcVYriK6OU7QbM85KoAw&usg=AFQjCNFJyHmYQFBOjX65rYNor7fEM2Hdiw&cad=rja Volker S. schrieb: > Der neueste Schrei ist der MCC (microchip code creator). Gefällt mir > bisher aber nicht :-( "Neuester Schrei" klingt abwertend - hab MCC zwar selbst noch nicht benutzt finde es aber nicht schlecht. Hier ist eine von 5 "Microchip Minutes" Videos die zeigen wie schnell man damit ein Programm erstellen kann (ohne dabei die Kontrolle ueber den Code zu verlieren). https://www.youtube.com/watch?v=4nOnEl8zLeM&list=PL9B4edd-p2ahRAG3QFVtrbtJf8HJH0zSZ
Hano Glahr schrieb: > Also > ein Datenblatt in dem genauso beschrieben wird wie man einen PIC in C > programmiert. Könnt ihr mir da weiterhelfen? Ja. Lies das Manual so wie es ist und lerne, die Maschinenbefehle zu verstehen - damit du einen Eindruck bekommst, mit was für einer Maschine du dich befassen willst. Das gehört schlichtweg dazu und was du da formuliert hast, klingt nach Überfliegerei. Also: Das Manual soll die Hardware erklären und nicht irgend eine Programmiersprache, die von hause aus rein garnix mit der konkreten Hardware zu tun hat. Das ist der Punkt. Ja, auch der Satz von Maschinenbefehlen gehört deshalb ins Manual. Ebenso die Darstellung, wie denn nun die Funktionalität von Registern, Akkus, Stack usw. konkret ist. Abgesehen davon gibt es zuweilen auch ganz konkrete Stellen, wo man GENAU SO UND NICHT ANDERS irgendwelche Maschinenbefehle verwenden muß, Beispiele sind Zugriff auf EEPROM und Flashrom - genauer gesagt die Sequenzen zum Freischalten von speziellen Funktionen. So etwas sollte gewußt und verstanden sein. Die bloße Hoffnung, daß der Compiler es wohl schon richtig machen würde, ist zu wenig. Dabei ist eigentlich die Doku von Microchip geradezu mustergültig und vorbildlich. Also meckere du mal nicht. Ich hätte da einiges an anderen Beispielen: z.B. einige Prozessoren von NEC (78K4 Reihe), wo man zum Entriegeln diverser Hardware einige Bitkombinationen in den Assemblercode setzen mußte, die im veröffentlichten Assembler-Befehlsumfang überhaupt nicht enthalten waren. Da kommt Freude auf! Versuche sowas mal in C überhaupt formulieren zu wollen... Insgesamt finde ich es ärgerlich, daß hier so viele Leute auftreten, die ganz dediziert NICHT über den Tellerrand von C hinausblicken wollen, die konkrete Hardware ebenso dediziert NICHT zur Kenntnis nehmen wollen und die dennoch von sich behaupten, sie seien interessierte Mikrocontroller-Leute. Nein, sind sie nicht, sondern (*** unanständiges Schimpfwort..). Wer Programme zum Simulieren von Antennen oder Hohlraumresonatoren oder Magnetfeldern oder für Wetterprognosen schreiben will und dies deshalb in Fortran oder anderen maschinenunabhängigen Sprachen tut, der betätigt sich auf einer ganz anderen Ebene als jemand, der einen Mikrocontroller für irgendeine Funktionalität auf seiner Leiterplatte programmieren will. Von letzterem sollte man mit Fug und Recht verlangen dürfen, daß er sich mit der zugrundeliegenden Hardware wirklich auskennt - wozu eben auch (s.o.) zumindest Grundkenntnis von deren Maschinenbefehle gehört. W.S.
Toxic schrieb: > "Neuester Schrei" klingt abwertend - hab MCC zwar selbst noch nicht > benutzt finde es aber nicht schlecht. Du hast es noch nicht benutzt, findest es aber nicht schlecht? Krass ;-) Ich wollte den MCC in die Unterlagen für unsere Studierenden mit aufnehmen war aber bei meinen ersten Versuchen nicht so überzeugt. Ich werde es wohl nur kurz erwähnen dass es das gibt, aber nicht auf die Verwendung eingehen. Da wird eine Unmenge Zeug erstellt, von dem die Anfänger dann im Endeffekt nichts verstanden haben. Das ganze landet dann in 'zig Dateien die automatisch zum Projekt hinzugefügt werden. Wenn es ähnlich abliefe wie bei den Config-Settings wäre es mir möglicherweise schon sympatischer. Da wird Code erstellt und du kannst ihn dann kopieren und irgendwo in eine Datei deiner Wahl einfügen. (Hier wäre es für mich sogar OK wenn automatisch eine Datei erstellt und dem Projekt hinzu gefügt würde, weil ich das gewöhnlich genau so mache) Ich kann mich momentan einfach noch nicht daran gewöhnen und vermutlich stört mich auch, dass dadurch die PLib nicht mehr automatisch mit den jeweiligen Compilern installiert wird, an die ich mich schon gewöhnt habe. Deren Funktionen verwende ich auch nicht alle, aber für die Initialisierungsphase schon. Also so was wie OpenUSART(), aber nie ReadUSART() wo es auch ein "neuesByte = RCREG; tut. Letztendlich habe ich mich nach etwas Kampf (http://www.microchip.com/forums/m668751.aspx) aber auch mit XC8 abgefunden (habe vorher immer C18 verwendet) also wird's mit MCC möglicherweise ja auch noch was.
Nachdem ich hier ein bisschen geschimpft wurde hust und ich mir auch mal ein C-Tutorial von Microchip angeschaut habe, bin ich zu dem Schluss gekommen, dass ich die Assemblervariante zuerst durcharbeiten werde. Im C-Tutorial wird - nur um ein Beispiel zu nennen - zwar erwähnt, dass es Programm und Datenspeicher gibt, aber es wird bei weitem nicht so detailliert darauf eingegangen wie im Assembler Tutorial (Wie er aufgeteilt ist, was er alles beinhaltet etc). Da ich aber grundsätzlich die Dinge verstehen möchte mit denen ich zu tun habe, arbeite ich das Assembler-Tutorial zuerst durch, dann habe ich die Hardware sicher soweit verstanden um auch mit dem Datenblatt zurecht zu kommen. Später, und soviel ist sicher, werde ich in C programmieren, weil es einfacher ist.
Und danke für die Verweise auf die Dokus C18 und XC8. >Dabei ist eigentlich die Doku von Microchip geradezu mustergültig und >vorbildlich. Also meckere du mal nicht. Ich will auch gar nicht über Microchip schimpfen. Einer der Gründe weshalb ich mich für Microchip entschieden habe ist der, dass Microchip einen sehr professionellen Eindruck auf mich gemacht hat. Compiler, Tutorials, spezifische Hardware - alles aus einer Hand und gut dokumentiert (so zumindest mein Eindruck).
Volker S. schrieb: > Du hast es noch nicht benutzt, findest es aber nicht schlecht? > Krass ;-) Wichtig ist , dass Du als Profi weisst was Microchip da wieder fuer einen Mist fabriziert.Bewirb dich bei denen und mach mal ordentlich Dampf dort !
Hano Glahr schrieb: > Nachdem ich hier ein bisschen geschimpft wurde hust und ich mir auch > mal ein C-Tutorial von Microchip angeschaut habe, bin ich zu dem Schluss > gekommen, dass ich die Assemblervariante zuerst durcharbeiten werde. Das ist sicher kein Fehler um den Controller wirklich kennenzulernen. C ist auf jedem Controller gleich. Die Registernamen aus den Datenblatt kannst Du auch in C 1:1 anwenden. Ist dann letztlich eine Frage des Geschmacks und der Leidensfähigkeit, grade bei größeren Programmen. Zur Doku wurde ja schon das XC8 Manual genannt. Da stehen auch die Besonderheiten des Compilers und auch die Makros drin. Interessant wäre wohl nich die Doku der PLIB. Da sind Beschreibungen von Funktionen drin, die die Hardware betreffen. ADC, Flash, EEPROM usw. Und keine Angst vor dem Umfang. Sind alles insgesamt wohl tausende Seiten, aber wenn man den Einstieg mal gefunden hat eine gute Quelle um mal was nachzuschlagen.
Toxic schrieb: > Volker S. schrieb: > Du hast es noch nicht benutzt, findest es aber nicht schlecht? > Krass ;-) > > Wichtig ist , dass Du als Profi weisst was Microchip da wieder fuer > einen Mist fabriziert.Bewirb dich bei denen und mach mal ordentlich > Dampf dort ! Ich sag doch gar nicht, dass es totaler Mist ist Volker S. schrieb: > Ich kann mich momentan einfach noch nicht daran gewöhnen und vermutlich > stört mich auch, dass dadurch die PLib nicht mehr... Im Moment habe ich nur das "Gefühl", dass ein " Profi" mehr Zeit verbraucht den erzeugten Code übersichtlich zurecht zu stutzen als wenn er alles selbst gescjtieben hätte. Für Anfänger die wirklich etwas verstehen wollen scheint es mir auch ungeeignet. Also wer ist die Zielgruppe? (im 8bit Bereich)
Bad U. schrieb: > Interessant wäre wohl nich die Doku der PLIB. Da sind Beschreibungen von > Funktionen drin, die die Hardware betreffen. ADC, Flash, EEPROM usw. Auf die Zukunft von plib würde ich nicht wetten. z.B. -> http://www.microchip.com/forums/FindPost/886302
vloki schrieb: > Auf die Zukunft von plib würde ich nicht wetten. OK. Danke für die Info. Ich nutzte sie nur für Flashzugriffe bei meinem Bootloader. Sonst habe ich mir alles selbst erstellt. Aber grade als Anfänger kann man mit der Lib wohl schnell erste Erfolge haben und dann tiefer einsteigen.
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.