Re: wild I/O interface idea

["Dean Franks" <dean-at-worlddigital.com>]

"just too crazy"

pretending to be a sdram dimm would be really difficult.  SDRAM does not
have the nice static memory type bus you remember from the Atari, you would
have to provide the id rom signals to even convince the bios to map the
sdram socket into address space.  Assuming you accomplished that, you would
have to decode ras and cas select lines, latch the address, provide the data
out using the sdram data timing, and keep the loads on the socket very low
with minimal signal reflections.

How about this:  Build the hardware as an EPP parallel device with a
external timer generating the ack pulses.  EPP ports can operate using DMA
to get data from system memory, the application would just try to stay far
enough ahead to prevent buffer under-runs.

Better yet, just move some of the intelligence off-board using an AVR or ARM
and connect to the host using a high-speed serial port.  Send queued, high
level commands across the rs232 port, both the AVR and ARM's would be
capable of doing linear and circular moves locally.  If you used the ARM,
you could probably port a good portion of the real-time emc code to the ARM
in it's original C form.

Dean

----- Original Message -----
From: "Doug Fortune" <pentam-at-home.com>
To: "Multiple recipients of list" <emc-at-nist.gov>
Sent: Wednesday, April 26, 2000 10:44 PM
Subject: wild I/O interface idea


>
> Regarding the previous ISA/PCI/USB/ethernet etc
> conversations on how to get signals out to/from the real world
> in a timely manner for steppers and servos.
>
> The problem with ISA is that it is constrained to
> operate on an 8MHz cycle.  I believe the accesses to the
> parallel port and system timers (for RT-Linux) also
> must pass over this bus.
>
> Once upon a time I built an analog/digital converter
> for an Atari/ST and it did its I/O through the cartridge
> game port - essentially memory mapped I/O at memory access speeds.
>
> I am thinking of a card, which to the computer looks like a
> SDRAM memory stick, but which actually is not memory,
> but otherwise provides three basic functions:
>
> #1 - provides a few 32 and 64 bit timers/counters.  These are
>           set up and read just by memory reads and writes to specific
>           locations.
> #2 - provides latched outputs to the real world (ie computer
>          writes 32 bits to a memory address, and those are latched)
> #3 - provides latched inputs to the computer (ie something
>         external writes and strobes bits into a latch, and the CPU
>         can read those bits just by reading a memory address).
>
>
> #1 would assist RT-Linux in quickly setting up timers (I haven't
> quite figured out how to do an interrupt, but perhaps cause a
> false memory parity error, which could be trapped and intercepted).
>
> #2 and #3 would give us all the I/O bits we needed.
>
> Most modern (Pentium) computers have 3 or 4 SDRAM memory
> sockets.  It would be easy to dedicate one socket for this function.
>
> It seems much simpler than designing dedicated PCI cards, writing
> drivers etc.  Also it would have a very wide variety of applications
> for fast data I/O.
>
> Sleeper, or just too crazy?
>
> Doug Fortune
>
>
>
>
>