Holgi's Tips zu PIC's

Vor der Programmierung von PIC Microcontrollern sollten ein paar wichtige Details berücksichtigt werden. Wer gerde erst anfängt PIC's zu programmieren sollte dies unbedingt lesen. Auch diejenigen die bisher nur 16C/F84 programmiert haben und jetzt auch andere PIC's programmieren wollen. Mein erster Tip: Es ist unbedingt notwendig die Datenblätter ganz durchzulesen um erfolgreich Programme für PIC's zu erstellen.

Antwort auf die vielen Anfragen zu einem einfachen PIC12C508 oder 16Cxxx Prommer: Ich kenne keinen. Nimm einen Flash PIC ! Vergiß die C-Typen oder besorge dir ein teures PIC-Programmiergerät.

Wenn du einen PIC-Prommer für Flash PIC'S oder einen Assemblerkurs für PIC's in deutsch suchst schau mal bei SPRUT rein.

Einen kleinen C-Kurs für PIC's findest du hier Fernando Heitors Homepage . Der C-Kurs ist zwar für den CCS Compiler, aber grundsätzliche Dinge zu C werden gut erklärt. Auf Fernando's Seite gibt es auch ein deutsches Forum zu PIC's und viele Links zu Projekten mit PIC's.

Kay Galinsky's Homepage PIC-Schaltungen für RC-Fernsteuerungen. Ein PIC-Prommer

Diese Seite entstand nachdem ich einige unangenehme Erlebnisse mit den Hardwareeinstellungen von PIC's erlebt habe. Ein falsches Bit im Configurationword oder in einem der Register des PIC's reicht um ein korrektes Programm mal eben so unerwartet abstürzen zu lassen. Das hier wird kein PIC Programmierkurs. Ich gebe nur meine Erfahrungen in der alltäglichen Arbeit mit der PIC Hardware weiter.

Letztes Update: 25.04.2007

Finger weg von PIC12Cxxx und 16Cxxx. Nimm 12Fxxx oder 16Fxxx
Warum der PIC Simulator in MPLAB oder die ICD's oft keine Hilfe sind
Worin unterscheiden sich 12Cxxx/16Cxxx PIC's von 12Fxxx/16Fxxx PIC's
Das Configuration Word
Security Bits im Configurationword. Kopierschutz !
Power Up Timer im Configurationword
RC-Calibration Wert
RC-Oscillator statt Quarz
Quarz-Oscillator Probleme
Der SLEEP Befehl
Der Watchdog Timer WDT
PORTA will nicht richtig arbeiten
PIC12F629/675 wollen nicht funktionieren
Die PORTA.4 Falle beim 16F84 u.a. PIC's
Probleme mit ICProg, JDM, Ludipipo und CO ?
LVP-Bit: Probleme beim brennen von PIC16F628 und neueren PIC16FXXX. Auch PIC18Fxxxx !
Nachteile bei der LVP Programmierung
PORTB6 und PORTB7: Funktionieren nicht wenn der Debug Modus aktiviert ist
PSPMODE Falle bei PIC's mit PORTE und PORTD
Die BOREN-Falle bei PIC16LFxxx
MCLR nicht direkt mit VDD verbinden !
Der Hardware-Stack
Probleme mit PIC18Fxxxx und Table Read Protection im ConfigurationWord
Bootloader funktioniert nicht
MCC18 und die Procedural Abstraction
PIC18F Löschprobleme beim brennen



Finger weg von PIC12Cxxx und 16Cxxx. Nimm 12Fxxx oder 16Fxxx
Die alten "C" PIC's sterben aus. Es gibt für fast alle "C" PIC's einen Flash PIC der mehr kann. Die kosten meist nur ein paar Cent mehr und sind zum Teil auch schon billiger als die entsprechenden "C" Typen. Für die alten 16C54 gibt es bereits 16F54.

Preisvergleich: Um Programme mit 12C508 in annnehmbarer Zeit entwickeln zu können braucht man 5 von den JW Typen und ein Eprom-Löschgerät. Ungefährer Preis: 50 Euro für das Löschgerät und ca. 16 Euro pro PIC. Dazu ein Programmiergerät das mit den "C" Typen auch klarkommt. Ein 12F675 kostet weniger als 2 Euro und läßt sich meist mit einem BilligstPicPrommer nach Programmupdate programmieren. Löschgerät nicht erforderlich.

Schmeiß deine alten PIC12/16xxx-JW einfach weg. Es lohnt sich nicht mehr sich damit zu beschäftigen.


Warum der PIC Simulator in MPLAB oder die ICD's oft keine Hilfe sind
Simulator oder ICD helfen oft nicht einmal bei den einfachsten Problemen. Programmier lieber gleich einen PIC und sieh nach was er tut. Das ist oft nicht das was Simulator oder ICD so vormachen.

Jemand fragte mal warum er mit seinem Programm das EEProm im PIC nicht programmieren kann. Es hängt sich auf. Programm in einen PIC gebrannt und geht. Er hat den Software Simulator von MPLAB benutzt. Der Simulator simuliert Schreibversuche in das EEProm nicht. Interrupts können mit MPLAB schlecht simuliert werden. Woher soll der Simulator auch wissen das man gerade versucht mit 10kHz auf INT rumzutakten oder damit einen Timer von draußen zu füttern. Der Simulator kann kein PWM-Signal ausgeben. An welchem Pin des PC's denn auch ?

Oder einfach die PORTA Falle bei PIC's mit AD-Modul oder Komparator. Weder Simulator noch ICD warnen einen wenn man versucht PORTA als digitale Ein/Ausgänge zu benutzen und ANSEL/ADCON/CMCON nicht richtig programmiert sind. Da muß man ganz einfach aufmerksam das Datenblatt lesen. Davor bewahrt kein Simulator oder ICD. Wenn man das getan hat braucht man beide nicht mehr !

Der beste Weg ist immer noch einen PIC zu programmieren und in seiner realen Arbeitsumgebung zu testen. Eine oder zwei Leuchtdioden und vieleicht ein LCD-Display zur Ausgabe von Zwischenergebnissen bringen viel mehr als der beste Debugger. Alle Schaltungen zu PIC's die du auf meiner Seite findest wurden ohne MPLAB, irgendwelche Simulatoren oder Debugger entworfen.


Worin unterscheiden sich 12Cxxx/16Cxxx PIC's von 12Fxxx/16Fxxx PIC's
Die meisten PIC's im Plastikgehäuse und einem "C" im Namen sind sogenannte OTP-Typen. OTP heißt "One Time Programmable" oder "Nur einmal programmierbar". Diese PIC's können nicht mehr gelöscht werden. Sie sind wie ROM's nur einmal beschreibbar. Diese preiswerten PIC's sind für die Produktion gedacht. Ein PIC12C508 kostet so um die 2Euro oder weniger. Die löschbare Version dieses PIC's kostet mehr als 10Euro.

PIC's im Keramikgehäuse mit Löschfenster können wie Eprom's mit einem UV-Löschgerät gelöscht werden. Preis für das Löschgerät ca. 50Euro. Diese PIC's haben ein JW am Ende der Typenbezeichnung, z.B. PIC12C508-JW. Der Löschvorgang dauert min. 5 Minuten. Deshalb ist es sinnvoll mindestens 5 Stück davon zu benutzten um zügig zu arbeiten.

Mehrmals programmierbare PIC's im Plastikgehäuse sind der alte 16C84 und alle PIC's mit einem "F" für Flash im Namen. Z.B. 16F84, 16F873, 16F628, 12F675 usw. Die müssen nicht mit UV-Licht gelöscht werden. Sie werden im Programmiergerät gelöscht. Microchip gibt die Anzahl der Programmiervorgänge mit ca. 1000 an. Sie sind also auch nicht beliebig oft neu programmierbar und irgendwann im Eimer. Einige meiner PIC's haben aber schon mehr Programmierungen auf dem Buckel. 1000 ist eine Mindestangabe.

Warum ein Programm für 16C54 nicht auf 16F84, oder ein Programm für 12C508 nicht auf 12F675 laufen kann: Siehe Hardware-Stack.



Das ConfigurationWord
Mit dem ConfigurationWord sollte man sich als erstes beschäftigen. Damit werden wichtige Dinge eingestellt wie Oscillatorkonfiguration, Watchdog an/aus usw. Leider steht es im Datenblatt ziemlich weit hinten, so das es oft übersehen wird. Ein aktivierter Watchdog oder eine falsche Oscillatoreinstellung führen dazu das das Programm im PIC nicht funktionieren kann. Es sollte auf jeden Fall im Quellcode definiert werden. Überlass das nicht dem Assembler/Compiler oder dem Programm mit dem der PIC gebrannt wird. Die Bits im ConfigurationWord sind nicht bei allen PIC's gleich belegt. Auf jeden Fall im Datenblatt unter Special Features of the CPU nachsehen welches Bit mit welchem Zustand für eine bestimmte Funktion gesetzt werden muß.
  • Eine sichere Einstellung für Anfänger (bei 4MHz):
  • XT-Oscillator
  • Watchdog aus
  • Powerup Timer an
  • Brown Out an ( bei 5V, bei 3V AUS )
  • LVP-Bit abschalten wenn es nicht benötigt wird
  • Code Protection aus ! Besonders bei UV löschbaren PIC's. Siehe unten.


Einige professionelle Programmiergeräte ignorieren das ConfigurationWord in der HEX-Datei. Das mußte ich vor einiger Zeit bereits bei einem alten Chiplab von Data/IO feststellen. Ganz aktuell wurde mir eine Schaltung mit PIC zur Prüfung vorgelegt die nicht funktionieren wollte. Das konnte gar nicht sein, die hatte ich nämlich selbst im Auftrag entwickelt. Die PIC's ließ der Kunde bei einem Programmierservice programmieren. Es stellte sich heraus das das ConfigurationWord nicht programmiert worden war. Wenn das ConfigurationWord nicht programmiert wird stehen dort alle Bits auf '1'. Der PIC sollte mit Quarzoscillator laufen, der Oscillator war aufgrund des nicht programmierten ConfigurationWords aber auf externen RC-Oscillator eingestellt. Und ganz nebenbei war damit auch die CodeProtection nicht gesetzt. Das Programm ließ sich auslesen. Zum Glück lief die Schaltung nicht, sonst wäre das vermutlich nie aufgefallen.


Security Bits im Configurationword. Kopierschutz !
Die Security Bits im Configurationword verhindern das der Inhalt des PIC's ausgelesen werden kann. Wenn diese Bits programmiert sind kann der Inhalt des PIC's nicht mehr ausgelesen werden. Es gibt keine Möglichkeit diese Bits zurückzusetzen, außer man löscht den gesamten Inhalt des PIC's. Die Security-Bits sind bei PIC's die man vorprogrammiert kaufen kann meistens gesetzt. Kopierschutz !

Achtung: Security oder CodeProtectionBits (Leseschutz) im Configurationword nicht setzen wenn nicht unbedingt erforderlich

Die Security-Bits im Configurationword nur bei OTP PIC's oder bei PIC's die mit einem Gerät verkauft  werden setzen. Die Security-Bits lassen sich oft nach dem programmieren von PIC's im UV-Gehäuse nur sehr schwer oder auch gar nicht mehr löschen. Bei einer 10er Serie von 16C73 im UV-Gehäuse ließen sich bei mir die PIC's fast alle zur selben Zeit scheinbar nicht mehr löschen. Beim Auslesen waren keine 0x3FFF Leerzellen vorhanden, sondern alle Zellen mit 0x007F gefüllt. Auffälligerweise war das Configurationword nicht ganz gelöscht worden. Die SecurityBits standen auf 0. Damit war der PIC trotz gelöschtem Programmspeicher immer noch kopiergeschützt und als Nebeneffekt auch schreibgeschützt. Erst nach mehreren 15Min. Löschvorgängen (min. 3, oft 10 und mehr) gingen die Security-Bits wieder auf 1. Setzt man die Security-Bits nicht , läßt sich ein PIC16C73 in ca. 5 Minuten wieder löschen. Ein PIC16C73Aließ sich gar nicht mehr löschen. Teurer Schrott.

Auch bei den Flash PIC's wie 16F84 sollten diese Bits im Configurationword nicht gesetzt werden. Freeware Programme wie ICProg wollen die Code Protection scheinbar nur über das Bulk Erase (alles löschen) Kommando entfernen. Ein Hilferuf läßt mich darauf schließen. Ein 16F84A ließ sich mit ICProg nicht mehr löschen. Bei neueren PIC's wie 16F873, 16F84A u.a. bewirkt das Bulk Erase Kommando bei gesetzter Code Protection gar nichts wenn nicht vorher die Befehlssequenz für Disable Code Protection zum PIC gesendet wurde. Wie die aussieht steht in den Programming Specifications zu PIC's auf der Seite von Microchip.


Power Up Timer im Configurationword
Der Power Up Timer sollte nur deaktiviert werden wenn die Schaltung so schnell wie möglich anlaufen soll. Das ist bei 99% der Schaltungen gar nicht erforderlich. Nach dem einschalten hält der Power Up Timer den  PIC für ca. 72ms im Resetzustand. Das ist bei netzbetriebenen Geräten nützlich um dem Elko hinterm Gleichrichter Zeit zu geben auf einen stabilen Pegel zu kommen. Er ist erst nach einer oder mehr Halbwellen der Netzspannung ganz geladen. Der PIC braucht mit PowerUp Timer in der Regel keinen Resetbaustein wie TL7705. Nur bei batteriebetriebenen Geräten kann die Betriebsspannung in sehr kurzer Zeit hochfahren.


RC-Calibration Wert
Bei UV löschbaren PIC's im Keramikgehäuse sollte unbedingt der Kalibrierwert des internen RC-Oscillators ausgelesen und auf dem PIC mit einem wasserfesten Stift notiert werden. Dieser Wert wird beim ersten Löschvorgang mit UV-Licht gelöscht und ist danach unwiderruflich verloren. Wer ein PIC-Programmiergerät kauft sollte darauf achten daß dieser Wert vor dem Löschen gelesen und bei der Programmierung eingegeben werden kann.

Der RC-Calibration Wert verursacht bei 12C(E)5xx Probleme ! Er wird bei PIC's im Plastikgehäuse von Microchip an der letzten Adresse des Programmspeichers im Werk fest einprogrammiert. Wer im Programm diese Adresse wie von  PIC16C5x gewohnt benutzen will um an die Startadresse des Programmes zu springen wird keinen Erfolg haben. Der Wert kann bei Plastiktypen nicht korrekt programmiert werden. Nach dem einschalten von 12C5xx PIC's gehen diese zuerst an die letzte Adresse im Programmspeicher. Scheint ein Relikt aus den 16C5x Typen zu sein. Bei 12C(E)5xx-Typen wird das W-Register über einen MOVLW xx Befehl mit dem RC-Calibration Wert geladen und der Programmzähler läuft über auf Adresse 0. Dort sollte erst das OSCCAL-Register mit dem W-Register geladen werden. Danach kann der Sprung zum Hauptprogramm erfolgen. Bei UV löschbaren PIC's ist es allerdings möglich den Sprung zum Hauptprogramm an die letzte Adresse im Programmspeicher zu legen. Der Calibration Wert wird ja gelöscht. Wenn so ein Programm dann aber in einen Plastiktypen programmiert werden soll geht das schief. Wie InCircuit Emulatoren für PIC12C(E)5xx mit diesem Problem umgehen kann ich nicht sagen. Falls Programme auf dem Emulator laufen, aber im PIC nicht, könnte oben aufgeführtes der Grund sein.

Bei 12C67x gibt es mit dem RC-Calibration Wert keine Probleme. Nach einem Reset wird bei Adresse 0 gestartet. Der RC-Calibration Wert ist als RETLW xx fest in der letzten Adresse des Programmspeichers einprogrammiert und kann über ein CALL 'Letzte Adresse' ins W-Register geladen werden. Bei Plastiktypen kann die letzte Adresse im Programmspeicher wegen des RC-Cal Wertes aber nicht für das Programm verwendet werden.

Der C-Compiler MPC V1.2 von ByteCraft führt den Sprung zum Hauptprogramm z.B. bei PIC12C508 falsch, wie oben beschrieben, aus. Erst nach aufwendiger Änderung der Headerdateien kann dieser lauffähige Programme für PIC12C508 erzeugen. In der Version 1.3 ist dieses Problem behoben.



Der SLEEP Befehl
Der SLEEP Befehl versetzt den PIC in den Tiefschlaf. Der Stromverbrauch sinkt unter 1uA. Fast alle Funktionen werden abgeschaltet. Z.B. der Quarzoscillator und auch TMR0. Bei allen Ereignissen die den PIC aus dem SLEEP Modus aufwecken können ist zu beachten das der PIC nicht sofort wieder voll einsatzbereit ist. Als Minimale Reaktionszeit muß der Oscillator Startup Timer OST beachtet werden. Erst nach 1024 Taktzyklen wird das Programm wieder bearbeitet. Dazu kommt noch die Anschwingzeit für den Oscillator selbst !

Doch Vorsicht: Der SLEEP Befehl wird in der PIC Familie unterschiedlich bearbeitet

Beim 12C508 führt ein Wakeup from SLEEP immer zu einem Reset. Beim 16F84 wird bei einem Wakeup (z.B. möglich durch Interrupt an PB0, PORTB-Change oder EEPROM Write fertig) nach einem SLEEP Befehl an der Stelle im Programm weitergemacht die hinter dem SLEEP Befehl steht. Dort sollte laut Microchip auch ein NOP stehen. Die Programmgestaltung ist bei diesen PIC's also unterschiedlich. Programme für den 12C508 die den SLEEP Befehl benutzen können nicht auf einem 16F84 benutzt werden.



Der Watchdog Timer
Anfänger sollten auf keinen Fall den Watchdog Timer aktivieren. Das Programm des PIC's muß darauf angepasst sein. Programme mit Watchdog sind selbst für Profis eine knifflige Sache. Wenn ein Programm nicht funktioniert weiß man oft nicht ob es ein Watchdog Timeout Reset oder ein Programmierfehler war.

Wer mit dem Watchdog arbeiten möchte sollte bedenken das dieser in regelmäßigen Abständen mit CLRWDT zurückgesetzt werden muß.
Der Watchdog ist nur im Configurationword ein/ausschaltbar. Also nur wenn der PIC programmiert wird. Er kann nicht im laufenden Programm de- bzw. aktiviert werden ! Wenn der Watchdog Timer überläuft führt dies gnadenlos zu einem Reset des PIC's. Egal an welcher Stelle des Programmes. Wer den Watchdog Timer nicht benötigt muß ihn auf jeden Fall im Configurationword deaktivieren.

Der Watchdog Timer läßt sich beim 16F84 hervorragend als zweiten Timer benutzen. Nur mit ihm ist es möglich nach einem SLEEP Befehl den PIC nach einiger Zeit automatisch wieder aufzuwecken. TMR0 z.B. wird beim SLEEP Befehl abgeschaltet . Der Watchdog wird von einem RC-Oscillator getaktet. Deshalb sind die Zeiten für den Watchdog Timer nicht besonders genau. Sie sind abhängig von der Betriebsspannung und von der Temperatur !

Nicht vergessen ! Der Watchdog muß regelmäßig im Programm zurückgesetzt werden damit er keinen Reset auslöst



PORTA will nicht richtig arbeiten
Ich bin früher immer davon ausgegangen das die IO-Pins nach einem Reset vom PIC erstens als Eingänge und zweitens als digitale IO-Pins konfiguriert werden. Das ist nicht so. Beim 16F873 werden die Pins für den AD-Wandler nach einem Reset auf analoge Eingänge  gesetzt. Bei 16C620 und 16F628 ist nach einem Reset das Komparatormodul aktiv. Wer diese Funktionen nicht braucht muß die Ports in den entsprechenden Registern (CMCON beim 16C620,16F628 oder ADCON beim 16F873 u.a.) zu Beginn des Programmes immer auf digitale IO-Pins setzen.


PIC12F629/675 wollen nicht funktionieren
Das gleiche Problem wie bei "PORTA will nicht richtig arbeiten". Siehe oben. Die IO-Pins werden nach einem Reset auf die analogen Funktionen eingestellt. Setze ganz am Anfang deines Programmes CMCON auf 0x07 und ANSEL auf 0x00. Dann arbeiten alle IO-Pins als digitale Ein/Ausgänge.


RC-Oscillator statt Quarz
RC-Oscillatoren kommen immer dann in Frage wenn der PIC sehr langsam getaktet werden soll und es dafür keine Quarze oder Keramikresonatoren gibt. Das ist der Bereich von 0Hz bis 1MHz. Dort sind nur wenige Werte verfügbar.

Wer den internen oder externen RC-Oscillator benutzen möchte sollte sich darüber im klaren sein das der bei weitem nicht so genau ist wie ein Quarzoscillator. Die Frequenz von RC-Oscillatoren ist abhängig von der Temperatur, der Versorgungsspannung, der Toleranz des Widerstandes und des Kondensators. Microchip gibt in Datenblättern bis zu 27% an. Genaues Timing ist damit kaum möglich. Für ein Blinklicht oder eine Ampelsteuerung reicht das, aber nicht für eine Uhr. Besonders beim externen RC-Oscillator spielt die Versorgungsspannung eine große Rolle. Eine Schaltung die bei 5V mit engem Timing funktioniert könnte bei 3V nicht mehr laufen weil der Ladestrom (Ladekurve !) für den Kondensator wesentlich kleiner und die Ladekurve flacher ist, und damit die Taktfrequenz des PIC's kleiner. Wenn die Versorgungsspannung schwankt wird die Oscillatorfrequenz quasi moduliert.

Das könnte aber auch ausgenutzt werden wenn der PIC mit einem Pin einen Widerstand zum RC-Oscillator zu/abschaltet um zwischen einem UltraLowPowermodus und hoher Rechengeschwindigkeit umzuschalten.

Statt des Widerstandes sollte wenn ein großer Spannungsbereich gewünscht ist besser eine Konstantstromquelle benutzt werden. Der interne RC-Oscillator von PIC's ist nach meinen Erfahrungen über größere Spannungsbereiche relativ genau. Dort scheint eine Konstantstromquelle benutzt zu werden. Microchip gibt aber Fertigungstoleranzen von mehreren 100kHz an.



Quarz-Oscillator Probleme
Normalerweise gehe ich bei PIC's etwas lax mit den Kondensatoren im Oscillatorkreis um. Meistens ist es ein 4MHz Quarz und Einstellung XT-Oscillator. Ich nehm da mal den mal den Kondensatorwert. Beim PIC16F84 z.B. 22pF oder 27pF. Was gerade so rumliegt.

Irgendwann fragte mich  jemand ob ich ihm helfen könnte, seine Schaltung mit PIC16F84 läuft einfach nicht. Die Schaltung schien laut Schaltplan und Stückliste ok zu sein. Kann sich also nur um einen Programmfehler oder einen Fehler im Configurationword handeln. Alle Tips dazu halfen nichts. Er hat den Fehler dann selbst gefunden. Er hatte 16pF Kondensatoren statt 20pF in der Stückliste eingesetzt. (Merkwürdige Werte !?) . Der Oscillator schwang damit nicht an. Die Kondensatoren waren einfach zu klein . Laut Datenblatt können 15pF bis 33pF Kondensatoren benutzt werden. Man sollte aber nicht zu dicht an die Grenzwerte gehen. Beim 16F84 und auch den meisten anderen 16C/Fxxx PIC's schwingt der Oscillator laut meinen Erfahrungen immer mit Werten von 22pF bis 27pF ohne Probleme an.

Dann bin ich selbst in die große Bärenfalle getreten. Ich wollte einen PIC12C509 bei 4MHz mit 33pF Kondensatoren betreiben. Laut Murphys-Law klappte das beim ersten Versuch natürlich. Einen Tag später ging nichts mehr. Mit anderen PIC12C509 auch nicht. Ursache: Der Oscillator lief wieder nicht. Die Kondensatoren waren zu groß. Ein Blick ins Datenblatt ergab das dort nur 15pF als Wert angegeben wurde. Hmm 15pF hab ich nicht, aber 22pF eingesetzt und der Oscillator läuft. 

Fazit: Wenn ein PIC Programm gar nicht läuft sollte man auch mal mit dem Oszi kontrollieren ob der Quarz-Oscillator schwingt. Wenn nicht, erstmal kontrollieren ob die Oscillatoreinstellung im ConfigurationWord richtig ist. Ist sie richtig unbedingt ins Datenblatt sehen ob die Kondensatorwerte für den Oscillator auch stimmen.



Probleme mit ICProg, JDM, Ludipipo und CO ?
Als erstes: Frag mich bitte nicht wenn du Probleme mit diesem ganzen Zeug hast ! Da kann ich dir nicht helfen. Ich benutze nichts davon und habe keine Ahnung von dieser und jener Einstellung die man in ICProg anklicken kann. Frag denjenigen der die Soft/Hardware entworfen hat wenn du Probleme damit hast.

Ich weiß das ich mich mit dem was ich hier schreibe in die Nesseln setzte weil bei unendlich vielen Usern diese Prommer funktionieren. Das ist prima. Aber leider nicht immer der Fall. Ich rate keinem davon ab diese Prommer zu bauen und einzusetzen. Sie haben dazu beigetragen das PIC's und andere Prozessoren auch ohne die teuren Entwicklungskits von Hobbyisten mit geringen Kosten eingesetzt werden können. Ich möchte das hier nur als Entscheidungshilfe verstanden wissen welchen Prommer man einsetzen sollte. 

16F84 lassen sich oft schon ab 8V Programierspannung programmieren. Das kann aber dazu führen das die irgendwann einmal im Betrieb wegen zu kleiner Programmierspannung ausfallen ! Die korrekte Programmierspannung für die meisten PIC's ist 13.0V. Bei 12C508 z.B. ist die untere Grenze laut Datenblatt 12.75V. Prommer die einen 12V Regler für Vpp benutzen liegen damit schon unter dem Limit ! Die obere Grenze liegt beim 12C508 bei 13.25V. Vpp muß also eng eingegrenzt werden. Schaltungen die Vpp nur mit Z-Dioden einstellen sind gefährlich für PIC's. Und neuere PIC18Fxxx dürfen maximal 12,5V Vpp. PIC16F91X/946 maximal 12V Vpp. Was passiert wenn man die mit 13V programmiert ? Keine Ahnung. Ich würde es gar nicht erst probieren. Und selbst wenn es klappt, die so programmierten PIC's nicht in kommerziellen Produkten einsetzen. Fazit: Ein universeller PIC-Programmer sollte eine einstellbare Programmierspannung haben. Und natürlich über das Treiberprogramm einstellbar ! Jumper oder Trimmer zum einstellen der Programmierspannung führen laut Murphy IMMER zu Fehlern weil der ANWENDER vergißt sie richtig einzustellen. Von solchen Programmern sollte man besser die Finger weglassen.

PIC Prommer am COM-Port:
Bei den Billigstprommern am seriellen Port liefert die Schnittstelle oft nicht genug Saft. Dann stimmt die Programmierspannung nicht! Leider wird auf keiner der Seiten die diese Prommer frei zur Verfügung stellen darauf hingewiesen. Das kann schon mal den einen oder anderen PIC kosten. Ich kenne einen Fall wo ein PIC12CE519 mit zu wenig Spannung programmiert wurde und auch das Verify OK meldete. Nur funktionieren wollte er danach nicht ! Bei OTP PIC's heißt das: Schrott ! Oder der PIC wurde an Speicherstelle 0 mit dem Wert von Speicherstelle 5 und dann folgend programmiert. Da wurde nicht darauf gewartet bis Vpp und Vcc auf richtigem Pegel liegen, bzw. die Elkos in der Schaltung sind einfach zu groß für das Treiberprogramm. Dann gibt es noch die Perfektionisten die sich eine LED am Prommer anschließen damit sie eine Anzeige haben ob der PIC auch wirklich programmiert wird. Tja, die LED leuchtet dann auch fleißig. Sie frißt dann aber soviel Strom aus der Schnittstelle das die Programmierspannung für den PIC nicht mehr reicht. Auch dann meldet das Verify oft OK (wenn während des Programmiervorgangs überhaupt ein Verify durchgeführt wird !?). Der PIC will danach aber einfach nicht funktionieren.

Laptop's liefern am COM-Port oft nicht die Pegel die man von einem richtigen PC erwartet. Wer JDM oder Ludipipo an einem Laptop einsetzen möchte sollte erstmal kontrollieren ob die Pegel ausreichen.

Billig PIC-Prommer am seriellen Port kann man nur als "experimentell" bezeichnen. Für OTP-PIC's wie 12C508 würde ich die auf keinen Fall einsetzen. Wer JDM oder Ludipipo als Produktionsprogrammer einsetzt oder eingesetzt hat sollte sich über Reklamationen nicht wundern ;)

PIC Prommer am Parallelport:
Diesen Prommern sollte auf jeden Fall der Vorzug gegeben werden. Sie benutzen immer eine externe Spannungsversorgung. Hier darauf achten das Vpp vom Programm passend zum PIC eingestellt werden kann ! Spannungsregler brauchen in der Regel ca. 3V Überspannung am Eingang um die Ausgangsspannung vernünftig zu stabilisieren. Für 13V muß das Netzteil also mindestens 16V= liefern können. Besser ein paar Volt mehr. 12V= Steckernetzteile sind dann nicht unbedingt empfehlenswert. Die Leerlaufspannung dieser Netzteile liegt oft weit über 12V. Wenn man etwas Strom zieht brechen die aber zusammen. Ein 15V~ Trafo mit Gleichrichter und Siebelko eingebaut in ein Steckergehäuse ist auf jeden Fall die bessere Lösung.

Doch Vorsicht: Das Problem bei allen Prommern ist die Kabellänge ! Bei ersten Versionen des Multiproms gab es schon ab 1,5m Probleme mit billigen Kabeln. Schaltflanken finden bei langen oder schlechten Kabeln manchmal den Weg in eine benachbarte Leitung. Das kann zur Katastrophe führen. Beim Multiprom habe ich deshalb schon sehr früh ein Hardwarehandshake eingeführt. Kein mir bekannter freier PIC-Prommer macht das. Deshalb mein Tip: Je kürzer das Kabel desto besser. Wer Kabel mit 2,5m oder länger benutzt ist selber schuld.

Ich bekomme öfter Mails von Opfern. Da kann ich nicht helfen. Bei Problemen mußt du dich an die Entwickler der Software/Hardware wenden. Da schon öfter danach gefragt wurde: Ich habe nicht vor Ludipipo oder JDM auf externe Spannungsversorgung umzubauen.


Die PORTA4 Falle beim PIC16F84 u.a. PIC's
PORTA4 beim 16F84 ist nicht so ohne weiteres als Ausgang benutzbar. Als Eingang macht PORTA4 keine Probleme, als Ausgang schon. PORTA4 ist ein OpenDrain-Ausgang oder bezogen auf bipolare Transistoren ein OpenCollector-Ausgang. Der Pin kann bei LowLevel ohne Probleme 25mA ziehen. Bei HighLevel passiert aber gar nichts. Der Pin bleibt auf 0V. Er kann keinen Strom liefern. Um bei HighLevel Strom liefern zu können muß ein Pullup-Widerstand angeschlossen werden. Das gilt auch für andere PIC's z.B. 16F873.

LVP-Bit: Probleme beim brennen von PIC16F628 und neueren PIC16FXXX. Auch PIC18Fxxxx !
PIC16F628 und andere neuere PIC16FXXX haben einen sogenannten Low-Voltage Programmiermodus. Der kann besonders bei der InCircuit Programmierung Probleme machen. Ich hatte eine Schaltung mit LCD-Display gebastelt. Den PIC wollte ich wie sich das gehört in der Schaltung programmieren. Ging aber nicht. Außerhalb der Schaltung: kein Problem. Nach langer Suche fand ich den Grund. Bei einem nagelneuen PIC16F628 ist das Configurationword gelöscht und das darin enthaltene LVP-Bit gesetzt. Damit ist der Low-Voltage Modus aktiv wenn man PORTB4 auf High legt. Und genau das hat das angeschlossene LCD-Display getan. Die High-Voltage Programmierung (13V auf MCLR) wird dadurch abgeschaltet bzw. funktionierte bei mir nicht. Abhilfe: Einen Pulldown Widerstand 4k7 an PORTB4 anschließen, den Pin offen lassen oder anders dafür sorgen das PORTB4 im Resetzustand auf 0V liegt. Leider ist nicht bei allen PIC's PORTB4 für dieses Verhalten verantwortlich ! Beim PIC16F873 aktiviert PORTB3 den Low-Voltage Programmiermodus, bei PIC18F458 PORTB5. Bei ähnlichen Problemen also erstmal das Datenblatt zum PIC durchlesen.

Und so nebenbei: Auch wenn in den Programming Specifications steht das der High-Voltage Modus den Low-Voltage Modus überschreibt, DAS STIMMT EINFACH NICHT ! Wenn das LVP-Bit im Configurationword auf 1 steht (PIC gelöscht bzw. neu gekauft), muß nach meinen Erfahrungen der Pin der bei der Low-Voltage Programmierung auf 1 liegen soll bei der High-Voltage Programmierung unbedingt auf 0V liegen.



Nachteile bei der LVP Programmierung

Wer PICs im LVP Modus programmieren will muß auf einen Portpin komplett verzichten. Der muß immer auf 1=High liegen. Er kann im Programm nicht verwendet werden weil er für die LVP-Programmierung reserviert ist. Bei PIC16F628 ist das PORTB4, bei PIC16F873 PORTB3, bei PIC18F458 PORTB5..... Bei anderen PICs siehe Datenblatt oder Programming Specifications auf der Seite von Microchip.




Der Hardware-Stack
PIC's haben im Gegensatz zu vielen anderen Microcontrollern z.B. 8051 einen Hardware-Stack. Das bedeutet das die Rücksprungadresse für ein CALL nicht im RAM abgelegt wird, sondern in speziellen nicht zugänglichen Registern. Das hat Vor- und Nachteile. Vorteil: Man muß sich nicht wie bei 8051 darum kümmern wo der Stack liegt. Er kann auch nie in RAM-Bereiche wandern und diese zerstören. Nachteil: Die Stackgröße ist fest und kann nicht verändert werden.

Die Stackgröße beträgt bei 16F84 acht Level. Das heißt man kann theoretisch acht CALL's verschachteln bzw. Hauptprogramm ruft Funktion1 auf, Funktion1 ruft Funktion2 auf, ..... Funktion7 ruft Funktion8 auf. Dann ist Schluß. Wenn Funktion8 ein CALL ausführt kann per RET nur noch bis Funktion1 zurückgesprungen werden. Die Adresse zum Rücksprung ins Hauptprogramm wird durch das CALL in Funktion8 überschrieben. Das Programm stürzt ab.

Dabei muß man beachten das ein Interrupt auch einen Stacklevel belegt. Tritt in Funktion8 ein Interrupt auf stürzt das Programm ab. Weiterhin werden auch Tabellen oder Zeichenketten mit Konstanten bei PIC-C-Compilern gerne durch eine Liste aus RETLW zusammengestellt die dann per CALL ausgewertet werden. Wird so eine Liste in Funktion8 ausgewertet stürzt das Programm ab. Wird so eine Liste in Funktion7 ausgewertet und dabei tritt ein Interrupt auf, stürzt das Programm ab.

12C508 und 16C54 haben sogar nur zwei Stacklevel. Was das bedeutet muß man wohl nicht weiter erläutern. Das ist unter anderem ein Grund weshalb die meisten Programme für 16F84 nicht auf 12C508 oder 16C54 laufen können. Programme für 12C508 oder 16C54 laufen aber ohne Änderungen auch nicht auf 16F84. Grund: der Resetvektor liegt bei 16F84 bei Adresse 0, bei 12C508 und 16C54 am Ende des Programmspeichers.

12C508, 12C509, 12CE518 und 12CE519 sind verwandt mit den alten 16C5x aus der Steinzeit. Das gilt aber nicht für z.B. 12C671 oder 12F675. Der Resetvektor liegt beim 12C671 auch bei 0 und die Stackgröße beträgt acht Level. Er ist verwandt mit den neueren 16C/Fxxx PIC's. Microchip hätte bessere Namen verteilen sollen. Die 12 vor dem Namen weist eigentlich nur auf ein 8 poliges Gehäuse hin, nicht auf eine verwandte Prozessorfamilie. In Datenblättern zu 12er PIC's habe ich gelegentlich auch schon gesehen, das sie nach dem runterladen im Datenblatt eine 16 vor dem Namen hatten ;) Wäre schön wenn es so geändert würde. Ich hätte nichts gegen einen 16C671. Ganz im Gegenteil, ich wünsche ihn mir. 

PIC18 haben einen 32 Level Hardwarestack. Im Gegensatz zu anderen PIC's kann der sogar manipuliert werden. Zusätzlich einen FAST REGISTER STACK. Damit kann man automatisch mit einem Fast Call oder bei einem Interrupt STATUS, WREG und BSR per Hardware sichern und über ein Fast Return wiederherstellen. Jetzt kommen aber gleich die Einschränkungen. Wenn ein Interrupt aktiv ist kann man den Fast Register Stack mit Fast Call's nicht benutzen, es sei denn man verbietet Interrupts. Der Interrupt überschreibt die gesicherten Werte vom Fast Call. Und wenn während eines LowPriority Interrupts ein HighPriority Interrupt auftritt wird der Fast Register Stack vom HighPriority Interrupt überschrieben. Benutzung also nicht ungefährlich. Ein eigener Fast Register Stack für jeden dieser drei Fälle wäre sinnvoller gewesen. Nur sechs Register mehr im PIC18 und der Unsinn hätte ein Ende. Die Hardwareentwickler bei MCHIP sollten besser mal darüber nachdenken wie man dem Anwender das Leben erleichtert, statt solche unübersichtlichen Fehlerquellen einzubauen.



Probleme mit PIC18Fxxxx und Table Read Protection im ConfigurationWord

Bei meinen ersten Versuchen mit PIC18F und Grafikdisplays lief merkwürdigerweise erstmal gar nichts. Problem: Die TableRead Protection im Configurationword war für alle Blöcke aktiviert. Der PIC kann keine Daten aus geschützten Blöcken lesen wenn der Programmteil der diese Daten lesen soll in einem ungeschützen Block oder nicht im geschützten Block selbst liegt. Abhilfe: TableRead Protection gar nicht erst setzen. Dann klappts auch mit dem Display.



PORTB6 und PORTB7: Funktionieren nicht wenn der Debug Modus aktiviert ist

Wenn der Debug Modus im ConfigurationWord aktiviert ist können die Portpins PORTB6 und PORTB7 nicht mehr vom PIC im Programm verwendet werden.



PSPMODE Falle bei PIC's mit PORTD und PORTE

Da bin ich gerade selbst voll ins Fettnäpfchen getreten. An PORTD sollten zwei 74HCT245 zur Dateneingabe. TRISD schön auf 0xFF für Eingänge gesetzt. Aber nix ging. Die Datenleitungen an PORTD kamen mit den 74HCT245 nicht richtig auf Nullpegel und auch ansonsten passte das was an PORTD auf dem Osci zu sehen war nicht zu meinem Programm :( Dachte schon die 74HCT245 Chip sind defekt. Waren sie aber nicht. An PORTE hatte ich ein paar Ausgänge. TRISE einfach auf 0xF8 für die drei Ausgänge. Alle anderen Bits einfach auf 1 für Eingang setzen. D3..D7 sind ja gar nicht vorhanden an PORTE. Dummerweise liegt in TRISE auf D4 das Bit zum aktivieren des PSPModus für PORTD. Das hatte ich gesetzt.  D4 in TRISE auf 0 gesetzt und PORTD funktioniert so wie geplant.



Die BOREN-Falle bei PIC16LFxxx

Wenn man einen PIC16LFxxx mit z.B. 3V betreiben möchte, darf man auf keinen Fall den Brown-Out Reset im Configurationword aktivieren. Der Brown-Out Reset hält den PIC unter 3.65V-4.35V Betriebsspannung im Resetzustand.



MCLR nicht direkt mit VDD verbinden !

Im Datenblatt zu PIC16F819 steht das man MCLR nicht direkt mit der Versorgungsspannung verbinden sollte. Es kann dann zu Latch-Up Effekten kommen (ne Menge Strom fließt in den MCLR Pin). MCLR sollte mit einem Widerstand von mindestens 1k Ohm mit VDD verbunden werden.



Bootloader funktioniert nicht

Das hatte ich gerade mit dem Bootloader von www.microchipc.com . Bei meinen 16F873-20 (keine A-Typen) funktionierte der Bootloader nicht richtig. Die Programmierung wurde immer wieder wegen Fehlern abgebrochen. Wie so oft lag das Problem nicht im Programm sondern im falschen Configurationword. Dort war das LVP-Bit auf an gesetzt. Setze ich das LVP-Bit auf aus funktioniert der Bootloader.


MCC18 und die Procedural Abstraction

Ich habe mich immer gefragt was diese Procedural Abstraction eigentlich ist ? Eine abgelaufene Demoversion von MCC18 V3.00 meldet dauernd diese Warnung beim compilieren. Ein Blick in das erzeugte Assemblerlisting einer nicht abgelaufenen Version brachte es ans Licht: Teile des Programmes die ähnliche Funktionen ausführen werden vom Compiler eigenständig in ein Unterprogramm verwandelt. Das macht den erzeugten Code ziemlich effektiv kleiner. Hat aber auch einen gravierenden Nachteil: Der Code wird durch die Aufrufe von Unterprogrammen langsamer ! Wer das  nicht möchte sollte Routinen die möglichst schnell sein sollen in eine separate *.c Datei legen und diese mit dem Parameter -Oa- compilieren.


PIC18F Löschprobleme beim brennen

Unterhalb von 4,5V Versorgungsspannung können PIC18F nicht mit dem Chiperase Befehl gelöscht werden.


E-Mail

Zur Startseite