Re: A little more information

[Tom Droege <tdroege@veriomail.com>]

Shawn and all,

OK here is how we have to try to make it work.

The PC knows when the Mark IV is going to start to send data.  It knows 
because it sends a "Start Scan" to the Mark IV.  Before it sends the "Start 
Scan" over the RS-232 link it sets up all the bookeeping and shuts down all 
processes that might interfere.

Shortly after the PC sends "Start Scan", the Mark IV starts sending 
bytes.  From looking at how the ECP works 
http://www.beyondlogic.org/ecp/ecp.htm
it appears that the following might work:

1)  The PC sets pin 16 "nReverseRequest" low.

2) At the Mark IV end, pin 16 "nReverseRequest" is tied to pin 12 
"nAckReverse".

3) Pin 11 "PeriphAck" is tied permaneltly high at the Mark IV end.

4) The Mark IV puts data on pins 2-9 and starts sending data strobes on pin 
10 "PeriphCLK"

5) The PC responds with "HostAck" on pin 14.  This is ignored in the Mark IV

6)  With the trailing edge of the roughly 600 ns data strobe sent by the 
Mark IV, the PC assumes that the Mark IV has responded to the "HostAck" and 
reads the data on pins 2-9.

7) This process continues until the PC has received all 16 MBytes of data.

8)  The PC knows when the process is completed by timing the 
operation.  The process takes an exact amount of time as determined by a 
crystal clock in the Mark IV.  This is a little over 40 seconds with the 
present prom program.  When enough time has elapsed, the PC assumes the 
transfer is completed and goes to process the data wherever the DMA process 
on the ECP channel has put it.

Note that there is no stopping the process once started.  The PC must clear 
the data at the rate it arrives.  I assume that the control program shuts 
down all processes that might cause a miss in data while the transfer is 
taking place.  This means that Linux or Windows is not allowed to go off 
and do "garbage collection" or some other such process in the middle of a 
transfer.  I assume we have talent here that knows how to do such 
things.  I assume that the clock tick interrupt can keep going so that we 
know the time without interfering with the data transfer.  This process is 
not all that fast on the scale of things these days, I think.  It would 
probably not have been possible with the speed of PCs when this project was 
started.

All that it takes to test this is a short jumper cable that reconnects the 
Mark IV pins as indicated above.  I will make this up for whoever wants to 
try it out.

Tom Droege

At 01:21 AM 8/15/01 -0400, you wrote:
>Wouldn't you still need to do some clocking on the transfer over the
>parallel port?  I'm not familiar with the workings of ECP ports so there may
>be additional capabilities, but I have done some work with interfacing
>devices using the old-fashioned parallel port.  There isn't any way to tell
>when data is ready on the input lines on the port unless you add some other
>control line that you would use as a strobe (either a "data ready" from the
>Mark IV, or a "Send data" from the PC).
>
>The Cookbook 245 CCD uses a simple implementation of the parallel port
>transfer, sending only 4 bits at a time.  The rest of the bits (there are 12
>or 13 actually available on a standard parallel port) are used for control.
>These additional bits are needed since there's no brains or memory in the
>CB245, so all of the A/D conversion and bit shifting to transfer the data a
>nibble at a time has to be controlled from the PC.  The Mark IV is much more
>sophisticated, but it seems that without some sort of clocking between the
>devices you'd just be hoping that everything ran at the right rate, or you'd
>end up with lost or duplicated bytes.
>
>Shawn
>
>
>----- Original Message -----
>From: "Tom Droege" <tdroege@veriomail.com>
>To: <aah@nofs.navy.mil>; <tass@listserv.wwa.com>
>Sent: Wednesday, August 15, 2001 1:08 AM
>Subject: Re: A little more information
>
>
> > Arne,
> >
> > Oh! No you don't!  Talk me into feature creap that is.  ;^)  You won't get
> > me attempting to add a serial IF into an existing system.  I know why you
> > want it.  There must be serial to fiber optic converters on the market.
>If
> > you need such a device then that is the path I would choose.
> >
> > I have now looked at the parallel port, and it looks like all that is
> > necessary is to rewire one end of the DB-25 cable.  Then write the DMA
> > software that puts the event onto disk.
> >
> > Tom Droege
> >
> > At 08:32 PM 8/14/01 -0700, you wrote:
> > >Bill/Tom's high-speed serial card is a reasonable solution
> > >in that the approach is to take the parallel I/O data at the
> > >Stamp end, convert it to serial for transmission, then convert
> > >back to parallel using a PCI card.  I'd like to know how large
> > >the FIFO is, what kind of handshaking is available, and how
> > >elaborate a PCI interface was made.
> > >   The real solution is to get rid of all copper between the
> > >Mark IV and the host computer.  This means to use fiber and to send
> > >the RS232 over the same link if it is bidirectional.  The RS232 stuff is
> > >slow speed compared to the rest, but you have to break it out
> > >at the Stamp end to make it look like a standard RS232 port plus
> > >parallel port, unless you want major software work on the Stamp as well.
> > >Since I raised my hand to work on the BX24 upgrade, we might
> > >be able to add such support in the fancier chip.
> > >   The PC printer port solution is ok if you use the ECP
> > >protocol, since that can use DMA access and removes the typical
> > >latency problem.  However, ECP protocol usually means additional
> > >software on the Stamp end in order to handle the port negotiation.
> > >Note that all of these solutions means work, which is why I'd
> > >like to see some more effort put into the memory cards first.
> > >Tom, you want to take data, not build another piece of hardware!
> > >Arne
> >
> >
> >