Ich möchte mich ein wenig in PIC Controller einarbeiten und habe mir dazu folgendes zugelegt. Buch: Mikrocontroller Basics mit PIC, Tam Hanna, Elektor Verlag MPLAB X IDE in der Version 4.15 PICKIT 3 PIC 16F18877 Alles wie vom Autor empfohlen. Auch die Einrichtung der IDE und des Controllers habe ich genau so gemacht wie vom Autor empfohlen. Beim ersten Projekt jedoch bekomme ich sofort einen Fehler: make[2]: *** [build/default/production/newpic_8b_simple.o] Error 1 make[1]: *** [.build-conf] Error 2 make: *** [.build-impl] Error 2 .... BUILD FAILED (exit value 2, total time: 1s) Der Code ist folgender: *********************************************************************** ; TODO INSERT CONFIG CODE HERE USING CONFIG BITS GENERATOR LIST p=16f18877 #include <p16f18877.inc> RES_VECT CODE 0x0000 ; processor reset vector GOTO START ; go to beginning of program MAIN_PROG CODE ; let linker place main program START ; set Bank 0, we never know BANKSEL TRISA MOVLW B'00000000' MOVWF TRISA BANKSEL ANSELA MOVLW B'00000000' MOVWF ANSELA BANKSEL PORTA MOVLW B'10101010' MOVWF PORTA COMF PORTA, 1 ; to F GOTO WORK ; loop forever END ************************************************************************ Kann mir jemand weiterhelfen? Gruß Karl
:
Bearbeitet durch User
Karl Z. schrieb: > PIC 16F18877 Da hast du ein bissel Pech, denn diese Sorte hat einen 15 Bit breiten Maschinencode. Hättest du einen kleineren, älteren Typ genommen, dann hättest du meinen Assembler nehmen können. So aber mußt du eben die Tools von Microchip nehmen und dir die Übersetzungsliste anschauen. Mit dem bloßen Nennen von "Error 1" und "Error 2" kann ich (und wohl auch andere) nicht allzuviel anfangen. Ich häng dir mal deinen Codeschnipsel in etwas umgemodelter Form hier dran. W.S.
Mit "Error 1" kann natürlich niemand was anfangen. Da muß irgendwo noch stehen, was für ein Error und in welcher Zeile. Warum willst Du Dich überhaupt noch mit Assembler abquälen? Assembler ist auf den PICs besonders häßlich mit den ganzen Bank- und Pageumschaltungen, sowie Hardwarestack.
Alles was ich zu den merkwürdigen Fehlern gelesen habe, hat mit 32/64bit Problemen bzw. einer nicht kompatiblen Java Version zu tun. Wäre eine aktuelle Version keine Alternative? https://www.microchip.com/mplab/mplab-x-ide
Vielen Dank für die zahlreichen Antworten. Leider bringt mich das alles nicht so richtig weiter. Ich fange ja erst mit Pics an und obwohl ich mich streng an das Buch halte, scheitere ich schon nach ca. 20 Seiten. Naja, das wars dann halt. Gruß Karl
:
Bearbeitet durch User
Karl Z. schrieb: > make[2]: *** [build/default/production/newpic_8b_simple.o] Error 1 Nur als kleiner Tipp: Error 1 oder Error 2 muss nicht zwingend ein Fehler im Source-Code sein. Ich hatte auch schon das Problem, das Files nicht existierten bzw. falscher Pfad, ein Fehler im Makefile oder eine falsch konfig. Umgebung...
Karl Z. schrieb: > scheitere ich schon nach ca. 20 Seiten. Naja, das wars dann halt. So ist das halt, in der Welt funktioniert selten etwas optimal. Wie hast du geschafft, selbständig zu laufen ?
Karl Z. schrieb: > Naja, das wars dann halt. Das ist leider der Grund warum Leute Arduino nutzen. Da will sich mal einer mit der Hardware vertraut machen und dann so ein Mist. Evtl. fehlt noch irgendwo eine Einstellung, aber so eine aufgeblasene schrottige IDE ist schwer zu durchschauen, da muss man sich viel mit beschäftigen. Was passiert, wenn du ein "leeres" PRogramm versuchst, z.B. nur LIST und/oder include?
Karl Z. schrieb: > Ich fange ja erst mit Pics an und obwohl ich > mich streng an das Buch halte, scheitere ich schon nach ca. 20 Seiten. Ich geb dir nen Rat: Fange nicht mit einem Buch von irgend einem Schreiberling an - diese Leute wollen ein Buch vollkriegen um damit Geld zu verdienen, aber sie wollen dir nicht wirklich helfen. Sondern gehe anders vor: - suche dir einen kleineren und überschaubaren PIC aus der PIC16 Reihe aus. Nicht das Allerneueste und zu älteren Chips inkompatible, sondern etwas bereits gut Eingeführtes. - lies dessen Manual, um zu verstehen, wie dieser Chip funktioniert - denke dir irgend eine für dich sinnvolle Anwendung aus und denke dir dazu die erforderliche Schaltung aus - fange an, die für den gedachten Zweck erforderliche Firmware zu entwickeln. Und nein, nicht sofort Quellcode hinschreiben, sondern zuerst die nötigen Teile skizzieren, quasi das Software-Blockschaltbild. - schau dir den Befehlssatz etwas genauer an, lerne wie man am sinnvollsten das eine oder andere Detail macht. - denke dir eine formale Struktur für deine Quellen aus. Also was du in welcher Reihenfolge schreibst. - dann erst kommt das Schreiben der Quellcode-Stücke dran. Ich geb dir hier mal ein Beispiel-Projekt zum Anschauen. Das ist ein Taschen-Frequenzzähler bis so etwa 100 MHz. https://www.mikrocontroller.net/attachment/474142/Frequenzzaehler.zip und https://www.mikrocontroller.net/attachment/474143/Count100_Quellen.zip Die erste Datei enthält die Eagle-Dateien für Schaltung+Board. Für ein µC-Projekt braucht man zum Verstehen der Firmware auch die Schaltung, in der der µC drin werkelt. Die zweite Datei enthält die Quellen, die Übersetzungsliste und das fertige Hexfile. Es ist allerdings so, daß ich mir damals (vor fast 30 Jahren) meinen eigenen Asembler schrieb, weil der von Microchip mir zu lausig war (und immer noch ist). Wenn du das Zeug von Mikrochip verwenden willst, dann mußt du die Quellen eben dezent umschreiben. Karl Z. schrieb: > Naja, das wars dann halt. > Gruß Karl OK, wenn du schon jetzt die Flinte ins Korn geworfen hast, dann war's das auch meinerseits, andernfalls sag was und ich poste hier auch mal meinen Eigenbau-Assembler. W.S. ps: Peter D. schrieb: > Warum willst Du Dich überhaupt noch mit Assembler abquälen? > Assembler ist auf den PICs besonders häßlich mit den ganzen Bank- und > Pageumschaltungen, sowie Hardwarestack. Das ist lediglich deine tiefe innere Abneigung gegen die PIC's. Ich sehe das ganz anders. Mit einem guten Assembler ist das Programmieren leicht, übersichtlich und elegant.
So. Ich hab mal einen Blick in dieses Buch geworfen, siehe da: https://www.elektor.de/mikrocontroller-basics-mit-pic-pdf Das Buch kostet über 30€ und es ist mMn wieder mal eines aus der großen Riege von Büchern wie "Alles über XYZ" oder "Das große XYZ Buch". Also ein auf die schnelle Tour zusammengeklatschtes Buch ohne wirklichen Tiefgang. Man möchte meinen, daß der Autor noch nie selber einen PIC jemals aus der Nähe gesehen hätte. Also: rausgeschmissenes Geld. Mit jedem Manual von Microchip ist man um Längen besser bedient. W.S.
Jens M. schrieb: > Das ist leider der Grund warum Leute Arduino nutzen. Dann müssen die Arduino-Entwickler ja was richtig gemacht haben. Ich habe auch den Eindruck, daß er hervorragend für Einsteiger geeignet ist. Und da er auf C/C++ basiert, ist man nicht auf einer Assemblerinsel gefangen, sondern kann einmal entwickelten Code auch in anderen Umgebungen und auf anderen Cores weiterverwenden. Er ist auch nicht so hoch komplex, überladen und ressourcenhungrig, wie die Linux basierenden Entwicklungsboards.
:
Bearbeitet durch User
W.S. schrieb: > Das ist lediglich deine tiefe innere Abneigung gegen die PIC's. Die tiefe innere Abneigung gegen PICs gibt es aber häufiger - ich habe sie auch. Beruflich musste ich mich mit zwei oder drei dieser Dinger beschäftigen. Was man mit anderen uCs in null-komma-nix hinbekommt (auch ohne Erfahrung mit dem speziellen Controller), ist beim PIC immer etwas komplizierter. Erst kämpft man mit den Tools, dann mit den seltsam implementierten Peripherien und irgendwann kommt man dann doch zu seiner eigentlichen Applikation. Wenn man die dann irgendwann hat, kämpft man wieder mit den Programmiertools... Ich habe beruflich und privat schon einige uCs mit Software versorgt (AVR, AVR32, MPC56xx, STM32, Kinetis, LPC, S12(X), Fujitsu MB9-irgendwas, C166,...), aber keiner hat bisher solche "Schmerzen" bereitet, wie die PICs.
MaWin schrieb: > So ist das halt, in der Welt funktioniert selten etwas optimal. > Wie hast du geschafft, selbständig zu laufen ? Leute die gleich persönlich beleidigend werden, gibt es leider in jedem Forum. Sie tragen aber nichts wirklich geistreiches zum Inhalt bei. Den anderen vielen, vielen Dank für eure Bemühungen. Aber ich bleibe trotzdem bei meinem Arduino bzw. den Atmel AVR Chips. Die reichen für meine Zwecke vollständig aus. Ich wollte mich nur interessehalber auch mal mit PICs beschäftigen, ohne dabei grössere Hürden nehmen zu wollen. Es ist halt auch eine Frage des Aufwands den man treiben möchte. Gruss Karl
Karl Z. schrieb: > Ich wollte mich nur interessehalber auch > mal mit PICs beschäftigen, ohne dabei grössere Hürden nehmen zu wollen. Bist halt ein 'Dünnbrettbohrer' ohne wirkliche Ambitionen Dich in neue Betätigungsfelder einzuarbeiten. Falls in dir doch noch Reste eine Ehrgeizes aufkeimen sollte: Nach einer .err datei suchen, da steht vielleicht noch was drin *Überprüfen ob die Pfade zum assembler richtig gesetzt sind *statt über eine Klickkacki Gui die toolchain manuell benutzen "The C language combines all the power of assembly language with all the ease-of-use of assembly language."
Karl Z. schrieb: > Der Code ist folgender: > *********************************************************************** > ; TODO INSERT CONFIG CODE HERE USING CONFIG BITS GENERATOR Frage: Wurde der Pic wie in der Anmerkung oben verlangt auch konfiguriert? Meine Codes beginnen in den ersten Zeilen z.B. so: list p=12F1840 ; list directive to define processor #include <p12F1840.inc> ; processor specific variable definitions ;*********************************************************************** ******* __CONFIG _CONFIG1, b'00111110000100' ;pwrte, wdte, intosc MCLR OSC etc. P33...35 __CONFIG _CONFIG2, b'01001111111110' ;LVPoff; BORV; PLLEN, selfwrite prot on, stackoverflowresetON,.... P33...35 Wie deine config-words lauten müssen findet man im Datenblatt. Alternativ kann man die Konfiguration aber auch mit dem "config bit generator" von MPLAB erstellen. Das hab ich aber bisher noch nie gemacht, sondern immer direkt im code festgelegt. Für den PIC-Einstieg findet man hervorragende Erklärungen bei sprut.de
Jens M. schrieb: > Das ist leider der Grund warum Leute Arduino nutzen. Nicht wirklich, da gibt es bei der Erstinstallation auch Ärger, weil notwenige Treiber nicht mit installiert werden, man ein chinesischen CH340 Exemplar erwischt, selbst ein Original so ewig lange braucht um den Treiber zu installieren dass man in der Zeit schon 10 mal den Fehler sucht, das Internet durchforstet, die IDE neu gestartet, den Gerätemanager aufgemacht, den Rechner neu gebootet (uups, Installation von vorne) hat, weil niemand denkt dass das dermassen lange dauern kann.
Tam Hanna ist aber auch ein spezieller Typ, siehe seine Videos auf YouTube... Muß nicht heißen das das Buch schlecht ist.
Karl Z. schrieb: > Ich wollte mich nur interessehalber auch > mal mit PICs beschäftigen, ohne dabei grössere Hürden nehmen zu wollen. > Es ist halt auch eine Frage des Aufwands den man treiben möchte. Eben. > Naja, das wars dann halt. > Gruß Karl Schönen Tag noch aswe schrieb: > Beruflich musste ich mich mit zwei oder drei dieser Dinger beschäftigen. > Was man mit anderen uCs in null-komma-nix hinbekommt (auch ohne > Erfahrung mit dem speziellen Controller), ist beim PIC immer etwas > komplizierter. Verstehe ich nicht, selber hab ich mit allen möglichen Controllern gearbeitet und die Einstiegshürde war überall gleich. Out of the Box ist nie was gelaufen und Spezialitäten haben Sie alle. > Erst kämpft man mit den Tools, MPLAB ist wohl mit Abstand das schrecklichste Tool was man in der Branche finden kann. Nix funktioniert, alles im ständigen Wandel und im besten Fall gibt es Verschlimmbesserungen. Hab ich aber nie genutzt da es sehr gute Tools von anderen Anbietern gibt. Inzwischen ist das aber etwas besser geworden. > dann mit den seltsam implementierten Peripherien die werden genau so über Register angesprochen wie überall anders auch. > und irgendwann kommt man dann doch zu seiner > eigentlichen Applikation. Mein erster Blinky hat ne halbe Stunde gedauert, wg. anloger Teile die man abschalten musste. Seitdem war das nie wieder ein Problem. > Wenn man die dann irgendwann hat, kämpft man > wieder mit den Programmiertools.. Vermutlich auch MPLAB, standalone sind die super zu bedienen. Microchip sieht das wohl ähnlich und hat die Progger von MPLAB getrennt. Deren tools kann man jetzt alle per batch steuern.
W.S. schrieb: > Das ist lediglich deine tiefe innere Abneigung gegen die PIC's. Sprach derjenige mit tiefsten Abneigungen gegenüber DMA, Debuggern und selbst der libc ;)
Peter D. schrieb: > Dann müssen die Arduino-Entwickler ja was richtig gemacht haben. > Ich habe auch den Eindruck, daß er hervorragend für Einsteiger geeignet > ist. Ja, und zwar eine offene billige Hardware und ein verkrüppeltes Stück Software, das aber genau weil es so viel Arbeit automatisiert abnimmt in den meisten Fällen funktionert. Wenn aber nicht, dann ist man genau so gearscht wie mit anderen IDEs. Peter D. schrieb: > Und da er auf C/C++ basiert, ist man nicht auf einer Assemblerinsel > gefangen, sondern kann einmal entwickelten Code auch in anderen > Umgebungen und auf anderen Cores weiterverwenden. Quatsch. Die Portierbarkeit basiert ganz erheblich auf dem Code selber, also wie derjenige schreibt. Ein Anfänger der Arduino nutzt ist da ganz sicher nicht portabel, sobald er von den unerträglich großen und langsamen Funktionen wie digitalWrite() abkommt und auch wenn man was anderes wie Arduino nutzen will. Also ist Arduino wie so vieles andere auch primär zu sich selber kompatibel. Ja, man kann portabel schreiben, aber das kann man auch woanders und wenn man C in welcher Variante auch immer so gut beherrscht das man das kann dann nutzt man die Arduino-IDE nicht mehr. Peter D. schrieb: > Er ist auch nicht so hoch komplex, überladen und ressourcenhungrig, wie > die Linux basierenden Entwicklungsboards. Das ist wahr, aber auch die MPLAB-X ist wie so viele IDEs heutzutage zusammengeklebter Müll, etliche hundert MB für einen Texteditor und einen Compiler ist schon hart. Gilt aber für Arduino auch, da ist auch vieles weit größer als es müsste. Baum schrieb: > Wurde der Pic wie in der Anmerkung oben verlangt auch > konfiguriert? Das ist für die Funktion der Schaltung wichtig, aber nicht für's kompilieren. Der Compiler nimmt einfach defaults an, die laufen vielleicht nicht, aber ein Hexfile kommt raus.
Pete K. schrieb: > Ist WORK denn jetzt irgendwo definiert? Stör bitte die Diskussion nicht mit Detailfragen. Falls es dringend ist, schick dem TO 'ne PM.
ich möchte auch mal an sprut.de erinnern, der behandelt zwar ältere Typen, ist aber für den Anfang super
Kannst du Bitte den Gesamten Output posten? Da muss noch was Anderes sein vor den make Fehlern.
Angehängte Dateien:
-
test_asm.jpg
150 KB
Ich habe den code jetzt in MPLAB X 5.10 getestet und die Fehler ausgebessert. Anmerkung: Die Fehler werden einzeln von MPLAB (inkl. der Zeilennummern) aufgelistet - man muss nur nach oben scrollen um das zu sehen. Im Wesentlichen fehlt der label "WORK" Beim Einfügen hatte ich noch zahlreiche andere Fehler weil die labels nicht ganz links standen und der Code nicht in der nächsten Spalte eingerückt war. Das ist vermutlich nur bei mir beim Einfügen passiert. ....dann funktioniert es. (Einen neuen label "WORK" hab ich vor der Zeile goto WORK eingefügt.) Die Zeilen "***************" brauchen auch ein führendes ";" um als Kommentar zu gelten... (falls die überhaupt im *.asm -file stehen. Der code vom beiliegenden screenshot wurde dann "fehlerfrei akzeptiert".
Peter D. schrieb: > Dann müssen die Arduino-Entwickler ja was richtig gemacht haben. > Ich habe auch den Eindruck, daß er hervorragend für Einsteiger geeignet > ist. Nö. Es ist hervorragend geeignet - aber eben nur für Leute, die ihrerseits eben NICHT einsteigen wollen, sondern quasi ernten ohne zu säen. OK, ist recht christlich, gelle. Mal im Klartext: Arduino ist für Leute, die einen µC einsetzen wollen, aber ausdrücklich NICHT sich mit eben dem µC befassen wollen. Benutzen ohne zu begreifen, ohne Wissen und Können sich zu erarbeiten. Sowas nenne ich nicht "Einsteiger". Ich hab da ganz andere Wörter dafür. Und dieser Thread hat sich offensichtlich auch erledigt, der TO meinte, mal eben auf die Schnelle in die PIC's hinein zu riechen. Aber er bleibt denn doch lieber bei seinen Arduinos, siehe oben. Der Umstand, daß die PIC's anders sind als ein Arduino, ist so manchem eben zu mühsam. W.S.
aswe schrieb: > aber keiner hat bisher solche "Schmerzen" > bereitet, wie die PICs. Ich sag mal so, wenn man den Fehler macht, vorher schon eine andere Architektur zu kennen, dann fällt es wirklich sehr schwer, das Niveau wieder auf einen extrem eingeschränkten Befehlssatz, segmentierten RAM, IO, Codespace und Hardwarestack zurück zu schrauben. Ich hatte auch mal MPLAB installiert, ein PIC12-Datenblatt angeschaut, dann mit dem Kopf geschüttelt und alles ganz schnell wieder von der Platte gelöscht. Ich kannte ja vorher schon 8051 und AVR.
Hallo, Peter D. schrieb: > Ich hatte auch mal MPLAB installiert, ein PIC12-Datenblatt angeschaut, > dann mit dem Kopf geschüttelt und alles ganz schnell wieder von der > Platte gelöscht. Mir hat das hier gereicht, um zu wissen das PIC-Prozessoren nicht das Richtige für mich sind: http://www.sprut.de/electronic/pic/fallen/fallen.html rhf
Roland F. schrieb: > Mir hat das hier gereicht, um zu wissen das PIC-Prozessoren nicht das > Richtige für mich sind: > http://www.sprut.de/electronic/pic/fallen/fallen.html Wenn man es weiss, ist es gut. Und viele dieser Fallen gelten bei den moderneren PICs nicht mehr
Roland F. schrieb: > Mir hat das hier gereicht, um zu wissen das PIC-Prozessoren nicht das > Richtige für mich sind: a) Steinalt b) Teilweise falsch c) zum Teil bei aktuellen Chips nicht mehr zutreffend d) Alles im DaBla erklärt Und komm mir nicht das andere Proze solche "Fallen" nicht haben. Genau die nicht, aber dafür andere. Die dämlichste bei AVR z.B. ist die, das die ihre Fuses nicht im Programmspeicher abbilden und man zu einer Hexdatei immer 3 Fusebytes oder noch schlimmer 23 Haken merken/aufschreiben/mitschicken/eingeben muss.
Hi habe früher auch mal PIC's in Assembler programmiert. Im Anhang ein Beispiel. Vielleicht hilfts dir was Gruß
Der PIC16F18877, den du da erwähnt hast, ist ein feines Teil. Habe ich schon was programmiert, aber in C. Die aktuelle MPLAB und ein XC8 (C-Compiler) gibts kostenlos zum downloaden auf Microchip.com. https://www.microchip.com/mplab/mplab-x-ide https://www.microchip.com/en-us/development-tools-tools-and-software/mplab-xc-compilers Gruß
:
Bearbeitet durch User
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.