[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Triplet after Trigger
Hello Christian!
On Thu, 18 Jan 2001, Christian Schulz (ahlrich) wrote:
> Hello Mr. Stein!
>
>
> > The following explanation is based on the assumption, that you are using
> > an INTERLACED camera. If not, we have to think again about the problem.
>
> I'm sorry, but the camera isn't an interlaced camera. The camera sends no
> analog, but an digital videosignal and doesn't work in an interlaced
> modus.
What a pity! The answer matches your question quiet well.
> But perhaps that's the problem:
>
> 332 /* trigger irq */
> 333 if (irqs[board] & CR_TRIGINT)
> 334 {
> 335 ICP_IRQ_PRINTF("t");
> 336 switch (icp.opmode[board])
> 337 {
> 338 case ICP_OP_TRIGGER:
> 339 ICP_IRQ_PRINTF("T");
> 340 icp_splhigh (board);
> 341 if (cr_get_vbstat (board) == CR_OUT_VB)
> 342 {
> 343 if (cr_get_smstat (board) == CR_ILACE)
> 344 {
> 345 if (cr_get_fldstat (board) == CR_IN_ODD_FIELD)
> 346 {
> 347 cr_set_fldsel (board, CR_ODD_FIELD);
> 348 cr_set_evbien (board, CR_DISABLE);
> 349 cr_set_ovbien (board, CR_ENABLE);
> 350 }
> 351 else
> 352 {
> 353 cr_set_fldsel (board, CR_EVEN_FIELD);
> 354 cr_set_evbien (board, CR_ENABLE);
> 355 cr_set_ovbien (board, CR_DISABLE);
> 356 }
> 357 }
> 358 #ifdef DEBUG_ICPCI
> 359 else
> 360 {
> 361 icp_irq_printf ("\nicpci[%c]: sample current "
> 362 "field in VB?\n", 'W');
> 363 }
> 364 #endif
> 365 }
> 366 icp_spllow (board);
> 367 cr_set_tmode (board,CR_DISABLE);
> 368 cr_set_acqmd (board, CR_SNAP);
> 369 icp.opmode[board] = ICP_OP_SNAP;
> 370 }
> 371 }
>
> in line 343 in icpciMain.c you check whether the camera is in interlaced
> modus or not (I think, you do). But the camera is not, and so there is
> an error print to messages instead of doing something with the even/odd
> fields as in line 345 - 356. Is it possible that the problem has
> something to do with that?
Using with non interlaced cameras, the code should do nothing (also not
printing an error message - this is a coding error). But removing the
prinf does not solve our problem! However - I think, that our trouble
still deals with the executiuon of the interrupt handler out of the vsync
interrupt. Perhaps it is a kind of race condition between the software and
hardware state. If the handler is executed out of VB, it means, that it is
too late executed.
The only solution to prevent this is, to make it executed in time - using
real time interrupts. If you want to do this, patch your kernel with
http://www.rtlinux.org
and bind iti_interrupt to be a real time one by calling request_RTirq(3)
in init_module.
It should work, but it is long time ago, that I have tried this.
matthias
Notice: Perhaps anyone at the list has real time expiriences!?
> Best regards
> Christian
>
>
>
-------------------------------------------------------------------------------
GOM mbH Tel.: ++49 531/3804-330
Gesellschaft fuer optische Messtechnik Fax.: ++49 531/3804-333
Rebenring 33 Mail: M.Stein@gom.com
38106 Braunschweig GERMANY http://www.gom.com
-------------------------------------------------------------------------------