Nachdem die von mir für verschiedene Anwendungen aufgebauten "TTL-Gräber" immer mehr Verlustleistung erzeugten, immer größere Stromversorgungen benötigten, und sich auf dem Weg vom ersten Versuchsaufbau bis zur funktionierenden Schaltung in unübersichtliche Drahtknäuel verwandelten, musste ich mich doch einmal mit der etwas moderneren (und flexibleren) Technik der Microcontroller beschäftigen. Da die dafür notwendigen Programme (Assemmbler, Simulator, ...) natürlich unter Linux laufen sollten, entdeckte ich sehr bald "www.gnupic.org" (Link entfernt, diese Seite wurde gehackt oder verkauft → Enthält nur noch "Müll", die "sinnvollen" Infos sind nun bei gputils.sourceforge.net zu finden), wo fast alles Notwendige zu finden ist. Nachdem mein erstes PIC-Programm im Simulator lief und die erste Testschaltung "stand", stellte sich die Frage "Und wie bekomme ich nun mein Programm in den Chip?". Die bei "gnupic" vorgestellten Schaltungen waren fast nur kommerziell, recht umfangreich und/oder für den Parallelport vorgesehen. Die einzige recht einfach aufgebaute Schaltung für die serielle Schnittstelle funktionierte zwar ganz gut, erzeugte jedoch am PIC Pegel, die doch recht weit von den Spezifikationen des Chips abwichen. Das muss doch (mit geringfügig größerem Aufwand) besser gehen! Nach einigen Variationen der Schaltung funktionierte diese auch an den Schnittstellen verschiedener PCs (-> Standard? Was ist das?) und die am PIC anliegenden Pegel stimmten relativ gut mit den Spezifikationen überein.
Den Schaltungsentwurf habe ich wieder einmal mit Hilfe von Eagle vorgenommen:
Da die Schaltung noch recht einfach geblieben ist, reichen ggf. auch ein paar Grafiken aus (die auch in dem dazugehörigen "Softwarepaket" enthalten sind).
 |
 |
 |
|
Funktionsweise: Solange das Signal TXD auf "Low" liegt (Ruhezustand), wird C1 über R3 und D6 auf ca. -12V aufgeladen und dient dann als Stromversorgung für den PIC. T3, R4 und D1 sorgen dafür, daß die PIC-Spannung ca. 5.5V beträgt und auch im Programmiermodus (TXD auf "High") noch eine Weile halbwegs konstant bleibt. Das Signal RTS liefert über R6 das Taktsignal während der Programmierung, und Signal DTR füttert über R1, R7 und R9 dem PIC mit Daten. Werden Daten vom PIC gelesen, bleibt DTR auf "High" und liefert über R1 ein "High"-Signal an CTS. Legt der PIC zur Signalisierung einer "0" RB7 auf "Low" (hier VSS = ca. -5V) bewirkt der Spannungsabfall über R9 das Durchsteuern von T2 und T1, was Signal CTS an den negativ aufgeladenen C1 legt und somit "Low" wird. D2, D3, D4 und D5 sorgen dafür, dass die Pegel am PIC so einigermassen im spezifizierten (erlaubten) Bereich bleiben.
 |
|
Update 14.06.2011:
Nachdem der Prommer einige Jahre problemlos funktioniert hat, tauchte ein Problem auf, welches mich fast zur Verzweiflung brachte: Ein gerade programmierter PIC war plötzlich weder programmierbar, noch auszulesen. Selbst die PIC-Id wurde nicht mehr erkannt. Ok, dachte ich, nun habe ich das erste Mal einem PIC durch statische Aufladung "zerschossen", kann ja mal passieren... Ein neuer Chip ließ sich auch wieder auslesen. Nur nach dem Programmieren der gleiche Effekt! Sollte meine Schaltung auf einmal PICs "killen"? Seltsamerweise funktionierte das neu gebrannte Programm sogar... Erst nach mehreren Tagen verzweifelten Messens und Experimentierens habe ich die Ursache entdeckt: In dem eingesteckten PIC lief das Anwendungsprogramm, welches u.a. MCLR abschaltete und als Port benutzte. Der PIC ging trotz Anlegens der Programmierspannung nicht in den Programmiermodus, da VDD kontinuierlich anlag. Daher habe ich einen weiteren Transistor in die Zuleitung zum Pin VDD eingebaut, der VDD erst ein paar µs nach dem Anlegen der Programmierspannung einschaltet. Nun lassen sich auch Applikationen in den PIC brennen, die MCLR abschalten... Die entsprechende Modifikation ist derzeitig nur in den beiden Eagle-Dateien enthalten, die drei Grafiken enthalten diese Änderung (noch) nicht.
Startseite Hardware Rechtliches Kontakt Darstellung