[Prev][Next][Index][Thread]

re: load & brightness

Thus spoke Paul Haas:
> Imagine a film camera.  Think of what would happen if every now and then 
> the camera gets distracted while the shutter is open.  You'll get an over 
> exposed image.
> 
In the words of Ed McMahon: "YES!...You, sir, are correct!"

My mistake was in assuming 2 things:
1. the transfer (shutter) command was atomic
2. timeslicing during image transfer was source of problem.

After reading your message I conducted a couple of experiments.  First I
inserted a delay half way thru transfering the image.  If I delayed some
huge amount (several seconds) the botom half of the image was very
subtly darker than the top.  Also a few scattered pixels always stayed
lit...sort of like a diamond-vision board with blown out lights.

This told me that delays during image transfer weren't too critical.

Next I tried inserting delays at various points within the transfer
image sendcmd call chain.  Sure enough- brightness problems- and the
dreaded "nuke flare".  If the delays were large enough (100000 usec) the
nuke flare effect was very pronounced.

So we have 2 potential solutions:
1. make sure the code that sends commands to start image transfer
doesn't get interrupted- which I believe can only be done in kernel
driver
2. use absolute timers to ensure the sequence takes some fixed amount of
time.  We no longer drive the camera at the max it can take but subtle
shifts in load no longer tweek the image.
Follow-Ups: