Probleme mit GAL16V8

[Daniel (Gast)]

Hallo zusammen,

ich arbeite gerade an meiner Studienarbeit mit einem GAL16V8A von 
Lattice. Ich möchte diesen Baustein mit einer einfachen Logik 
programmieren. So sieht mein Programm aus:

Name     Test4 ;
PartNo   00 ;
Date     24.08.2010 ;
Revision 01 ;
Designer ******** ;
Company  ********** ;
Assembly None ;
Location  ;
Device   G16V8 ;

/* *************** INPUT PINS *********************/
PIN 2   = A                        ; /*                                 */ 
PIN 3  = B        ;  

/* *************** OUTPUT PINS *********************/
PIN 19    = X               ; /*                                 */ 
PIN 18     = Y      ;
/* *************** LOGIC EQUATION *********************/

X = A;
Y = B;

Als IDE benutze ich WinCUPL von Atmel. Beim compilieren erhalte ich 
keine Fehlermeldung. Jedoch ist WinCUPL ein Produkt von ATMEL und somit 
der Compiler nur auf deren GALs abgestimmt. Ich habe gelesen, dass aber 
auch der ATF16V8B (Wird als Device bei WinCUPL angezeigt) dem GAL16V8 
von Lattice ähnelt und man diesen compiler ebenso verwenden kann...

Jedenfalls der Simulator WinSIM zeigt mir die richtigen Ergebnisse, also 
richtiges Ausgangverhalten.

Als Programmiergerät nutze ich TOP2004 (irgendein ein Import aus Asien). 
Auf den GAL habe ich dann dieses JEDEC File geladen. Bis hier hin 
scheint alles soweit so gut.

An den Ausgängen des GAL hab ich 2 LEDs dran gehängt (natürlich jeweils 
mit einem Vorwiderstand). Als ich den GAL mit Spannung versorgt habe, 
also VCC mit 5V, leuchten sofort die LEDs auf... Das sollte eigentlich 
nicht sein.

An meine Eingängen habe ich nichts anliegen, also garnicht beschaltet. 
normalerweise sollte die LEDs auflechten, sobald an den Eingänge ein 
High-Pegel anliegt...

Wo liegt hier mein Fehler?

[Sebastian (Gast)]

Das sind TTL-Eingänge. Offen wird als High erkannt. Pull-Down-Widerstand 
sollte Ruhepegel Null gewährleisten, falls erwünscht.

[Daniel (Gast)]

Hab nun beide Eingänge jeweils mit einem 110k Ohm Widerstand auf Masse 
gelegt... die beiden Ausgänge bleiben trotzdem auf High... daran liegt 
es wohl leider nicht

[Hc Z. (mizch)]

Für TTL sind 110k gegen Masse etwa gleichviel wie unendlich gegen Masse.

[faustian (Gast)]

"110k"

In der Digitaltechnik ist sowas ein schlechter Isolator.

Pullups kann man fast immer als 2.2K oder 4.7K machen, dasselbe gilt bei 
CMOS fuer Pulldowns (bei TTL besser Pegelbereiche und 
Ein/Ausgangsstroeme aus dem Datenblatt nehmen und rechnen!).

[Daniel (Gast)]

Danke! Und wieviel Ohm wäre demnach angemessen?

[Daniel (Gast)]

Na das probier ich doch gleich mal aus

[Hc Z. (mizch)]

Welche mentale Sperre hindert Dich, 0 V an einen Eingang anzulegen? 
Wozu der Widerstand?  Du möchtest 0 V haben und doch nicht wirklich?

[Daniel (Gast)]

Wenn ich aber an den Eingang < 0,8V anlege, dann müsste der doch auch 
als Low-Pegel erkannt werden?

[Daniel (Gast)]

Das funktioniert leider immer noch nicht. Wenn ich ne Spannung kleiner 
0.8V an den Eingängen setze, tut sich nichts und ebenso so auch nicht 
mit den Pull-Down Widerständen...

[Sebastian (Gast)]

Offensichtlich ist der dann wohl doch nicht korrekt programmiert worden, 
sorry für die falsche Spur. Das korrekte Beschreiben von GALs ist nicht 
immer leicht. Mit einem "Superpro Z" habe ich letztens auch keine 16V8 
von Lattice beschrieben bekommen, obwohl er das eigentlich können soll. 
Mit einem steinalten anderen Gerät (>20 Jahre) ging es dann.

[Sebastian (Gast)]

Ach ja, noch ein Test... Was ist denn, wenn im Programm steht "Y=0". Ist 
die LED dann aus, oder erlaubt der Compiler keine Konstanten?

[Daniel (Gast)]

Also Y=0 geht nicht... das mag der Compiler nicht. Aber wenn ich Pin 18 
= !Y setze, also negative Logik... dann ist der Ausgang auch wirklich 
auf Low... Sehr interessant... Also die Ausgänge scheinen zu 
funktionieren. Nur die Eingänge machen was sie wollen.

[Daniel (Gast)]

Also am Compiler kann es auch nicht liegen... der unterstützt auch die 
GAL16V8A von Lattice. Zumindest laut einigen Erfahrungsberichten.

Einen anderen GAL hab ich auch schon getestet. Der hat aber das gleiche 
Verhalten.

Also kann das ja nur an der Beschaltung sein...

[Martin (Gast)]

... Device   G16V8 ; ...

Guck mal, ob du den richtigen Baustein "g16V8a" hast.

[jjk123 (Gast)]

Ich kann nur empfehlen von GALs die Finger zu lassen. Speziell von
Lattice. Das Problem ist das folgende: Man hat etwas was funktioniert
also eine Software einen Programmer und Gals z.B GAL16V8A. Dann kommt 
die Firma Lattice macht einen "Dieshrink", der GAL heisst jetzt 16V8B. 
Die Jedec Datei geht dann einfach nicht mehr, eine Converter gibt es 
nicht. Der Programmer kann das Teil nicht mehr programmieren. Jetzt 
investiert man neu. ALso Software und Programmer. Die Firma Lattice 
macht wieder einen "Dieshrink". Man hat wieder ein Problem. Um dem 
ganzen noch die Krone aufzusetzten sind dann die Projektfiles der 
Software irgendwann nicht mehr kompatibel. Ich glaube mittlerweile ist 
man bei 16V8D oder vielleicht auch "Z" .Ich habe das über viele Jahre 
mit GALs und den  ISPLSI-Bausteinen von diesem Saftladen mitgemacht. Man 
wird einfach Wahnsinnig.

[MaWin (Gast)]

Seit 10 Jahren tut sich bei GALs nichts mehr.

Diese Probleme sind also aus der Welt.

Dafür kaufen die Leute heute Microcontroller,
die es schon nach 2 Jahren nicht mehr gibt....

[Daniel (Gast)]

Da ist was dran... ein GAL Baustein ist fast so teuer wie ein µC und 
außerdem ist das Technik von Vorgestern. Bin gerade am überlegen ob ich 
net doch meinen ATmega16 einsetzen soll.

Trotzdem find ich es schade...hätte gerne gewusst, woran es lag.

Vermutlich liegt es am Programmiergerät. Ich werd die Tage mal einen 
anderes Programmiergerät testen.