Peter C. Wallace wrote:
> The unknown is the read and write overhead from the PCI-E bus, though I doubt
> it will be any worse than a PCI parallel port. The UARTs are indeed 16550
> type
> with 256 byte receive and trasnmit FIFOs
>
> The fact that the parallel port connects via PCI-E should be transparent.
There's that dreaded word again, "SHOULD". And, the IEEE-1284
is a weird protocol, that pretty much requires the CPU to go
into a wait state until the remote device answers that it has
received the data. We have some code that looks like :
for (i = 0; i < 4; i++) {
for (j=0; j < 3; j++) {
var[i,j] = inb(port);
}
}
where the inb(port) translates to a single CPU instruction. The
CPU has to wait for the data to become stable on the bus and
read the bits. That code would read 12 consecutively addressed
byte registers, such as the 24-bit encoder counters for 4 axes.
I have no idea how they handle this kind of locking with PCI-E,
and whether there are any implications to the software. I
wouldn't be surprised if some of this bends PCI-E way farther
than it wants to be bent. The IEEE-1284 definition allows up to
10 us before the operation times out. I just can't believe that
PCI-E wants to have 10 us deadlocks going on, but they may have
a scheme so it looks the same to the CPU. When these cards come
out, I definitely have to try it and see. If a modest software
change is required, that wouldn't bother me too much, either, as
long as it is standard.
Jon
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
