Bisher habe ich für den PIC16F873A erfolgreich in Assembler programmiert. Eventuell möchte ich auf den PIC16F1934/6/7 umsteigen. Das Datenblatt zeigt mir, dass die Programmierung sich doch deutlich von der für den PIC16F873A unterscheidet. Wo kann ich Hilfe finden? Ich habe aber nicht die Absicht, in C zu programmieren. (Ich bin Jahrgang 1930). Besten Dank im Voraus! DIKOMOE
Die neuen Config Word Daten finden sich im Netz und der Assembler sagt Dir schon was er nicht mehr mag. Der Rest steht im Datenblatt. Mein vor 10 Jahren gemachten Assemblerprogramme brauchen bis zu 5 Stunden um auf neueren PICs zu laufen. Der Unterschied zum 18F ist grösser. mfg Michael
Dieter K. schrieb: > Ich bin Jahrgang 1930 Das sind ca 87 Jährchen! Damit bist du als Assemblerprogrammierer reif für's Guinness-Buch der Rekorde. > deutlich von der für den PIC16F873A unterscheidet Nicht wirklich, der PIC16F873A hat lediglich einen erweiterten Befehlssatz und mehr Spezialregister. Steht aber alles im Datenblatt.
:
Bearbeitet durch User
Dieter K. schrieb: > (Ich bin Jahrgang 1930). Alle Achtung. Hättest ja fast bei der Enigma mithelfen können.
Dieter K. schrieb: > Wo kann ich Hilfe finden? Ich habe aber nicht > die Absicht, in C zu programmieren. Wenn dir englische Tutorials keine Probleme bereiten,wuerde ich dir Gooligum-Tutorials empfehlen: http://www.gooligum.com.au/PIC-Tutorials http://www.gooligum.com.au/PIC-tutorials/enhanced-PIC-tutorial Bei dem "enhanced-PIC-tutorial" wird Assembler und C behandelt - 10€ Ich koennte auch 2 aeltere Gooligum-PDF-Dateien (enhanced & enhanced MIDrange)mit jeweils 2MByte posten.Da die damals kostenlos fuer jedermann zum Download zur Verfuegung standen,sollte es rechtlich eigentlich keine Probleme geben.Aber moeglicherweise ist Englisch eh nicht so dein "Ding" womit sich dieses Problem dann auch schon erledigt haette....
Dieter K. schrieb: > Eventuell möchte ich auf den PIC16F1934/6/7 umsteigen. Das Datenblatt > zeigt mir, dass die Programmierung sich doch deutlich von der für den > PIC16F873A unterscheidet. Kommt drauf an, wie Du vorher programmiert hast. Wenn Du immer schön die Register- und Bitnamen aus dem Datenblatt verwendet hast und modular programmiert hast, sollte das Anpassen doch recht schnell und problemlos gehen. Wenn ich so an meine Assembleranfänge zurück denke, waren die ersten Versuche das Gegenteil von übersichtlich und modular. In Assembler gehört sehr viel Disziplin dazu, Programme so zu schreiben, daß man sie später noch versteht und sogar erweitern kann. Ich hab mir viel abgeguckt, wie C-Compiler arbeiten und Register als Scratchpad oder für Parameterübergabe und Returnwerte reserviert haben. Und irgendwann habe ich gemerkt, dann kannste doch gleich besser in C schreiben.
Hallo, Leute, besten Dank für Eure gut gemeinten Ratschläge. Das Umsteigen auf den PIC16F1934 zieht doch allerhand Blasen, wenn man genauer hinschaut. Fazit: Ich bleibe beim bewährten PIC16F873A
@Dieter Kohtz ...anerkennend neige ich, als junger 70jaehriger, mein Haupt vor Deinem hohen Alter :-) Werfe nicht gleich die Flinte ins Korn! Es macht Spass die Moeglichkeiten des PIC16F19xx zu entdecken! Ich programmiere bis jetzt nur in Assembler und verwende wie ich es gerade brauche, wahlweise PICs 16F628, 16F876, 16F1827, 16F1936 (28 Pin, 5V). Die neuen PICs 16F17xx mit Configurable Logic Cell und Numeric Conrolled Oscillator, besorge ich mir zum Experimentieren, sobald ich wieder zuhause bin. Du hast bei den "Extented MCUs" 16F18.. 16F19.. einige Vorteile: - Interner Ozillator gestuft bis 32MHz, ersetzt oft den Quartz - 10 bit Analog-Digital-Converter - 8 bit Digital-Analog-Converter - Capacitive Sensing Module - 5 Timer (Timer 0,1,2,4,6 - Capture, Compare, PWM Modules - usw... (siehe Datenblatt) Also jede Menge Module zum Spielen, Experimentieren und zum Aufbau praktischer Schaltungen (hier im Forum gibt es ja Hilfe wenn Du mal feststecken solltes). Wenn Du Dir ein Modul ums andere vornimmst, kannst Du viel Neues lernen und dabei Spass haben! Also, ruecke vor auf LOS! VirusAfricanus
@VirusAfricanus Eugen Roth sagt: Ein Mensch in seinem ersten Zorn wirft schnell die Flinte in das Korn. Doch es bedarf dann mancher Finte, zu kriegen eine neue Flinte. Vielen Dank für Deine aufmunternden Worte. Nur geht es mir nicht um die beachtlichen Fähigkeiten des PIC16F19xx, sondern um seinen Preis. Für die Anwendungen, die ich im Auftrag programmiere, sind die Fähigkeiten des 16F873A völlig ausreichend. Ich müsste mir für den PIC1619xx einen anderen Programmer besorgen und auf MPLABX umsteigen und mich mit den Unterschieden der Programmierung vertraut machen, und das sehe ich für mich nicht als lohnend an. Beste Grüße Dieter Kohtz
Dieter K. schrieb: > Ich müsste mir für den PIC1619xx einen > anderen Programmer besorgen und auf MPLABX umsteigen Pickit3 für unter 15€ und MPLAB IDE v8.92 kann den auch. Ich mag MPLABX auch nicht.
@Werner H. Ich habe MPLAB IDE 8.46, kann damit ein Testprogramm für den 16F1934 "builden" und simulieren. Ich habe auch PICKit3, aber schaffe es damit nicht einmal, ein Programm für den PIC16F873 zu brennen. Das Manual für PICKit3 ist eine Zumutung, und keine Hilfe.
Hallo Hr. Kohtz! Ich wollte ihnen auf diese Weise nochmal für die Artikelserie "PIC Programmierung mit PIC 16F84A" in der EAM (Ausgabe 12/2000 - 2006 glaube ich) danken. Ich habe damals ihre Beiträge sehr interessiert gelesen und mir auch manche Sachen abgeschaut. Zu ihrer Anfrage: Wenn es nur um die Erweiterung von 28 auf 40 Pins geht, dann sind doch der PIC16F877 (alt aber gut) oder der PIC16F887 (nicht so alt aber besser) genau das Richtige. Der Befehlssatz ist gleich, ebenso die Handhabung. Die Unterschiede zwischen den Controllern sind dem Datenblatt leicht zu entnehmen. Mfg
@Erhard S. Herzlichen Dank für die netten Worte! Den Anstoß für meine Frage ist nicht die Pin-Zahl sondern der Preis. Bei Reichelt: PIC16F873A: 3,35 EUR, PIC16F1936: 2,35 EUR. Würde ich nur zum Spaß programmieren, wäre mir das egal, es geht aber um Stückzahlen, die meinen Auftraggeber nachdenklich machen könnten. Freundliche Grüße Dieter Kohtz
Hallo Dieter, Dieter K. schrieb: > Ich habe MPLAB IDE 8.46, die ist aber arg veraltet - die letzte MPLAB-Version ist 8.92. Die solltest Du besser mal updaten. Vielleicht liegt das Problem mit dem PK3 ja auch daran? Der Link zum Download der MPLAB-IDE 8.92 ist etwas versteckt (über den Reiter "Download Archive", nachdem man sich zum Download von MPLAB-X durchgeklickt hat). Das Programmierproblem mit dem PICKit sollte sich jedenfalls lösen lassen, evtl. mit etwas Hilfe aus dem Forum. Bei mir wollte das am Anfang auch nicht gleich, und manchmal gibt es auch merkwürdige Effekte. Z.B. musste ich mal die VDD-Spannung am PICKit auf etwas weniger, als 5V konfigurieren, damit ich den PIC programmieren konnte. Ich denke, der Umstieg von Midrange auf auf die Enhanced Midrange Typen lohnt sich m.E. auf jeden Fall, nicht nur wegen dem Preis. Allein schon, daß bei Interrupts automatisch alle Register gerettet werden, finde ich einen großen Fortschritt. Aber auch andere Kleinigkeiten, wie die neuen Möglichkeiten mit den FSR-Registern oder daß das W-Register auch als SFR angesprochen werden kann (z.B. incf WREG,F) und viele Kleinigkeiten mehr, die einem das Leben erleichtern können... Viele Grüße, Thomas
>Ich habe aber nicht die Absicht, in C zu programmieren. >(Ich bin Jahrgang 1930). Das wäre ein hervorragender Grund, damit JETZT anzufangen. Du hast nicht mehr endlos Zeit. Wer mit dem Hirnkrebs PIC zurande kommt, für den sollte alles Andere kein Problem mehr sein.
Ich fand ICD2 war eine Zumutung aber seit ICD3 und PicKit3 läuft es bei mir immer ohne Klimmzüge am Brotkasten. Spielen mit der Versorgung war auch nie nötig, ich versorge die meisten Projekte aber nicht über den Programmer. Die MPLABx habe ich auch nicht gleich gemocht, fand ich den Aufwand mich da einzuarbeiten doch einfach viel zu groß. Wir haben uns aber aneinander gewöhnt... Das einzige was ich dem PicKit3 nachsagen kann ist, das da gern mal ein Transistor drin stirbt und ich schon zwei davon reparieren musste. mfG Michael
kopiert schrieb: > Wer mit dem Hirnkrebs PIC zurande kommt, für den sollte alles Andere > kein Problem mehr sein. Schön gesagt. Ich habe mit Z80, 8051 und AVR angefangen, die waren leicht verständlich. Aber der PIC war mir zu kompliziert. Man muß beim PIC zu sehr um die Ecke denken.
Peter D. schrieb: > Man muß beim PIC zu sehr um die Ecke denken Ist mir nie aufgefallen. Z80, 68HC??, C166, C51 und schon seit langem nur noch PICs. Die haben genau so viele Ecken wie die Anderen auch. (Vier - wenn wir das jetzt Mal zweidimensional betrachten ;-)
Richtig Mist fand ich nur 8051. 8085 war richtig nett und die PICs finde ich richtig gut. Etwas Herausforderung sollte man seinem Gehirn schließlich gönnen. Und die neueren PICs mit ihrer sehr aufwändigen Peripherie sind schon manchmal eine Herrrausforderung. mfg Michael
Mir scheint dass ein großes Problem bei der Assembler-Programmierung die zur Verfügung stehenden Schreibfläche ist. Einige Verzweigungen etc. brauchen Platz zum Notieren... ich benutze schon Vorder- und Rückseiten meiner DIN-A4 Blätter für den Programmablaufplan aber es geht manchmal zweispurig und wenn da noch eine Verzweigung auftritt wars das. Man bräuchte eine große Pinwand, aber meine Wände sind alle zugestellt...
H-G S. schrieb: > Einige Verzweigungen etc. brauchen Platz zum Notieren... ich benutze > schon Vorder- und Rückseiten meiner DIN-A4 Blätter für den > Programmablaufplan aber es geht manchmal zweispurig und wenn da noch > eine Verzweigung auftritt wars das. Das wäre dann der richtige Zeitpunkt, weg vom Spaghetticode und hin zur modularen Programmierung zu gehen. Diese Erfahrung muß wohl jeder Programmieranfänger für sich selber machen, das Mantra der erfahrenen Programmierer verhallt bis dahin ungehört. Und ja, man muß in der Regel allen bisherigen Code wegschmeißen. Belohnt wird damit, daß man nun deutlich größere Projekte in Angriff nehmen kann und diese nun wartbar, erweiterbar und wiederverwendbar sind.
Ja, alleine das einfache Erstellen von Variablen ist ein unglaublicher Segen! Per Hand in Assembler muss man sich eine freie Speicherstelle im (internen ?) RAM suchen und diese im Variablen-Übersichtszettel notieren etc. - im C-Compiler gibt man nur Typ und Namen an und ab gehts.
@Thomas Elger Hallo, Thomas, Besten Dank! Ich habe MPLAB IDE 8.92 installiert und zum Testen versucht, einen PIC16F873 mit PICKit3 zu programmieren. Beinahe mit Erfolg. Folgende Fehlermeldung erscheint: target ID 00000000 not required ID 0000960. Der Versuch, mit CONFIGURE > ID Memory die gewünschte ID zu laden, führt nicht zum Erfolg. Der Programmiervorgang lässt sich zwar starten und läuft offenbar auch, aber mit dem Ergebnis 00000000. Hast Du eine Ahnung, wo der Kinken Stecken könnte? Besten Gruß Dieter
target ID 00000000 ist ein Indiz für unterbrochene Kommunikation zwischen Controller und PICKit.
Volker S. schrieb: >> Man muß beim PIC zu sehr um die Ecke denken > > Ist mir nie aufgefallen. Z80, 68HC??, C166, C51 und schon seit langem > nur noch PICs. Die haben genau so viele Ecken wie die Anderen auch. Die PICs sind mnemotechnisch teilweise etwas aus der Zeit gefallen und die Kennzeichnung der Operationsweise durch W oder F hinten ist gewöhnungsbedürftig. Aber wer alt genug ist, schon Architekturen aus den 50ern und 60ern zu kennen, den schreckt das nicht. Die waren oft ähnlich schräg.
@Dieter Werner Beim Aufruf von Programmer > PICKit3 erscheint folgende Meldung: PICkit 3 detected Connecting to PICkit 3... Firmware Suite Version...... 01.28.90 Firmware type......................Midrange PICkit 3 Connected. Target Detected Target Device ID (00000000) does not match expected Device ID (00000960). Geht daraus nicht hervor, dass PICKit und Controller verbunden sind? (Ich hatte auch schon mal die Meldung: Target not detected)
Hallo Dieter, leider habe ich kein PICKit3 zuhause, so daß ich hier nichts Testen und ausprobieren kann. Deine Firmware-Version (01.28.90) scheint aber auch nicht gerade die neueste zu sein, zumindest erscheinen in diversen Google-Suchergebnissen höhere Nummern. Bei "Firmware type" müsste für den PIC16F193x m.E. auch "Enhanced Midrange" stehen. Die Firmware des Programmers kannst Du im MPLAB über Programmer->Settings->Configuration updaten. Vielleicht klappt's dann schon...
Target ID 00000000 deutet immer darauf hin, das das PicKit den PIC nicht richtig lesen kann. Fremdbeschaltung auf MCLR fehlende Versorgung oder irgend etwas das die Clock oder Datenleitung nicht richtig spielt. Wenn das PicKit in Ordnung ist und alles von den Datenleitungen entfernt wurde nur noch Prüfen wer die Versorgung übernehmen soll - PicKit oder Selbstversorger muss einsprechend im MPLABx angegeben werden. Einzige Ausnahme war bei mir mal der Transistor der die Versorgung im PicKit schaltet. Wenn der durch ist kommt halt keine Versorgung beim PIC mehr an und es gibt immer Device ID Fehler. mfG Michael
Dieter K. schrieb: > PICkit 3 detected > Connecting to PICkit 3... > Firmware Suite Version...... 01.28.90 > Firmware type......................Midrange > PICkit 3 Connected. > Target Detected > Target Device ID (00000000) does not match expected Device > ID (00000960). Ich benutze keinen PICKit aber ich habe eben mal auf dem Microchip Forum nachgesehen: http://www.microchip.com/forums/m759961.aspx?high=does+not+match+expected+Device+ID Interessant sind die letzten Eintraege die den PICKit als Fehlerursache ausmachen. Unabhaengig davon: Als angemeldeter User kannst du auf diesem Microchip Forum gute und schnelle Hilfe bekommen. http://www.microchip.com/forums
Ein fieser Fehler kann auch auftreten, wenn man aus irgendwelchen Gründen die Programmer Software benutzt, die das PICkit in etwas anderes verwandelt. Es funktioniert unter der IDE dann nicht mehr korrekt. Da habe ich diesen Fehler auch schon gesehen. In der Programmer Software bekommt man aber einen entsprechenden Hinweis, dass man das PICkit hier zuerst wieder richtig konfigurieren muss, damit es in der IDE nutzbar ist.
Dieter K. schrieb: > Ich habe auch PICKit3, aber schaffe es damit > nicht einmal, ein Programm für den PIC16F873 zu brennen. Das Manual für > PICKit3 ist eine Zumutung, und keine Hilfe. Hach, das kenne ich zur genüge. ich hab mit den PIC16's so 1991 herum angefangen und finde sie noch immer für kleinere Aufgaben in Assembler richtig handlich. Knuffig sozusagen. Aber die Software von MicroChip ist ne Kröte - schon immer gewesen. Die Programmierhardware auch. Kennst du noch den sauteuren PIC-Programmer, wo man für jeden Typ ne neue SHFassung zum Draufschrauben mit diesen häßlichen Leitplastik-Kontakten kaufen mußte? Oder den ollen PICALC ? Ich hatte mir notgedrungen nen handlicheren Assembler selber geschrieben und auch einen ordentlichen Programmer gebaut, beides benutze ich im Prinzip immer noch. Allerdings den Assembler als DLL entweder mit vorgeschaltetem Kommandozeilentool oder in selbstgebauter Mini-IDE. Der Brenner läuft seit damals (vor 25 Jahren!) per Parallelport, was einem heutzutage seit Win7 ein Problem macht. Aber mit den PICkit2 und 3 bin ich nie wirklich warm geworden. Es sind mMn elende Krücken, ebenso wie der letzte PIC-Assembler, den ich mir (mal wieder) angewidert angesehen habe. So. Derzeit denke ich über nen eigenen Brenner nach, als USB-Teil mit nem STM32F103 als Adapter und das PC-Programm von meinem ST-Programmer abgeleitet - soweit ich abends dazu Zeit habe. Peter D. schrieb: > Schön gesagt. > Ich habe mit Z80, 8051 und AVR angefangen, die waren leicht > verständlich. Aber der PIC war mir zu kompliziert. Man muß beim PIC zu > sehr um die Ecke denken. Hehe, du bist lediglich vom AVR versaut. Bei den PIC's (gerade bei den kleinen 16F) muß man eigentlich garnicht um die Ecke denken, es erscheint dir bloß so. Das läuft auf ne Diskussion a la C versus Pascal hinaus - und die ist überflüssig, weil die AVR-Leute die PIC-Architektur einfach nicht verstanden haben. Glaube du also lieber nicht, in den PIC16 würde man per Assembler nur Spaghetticode schreiben. Zumeist ist das völlig Gegenteil der Fall. Allerdings gibt es eben wegen des HW-Stacks keine Parameter auf dem Stack, sondern nur in W und/oder FSR oder FSR^. Diesen Umstand muß man erstmal kapieren. Ich hab nie verstehen können, warum manche Leute ne Registermaschine als einfacher empfinden: Lade Register aus RAM mache ne Operation mit Register speichere Register in RAM anstatt mache ne Operation im RAM zu schreiben. W.S.
W.S. schrieb: > Aber mit den PICkit2 und 3 bin ich nie wirklich warm geworden. Es sind > mMn elende Krücken, Ich finde die richtig gut. Das PICkit2 haben wir früher als SMD-Bestückungsversuch von unseren Studierenden bauen lassen. Das dürften sie dann sogar behalten. Als das PK3 dann rauskamen und es anfing, dass einige PICs vom PK2 nicht mehr unterstützt würden hat das schon genervt und auch, dass das neue ständig seine Firmware ändern muss, wenn ein anderer PIC programmiert werden soll. Inzwischen habe ich mich daran gewöhnt... Auf jeden Fall für viel besser als ICD2 mit denen wir ständig in den Rechnerpools Treiberprobleme hatten. MCHP hat kostenlos alle unsere ICD2 gegen PK3 ersetzt. Die alten ICD2 müssten wir noch nicht mal zurück schicken. Einen reinen Programmer, der nicht debuggen kann würde ich nicht mal geschenkt nehmen und auch nicht selber bauen, solange ich ein PK3-Klon für 10€ bekomme. W.S. schrieb: > Peter D. schrieb: >> Man muß beim PIC zu >> sehr um die Ecke denken. > > Hehe, du bist lediglich vom AVR versaut Jo, verstehe gar nicht, warum manche PIChater sich immer wieder so blödsinnig in reinen PIC-Threads äußern müssen. W.S. schrieb: > Ich hab nie verstehen können, warum manche Leute ne Registermaschine als > einfacher empfinden: +1
Hallo, Leute, jetzt habe ich tagelang versucht, den PICKit3 zum Programmieren zu überreden, leider ohne Erfolg. Was ich im Forum von Microchip so über ihn erfahren habe, hat meine Motivation endgültig zu Null gemacht. Für die Aufgaben, die ich vorhabe, komme ich mit den 16F8xx-Typen und PICKit2 bestens zu Potte. Habt Dank für Eure guten Ratschläge und macht's gut.
Ich mag ja Bootloader via Async. Vorzugsweise schon ab Werk drin. Erspart die Suche nach dem passenden Programmer.
Dieter K. schrieb: > Was ich im Forum von Microchip so über > ihn erfahren habe, hat meine Motivation endgültig zu Null gemacht In den Foren stehen eben immer nur Probleme. Wenn's läuft fragt doch keiner warum ;-) Dieter K. schrieb: > Für > die Aufgaben, die ich vorhabe, komme ich mit den 16F8xx-Typen und > PICKit2 bestens zu Potte. Dann nimm doch das PK2 ;-) Kann mir zwar nicht vorstellen warum es nicht auch mit dem PK3 gehen sollte, aber wenn es schon eine funktionierende Lösung gibt... A. K. schrieb: > Ich mag ja Bootloader via Async. Vorzugsweise schon ab Werk drin. > Erspart die Suche nach dem passenden Programmer. Kann man da auch debuggen? (also mit Anhalten, Breakpoints, Register anschauen und so...)
:
Bearbeitet durch User
Volker S. schrieb: > Kann man da auch debuggen? (also mit Anhalten, Breakpoints, Register > anschauen und so...) Nö, brauche ich aber nur selten. Ich hatte mir zwar mal ein JTAG für ein paar alte AVRs gebaut, aber so gut wie nie verwendet.
:
Bearbeitet durch User
A. K. schrieb: > Nö, brauche ich aber nur selten. Ich hatte mir zwar mal ein JTAG für ein > paar alte AVRs gebaut, aber so gut wie nie verwendet. Genies brauchen keinen Debugger, die machen immer alles gleich richtig. Richtige Programmierer morsen Registerwerte auf ner LED. Nur Weicheier lassen sich Strukturelemente mit Klartextnamen im Debugger anzeigen. MfG Klaus
A. K. schrieb: > Ich mag ja Bootloader via Async. Vorzugsweise schon ab Werk drin. > Erspart die Suche nach dem passenden Programmer. Du sprichst mir aus dem Herzen. Und die obigen Einlassungen bzgl. Debugging sind eben auch nur ein Zeichen dafür, daß die Betreffenden nicht wirklich sauber und zumeist eben nur in C programmieren können und genau deshalb den Debugger brauchen, um zu merken, was für einen Murks sie tatsächlich geschrieben haben. Oft genug ist nämlich gerade bei C ein himmelweiter Unterschied zwischen dem, was man gemeint hat und dem, was der Compiler dabei verstanden hat. Ich hab auch diverse Debugger-Geschirre in der Bastelkiste sedimentieren, aber eigentlich noch nie eines davon wirklich benötigt. W.S.
Klaus schrieb: > Genies brauchen keinen Debugger, die machen immer alles gleich richtig. Missverständnis. Es gibt schlicht auch andere Methoden. Typischerweise ist etlicher Tracecode drin. Wichtig ist, dass z.B. eine Miniversion von printf funktioniert (C), oder andere Formen irgendeiner Ausgabe (ASM). Ganz am Anfang und auf unterster Ebene auch mal LEDs. Letztere sind dort von Vorteil, wo der Zeitfaktor keine andere Möglichkeit lässt, oder ISRs beteiligt sind. Liegt vielleicht auch daran, dass diese Methode so ziemlich überall gleichermassen funktioniert. Debug-Schnittstellen hingegen sind grad bei AVRs vergleichsweise neumodisch, gab es früher nur bei den Grossen. Bei den PICs fehlt mir der diesbezügliche Überblick.
:
Bearbeitet durch User
W.S. schrieb: > nd genau deshalb den Debugger > brauchen, um zu merken, was für einen Murks sie tatsächlich geschrieben > haben. Es ist einfach nur Faulheit. Wenn man merkt, dass man IRGENDWO einen Murks geschrieben hat, dann findet man viel schneller wo. (Natürlich murkst man viel einfacher in C ;-) In der "Lehre" ist es aber auch ganz nett, Schritt für Schritt durch den Maschinencode eines in C geschriebenen Programms steppen zu können...
:
Bearbeitet durch User
A. K. schrieb: > Typischerweise > ist etlicher Tracecode drin. Wichtig ist, dass z.B. eine Miniversion von > printf funktioniert (C), oder andere Formen irgendeiner Ausgabe (ASM). > Ganz am Anfang und auf unterster Ebene auch mal LEDs. Letztere sind dort > von Vorteil, wo der Zeitfaktor keine andere Möglichkeit lässt, oder ISRs > beteiligt sind. Ausgaben über die Serielle Schnittstelle sind mir zu umständlich/bremsen das Programm aus, für LEDs bin ich meistens zu langsam. Ein Oszilloskop als Hilfsmittel weil ich zu langsam bin und das Programm auch nicht anhalten will, finde ich aber mehr als nützlich! <edit>Sorry, ich(wir) schweife vom Thema ab. JA, Assemblerprogrammierer haben das/sich besser im Griff und müssen weniger debuggen!
:
Bearbeitet durch User
W.S. schrieb: > Oft genug ist nämlich gerade bei C ein himmelweiter Unterschied > zwischen dem, was man gemeint hat und dem, was der Compiler dabei > verstanden hat. Das gilt aber eigentlich nur, wenn man C nicht verstanden hat, es einfach nicht kann. Wer es können will, kann es lernen, wer nicht findet Ausreden. A. K. schrieb: > Debug-Schnittstellen hingegen sind grad bei > AVRs vergleichsweise neumodisch, gab es früher nur bei den Grossen. Bei > den PICs fehlt mir der diesbezügliche Überblick. Einen Pic debugged man über dieselbe Schnittstelle, über die man ihn auch programmiert. Und das tut man auch über das gleiche Teil, z.B. einen PICKit. 3 Drähte, Vcc und GND, fertig. Das können selbst die 8-Beiner. Hardwarebreakpoints sind im Chip eingebaut, bei den neueren auch Datenbreakpoints. Ob ich C-Code für den PC mit netbeans entwickle oder mit MPLABX (ist auch netbeans) für einen PIC ist fast kein Unterschied. Bevor ich auf diesen Komfort verzichte, muss der µC schon etwas besonderes leisten, so wie der ESP z.B. mit WLAN. MfG Klaus
Dieter K. schrieb: > jetzt habe ich tagelang versucht, den PICKit3 zum Programmieren zu > überreden, leider ohne Erfolg. Ja, kenne ich. Das Ding ist widerborstig mit dem MPLab. Ziehe dir einfach die Standallone Software bei Microchip runter, dann gehts problemlos.
Werner H. schrieb: > Ja, kenne ich. Das Ding ist widerborstig mit dem MPLab. Ziehe dir > einfach die Standallone Software bei Microchip runter, dann gehts > problemlos. Danke für den konstruktiven Beitrag. Ich habe die Standallone Software erfolgreich installiert. Sieht alles wunderbar aus, aber Ergebnis trotz diverser Versuche: No device detected. Meine Hardware ist dieselbe, mit der PICKit2 bestens funktioniert. Versorgung extern mit 5 V. PICKit3 ist original Microchip und praktisch neuwertig.
Dieter K. schrieb: > Ich habe die Standallone Software erfolgreich installiert. Hast du die "PICkit3 Programmer Application v3.10" verwendet oder die "PICkit_3_Programmer_1_0"? Die 3.1 ist die richtige. Du musst auch die Firmware Laden (PK3OSV020005.hex), im Menü Tools.
So langsam macht ihr mich echt neugierig. Ich muss das wohl mal ausprobieren, ob es mit dem 16F87xA auch bei mir Probleme gibt. Einen 873A habe ich zwar nicht, aber noch viele alte 877A, die früher beim PICDEM 2+ dabei waren. Müsste ja vom Programmieren her gleich sein. PIC16 habe ich in letzter Zeit nur neuere benutzt (mit 4 oder 5 Stellen hinter dem F, z.B 16F1459) und bei denen gab es keinerlei Probleme. Mit PIC18 auch nicht. (alle mit USB, die K22, K80 ...). Bei PIC10, 12, PIC24... eigentlich kann ich mich an keine nennenswerte Probleme erinnern. Die alte IDE verwenden wir schon lange nicht mehr. Wenn man auch in C programmiert, bietet MPLABX trotz den deutlichen Geschwindigkeitseinbußen für uns einige Vorteile. (unter anderem den, dass die Studierenden vorher schon Netbeans benutzt haben und nicht die unsägliche Einrichtung der Tools von jedem neuen Benutzer gemacht werden muss) Die Verwendung der Programmer App bringt bei uns nur Probleme, weil die Studies natürlich immer einfach alles anklicken und dann das PICkit3 in MPLABX nicht mehr funktioniert. Egal, ich muss es testen - aber erst übernächste Woche ;-)
:
Bearbeitet durch User
Werner H. schrieb: > Hast du die "PICkit3 Programmer Application v3.10" verwendet oder die > "PICkit_3_Programmer_1_0"? > Die 3.1 ist die richtige. Du musst auch die Firmware Laden > (PK3OSV020005.hex), im Menü Tools. Ich habe von Microchip "PICKit3 Stand Alone Programmer Application v1.0" verwendet und installiert. Nach dem Aufruf von PICKit3 erscheint u.a. die Meldung: "Found 1 Firmware suit, latest Version 01.38.51". Wenn ich tools anklicke, wird das file "PK3FW_012633.jam" angeboten. Wenn ich das wähle, werden die files "AP01.14.15-07" und "RS01.13.04" als geladen gemeldet, dann erfolgt ein endloser Ladevorgang (offensichtlicher Absturz?) Das file "PK3OSV020005.hex" ist im Verzeichnis PICKit3 nicht zu finden.
Dieter K. schrieb: > Das file "PK3OSV020005.hex" ist im Verzeichnis PICKit3 nicht zu finden. Ich glaub dafür muss man das installieren: "PICkit 3 Programmer App and Scripting Tool v3.10" http://ww1.microchip.com/downloads/en/DeviceDoc/PICkit3%20Programmer%20Application%20v3.10.zip <edit> Siehe auch https://www.youtube.com/watch?v=vfmLu6XzBtw (38:40)
:
Bearbeitet durch User
Dieter K. schrieb: > Target Detected > Target Device ID (00000000) does not match expected Device > ID (00000960). > > Geht daraus nicht hervor, dass PICKit und Controller verbunden sind? > (Ich hatte auch schon mal die Meldung: Target not detected) Dieser Fehler tritt auch auf, wenn der PIC sich in der Schaltung befindet und per ICSP programmiert werden soll. Abhilfe: ; Wird die ICSP-Schnittstelle verwendet, MÜSSEN die Pins PGC und PGD ; (beim 16Fxxx RB6/PGC, RB7/PGD) mit einem Widerstand von wenigstens ; 1kOhm (oder mittels Jumper) von der übrigen Schaltung (auch von ; LCD-Datenleitungen) entkoppelt sein! ; ; Geschieht dies nicht, meldet das PICkit3 schon beim Anschluss ; "Target Device ID (00000000) does not match expected Device ; ID (00001060)" ; oder ; "The following memory regions failed to program correctly: ; Program Memory" Bei mir hat dieser Tip beim Brennen mit dem PICkit3 geholfen. Dazu mehr auf der Seite von "sprut": http://www.sprut.de/electronic/pic/icsp/icsp.htm (Takt- und Datenleitung PGC (RB6) und PGD (RB7) mfg Ottmar
Klaus schrieb: > Das gilt aber eigentlich nur, wenn man C nicht verstanden hat, JEIN - so kann man das nicht stehenlassen. Man kann mit C durchaus programmieren, wenn man noch längst nicht alle Möglichkeiten verstanden hat, ABER: man sollte sich dabei eine biedere Art des Programmierens angewöhnen und eben nicht jeden Furz, den C so bietet, auch tatsächlich benutzen wollen, bloß weil man solche Husarenstückchen irgendwo im Internet als Beispiel gefunden hat. Auch bei ganz simpler Programmierung kommt heutzutage kein schlechter Code heraus, weil man die tatsächliche Optimierung dem Compiler überlassen kann. W.S.
Dieter K. schrieb: >.. Application v1.0" verwendet und installiert... Das ist die Falsche, du musst die v3.10 nehmen da ist auch die "PK3OSV020005.hex" Datei mit dabei.
W.S. schrieb: > Auch > bei ganz simpler Programmierung kommt heutzutage kein schlechter Code > heraus, weil man die tatsächliche Optimierung dem Compiler überlassen > kann. Sorry, in diesem Teil kann ich jetzt nicht so ganz folgen. (Ich raff's nicht, was du da sagen willst)
Werner H. schrieb: > Das ist die Falsche, du musst die v3.10 nehmen da ist auch die > "PK3OSV020005.hex" Datei mit dabei. Jetzt habe ich die heruntergeladen (wozu ist die andere gut?,)aber trotzdem keinen Erfolg. Ich brauche PICKit3 nicht und werde nun den thread nicht weiter beobachten. Tschüs!
Dieter K. schrieb: > Ich brauche PICKit3 nicht... Falls du es loswerden willst, dann schreib mir doch eine PN
W.S. schrieb: > Klaus schrieb: >> Das gilt aber eigentlich nur, wenn man C nicht verstanden hat, > > JEIN - so kann man das nicht stehenlassen. > > Man kann mit C durchaus programmieren, wenn man noch längst nicht alle > Möglichkeiten verstanden hat, ABER: man sollte sich dabei eine biedere > Art des Programmierens angewöhnen und eben nicht jeden Furz, den C so > bietet, auch tatsächlich benutzen wollen, bloß weil man solche > Husarenstückchen irgendwo im Internet als Beispiel gefunden hat. Auch > bei ganz simpler Programmierung kommt heutzutage kein schlechter Code > heraus, weil man die tatsächliche Optimierung dem Compiler überlassen > kann. Das ist eigentlich eine Binsenweißheit. Ich kann Fahrradfahren, trotzdem versuche ich nicht jeden Stunt, den ich mal gesehen hab. Deine Bemerkung war aber: W.S. schrieb: > Oft genug ist nämlich gerade bei C ein himmelweiter Unterschied > zwischen dem, was man gemeint hat und dem, was der Compiler dabei > verstanden hat. Und das ist eigentlich nicht so. Mir ist es bisher noch immer gelungen, mein Problem so zu formulieren, daß mich der C-Compiler verstanden hat. Und das war eigentlich nie wirklich schwer. Dabei spare ich nicht beim Source, ein komplexer Regler muß nicht in eine Zeile passen, noch beim Objektcode. Guter Code zeichnet sich für mich dadurch aus, daß man ihn beim ersten Mal lesen versteht. Dabei ist es mir vollkommen egal, ob die CPU, auf der er läuft, Register hat, Banks umschaltet oder einen Datenstack in SW realisiert. Um beim Beispiel eines Reglers zu bleiben: wenn ich mir die Reglergleichungen im Lehrbuch ansehe, kommen CPU-Register oder Flash-Banks nicht vor. Ich programmiere PICs. Da ich das schon länger mache, als es C-Compiler für sie gibt, weiß ich das die alten, kleinen keine Register und Memorybanks haben. Ob das bei den neuen Midrange immer noch so ist, weiß ich nicht. Ich verwende auch die 16 Bitter, PIC24. Ob die Register haben? Hab nicht nachgesehen, keine Ahnung. Erzeugter Assemblecode? Schau ich nicht an, was der Compiler für den CoreIxx auf meinem PC macht schau ich auch nicht an. Trotzdem hab ich allen Code zum funktionieren bekommen. MfG Klaus
Klaus schrieb: > Ich verwende auch die 16 Bitter, PIC24. Ob die Register > haben? Haben sie, deren 16. Die PIC30 waren erkennbar so konzipiert worden, dass heutige C Compiler wie GCC keine Verrenkungen benötigen. Das ist schon aus Faulheit (Sparsamkeit) sinnvoll, denn nur dann kann man effizient auf bestehenden Compilern wie GCC aufbauen. Was Microchip ja auch getan hat. > Erzeugter Assemblecode? Kann in Einzelfällen schon mal nützlich sein. Nicht zuletzt um sicher zu sein, dass der Compiler auch tut was er soll. Bei meinem ersten (und einzigen) Testprojekt mit einem PIC30 bin ich ziemlich früh über einen echten Fehler im Compiler gestolpert (Kontakt mit Microchip, bestätigt und behoben).
A. K. schrieb: > Kann in Einzelfällen schon mal nützlich sein. Nicht zuletzt um sicher zu > sein, dass der Compiler auch tut was er soll. Naja, Ausnahmen bestätigen die Regel. Ich schau mit dem Source-Debugger in die C-Variablen, genau wie auf dem PC. Ich setze einen Breakpoint und schaue welchen Zweig der Code durchläuft. Da die Header für die PICs mir die SFR schon in Variable zerlegen, kann ich z.B. einen FIFO-Füllstand aus einem SFR einfach als Zahl, auf Wunsch auch als Dezimalzahl auslesen. Aber zu wissen, daß die PIC24 16 Register haben, beruhigt ungemein. Ich hab auch noch keinen Compilerfehler entdeckt, Fehler des Programmierer (meist ich selbst) schon viele. MfG Klaus
Volker S. schrieb: > Falls du es loswerden willst, dann schreib mir doch eine PN Wenn ich wüsste, was eine PN ist, würde ich Dir schreiben. Gern wäre ich PICKit3 + Demoboard und CD los.
Persönliche Nachricht, E-Mail über Benutzer. Wenn die Teile günstig wären, würde ich die an Studierende weiter geben. Wie gesagt - bei uns gibt es eigentlich keine Probleme mit dem PICkit3. Sollte es wirklich defekt sein, könnte ich es vermutlich auch ohne allzu große Mühe wieder richten.
@ Volker S. Volker S. schrieb: > Persönliche Nachricht, E-Mail über Benutzer. > Wenn die Teile günstig wären, würde ich die an Studierende weiter geben. > Wie gesagt - bei uns gibt es eigentlich keine Probleme mit dem PICkit3. > Sollte es wirklich defekt sein, könnte ich es vermutlich auch ohne allzu > große Mühe wieder richten. Ich verschenke die Teile gern, besonders, wenn sie an Studierende gehen. Nur sag mir bloß, wo ich sie hinschicken soll. Wie geht "Persönliche Nachricht, E-Mail über Benutzer"? Beste Grüße Dieter Kohtz
Ich habe dir geschrieben. (einfach den Benutzernamen in der Klammer anklicken)
Das PicKit3 ist so gut, das ich seit es das gibt das ICD2 im Schrank liegen lasse und auch das ICD3 so gut wie nie benutze. Aber für den Fall eines Falles habe ich auch Ersatz für PicKit3 da denn zum reparieren muss man schon etwas Muße aufbringen den Fehler zu suchen und zu finden. mfG Michael
Dieter K. schrieb: > Ich verschenke die Teile gern, besonders, wenn sie an Studierende gehen. > Nur sag mir bloß, wo ich sie hinschicken soll. Vielen Dank ist heute angekommen. Wenn doch nur mehr so großzügig wären ;-)
Servus, ich verstehe das gemurmel nicht um die "unverständliche" Programmierung der PIC's. 1. sind das EinAdreßmaschinen und zweitens haben die Pic12 und alle alten PIC16 nur 35 Befehle zum Auswendig lernen. Somit haben die ihren Platz neben all den anderen Chips verdient. Ich habe seid uber zwei Jahren mal wieder aus dem "kalten" eine Funkuhr gebaut mit Pic16f628 in Assembler. Habe zwar vergessen das man auch einzelne BIT's setzen kann mit BSF o. BCF aber sonst null problemo. Die wirken halt blos wie ZweiTakter aber sonst finde ich die so schlecht nicht. Die DSPIC's machen freilich auch Spaß. Die haben 16 Workingregisters und relativ viel Dampf im Kessel..... Grüße ausm Osten
Maik W. schrieb: > ich verstehe das gemurmel nicht um die "unverständliche" Programmierung > der PIC's. Oh je, das versteht jetzt bestimmt wieder irgendeiner als Einladung seinen PIChater Stuss abzusondern ;-)
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.