Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I know this subject has been beaten to death... but... I'm trying to be inventive here.
I have a few USB-Parallel adapter based on the Prolific 2305 chip. As far as I can tell from the documentation, it only works in some sort of a high speed printer data mode as a character device... you can't access the IO lines directly... but I would really like to play around with some output... and I think I have a scheme that will simulate a true parallel port.
I am hoping to write a small program that listens to a pipe for 1 byte of data. Each time a byte is written this program will continuously send that byte out to the usb->parallel adapter until the next byte arrives, at which point it will begin writing that new byte. repeating this process indefinitely...
I'm assuming that this printer protocol likely has control words and I am willing to filter them out with a cap or something.. My hardware requirements are very loose aI just want to turn on and off fans and lights... I can ignore up to 200ms or so of delay
after a little more reading it looks like the PL2305 chip does support a unidirectional mode... so there is no strobing between tx and rx... this leads me to believe that what i want is entirely possible.
I would also like if someone point me/us to a USB->parallel adaptor that allow I/O pins to be set manually from C code just like onboard DB25 ports. There is no reasons in the universe it can not exist.
bingo... there were all the ioctl's already done for me.. so I split this into 3 separate programs.. one to set unidirectional mode(hint.. the int for uni mode is 1), one to read back the current settings, and one for soft reset.
First I put it into unidirectional mode, t and read back the settings. I was indeed in uni mode.
Then I did a: "#echo U > /dev/usblp0". Using a logic probe I looked at each of the data pins. 00010000. Thats a "DLE"(Data Link Escape) character.. The only way to clear that is to send a reset. I tried a few other letters and even a "hello world" string... same results. One more note... If you issue the echo command more than 3 times redirected to /dev/usblp0, it will lock up... doesn't matter if you use 1 character or the entire xorg.conf... same results.
One website I found suggests that the DLE is the prefix to the data stream.... so... using a piece of jumper wire I toggled the ACK line... it reset to all zeros... still no data...
Another interesting note... if you issue more than 2 consecutive resets without sending data, the thing seems to lock up...
Finally, someone gave me an old laptop with a parallel port so I didn't need this... there is my 4 hours of contribution. I might come back to it some day but for now I have other things to do.
Last edited by flyznest; 10-14-2010 at 12:23 PM.
Reason: status changed
so... This basically says that the printer strobes the "BUSY" line to indicate when its ready for more data... so...
I hooked my little rig up... sent a reset, followed by a set... then sent an "#echo U > /dev/usblp0"... and I got my same "00010000". then I took a jumper wire and jumped BUSY to ground... nothing. hmm.
Then I read back through my notes and saw that if I momentarily jumped "ack" to ground, it would clear the LED's to all 0's... so I did so and everything was 0... then I momentarily jumped BUSY to ground... BINGO!!! I HAVE MY DATA. and it latched too!!!
then lunch ended... but I am very very close to getting this working You're gonna eat your words, business_kid
got a few more minutes to play. Connected busy and ack together and tested what happens if they are treated as one pin...
sent a reset, sent an "echo U > /dev/usblp0", jumpered to ground... MY DATA!!
so... I tried just leaving them permanently grounded... reset, "echo..."... worked the first time, worked the second time, and it hung on reset the third time... hmmmm... tried it a bunch more times and the results were very inconsistent. Sometimes it would work, and sometimes it wouldn't. I'm starting to wonder if I'm gonna have to use data line P4(remember the 00010000?) as a trigger for a transistor or something to ground those pins.
its probably worth mentioning that even if I do continue to spend time to get this working, it will only be good for really slow I/O, and data line P4 will be very noisy.
so... i have a solution that I believe will work. it involves a single NPN transistor. tie ACK and BUSY together and connect them to the collector, Base goes to p4(or D4.. whatever you may call it), emitter goes to one of the ground lines. I might also have to add an RC network to cause a small delay.. we'll see. My adapter must have some internal current limiting because I was using jumpers without any resistors with no problem.
I don't know when I will get a chance to try this... maybe tomorrow... maybe not... If there is anyone reading this besides me(doubtful) and you feel brave enough to try... tell me how it works out... but if you destroy your adapter then don't blame me.
IT WORKS!! IT WORKS!! IT WORKS!! IT WORKS!! IT WORKS!! IT WORKS!! IT WORKS!! IT WORKS!! IT WORKS!! IT WORKS!!
so... I got my hands on a 2N3904 transistor(2N2222 would be just as good). Base to D4, Emitter to ground, Collector tied to ACK and BUSY. plugged my adapter into the USB port and I couldn't reset it... so I pulled the transistor off, plugged the USB back in.. set it up, reset it, then hooked the transistor back up... sent a character to /dev/usblp0 and bingo... there it was... tried a reset... hung... so there is apparently something going on during reset that the transistor screws up... I need a delay to bypass this..
I picked out some HUGE values of R and C... I wanted enough of a delay to see it charge and trigger(for testing purposes). 100uf and 1M ohm... I put this delay on the base... and IT WORKS! IT WORKS! IT WORKS!
I only set it to uni mode one time when I first plug it in. After that, just send a reset between each character. For some reason it frequently requires 2 resets. I believe this is a byproduct of my ridiculous RC values.... So... what I need to do now is start shrinking the RC value until I can make the thing practical to use. One note.. because of the delay, the reset, and the momentary 00010000 state... I'm gonna be pushing it to get this thing useful at 1khz.
but IT WORKS!! IT WORKS!! IT WORKS!! IT WORKS!! IT WORKS!!
got a few free minutes at the end of today... had a stack of caps from .1uf to 22uf... 10uf was as far as I could drop without seeing the reset glitch. thats gonna be slower than 20hz which is ok for lights and dc motors but I wanna see if i can get it faster. Using discrete logic i could probably trigger off of a combination of things and eliminate the reset problem without the need for the delay... I'll save that for another day.
I don't have your circuit, but a data line is not guaranteed to stay below the 0.6 or so volts that starts to turn on a 2n3904. Just adding a diode in series might help. As for the delay capacitor, remember when it's charged, and you switch off, the charge remains. Best to bleed it off to V+ with a diode which only turns on when V+ is low.
The place to go with this stuff is alt.sci.repair or whatever replaced it.
The place to go with this stuff is alt.sci.repair or whatever replaced it.
Yeah... I thought about hitting the news groups but I saw quite a few people asking about these adapters in different Linux forums so figured it was worth a try...
Originally Posted by business_kid
I don't have your circuit, but a data line is not guaranteed to stay below the 0.6 or so volts that starts to turn on a 2n3904. Just adding a diode in series might help.
Now that you mention it, the LED's on my data lines do sometimes glow very dim when I first plug in the adapter, before I send the first reset... I wonder if this is actually the cause of a good bit of the problems... I can't believe I hadn't thought of that.