Gal durch Tiny26 ersetzen?

[R. F. (rfr)]

Hallo allerseits,

ich habe eine Schaltung, in der ein GAL verwendet wird. Ein tiny26 hat 
für diesen Anwendungsfall ausreichen IO, ich würde daher gerne wissen, 
ob ich den GAL durch einen nentsprechend programmierten µc ersetzen kann 
und was dabei zu beachten ist.

Grüsse

Robert

[2N3055 (Gast)]

Müssen wir wieder die Glaskugel bedienen?
Zeig die Schaltung und dann kann man sagen ob das geht, so aber nicht.

[TestX .. (xaos)]

Wenn die Schaltung relativ langsame Dinge macht und der Attiny 
pinkompatibel ist sollte es eigtl funktionieren. Betiebsspannung von 
3-5V vorrausgesetzt.

Zeig uns doch einfach mal den Schaltplan.......

[R. F. (rfr)]

Ich habe keinen Schaltplan, die Anwendung ist die Adressdecodierung in 
einem Z80 mit 4 MHz.

[Jonas B. (jibi)]

Bei 32Mhz hast du genau 8 takte für die Decodierung...
Ich könnte mir vorstellen das der GAL da durchaus eine 
Daseinsberechtigung hat.

Gruß Jonas

[MaWin (Gast)]

R. Freitag schrieb:
> Ich habe keinen Schaltplan, die Anwendung ist die Adressdecodierung in
> einem Z80 mit 4 MHz.

Vergiss es, Logic im uC ist dafür viel zu langsam.

GALs kann man noch kaufen, und noch programmieren.

http://www.armory.com/~rstevew/Public/Pgmrs/GAL/_ClikMe1st.htm

[Peter D. (peda)]

Schau einfach mal ins Datenblatt des Z80, welche Timings einzuhalten 
sind und dann in die Datenblätter der RAMs/ROMs, welche Durchlaufzeiten 
davon abzuziehen sind.

Dann dürfen nur noch wenige ns übrig sein für den Dekoder, d.h. mit ner 
>1GHz CPU könnte es machbar sein.

GALs im DIP stellt nur noch Atmel her (ATF22V10, ATF16V8).

[R. F. (rfr)]

na gut, Bestellung bei Reichelt wird veranlasst. Zur Not könnte man das 
aber auch auf TTL-Basis machen?

[Jonas B. (jibi)]

>Zur Not könnte man das aber auch auf TTL-Basis machen?

Machbarkeitsanalyse sagt dir was?

Gruß Jonas

[Falk B. (falk)]

@ R. Freitag (rfr)

>na gut, Bestellung bei Reichelt wird veranlasst. Zur Not könnte man das
>aber auch auf TTL-Basis machen?

Ja, aber warum glaubst du, haben die Jungs sich damals für einen GAL 
entschieden? Womöglich, weil man mit EINEM GAL ein Dutzend TTL-ICs 
ersetzen kann?

[karadur (Gast)]

Hallo

bevor du ein Gal bestellst schau erst mal ob du den programmieren 
kannst.

[2N3055 (Gast)]

Ahhhhhaaaa,

Du hast keinen Schaltplan, willst aber ein GAL durch nen Attiny 
ersetzen?

Neben der Tatsache das der zu langsam sein wird, glaube ich das Du auch 
so keinen Plan hast.
Lass es sein.

[Ein Elektroniker (Gast)]

R. Freitag schrieb:

> Zur Not könnte man das
> aber auch auf TTL-Basis machen?

Vermutlich hat man genau ein GAL deswegen eingesetzt, um ein größeres 
TTL-Grab zu vermeiden.

Wenn z.B. ein 8085 bei mir im Hobby sehr langsam läuft, eine 
Retro-Bastelei mit 10 oder 100kHz, dann würde ich mich trauen, z.B. als 
Adreßdekodierer einen schnelleren µC zu nehmen, der I/O in wenigen µs 
schalten kann. Aber es wird nicht leicht, es läuft ja da auch noch ein 
Code auf dem Dekoder-µC, mit Laufzeiten, I/O werden nicht sofort 
bedient.

[Christian K. (christian_rx7)]

Würde eher zu einem CPLD greifen, da die einfach zu programmieren sind 
und den Flash gleich integriert haben.

[c-hater (Gast)]

R. Freitag schrieb:

> ich habe eine Schaltung, in der ein GAL verwendet wird. Ein tiny26 hat
> für diesen Anwendungsfall ausreichen IO, ich würde daher gerne wissen,
> ob ich den GAL durch einen nentsprechend programmierten µc ersetzen kann
> und was dabei zu beachten ist.

Die böse Zeit. Der Tiny ist ziemlich wahrscheinlich zu langsam.

Nur mit einem zum Systemtakt synchronen, auf 24MHz versechsfachten Takt 
besteht eine realistische Chance. Und die auch nur unter folgenden 
Randbedingungen:

1) Es sind nur maximal 7 Eingänge zu verarbeiten
2) Es sind nur maximal 8 Ausgänge anzusteuern
3) Die komplette GAL-Funktion ist reine boolsche Logik
4) Ein Delay zwischen Ein- und Ausgang von von mehr als einer halben
   Periode des 4MHz-Systemtaktes ist akzeptabel.

Die Hauptschleife sieht dann so aus:

loop:
 in XL,INPORT    ;1
 ld XL,X         ;2
 out OUTPORT,XL  ;1
 rjmp loop       ;2
                 ;-
                 ;6

Vor dem Eintritt in die Hauptschleife wäre im RAM die Logiktabelle zu 
initialisieren und der Eintritt in die Hauptschleife anhand der 
Eingangssignale taktgenau zu synchronisieren.

Aber ich vermute mal, daß die Sache sowieso schon an den vier 
Randbedingungen scheitern wird...