[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Mark IV Electronics Design
- To: firstname.lastname@example.org, "Griffing, Dan" <DAN.GRIFFING@kla-tencor.com>
- Subject: RE: Mark IV Electronics Design
- From: Tom Droege <email@example.com>
- Date: Fri, 09 Jan 1998 13:24:22 -0600
- Old-Return-Path: <firstname.lastname@example.org>
- Resent-Date: Fri, 9 Jan 1998 15:07:31 -0500
- Resent-From: email@example.com
- Resent-Message-ID: <"rETctC.A.oVF.7ont0"@kani.wwa.com>
- Resent-Sender: firstname.lastname@example.org
The basic problem is that I don't have a live in programmer, or
any way to muck with system functions. When I run my computer
it from time to time goes off and does something. This is the
essence of multitasking systems.
I want to unload the cameras in one continuous operation. This
is because I have experience with systems where the computer
takes a few cycles here and there. The result is a noise pattern in
the data because of the computer operations. The way to avoid
this is to always read out the CCD with exactly the same spacing
between operations. I have built big analog systems both ways.
This is a 16 bit system. The only way I have found to make such
systems work to their potential is to make sure there is no
asychronous stuff around.
Believe me, I no longer build systems that interupt. I build systems
that pole. If you pole you are always in control. True, you may
find when you pole that you got somewhere too late. But you
always know (if properly designed) that you did not get there in
time. True, you can achieve the same thing with interrupts, but
it is harder.
Now if I could just turn off all other system functions for 40
seconds while I did a read, I might attempt some of the routes that
yout describe. But I don't know how, and if I did, the operating
system would not like it. At the minimum the system clock would
While I am reading 32 Mbytes in 40 seconds with the current system,
there are ADC's around that would do it in 2 seconds or so. So I want
to be able to transmit 32 Mbytes in 2 seconds over a 8 bit wide bus
without *any* variation in timing. If you know how to do this let me
This is why I designed my own memory. (Merle did it). Now I can
run "data push" with no handshake. My memory is always ready
since no one but me has access.
At 09:55 AM 1/9/98 -0800, you wrote:
>Tom & Chris
>Thursday, January 08, 1998 7:21 PM
>Tom Droege wrote:
> >As outlined some time ago, this has long been done. The
> >to design an interface that was data push. The receiving end
> >control. I did not want the read out from the chip to vary in
> >would be the case with any computer interface. i.e. from time
> >the computer wants the interface and holds things up. So the
> >is a straight byte parallel interface designed to go at up to a
>20 MB or
> >so rate (for a short cable). So it is not any standard
> At 05:27 PM 1/8/98 -0800, you wrote:
> >Tom Droege wrote:
> >> This is mostly a reply to Grzegorz Pojmanski who is
>interested in using the
> >> Mark IV electronics. I am posting it to the group as there
>may be general
> >> interest. The status today is that there are rough drawings
> >> The connector details have not been worked out.
> >If you have not yet worked out the cable that feeds the
> >memory board would you make it look like a printer
> >interface. Modern printer ports are bi-directional
> >and very fast. (Just look at what a ZIP drive can do.)
> >If camera data could look like data comming
> >back from a printer (or parallel interface ZIP drive)
> >then at some point down the line
> >we could just pull the memory card and plug the cable
> >into an EPP printer port. You've likely got the required
> >signals already. Likely just need to get the pinout
> >correct. I think it is simple: ready, ack, and data.
> >One advantage of dropping the card is cost, but also, the
> >PC gains access to the pixels quicker by several tens
> >of seconds. May help when you are tring to focus.
> >I think the new ports bypass the ISA buss which should
> >help, but also you don't need to write software to read
> >from a standard port.
> >Any rate if you copy the printer port pinout someone can
> >experiment later.
> >--Chris Albertson
> > email@example.com Voice: 818-351-0089
> > Logicon RDA, Pasadena California Fax: 818-351-0699
>Why not use a high speed LAN interface?
>Then any one of a wide range computers
>with different speeds and operating systems
>with standardized LAN hardware and low level
>vendor-supplied drivers could interface to your
>system. Alternatively, because Intel Pentium
>PC compatible computers are dirt cheap, you
>could make an entire Mark IV server with a
>You could go ISA parallel to the PC server with
>standard off-the-shelf interface cards and this
>wouldn't be a problem since the Mark IV would
>include the entire server. Server software would
>allow internet connections or other client computers
>on a LAN to connect and run the system.
>Window 95 and NT have a DCOM (Distributed
>Component Object Technology) software
>technology which allows distributed computing
>so that the Mark IV telescopes can be remotely
>controlled over the network and even over internet.
>With DCOM, you could easily have completely
>remote observation sites with the ability to make
>Staff Software Engineer,