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

Do I have a chance in hell of this working?

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.

No harm in being inventive . . . Not a chance in hell of it working. Just try not to blow too much on the way.

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.

The only device I know about is:
http://hackaday.com/2009/09/22/intro...-bitbang-mode/
http://m8051.blogspot.com/2010/05/ft...ng-python.html

Edit: I got it mostly working... read entire thread

hahaha.. well... I blew about 4 hours... no money... and as you suggested I didn't get too far. But i'll post my findings anyway in case someone else decides to have a go at it.

I did a quick search online for the usblp source code and found this:
http://www.sharms.org/blog/category/...related-posts/

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.

I took this thing to work and was messing with it over lunch today... I decided that if this thing was using the ieee-1284 protocol, maybe I should read said protocol...

http://zone.ni.com/devzone/cda/tut/p/id/3466

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 did read it, although I wondered at myself:-).

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.

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...

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.

THX

yep.. diode fixed up a few reliability issues. the thing is actually starting to work pretty well... parts list is up to 1 transistor, 1 diode, 1 cap, and 1 resistor.

mark this solved, then