We're using a parallel port for motion control. We're building the hardware logic for the device we're going to control, and want to be able to send a packet containing 2 bytes of information, and let the circuit we build translate it and drive our device. I know that parallel port was designed with a standard for printers, using a 1 byte data regisiter. What I want to know is how to hack it so that I can use more than pins 2-9 to output data from our computer. The control register has pins 1, 14, 16, 17. I take it that i can set whatever I want to these (TTL), and on the device end, translate it however I choose. So i need 4 more pins from something. I know that pins 18-25 are ground. I think that makes them out of the question, though if anyone knows how I could use some of them to transmit data I'd be interested. The info i have on status register says its read only, and that data written there is ignored. What ignores it, the computer or the printer? Is there a way to get around it?
What's wrong with latching two bytes, sequentially? I assume you can write software to handle that. Or using a serial to parallel chain and driving that synchronous-serial using the parallel port? There are actually some 4-bit wide chips often used (in olden days, anyway) when there was only an 8-bit wide path to parse. But with the PC parallel port you are in high cotton. You can use the 8255, if you want. You can hook up to /RD /WR A0 A1 and with a tiny bit of logic you can use /RD and /WR in combo to generate the /CS and RESET, as well. That gives you 24 bits to play with, I think.
It is a hardware issue, as there is no internal way to change the voltage on the pins. You usually can control the control pins like the data pins. I've got some simple parallel port stuff on the below pages that might be of interest.
Jon has given most of the easy ones. I've used his second solution many times, with two 74HCT595 serial-to-parallel shift registers. By using serial-in-parallel-out (SIPO) shift tegisters, you only need 5 parallel port pins for any number of outputs. It should only take several of microseconds to shift out the data for 16 bits in assembler, and even in a high-level language, it should be far faster than your time requirements for real time motion control.
formatting link
It's a 16-pin IC, available for less than a buck each in single quantities, and the wiring and control logic is pretty much self-evident if you read the data sheet.
You get 8 more outputs with every '595 chip you daisy chain, without adding any more parallel port pins. You can realistically have just about as many outputs as you want with those 5 pins, limited only by the time you have to shift out the data. Remember you'll need an external 5V power source for the '595s, or you can use power from the PC (drive power cable extender).
One issue is that you need to indicate, to the receiving hardware, where the first part of the word is. If you truly have only eight bits at-a-time, you can dedicate one of the bits as the start-of-frame indicator, and use the other seven as the data path. If you use this technique, then it's probably simplest to send four data bits per transfer, and do four transfers to get each sixteen bit word.
If it turns out that you can find an extra bit, then it can be become your start-of-frame indicator.
A CPLD would be an ideal candidate for the receiving hardware (and they're cheap). You just need to learn and little HDL (either VHDL or Verilog).
Remember, all sorts of data paths use only one bit at-a-time to send all kinds of data types (widths), so having eight bits is a real luxury.
schreef in bericht news: snipped-for-privacy@g43g2000cwa.googlegroups.com...
James,
You'd better first learn more about programming the paralllel printer port. For instance:
formatting link
It should be clear that even the last ECP is not able to transfer 16 bits at a time. But there's no need to. If you check out the EPP specification you'll find that you can send two bytes sequentially, one data and one address, and latch each of them into its own LS163, LS364 or similar.
Others have answered the hardware aspect of your question. However, note that if you plan to use this on PCs running Windows versions later than 9x, you will have to use a special ring 0 device driver to have access to the printer port. (GIVEIO and USERPORT are two that I have heard of, put haven't tried myself.) That might be one advantage for using the serial port, which can be accessed through more-or-less standard Windows API functions.
Another thing to think about is that parallel printer ports are rumored to be slated for extinction... but then again, aren't we all!
Best regards,
Bob Masta dqatechATdaqartaDOTcom D A Q A R T A Data AcQuisition And Real-Time Analysis
You know? What bugs me about this very true point is that we are losing all of the really good hobbyist interfaces for adapting a PC. The ISA bus was really nice and not too complex for a serious hobbyist to use, in adding boards. Gone now, or nearly so. Ever consider trying to do a PCI card as a hobbyist? Reflection wave bus, 2ns clock skew on 33MHz and 1ns clock skew on 66MHz with a 1.5" +/- 0.1" trace length for the clock (often serpentined in order to get there), etc. Just getting equipment to monitor the analog characteristics for debugging a design is a fortune. Lose the parallel, lose the serial, add USB 2.0, replace the old IDE controller cables with SATA 2, and what are you left with to use, anymore? It's getting to be a pain in the ...
Well, of course, there are microcontroller boards. But then you lose out on the excellent and easy availability of very excellent and well documented development tools.
Contrivers of contrivances are going to have a more difficult time when the ol' parallel port is no more, Jon. Of course, we can squirrel away more older PCs (that is, until the War Department issues the Ultimatum again). I would guess, though, you'll be seeing more standardized USB experimenter-type interfaces to replace the parallel port for classroom and hobbyist work. You'll also see more use of PCI DIO type boards for the parallel I/O. You will be seeing a lot less hobbyist bus interface.
But it should still beat those "thrilling days of yesteryear" (early '80s), when PCs cost thousands, you had to wait in line for one, and you took your career in your hands every time you turned on the power for a new prototype, consigning it as well as everything else in the box and possibly your job to the tender(?) mercies of a harsh 85 watt switching power supply.
I learned about the advantages of the trailing edge back then, picking up cheapie Kaypro IIs for their serial and parallel ports as IBM and Micro Soft (two words back then) cleaned Kaypro's and CP/M's clocks. Everyone who wanted to replace VisiCalc with Lotus had their first obsolete computer (aaaaww!), and after having it sit around unused for a few months, was willing to practically give it away (for a couple hundred dollars).
Those were the days. Womenfolk swooned as real engineers and techs walked by, TI-57s bobbling suggestively from their belt loops. ;-)
You should see my collection. I still multi-IO boards, floppy interface boards, etc.
That adds complexity that can be difficult to diagnose. But worse, how do you arrange for precise timing control of I/O pins?? And under Windows?!?!?! It's just not the same thing, you know.
Only a few years back, I developed software for aligning and calibrating a medical infusion pump motor/cam system. I had to spin the motor and monitor it in real time, because this is how the alignment worked -- at operational speed, I had to see how the cam alignment looked with respect to the optical quadrature encoder. It was different, stopped or very slow, because of the cam follower's lag as it ran. The quadrature encoder gave me 10,000 pulses per rev. And I ran the motor at 50, 150, and 300 RPM. At 300, that's 5 revs per second. And I was getting 50,000 pulses each second on A and B side channels.
It was absolutely no problem on a modern CPU with an I/O card plugged into the ISA. I sat in a tight loop and pulled out I/Os at 750ns each. I coded the quadrature decoder in assembly.
Now?? What, with some USB thing?? How will I code that, in assembly, under DOS?? And if I use Windows, what chance do I have?
No, this is a serious loss.
Well, there is that. But you cannot build them yourself and PCI isn't all that easy under DOS-only. I often need to completely remove Windows when doing embedded PC instrumentation, as timing is crucial to control and a lot of stuff I do is _fast_ and I require very tight control over latencies. Under Windows, this is ... very difficult, and will require VxD work to get there, if at all.
I've developed PCI testing software for Intel, while running a multi-CPU O/S of my own development. We'd load up Xilinx-FPGA cards with code so that we could literally fill up the PCI bus with dense traffic and try and break the chipset with it.
I'm really not looking forward to using PCI for instrumentation. In the case I earlier mentioned, about the testers, the customer is a very large medical instrumentation builder but their need for testers is perhaps a dozen or two systems. In some cases, I've actually done systems where there were only two. They may, themselves, test a large number of devices very quickly, but they are in effect one-off systems
-- custom for the need and don't represent large volume to anyone, part-wise. Buying the boards won't mean much to the vendor, so support won't be all that great. For PCI, they may not even bother with a DOS-based PCI driver. And setting up the PCI board under DOS may require my configuring all of the PCI boards, if I don't like the BIOS defaults -- which the board maker may not even care about because Windows is PNP-aware and they don't have to mess with it much.
That's assuming, of course, that I can find what I need in PCI. In ISA, at least, I can do a board design and wire wrap it up on my own and test it out. Then do a final board(s) for the customer that meets the needs. PCI?? No way. I just don't have the equipment or the knowledge, except that I know enough to watch out.
What I'd like to do is be able to capitalize on modern low-cost systems and still have access to low-development-cost interfacing for small-run or one-off tester systems for customers or personal use. There is no sense in taking on an expensive PCI design project for what would otherwise merely be a simple, customized I/O board for external instrument control. Think of chicken hatcheries, IC testers, LED binning, etc. etc. Highly integrated, labor-intensive, one-off systems with a lot of knowledge buried in them about the specific requirements. ISA still makes sense for these, as even a custom logic board is a no-brainer to do and test out. PCI raises the bar so high that many of these projects would find their labor growing very substantially for no good reason except the fact that ISA has disappeared.
My first Kaypro was a 286i that I bought for about $3k, new. It was the first PC-compatible on the market that was really PC-compatible based on careful testing. The other systems would fail to even run PC applications at least 10% of the time. More, often. But this one would run everything I tried, out of the box. And was the only system at the time, other than an IBM of course, that could.
I remember when visicalc first came out -- not on the PC, but I believe on the Apple II, as the PC didn't exist then (early 1980, I think, when I first saw it.) I laughed at it, because I thought "who'd buy this?" It seemed way too technical to reach any popular market and I figured programmers could just program the equations.
You seem to be in good company Jon. Whoever said the world would need only a couple of computers? Who said a PC would never require more then 640k memory? Guess your bank account did not line up with the ones of that guys :)
Still have some empty ISA boards laying around. Good chance they'll never be used as such. Lack of ISA-slots in present-day machines. But don't be too sad. The new interfaces give new opportunities as well. USB-interface chips are almost as cheap as the TTL-buffers were in the old days. You'll sure have to do little more work in those micros and maybe in the hardware but I consider it a part of the fun. Besides it will be less easy to copy your application. As for PCI I was told you can buy chips or even boards with the PCI-part already implemented. Did not check out as I did not need it myself. Still enough challenges in this crazy world. The times they were a changing in that old days. They still are.
PC-104 is just a reconfigured ISA bus and the cards stack rather than plug into a motherboard. The last ones I worked with had a Cyrix 586 CPU, and were running embedded NT in the Microdyne/L3-com RCB2000 telemetry receiving system. I still have some of the data on the board around here, somewhere.
--
Service to my country? Been there, Done that, and I\'ve got my DD214 to
prove it.
Member of DAV #85.
Michael A. Terrell
Central Florida
Yes. But I think the PC-104 is dying. As I understand it, from talking with a few key manufacturers in that business, the ability to secure PC-compatible CPUs _with_ the ability to provide PC-104 signaling isn't likely to survive many more years. They are meeting (or were) to try and see if they could collectively (some of the bigger ones, anyway) pony up for their own ASIC design to handle the PC-104 bus, before the remaining suppliers stop making their parts. But I fear this whole attempt will fail and they will be forced to use PC-104+ only (PCI.)
I'm not privy to the whole picture, but here is about how I see it.
There were some CPU manufacturers who provided x86 CPUs with ISA interfaces. But there are several pressures away from what remains of these, if anything does. For one, customers are usually looking for faster and faster CPUs, even in the PC-104 business. And faster CPUs probably use the front side bus arrangement for the CPU, followed by a chip that mediates between that and the PCI, followed by another chip that mediates between the PCI and the ISA and has all kinds of sideband channels back to the chip that handles the front side to PCI, since ISA DMA transactions cannot be properly remapped as PCI transactions and require "special support." No one wants to keep making the PCI to ISA bridge for that mess -- except maybe the PC-104 folks. But they don't have the business level to keep those current makers making those chips. And I don't think they have the steam themselves to get into that business.
"Jonathan Kirwan" wrote in message news: snipped-for-privacy@4ax.com... [...]
[...]
Having also designed machine controllers based on PC's complete with the "older" interfaces, I agree wholeheartedly on how a cheap PC, is (was) capable of massively slashing project times and costs when used within an industrial environment. One 486/DOS/ISA/Powerbasic test/measuring system I designed 7 years ago has been running 24/7/350. Impossible to conceive doing the same using TDM windows c/w and bloatware. Looked at PC104s but found them (very) expensive and limiting and agree that they will die out in time. From a customers POV, a big no-no is the PC104 has a "Look at me, I'm special equipment" aspect. If the kit fails then another unit can't just be picked up locally for next to nothing. I've had enough of busses. I'm out of here. ISA/EISA/MCA/PCI/Express/AGP/USB/Claphamcommon, It's just not worth the time and mental effort. Decided I'll only (can only!) interface with the truly crap RS232, which I suspect will be around long after the pityfully apalling USB, has been junked in favour of the apalling Firewire. Just finishing off on an industrial project which uses a number of these,
formatting link
Final deciding factor for it's use was direct byte control of the RS232/RS485 ports (crazy world). Who now cares about industrial technology?. In UK, focus is on 'supply of services'. All they want from a PC is email and pretty pictures, yet for a pittance they are handed a supercomputer. john
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.