Hallo zusammen,
ich möchte einen Datenlogger konstruieren, der zwischen Computer (LPT)
und Parallelport-Drucker geschaltet wird. Diese Box soll zwei LPT
Anschlüsse haben (in & out) sowie eine RS232 Schnittstelle, wo die Daten
herausgegeben werden.
Betriebsarten:
AUS: Daten werden 1 zu 1 durchgeschliffen, ggf. durch Reedrelais zu
realisieren, welche im Spannungslosen zustand "LPT in" mit "LPT out"
verbinden.
EIN: Die Daten werden von µC an am "LPT in" eingelesen, und gleichzeitig
wieder am "LPT out" ausgegeben. Zusätzlich wird die Zeichenfolge an der
RS232 Schnittstelle herausgegeben.
Nun meine Fragen:
Ist soetwas realisierbar?
Welche Bausteine (µC) wäre dazu geeignet. Kenne mich ein wenig mit AVR
aus.
Für die RS232 könnte ein MAX232 eingesetzt werden.
Wer kennt sich mit der LPT Schnittstelle aus ? Welche Kontakte könnten
permanent verbunden sein (von IN zu OUT), und welche müssen duch z.B.
Reedrelais getrennt werden, wenn der Logger in betrieb ist?
Vielen Dank für eure Kommentare.
Manuel
Hallo Manuel,
eigentlich kannst du die LPT-IN und LPT-OUT direkt durchschleifen.
Wenn du Daten mitschneiden möchtest dann brauchst du nur die
Signale: D0-7 und /Strobe abfragen.
/Strobe auf einen Interrupt Eingang legen dann die Datenleitungen
abfragen zwischenspeichern und per RS-232 versenden.
Da die Daten auf der Parallelschnittstelle typischerweise viel schneller
durchrauschen können als auf einer popeligen RS232, wäre aber entweder
ein großer Puffer im µC nicht schlecht oder (mangels solchem) Strobe
oder Ack zu verzögern, um die Paralleldaten zu bremsen.
Danke für die bisherigen Antworten.
Also, so viele Daten werden nicht über Parallelschnittstelle "rauschen".
Es wird gelegentlich eine Meldung gedruckt (1-2 Zeilen reiner Text).
Diese möchte ich mit der von mir zu entwickelnden "Logger Box" abfangen,
und an der RS232 ausgeben, so dass ich den Text über die RS232 mit einem
Terminalprogramm lesen kann.
Wenn es wirklich um einen Dongle geht: da sind die Chancen gering. Die
mir bekannten (sind nicht viel) arbeiten nach dem
Challenge-Response-Verfahren: Schick mir (dem Dongle) einen zufälligen
String, ich verschlüssele den und schicke ihn zurück. Dann prüfe Du
nach, ob ich den richtig verschlüsselt habe.
Da der String zufällig ist und jedesmal wechselt, besteht wenig Chance,
dem Verschlüsselungsalgorithmus durch eine (doch sehr) endliche Zahl an
Sniffereien beizukommen. Ein Angriff aufs Programm ist
aussichtsreicher.
T.Danielzik schrieb:> Hallo Manuel,>> eigentlich kannst du die LPT-IN und LPT-OUT direkt durchschleifen.>> Wenn du Daten mitschneiden möchtest dann brauchst du nur die> Signale: D0-7 und /Strobe abfragen.>> /Strobe auf einen Interrupt Eingang legen dann die Datenleitungen> abfragen zwischenspeichern und per RS-232 versenden.
Ich befürchte, dass dazu die Interrupt-Response-Time zu lange dauert,
also dass die Daten bereits ungültig sind, ehe der AVR auf den Interrupt
reagieren kann. Da wird wohl noch ein Latch-IC nötig werden.
Nabend zusammen,
also, es geht hier nicht darum, einen Dongle
nachzubilden, auszulesen oder Algorithmen zu knacken.
Es handelt sich um einen Alarmdrucker, dessen Alarmmeldungen ich
weiterverarbeiten möchte, ohne in das bestehende System einzugreifen
zu müssen (sprich Software einspielen).
Gruß, Manuel
>Es handelt sich um einen Alarmdrucker, dessen Alarmmeldungen ich>weiterverarbeiten möchte, ohne in das bestehende System einzugreifen>zu müssen (sprich Software einspielen).
Dann lerne halt wie ein Drucker und die LPT Schnittstelle arbeiten.
UART ist viel langsamer als LPT. Du musst den PC also aufhalten
solange du Daten über UART sendest. BUSY wär vieleicht dein PIN;)
Früher gab es für Drucker parallel-> seriell-Interfaces und umgekehrt.
Mal Tante Google bemühen ... und heute auch noch, erster Treffer:
http://www.pccables.com/cgi-bin/orders6.cgi?action=Showitem&id=ID10924607&partno=30200&search=SERIAL_DEVICE&rsite=&rcode=
Nachdem bei den paar Zeilen die Geschwindigkeit wohl keine Rolle spielt,
wäre es da nicht die einfachste Möglichkeit, mit so was nach seriell zu
wandeln, dort die seriellen Daten abzugreifen und diese ganz einfach
wieder in parallel für den Drucker zu wandeln? Dann wäre man die ganzen
Timing-Probleme los; bei parallelen Daten musst Du u.U. im µs-Bereich
wegschaufeln.
Gangbar ist das natürlich nur, wenn es sich um kleine Stückzahlen
handelt.
EDIT: ich sehe gerade, das Ding im Link ist unavailable, aber Du wirst
schon was finden - war ja bloß der erste Treffer.
Was spricht dagegen, einen uC zu nehmen, der ein Datenwort mittels
Strobe-Signal übernimmt, per RS232 sendet, das Datenwort über einen 2.
Port ausgibt, dort auch ein Strobe-Signal für den Drucker erzeugt, auf
ein ACK-Signal oder Busy abwartet und auf der Eingangsseite dann auch
ein ACK- und Busy-Signal erzeugt.
Nur das Abschalten über eine Tüte Reed-Relais würde ich mir sparen.
Ein AVR könnte - wie bereits erwähnt - dafür eine zu hohe
Interruptlatenzzeit haben, so dass ein Latch benötigt wird.
Einige PICs gibt es mit sogenanntem "Parallel Slave Port".
Das ist im Prinzip ein Businterface als Slave. Das sollte besser dafür
geeignet sein.
http://ww1.microchip.com/downloads/en/AppNotes/00579b.pdf
Grüße,
Peter
Peter Diener schrieb:> Ein AVR könnte - wie bereits erwähnt - dafür eine zu hohe> Interruptlatenzzeit haben,
Dann nimmt man halt einen XMEGA mit Event-System und DMA und viel
internem SRAM zum Puffern.
Travel Rec. schrieb:> Peter Diener schrieb:>> Ein AVR könnte - wie bereits erwähnt - dafür eine zu hohe>> Interruptlatenzzeit haben,>> Dann nimmt man halt einen XMEGA mit Event-System und DMA und viel> internem SRAM zum Puffern.
Genau den würde ich wegen Lötbarkeit und eingeschränktem
Spannungsbereich (vorläufig) nicht nehmen.
Moin Leute,
ich werde wenn es die Zeit zulässt, mal ein wenig forschen, welchen
Controller und weitere Bauteile benötigt werden, und wie so eine
Schaltung aussehen kann.
Danke erstmal für eure Kommentare.
Gruß, Manuel
Kluchscheißer Kluchscheißer schrieb:> Genau den würde ich wegen Lötbarkeit und eingeschränktem> Spannungsbereich (vorläufig) nicht nehmen.
Na TQFP44 wirste ja wohl noch gelötet bekommen. Es gibt nicht nur
Ausführungen des XMEGA mit 100 oder mehr Pins.
