Stamp Out Code

[Tom Droege <tdroege@veriomail.com>]

I am working on the Stamp code to help hold the Declination drive from 
moving.  Arne asked for better exposure control while I am working on the 
code.  A reasonable request on the surface.

The problem with the exposure control is that the RS-232 link does not work 
properly.  If it did, the Stamp code could be simplified, and camera 
control would be much more powerful.  If the RS-232 link worked as it 
should Arne's request would be a non problem.  It would already work to 
meet his request.

In looking at the exposure control code, I note that I am running the 
RS-232 link at 2400 baud.  The Stamp will run at 48000 baud.  We should be 
running there.  The reason we are not, is Windows and Microsoft.  This is a 
heck of a reason for not running properly.  It is probably not just 
Windows, but the later versions of DOS that keep us from running at the 
higher baud rates.

For newcomers, there is a mystery 10 second wait.  If one tries to do 
things on the RS-232 port, DOS/Windows will at arbitrary times insert a 10 
second wait.  Probably while they try to figure out how they can sell me 
something.  This means that if you try to make a 1 second exposure by 
sending "OPEN" followed 1 second later by "CLOSE" you might get 1 second, 
you might get 11 seconds. Or something in between.  Or you could get a 1 
second exposure ten seconds later that you expected to get it.

If we could run at 48000 baud, then we could do many things in the control 
CPU that I am trying to do in the stamp, and the stamp code would be more 
bulletproof.

For example, here is the way I presently move a shutter:

I send a command to the stamp which contains the shutter channel and a 
time.  The stamp code uses the time to set a pulse width, then enters a 
loop where it sends out a pulse of that width to the servo, and repeats it 
50 times with a 20 ms pause in the loop.  The result is 50 pulses of the 
proper width for an open or a close sent out to the servo over 1 
second.  It does not really need to be sent for a whole second, probably 
200-300 ms would do.  Note the shutter servo motor responds to pulse width 
between 1 and 2 ms, and moves to match it's internally generated pulse 
width to that applied to it.  The Stamp is busy during this whole time, and 
one cannot, for example, open the other shutter during this time.

Now suppose the RS-232 link worked as it should.  I could send a single 
command to generate a single pulse of the desired width.  At 48000 baud 
this should take 166 us.  I could now send the same command to the other 
shutter servo a couple of milliseconds later.  One could then alternate 
between the two for a few hundred milliseconds.  Note that it should only 
take a fraction of a microsecond to load up the RS-232 interface to send 
out the signal to the stamp.  So most of the time the CPU would be 
available for other things.  One needs a real time system to schedule all 
this, but lots of people have built these.

This puts all the timing and control into the CPU, where I think it 
belongs, and where anyone can work on it and improve it.

Sounds like a plea for a real time Linux, or Forth, or ...  , system to me.

If I had something that worked at this speed I could even solve my 
Declination drive problem.  At millisecond speed I could switch from 
Declination drive motor to Declination clamp and back before the 
Declination had time to move.  I am not implying that I could move the 
Declination clamp all the way on, but I could sneak in clamp steps by 
jumping away and back before the motor field decayed.  Well it might not be 
so easy, but worth a try.

OK, when I started this, the design planned on the Stamp link being pretty 
fast.  When I could not make it work, I just charged on and made the camera 
system work anyway.  But it would sure be nice if the RS-232 link worked as 
it should.

This is a big hint.  There are three systems out there where this code 
could be developed.  Soon there will be five.  Someone (not me) needs to 
take this on.  Possibly Chris has already solved the problems.  If so, we 
should work on the Stamp code to bring it up to speed and start trying to 
shift over.   I am ready to try to run under Linux.  It will be a pain at 
first, but I will do it.

I really don't want to muck up the stamp code to try to make it do 
something that it is much better done in the CPU just because we have not 
gotten around to making good CPU code work.

Tom Droege