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

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.

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.

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.

• 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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

---