Tool/software: TI-RTOS
Hello.
For a TOF project, I need to control a camera using Cortex M4 running under TI-RTOS feeding a ring-buffer containing sequences of 4 frames corresponding to different phases : the 4 frames are the input for the algorithm running on DSP under TI-RTOS while M4 is controlling the camera and launching next acquisition. I have in mind to implement a producer-consumer mechanism between M4 and DSP where M4 is feeding a ring buffer in a shared memory and DSP is consuming the input triggered by a mailboxes from M4. The problem is how to implement this idea inside VPS driver library:
1) analyzing examples by TI, seems that the mechanism of deque-queue frame list is acting on the same set of addresses: it seems that frame buffers provided to driver are temporarily released by the the call to FVID2_deque and after a copy of the contents are again given back via FVID2_queue to the driver without any change. Is this the only mechanism available ?
2) I allocated a static ring buffer of frames and, between a FVID2_deque and a FVID2_queue, I tried to change addresses in the frame list provided to the FVID2_queue in the context of a swi triggered by the capture callback: the result was a "Bad Context Exception" even if documentation and examples by TI are calling FVID2_deque directly in the capture callback. I suppose that the problem comes from the fact that the address change is involving VPDMA reconfiguration and this could not happen in Isr/Swi context: is it correct ? Are there other ways to access to VPDMA register in the context of Isr/Swi ?
3) I moved ring buffer management in a high priority task triggered by an event generated by capture callback and it's working - no Bad Context Exception this time - but I found initially a very strange problem: I configured VIP disabling callback periodic call (periodicCbEnable = FALSE in Vps_CaptCreateParams structure) and I set the buffer capture mode as VPS_CAPT_BCM_FRM_DROP ( bufCaptMode = VPS_CAPT_BCM_FRM_DROP in the same structure); reading the documentation this means: "In this mode the driver will stop capturing data when there are no more buffers at the input queue. The driver will not hold any buffer with it and the last buffer will be returned to the application through dequeue call. For this mode, the driver makes use of the VPDMA drop data feature."
If I'm queuing 4 frames, does the sentence mean that the callback is triggered only one time at the end of 4 frames acquisition ? What about the callback trigger mechanism ? From my analysis using a counter, the callback is triggered at every frame and it stops on the last one: is this true ?
