A few more words.
Posted by
Arne Chr. Jorgensen
on 1999-10-01 18:29:51 UTC
Hi
Jon, about that GPIB, let say that you put a DAC on your servo
board, and skipped the whole Stg board, an encoder board, an IO
board, maybe an EDM control, a consol, - all of it could be
attached to the bus. The only question is speed, but this again
has to do with the way the communication is set up, the way the
code is writtten, and how it interface with the Real time kernel.
The time window that RTLinux is active, could be ended with
addressing for the next byte transfers, that way you will speed up
the latency of the bus. ( maybe not a good idea - but I just want
to point out, there might be ways to overcome these problems )
If you would like to have a DRO device, just hook it in to the
bus, with the encoder module. The thing is, you arrange your
hardware in a modular fashion. If we could break it down to
modules, then we could see if it would be possible.
The other alternative would be to make a bus system, with address
and data. This would be partial encoded into the ISA address space.
( I have made such a board, but I have never tested it for speed,
lenght of cable and such )
Or you may use the SCSI interface. ( This is best for bursts of
data, but the physical standard is good regarding signal
reflections, etc. )
But the easiest way could be to use the GPIB, and it is the most
supported bus system for instrumentation. So I do believe this
could be a solution for an extended bus.
I am not sure of these data, but I found something that suggest
transfer rates:
IEEE 488.1 ! HS 488
------------------!-------
ISA 1,5Mb/s ! 1,6Mb/s
EISA 1,5 " ! 3,4 Mb/s
PCI 1,5 " ! 7,7 Mb/s
--------------------------
( note this is bytes pr. second, not bits pr. second that some other
buses use )
Any one have some comments to this ?
Here is a few other things. The bus is available to about 30 OS
systems ? Anyway, you can control it in BASIC, VBasic, C, what
ever - there is code examples for most languages. This would make
it easy for many to test, and control it. It would be easy to make
some applications, and then upgrade the system for speed ( say move
from basic to C )
There must be someone on the list with experience on this topic.
Say a few words about it.
//ARNE
Jon, about that GPIB, let say that you put a DAC on your servo
board, and skipped the whole Stg board, an encoder board, an IO
board, maybe an EDM control, a consol, - all of it could be
attached to the bus. The only question is speed, but this again
has to do with the way the communication is set up, the way the
code is writtten, and how it interface with the Real time kernel.
The time window that RTLinux is active, could be ended with
addressing for the next byte transfers, that way you will speed up
the latency of the bus. ( maybe not a good idea - but I just want
to point out, there might be ways to overcome these problems )
If you would like to have a DRO device, just hook it in to the
bus, with the encoder module. The thing is, you arrange your
hardware in a modular fashion. If we could break it down to
modules, then we could see if it would be possible.
The other alternative would be to make a bus system, with address
and data. This would be partial encoded into the ISA address space.
( I have made such a board, but I have never tested it for speed,
lenght of cable and such )
Or you may use the SCSI interface. ( This is best for bursts of
data, but the physical standard is good regarding signal
reflections, etc. )
But the easiest way could be to use the GPIB, and it is the most
supported bus system for instrumentation. So I do believe this
could be a solution for an extended bus.
I am not sure of these data, but I found something that suggest
transfer rates:
IEEE 488.1 ! HS 488
------------------!-------
ISA 1,5Mb/s ! 1,6Mb/s
EISA 1,5 " ! 3,4 Mb/s
PCI 1,5 " ! 7,7 Mb/s
--------------------------
( note this is bytes pr. second, not bits pr. second that some other
buses use )
Any one have some comments to this ?
Here is a few other things. The bus is available to about 30 OS
systems ? Anyway, you can control it in BASIC, VBasic, C, what
ever - there is code examples for most languages. This would make
it easy for many to test, and control it. It would be easy to make
some applications, and then upgrade the system for speed ( say move
from basic to C )
There must be someone on the list with experience on this topic.
Say a few words about it.
//ARNE