[Elphel-support] channel switching and exposure question

[Andreas Bean]

Andrey Filippov schrieb:

> > On Mon, Sep 6, 2010 at 2:22 PM, Andreas Bean <office at beanbox.com
> > <mailto: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?
> >  
>   
I will try to write 4 bytes.

> >
> >     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 
> >  
>   
Currently I'm using two modes. The combined mode which works for 50%
width, 50% height frames only (in my old version) and the alternating
mode with buffering for full resolution frames. I haven't looked at the
latest development for some time.

What I need is the ability to capture two frames at exactly the same
time. You said that the alternating mode with buffering(?) isn't
supported any longer. The combining mode doesn't support full resolution
which would be 2 * 5Mpix = 10Mpix, does it?

I suppose that you have solved that for the Eyesis with three sensors,
so I think it should work. Which mode are you using?


> >     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)
>   
Do you mean the driver which handles the device /dev/xi2c16 ? If so, I
don't have to take care of the sequencer, do I ?

> >  
> >
> >     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.
>   
I have seen that in the code for autoexposure. Good to know that the
queue is 7 frames.

> >
> > 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.
>   
Ok, I will have a look at parsedit.php.

> >  
> >
> >     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
>   
Andreas


	
Andreas Bean <www.beanbox.com> <office at beanbox.com
<mailto:office at beanbox.com>>
BEANBOX.COM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: office.vcf
Type: text/x-vcard
Size: 242 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20100907/bfb83147/attachment.vcf>