FVID_Exchange Control

Carl Allendorph said:

Is it possible to set a timeout on FVID_exchange?

This is not a feature implemented in the driver.

Carl Allendorph said:

Can I set FVID_exchange to non-blocking mode?

This also does not appear to be a feature of the driver for DM6437, the user's guide in C:\dvsdk_1_11_00_00\pspdrivers_1_10_00\packages\ti\sdo\pspdrivers\drivers\vpfe\docs makes no mention of control over blocking, or even that the function does in fact block. Note that the FVID_exchange call is actually equivalent to sequential calls to FVID_queue and FVID_dequeue, so you could queue a frame and than do some work and than dequeue a frame to block for the next frame being available. The DM648 on the other hand looks to allow a non blocking call by using the FVID_control (fvidChan, VPORT_CMD_STOP, args); call before the FVID_exchange/dequeue call as discussed in the DM648 vport driver user's guide in C:\dvsdk_1_11_00_00\pspdrivers_1_10_00\packages\ti\sdo\pspdrivers\drivers\vport\docs.

Carl Allendorph said:

Is there a way I can get a PDF of the documentation for this API? Is there a distribution for this that I am overlooking? Can someone post a link to this documentation?

Unfortunately the DM6437/DM648 DVSDK is not included in the new public DVSDK downloads so to access it you would have to obtain it by registering your DM6437 EVM through www.ti.com/davinciregistration. My understanding is that the documents are not posted seperately due to legal/licensing issues, you have to register a EVM board to access the installer and accept the license agreement with the installer to access the documentation. I would think you already have this if you are developing with the FVID API?

The board I'm using was through D3 Engineering, so I have neither those documents nor an EVM. Is there any other way I can register for this besides buying an EVM?

I'm taking really long exposure time images (1-5 seconds), and I check the time around each FVID_exchange and it is blocking for approximately the exposure time. So, even if it's not documented, I'm pretty sure that function blocks for the dm6437.The problem is that if this blocks, then the task that is running capture can't tickle the WDT. I don't want to make my WDT period be 5-10 seconds, I think that would be counter-productive...

One possible method would be to launch the FVID_exchange on its own task and then kill it after the timeout ,  but I'm concerned about putting the driver in an unknown/invalid state. The only option that seems to be left is writing my own driver that implements blocking and non-blocking access. Anyone have any better ideas?

Are there any other devices that have an API similar to the DM6437's for the fvid driver? I saw a doc on the dm642 but it was a little different and didn't have some of the functions you talked about (FVID_queue, dequeue).

Thanks,

~C

Carl Allendorph said:

The board I'm using was through D3 Engineering, so I have neither those documents nor an EVM. Is there any other way I can register for this besides buying an EVM?

If you got the board from D3, how did you get the FVID driver? If they are providing you the software somehow I imagine they have a way of getting you the documentation as well, the drivers generally come with the documents. .

Carl Allendorph said:

I'm taking really long exposure time images (1-5 seconds), and I check the time around each FVID_exchange and it is blocking for approximately the exposure time. So, even if it's not documented, I'm pretty sure that function blocks for the dm6437.The problem is that if this blocks, then the task that is running capture can't tickle the WDT. I don't want to make my WDT period be 5-10 seconds, I think that would be counter-productive...

One possible method would be to launch the FVID_exchange on its own task and then kill it after the timeout ,  but I'm concerned about putting the driver in an unknown/invalid state. The only option that seems to be left is writing my own driver that implements blocking and non-blocking access. Anyone have any better ideas?

 If it is just a watchdog timer issue than you could have a seperate periodic function that runs to manage servicing the WDT, though if the driver blocked forever you would not notice by default, however you could have the seperate WDT PRD loop check on a status value from the FVID exchange loop. The problem would be recovery, as you mention if the driver is blocking forever there is probably something wrong and recovering from that could be problematic, though that gets more system specific than I can comment much on.

Carl Allendorph said:

Are there any other devices that have an API similar to the DM6437's for the fvid driver? I saw a doc on the dm642 but it was a little different and didn't have some of the functions you talked about (FVID_queue, dequeue).

The FVID API on the DM6437 is based on the older DM642 API, some of the function names changed though the functionality is largely the same.

Hi Bernie

I too am seeing the DM648 FVID_exchange block and am also confused why since the BIOS_VPORT_Driver_Arch.pdf document Figure 26 shows FVID_exchange returning IOM_PENDING when a buffer is not present. According to Fig 24, FVID_dequeue shouldn't block either.

Is using a callback the best way to deal with these so that you only enter FVID_exchange when the buffer is available? (ie using FVID_control (fvidChan, VPORT_CMD_SET_VINTCB, args); )??

Thx

Eddie,

Even though the VPORT driver returns IOM_PENDING, the call goes to the GIO layer of BIOS and blocks there on a semaphore.

The call does not return to the application.

When the capture/display is complete, the driver notifies the GIO layer using the callback function and hence the GIO layer post the semaphore and the call returns to the application.

This is abstracted from the application and hence application don't get this return value even though the driver returns the same.

Hope this clarifies your doubt.

For further details refer to GIO driver model in BIOS user guide.