Mein PIC-Prommer ist nun "schon etwas in die Jahre gekommen", der Aufbau ist etwas sehr primitiv, und die Handhabung ist auch nicht gerade angenehm. Und da ich nun auch gelegentlich (alte) EPROMs auslesen wollte, ohne dafür jedes Mal (auf die Schnelle) eine kleine Schaltung aufzubauen, musste ich mir so langsam mal Gedanken über die Neukonstruktion eines Prommers machen. Ja, manche Leser mögen mich nun fragen "Warum kaufst du dir nicht einfach ein entsprechendes Gerät? Die können doch einer Menge verschiedener Chips programmieren". Das ist durchaus richtig, aber wenn ich mir die Preise von "brauchbaren" Programmiergeräten so ansehe (meist mehrere hundert €), und dann noch lesen muss "mit Software" (ohne Angabe des Betriebssystems), dann weiss ich schon, daß es für mich unbrauchbar ist. Und bei einem Selbstbau wird man ja auch nicht gerade dümmer...

Überlegungen zur Konstruktion

Für das Auslesen und die Neuprogrammierung von alten EPROMs hatte ich vor Jahren mal ein entsprechendes Gerät, welches ich dummerweise mal verliehen (und natürlich nicht mehr wieder bekommen) habe. Eine Suche in meinen alten Unterlagen förderte tatsächlich noch einen Schaltplan ("Ludi-Prommer"?) zutage, den ich erst einmal in KiCad nachzeichnete, um die Funktionsweise zu ergründen.   Hmm, zu diesem Konstrukt habe ich sogar noch etwas Quellcode (in Pascal) gefunden, was ich hätte in "C" umschreiben können, um ein solches Gerät auch unter Linux zu betreiben. Nur welcher heutige PC hat noch eine Parallel-Schnittstelle? Es mag zwar auch Adapter von "USB auf Parallel" geben, nur ob die auch die "kreative Verwendung der Portbits (bidirektional!)" noch unterstützen, ist doch sehr fraglich...   Aber die Verwendung der "Portexpander"-Chips gefiel mir, zumal ich noch ein paar davon in meinem Fundus entdeckte. Wenn ich die nun mit einem Microcontroller ansteuere, der eine (eher übliche und universelle) serielle Schnittstelle hat, ...

Der neue Schaltplan

Den Entwurf eines neuen Schaltplans begann ich mit den verschiedenen EPROMs, die in den Programmiersockel passen sollten, wobei sich die Problematik ergab, daß die verschiedenen Chips nicht nur eine verschiedene Anzahl von Pins hatten, sondern einige Pins auch bei verschiedenen EPROMs unterschiedlich verwendet werden → Mal als Adressbit, mal Betriebsspannung, mal Programmierspannung... An dieser Stelle fiel mir auf, daß die Schaltung nicht ganz so trivial werden würde, wie ich es mir anfangs vorgestellt hatte.
	Und dann waren da ja auch noch die PICs, die ich meist verwende... Da diese Chips ein schmaleres Gehäuse haben, wurde wohl ein Adaptersockel notwendig. Und auch hier zeigte sich das Problem, daß die Pinfunktionen über die verschiedenen Chips auch keineswegs immer gleich sind...
Da natürlich auch die Programmierspannungen für die verschiedenen Chips auch unterschiedlich sind, ergab sich noch die Notwendigkeit einer (mittels PWM) steuerbaren Programmierspannung. Dazu dann noch eine "echte" serielle Schnittstelle (incl. Hardware-Handshake RTS/CTS), ein paar Logikgatter, und ein paar trickreich plazierte Dioden. Das Ganze gut durchrühren, etwas "Hirnschmalz" zusetzen, eine Weile "gären lassen", und fertig ist der Schaltplan... Naja, zumindest ein erster Entwurf, der sich während des Layouts und des ersten Aufbaus noch an einigen Stellen änderte... In den nebenstehenden Schaltplan sind diese Änderungen bereits vorgenommen.

Der Aufbau der Hardware

Schon während des Entwurfs des Schaltplans wurde klar, daß das Layout aufgrund der Packungsdichte wohl doppelseitig werden würde. Außerdem musste ich einige Pins u.a. am Microcontroller vertauschen, um überhaupt mit zwei Layern auszukommen. Zusätzlich achtete ich darauf, möglichst wenige Durchkontaktierungen zu verwenden, und diese nicht unter Bauteilen zu plazieren. Das Layout der Adapterplatine für den 18poligen Programmiersockel fügte ich gleich mit ein, sodaß die Herstellung der beiden Leiterplatten "in einem Rutsch" zu realisieren war.   Die Leiterplatte stellte ich mit meinem "üblichen" Thermotransferverfahren her. Während der Bestückung stellte sich heraus, daß ich den Programmiersockel entgegen meines Plans nicht direkt (oder in einem Sockel) auf der Platine bestücken konnte → In einem Gehäuse eingebaut wäre, aufgrund der Bauhöhe anderer Bauteile, der "Klemmhebel" des Sockels nicht mehr zu betätigen gewesen. Also habe ich dieses Bauteil mit Hilfe eines Flachbandkabels angeschlossen. Durch diesen Umstand wäre es auch möglich geworden, auf die Adapterplatine zu ganz verzichten, und stattdessen den 18poligen Programmiersockel ebenfalls mittels Flachbandkabel zu kontaktieren.

Die Firmware des Microcontrollers

Um den Prommer möglichst universell (an beliebigen Systemen) einsetzbar zu bekommen, habe ich sämtliche Befehle und Ausgaben als "lesbares ASCII" implementiert. Dadurch wird zwar die Datenübertragung etwas ineffektiv (es müssen pro Datenbyte immer zwei Hexziffern übertragen werden), aber dafür lässt sich das Gerät (mit entsprechender Kenntnis der Befehle) vollständig mit Hilfe eines Terminalprogramms bedienen, was sich insbesondere beim "Debugging" als sehr nützlich erwiesen hat.   Die ersten implementierten Befehle waren "i" (Hardware-Initialisierung), "s<portnum><bitnum>" (Setzen eines Bits an den Portexpandern), "c<portnum><bitnum>" (Löschen eines Bits), "p<portnum><bitnum>" (Auslesen eines Bits), und "v<hexvalue<" (Einstellen der Programmierspannung), womit ich anfangen konnte, die Hardware zu testen.   Als die Hardware einigermaßen funktionierte, kamen die Funktionen "a<address>" (Setzen der Adressbits), "r" (Lesen eines Bytes), "w<byte>" (Schreiben eines Bytes), und "n" (Inkrementieren der Adresse) dazu, womit das Auslesen und Programmieren von EPROMs prinzipiell möglich wurde. Nur leider liegen die Adressbits nicht bei allen EPROMs auf den gleichen Pins, ganz zu schweigen von der unterschiedlichen Programmierspannungen und den Programmierverfahren... Also musste ich noch eine Funktion einbauen ("t<socket><type>"), die der Firmware mitteilt, um welches EPROM es sich handelt.   Noch etwas komplexer wurde der Code, als dann noch die PICs (bei denen es auch mehrere Programmier- und Löschverfahren gibt) im Adaptersockel dazu kamen. Mittlerweile ist mir durchaus verständlich, warum für Programmiergeräte solch hohe Preise verlangt werden...   Für den im Schaltplan vorgesehenen 8polige Sockel (für 24Cxx-EEPROMs und einige Kabeladapter) habe ich bisher noch keinen Bedarf gefunden, und mir daher den Aufwand gespart, diesen in der Firmware zu implementieren.

Das Steuerungsprogramm

Um das gesamte Konstrukt einigermaßen "handhabbar" zu bekommen, war natürlich noch ein PC-Programm notwendig, welches über eine serielle Schnittstelle mit der Prommer-Hardware kommuniziert, die Daten aus einen Chip holen, und in eine entsprechende Datei schreiben kann. Und natürlich auch Chips "brennen" kann. Da ich für diese Zwecke keine grafische Oberfläche benötige, ist dieses Programm auch "nur" mit einem Kommandozeilen-Interface ausgestattet, was (ganz nebenbei) auch eine Portierung auf andere (nicht-Linux) Betriebssysteme recht einfach machen sollte. Momentan unterstützt das Programm (in der Version "V0.1.5") die EPROMs 27C16, 27C32, 27C64, 27C128, 27C256, 27C512, 27C1001, 27C2001, und 27C4001 und die PICs 12F629, 12F675, 12F683, 16F628A, 16F84A, und 16F819.   Von Nachfragen im Stil "Kannste mal Chip XYZ implementieren?" bitte ich abzusehen → Ich implementiere nur die Funktionen, die ich selber benötige. Wer dieses Projekt erweitern möchte, findet alles dazu Notwendige auf dieser Seite. Falls jemand eine Erweiterung hergestellt hat, verlinke diese gerne hier.

Das "Material"

Das hier angebotene Material unterliegt der Creative Commons Lizenz "CC BY-NC-SA".

prommer_V1.1.tgz Archiv mit allen benötigten KiCad-Dateien.

fw_prommer_V07.tgz Quellcode und Hexfile für den Microcontroller.

multiprom.V0.1.5.tgz Quellcode des Steuerungsprogramms.

Hinweise für Nachbauwillige:

Wer diese Konstruktion nachbauen möchte, sollte über etwas Kenntnisse der Herstellung doppelseitiger Leiterplatten, dem Umgang mit PIC-Mikrocontrollern, und ggf. auch mit der Programmierung in PIC-Assembler und "C" haben. Es handelt sich hierbei nicht um einen Bausatz, sondern eher um eine Anregung für eigene Konstruktionen. Alles, was ich dazu anbieten kann, befindet sich auf dieser Seite, d.h. Nachfragen nach fertigen Geräten oder Bausätzen sind zwecklos → Ich "produziere" ausschliesslich für den Eigenbedarf.

Für die Funktionalität und Nachbausicherheit dieser Konstruktion kann ich keinerlei Verantwortung übernehmen. Die hier angebotenen Schaltpläne, Layouts, Quell- und Hexcodes unterliegten der Creative Commons Lizenz "CC BY-NC-SA" Eine kommerzielle Verwertung dieses Materials (oder auch von Teilen davon) ist nur mit meiner ausdrücklichen Genehmigung zulässig.

Startseite  Hardware  Rechtliches  Kontakt  Darstellung