[Elphel-support] channel switching and exposure question

[Andrey Filippov]

On Mon, Sep 6, 2010 at 2:22 PM, Andreas Bean <office at beanbox.com> wrote:

> Andrey, Oleg,
>
> fpcf does not. I still don't understand why. Anyway, I will update and
> try the commands mentioned below.
>

that register was probably a 32-bit one and PHP code writes 4 bytes. "fpcf
-i2cw16 " writes 2 bytes per each data item, did you try to write 2 16-bit
words, not one?


> Should the combining/alternating modes work in the current version?
>

Alternating mode is not supported (it is too alien to the pipe
lined-oriented software), it is for designed for combined mode only. And
that mode works only in "TRIG=4" mode


> Andrey, nor fpcf or reg_write.php follow the safety procedure you
> mentioned in your last mail, do they?
>

It is done on the driver write level, there were some updates recently
(mostly related to access to the sensor and 10359A boards EEPROMs - their
i2c is slower than sensor and 10359 FPGA)


> If I understand you right then placing i瞔 commands through the
> sequencer is the safer option. How can I do that from c?


Through writing higher level parameters to /dev/framepars driver (you may
look at autoexposure or php extension as examples). there are global
parameters that can be accessed as mmap-ed array, but fro most other
parameters such simple approach would not work as parameters have extra
"frame number" dimension, when you write to the driver you specify
parameters number, frame number it should be applied to and the value (plus
some modifiers, i.e. trigger action even if new parameter value did not
change from the old one). The hardware sequences (one fro i2c and another
for the internal FPGA registers) support only 7 frames queue, so you can not
write too far ahead.

Some parameters of the frames (such as dimensions, quantization parameters
are stored in the same circular buffer in the 32-byte inter-frame gap - they
are used for meta data generation when the image is retrieved from the
buffer. Some other parameters that do not fit into 32-byte space are stored
in Exif buffer. Histograms have 8  frames history too so there is some time
to analyze data after the frame was acquired.

It is possible to read/write sensor and 10359 FPGA register as parameters
(they are mapped) - you can find examples in parsedit.php, but it is better
to avoid direct registers but rather use higher level parameters - inthat
case driver will take care of synchronized change in differnt registers ion
the sensor registers, 10359 registers and the internal 10353 FPGA ones - all
with the latencies appropriate. Of course ther still can be some bugs and
inconsistencies - parsedit.php with test mode is a good tool to try
different ones.


> Can you tell me a starting point for further code investigation?
>

http://192.168.0.9/index.php?site=diag_utils.php is a good starting point.
There are many debug outputs in the driver (the global DEBUG parameter is
available), different bits enable different outputs (in the driver they are
mostly MDFxx() macros, where xx is DEBUG bit number). Some bits enable
output from inside interrupt service routines so it is better to run
printk_mod &
from the command line - it will redirect all printk() output to
/var/html/klog.txt - you can access it through the web browser as
http://192.168.0.9/var/klog.txt

repeating "printk_mod &" command clears the klog.txt file


Debug output includes file name, function and line number - you can find
them in the driver source code.

Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20100906/954607b8/attachment-0002.html>