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
chaosMAKER schrieb: > 1 zu 1 durchgeschliffen Nicht gut, verursacht jede Menge Schleifstaub. chaosMAKER schrieb: > Wer kennt sich mit der LPT Schnittstelle aus ? http://www.beyondlogic.org/ chaosMAKER schrieb: > Welche Bausteine (µC) wäre dazu geeignet. Kenne mich ein wenig mit AVR > aus. > Für die RS232 könnte ein MAX232 eingesetzt werden. Kannst Du beide dafür nehmen.
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.
Dazu brauchst Du kein Signal zu unterbrechen. Eine reine Sniffer-Funktion tut's. Es reicht, wenn Du passiv mitliest, pufferst und seriell ausgibst.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.