8255 über Druckerport programmieren

Gast #417516
Lesenswert?

Habe folgendes Problem :
Ich versuche über den Druckerport (Major 99/ Linux)
einen 8255 zu beschreiben und zu lesen.
Schreiben geht, aber beim Lesen bekomme ich immer, was ich zuletzt auf
B geschrieben habe -  nicht, was z.B. auf Port C anliegt.

Woran kann das liegen ?

cs
Gast #417518
Lesenswert?

Hallo,
danke erstmal für den Tip.

Ich Nutze ( zwischenzeitlich ) ioctl mit
1. PPDATADIR (input = 1) und ioctl(fd,PPRDATA &x)
um die Daten in x einzulesen.
entsprechend
PPDATADIR (output=0) und PPWDATA, &x
zum schreiben.

Das Problem mit dem Wiedereinlesen scheint damit teilweise gelöst.

Jetzt kann ich zwar lesen, aber noch nicht das, was ich erwarte.
Es sind halb-reproduzierbare "Hausnummern" die aber mit dem
geschriebenen nichts zu tun haben.

(Erklärung :
Ich will mit dem 8255 einen 6264 oder später einen 28C64(EEPROM)
Speicherbaustein beschreiben.
Adressieren klappt (messbar). Beim Beschreiben bin ich mir noch nicht
sicher, da die gelesenen Ergebnisse nicht schlüssig sind.)

Den 8255 muß ich zwischendurch auf Port C von Ausgabe auf Eingabe
umschalten. Das Ganze geschieht über die Steuerleitungen
(Strobe, INIT, Autofeed und Select) Zwie Leitungen steuern, welche
Register, die anderen beiden sind für Schreiben oder Lesen.
Die WE, CS ect. Leitungen werden durch die für die Adressierung des
Speichers nicht benötigten Bits geschaltet.

Der Reiz der Schaltung liegt in dem Minimalistischen Aufwand der
Bauteile. Die Idee stammt von folgender Internetseite :
http://users.swing.be/gonzague.colpaert/prog.html
Allerdings ist in seinem Schaltungsentwurf ein kleiner Fehler.
Die Reset Schaltung ist so immer gesetzt ! Dann läuft gar nichts.

Ich habe das ganze sehr ähnlich - leicht veränderte Leitungsführung und
damit eine veränderte Adressierung - nachgebaut (Lochraster)
und möchte aber unter Linux entwickeln.


Gruß
cs
Gast #417522
Lesenswert?

Stimmt, die INIT Leitung ist ander herum, als beschrieben.
Das hatte ich Gott sei Dank schon bald bemerkt.

Ich glaube aber daß ich das Problem gefunden habe.

Der 8255 "latched" A, B und C, aber C nur bei der Ausgabe, nicht bei
der Eingabe.
Wenn ich dann zur Datenübernahme ( -RD wieder auf High) Port B
benutze,
dann gehen die gelesenen Daten genau in diesem Moment auf C verloren.

Folglich geht die Schaltung (so wie sie ist) nur zum Programmieren des
Speichers,
nicht aber zum Verifizieren!

Man könnte allerdings die OE - Leitung fest auf Low legen, und den Pin
für einen zusätzlichen Latch Baustein verwenden. Mit dem
Minimalistischen Aufbau ist es dann allerdings nicht mehr ganz so
toll.

cs
Gast #417523
Lesenswert?

Ja, erst wenn man sich intensiv
damit beschäftigt hat, dann sieht man
wo der  Fehler liegt.

Der ganze Entwurf (http://users.swing.be/gonzague.colpaert/prog.html
) hat meiner Ansicht nach seinen Fehler darin, das
man PORT C für den Datentransfer nimmt.

Wenn ich richtig liege, wäre man mit PORT A besser beraten.
Dieser ist nämlich in beide Richtungen "gelatched",
vergisst also nicht, was man geschrieben hat.
Das ist nötig, denn wenn -OE wieder auf high gehen soll braucht man
einen der anderen PORTs (Adresse bleibt gleich, aber Steuerleitungen
sind ja Teil der zusammengesetzten Adresse (5 Bit Aresse im Highbyte
+ 3 Bit Steuerletungen)

Beim nächsten Entwurf werde ich wohl umbauen auf Port A,
aber für's Erste reicht wohl auch nur Schreiben und mit
Prüfsumme testen, ob Ok

cs

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren