🚀 go-pugleaf

In article <37c252ac@news.zeitung-online.net>,
  "Udo Waigand" <uwaigand@fbam.de> wrote:

> Ich w�rde mir gern mal den CT-Eprop zusammenbauen .. und testen wie
der so
> ist ..

Ohne der C't und ihren Autoren zu nahe treten zu wollen,
m�chte ich davor warnen, blind auf Ver�ffentlichungen vertrauend so ein
Projekt zu Programmierger�ten nachbauen zu wollen.

Das kann schnell zu erheblicher Geld- und Zeitverschwendung und zu einem
�rgerlichen teuren Bauteilegrab werden.

Ich selbst war vor Jahren so naiv, den C't Galprog (in alter damals
jedoch aktuellster Variante) zur Programmierung von GALs nachbauen zu
wollen. Ich ging davon aus, da� sich die Autoren des Projektes
hinreichende Informationen der Hersteller zur GAL-Programmierung
beschafft h�tten, so da� das Ger�t funktionsf�hig sei und ich mir eine
Eigenentwicklung nebst Beschaffung der Unterlagen sparen k�nnte. Dieses
Vertrauen wurde jedoch sehr bitter entt�uscht :-( .

Erste Versuche mit GALs 16V8/20V8 endeten mit einem Desaster. Obwohl ich
exakt den Programmierer nachgebaut und gepr�ft hatte und die
Programmierspannung exakt justiert hatte und das Ger�t die in dem
Artikel erzeugten Impulse am GAL-Sockel anlegte, waren die GALs entweder
sofort falsch programmiert und funktionsunf�hig (20V8) oder verloren
den Inhalt in weniger als 3 Tagen so sehr, da� die Bausteine ausfielen
(16V8). Sie lie�en sich mit dem Programmierer auch nicht mehr richtig
l�schen.

Ziemlich ver�rgert beschaffte ich mir dann die Programmierunterlagen von
eines Herstellers, welche auch die Programmierung einiger Chips anderer
Hersteller auff�hrten. Die Unterlagen erhielt ich problemlos nach einer
Anfrage mit Bezug auf das Datenblatt, worin die Zusendung auf Anfrage
versprochen wurde.

Ein Vergleich der Algorithmen mit denen der C't deckte dann die
�rgerlichen Ursachen der Probleme auf:

Die C't hatte nicht nur mit einer Einheits-Programmierspannung und
Programmierimpulsl�nge gearbeitet obwohl bereits zur damaligen Zeit
eine ganze Reihe von Algorithmen existierten, welche ziemlich
unterschiedliche Spannungen und Impulsl�ngen benutzten.
Den korrekten Algorithmus mu� man aus dem GAL vor der Programmierung
auslesen. So waren die Bausteine stets v�llig ausserhalb der
Spezifikationen "programmiert", was obige Effekte erk�rt.

Besonders schockierend jedoch fand ich die L�nge des von der C't
gew�hlten L�schimpulses. Diese entsprach -soweit ich mich erinnern kann-
nur bei einem einzigen, vom C't Programmierer gar nicht unterst�tzten,
GAL-Typ der von der C't benutzten Zeit.
Alle anderen GALs waren in Wirklichkeit mit einer f�r alle Algorithmen
einheitlichen, einer ganzen Gr��enordnung (!!!) l�ngeren
L�schimpulsl�nge zu l�schen.

Dann war es nat�rlich auch kein Wunder, da� das L�schen nie
funktionierte.

Fazit: Man h�tte den Programmierer durch das Schreiben eigener Software
und Verstellen der Programmierspannung an der Karte im Rechner mit
jeweils einigem Gefummel unter Verwendung der obigen Informationen
benutzen k�nnen. Wenn man die Kosten f�r Platinen, PAL, Software und
Bauteile jedoch in Relation zur Verwendung des
damals zum etwa gleichen Preis erh�ltlichen ST-Programmierers sieht und
noch die Arbeit und leichte Nutzbarkeit rechnet, w�re der kommerzielle
Billigprogrammierer viel g�nstiger gewesen.

Ich kann auch nicht ganz verstehen, wie eine Zeitschrift so etwas
als Bausatz ver�ffentlichen kann. Wenn man die richtigen Informationen
nicht herausgeben darf, da sie als Firmeneigentum des Herstellers
gekennzeichnet sind und so etwas untersagt wurde, kann man doch nicht
einfach falsche Werte verbreiten und sogar als Bausatz verkaufen.
Ich habe jedoch den Verdacht, dass man sich gar nicht die erforderlichen
genauen Informationen beschafft hatte. Denn als Literatur waren
zwei allgemeine Informatiklehrb�cher und ein altes ST-Datenbuch
angegeben- von Herstellerinformationen war da keine Rede.

Die billigste L�sung w�re die Verwendung eines ISP-GALs gewesen.
Dazu braucht man nur einen PC mit paralleler Schnittstelle nebst einem
5-poligen Kabel und kostenloser Software von Lattice. Das klappt
wunderbar.

Falls ein billiges gutes und zuverl�ssiges EPROM/EEPROM-Programmierger�t
mit M�glichkeit zur Programmierung einzelner GALs gesucht wird,
kann ich z.B. die Programmierer von Needham's Electronics
(http://www.needhams.com, klappt momentan leider ausgerechnet nicht
richtig,
 http://www.electro.com.au/pg_prog.htm,
 http://www.geocities.com/ResearchTriangle/1495/ee_pr_ne.html)
sehr empfehlen.
Sie werden von mindestens 5-6 EPROM/EEPROM-Herstellern wie z.B. TI,
Xilinx, Hitachi, ST, Atmel, Philips usw. empfohlen. Das war mir nach
obigem Reinfall sehr wichtig.

F�r viele Ger�te auf dem Markt liegt eine solche Empfehlung
n�mlich nicht vor. Empfohlene Ger�te sind oft dementsprechend relativ
teuer.
Das billigste Ger�t PB10 kostet ca. $99-140 und ist eine PC-Steckkarte
mit Sockel an einem Flachbandkabel.

Ich entschied mich f�r den $225/ca. DM 399 EMP10,
der f�r Deutschland mit 230V Netzteil vertrieben wird, um eine
typgerechte Programmierung wie beim gr��eren EMP20 sicherzustellen. Das
mitgelieferte separate Netzteil gab jedoch schnell den Geist auf, so da�
 ich anstelle des Austauchger�tes ein eigenes 12V ~ Netzteil verwende.
Der Programmierer kann alle f�r mich wichtigen Bausteine
(EPROMs/EEPROMs/GAL22V10) programmieren.
Manchmal ist es erforderlich, f�r eine Reihe von Bausteinen ein Family-
Modul auszutauschen.
Der noch teurere EMP20 (bzw. EMP30) kann eine gr��ere Vielfalt von
Bausteinen programmieren, kostet jedoch um $500/DM 900. Z.B. unterst�tzt
er die GALs 16V8 und 20V8, 6001 usw. (vgl.
http://needhams.com/e20ddevs.htm, klappt z.Z. trotz obiger Probleme).
Updates der Software konnte ich von der sonst laufenden WWW-Seite
downloaden. Sie hat bisher eine SAA-Oberfl�che.
Needham's hatte bisher zwei deutsche Generalvertreter.

Ich hoffe, diese Informationen sind hilfreich.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.