Well, that could be used for some testing. But, this is a widely used CNC control program, and the code for this EPP port operation has been working for years. We don't want to have to have special code for one quirky PCIe card.
And, the EPP mode (when used by correct parport cards) is WAY faster than what you can do in SPP mode. The latest ports complete a handshaked transaction in about 350 ns.
Jon
I'm not suggesting you switch mode, I was wondering if the card might be in the wrong mode. Looking at the datasheet it supports multiple modes and someone has to tell it what to do
-Lasse
Parallel ports on the PCI bus work essentially the same way, through deferred procedure calls. No such thing as "real time" on a PC anymore, if there ever was. Your best bet is to plan accordingly.
-- john, KE5FX
Well, I don't THINK so. EPP mode works on write operations to the addr and data ports. Many signals on the port are reconfigured, such as DATASTB/ ADDRSTB/, WAIT/ which don't exist in that function in SPP mode. When you write to the EPP data port, it asserts WRITE/, applies the data bits and then pulses DATASTB/, and waits for acknowlege on WAIT/. This is all done automatically by the port chip. It holds the CPU in wait until the operation is completed.
So, I DO see the EPP mode cycles working when writing, but not when reading. I don't know how that can be done from software. We do have several port configuration programs that set the port to various modes and verify the registers are properly set.
Jon
what valUES DO thE CoNfIgUrAtIoN rEgisTERs /*HAVE*/ ? does it have cnfgA cnfgB regs? Or even some additional thingmajig in PCI conf SPACE to select opmode.
NIST has been been doing this since 1996 or so, I started using the EMC program in 1998. We got about 10 us jitter on a 100 MHz pentium classic, which was sure good enough for regular motion control.
I'm now using LinuxCNC (the successor of the old EMC and EMC2 program) and on a good motherboard you can get jitter down to about 4 us. I've sold about 300 motion control interfaces that use the EPP parallel port, it has worked fine for years. When using the RTAI real time package, as far as I know, an INB or OUTB instruction is just what it says, read or write a byte from an I/O port.
Jon
Yes, those regs exist, but they are mostly for serial port config. The parport config is the next register up, ECR (extended control register). Setting the highest 2 bits to 10 is the setting for EPP mode.
Everybody should remember that this code has been working for 15 years on dozens of implementations of parallel ports, from ISA to PCI, and motherboard, with few problems. So, this one particular chip (OXPCIe952) seems to have a flaw. Another PCIe chip, the MosChip 9900 works perfectly.
Jon
looking at the datasheets;
the OXPCI is EPP 1.7 the MosChip 1.9(IEEE1284)
look at page 275
-Lasse
Yes, I noticed that, too. Kind of strange, as EPP 1.7 is a VERY old standard, like 1994. EPP 1.9 came out in , I think 1999. So, I can't understand why the PCIe chip only complies with EPP 1.7 But, anyway, our device will handle the EPP 1.7 timing, if the board will only generate the appropriate strobe signals when requested.
Jon
I've always wondered how much buffering goes on with those.
Obviously(?), you can't get a parallel port going into the nanoseconds (Fclk = 8MHz, at least in the original case). PCI (33MHz+) PPs exist, so are they inserting wait states, or what?
Are IO instructions cached/buffered, or do they WAIT the CPU until the transaction is complete? I never looked deep enough to get a clear answer.
I know all the memory space of a Pentium is pulled through caches -- that was one of its big features after all, internal L1 cache plus expandable external L2 cache (if you had the money to afford it). And it's very typical to have PCI cards with large memory apertures, usually directly into e.g. video or texture RAM, or IO buffers.
Tim
-- Seven Transistor Labs, LLC Electrical Engineering Consultation and Contract Design Website: http://seventransistorlabs.com
Depends but generally pipelined. I/O instruction ordering can be forced but I wouldn't expect it in the general case. PowerPC has an EIEIO instruction (Enforce In-order Execution of I/O) to accomplish this, for example.
Main memory is, of course, coherent. Anything mapped into I/O is up for grabs but probably not coherent. I/O devices generally don't snoop caches.
They put the CPU in a wait state. I had one early PCI card that didn't make the CPU wait, and you'd see the data bus changing while the DATASTB/ was true.
This is plenty inefficient for the CPU, multi-GHz CPUs waiting on a 1 MHz peripheral, but it guarantees proper timing.
On the latest generation of parports, the EPP cycle seems to take a total of
350 ns.Jon
On X-86 PCs, I/O is a separate address space, so totally separate from the memory address space. I would think in all systems, out of order execution and memory tricks must leave I/O order as programmed. Writing GO to the command register before writing the memory location or disk location could cause real trouble.
Jon
Sure, you don't want I/O cached, for one thing.
Forcing in-order execution hits performance. PowerPC gives the programmer the option.
Jon
About ten years ago I worked with a very high end Intel server motherboard. We ended up buying thousands of them. One thing we found was a very obviou s design error where the bios wrote to the VGA graphics with errors. Once y ou knew to look you could see speckles on the screen. Once windows booted a nd the display memory was written to by the GPU there were no errors. When Intel were told they just didn't care.
In your case it could be a chip or PCB error, but why should the manufactur er care when most customers don't.
Colin
Yeah, this seems to be the problem, especially when the "customer" appears to them as Amazon or Best Buy! The makers of this stuff make it essentially IMPOSSIBLE for the end user to even contact them. I looked, I couldn't find anything that looked like a way to actually contact anybody related to the product line.
But, the problem is, I have to support MY product, and now one of the most common PCIe parport cards, sold under at LEAST 3 different manufacturer names, is defective! This is going to be giving me support headaches for the next couple years.
Jon
How sure are you of that? The LOCK prefix exists to bus-lock a CAS operation all the way to main memory, instead of just from a CPU-local cache. Why would they do that if main memory was consistent anyway? I mean, the memory is consistent, but each processor's view of it is not.
It's been a long time since I've looked at this stuff but it has to be choherent, at least on a memory model level or MPs wouldn't work.
On Sat, 23 Apr 2016 10:50:48 -0400, krw Gave us:
snip
Software authentication dongles. Some parallel port configurations do not work with them and faux ports on VMs do not work at all.
Ok. In that case, you're wrong. Multi-processors only have to flush cache on a thread switch. Each thread may be scheduled on a different CPU core, and will not necessarily see changes made by threads on other CPUs - unless that CPU has a cache flush *or* the bit of memory was written using a bus-locked instruction. Inter-thread communication relies on either memory barriers or locked instructions.
The virtual memory TLB cache has to get flushed in appropriate cases too, or you get bugs in page mapping. Linux and Windows flush the TLB on entry to the O/S kernel, though some newer micro-kernel architectures don't require that (on Intel hardware).
This stuff is complicated. Much more complicated than I've implied by what I wrote above. But the bottom line is, main memory is not coherent unless the software forces the issue.
Clifford Heath.
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.