Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[FAQ] TDA4VM: Process OpenVX Graph while simultaneously configuring a camera

Part Number: TDA4VM

How to configure a camera without affecting the OpenVX graph, while the single cam application graph is running

  • Configuration of the imager happens using a remote service call from the application to the R5 core.

    The priority of this remote service task is 10.

    However, the task priority of other tasks like the LDC, AEWB etc are less than the remote service task.

    Hence, while the graph is running, if we call a remote service to configure a sensor, this would block the lower priority tasks thus causing a halt in the graph.

    The graph would resume after the sensor is configured.

    The usecase is as shown in the below patch which is to be applied in the ${PSDKRA}/vision_apps/ directory.

    /cfs-file/__key/communityserver-discussions-components-files/791/init_5F00_sensor_5F00_parallel.patch

    This patch consists of the changes to be done to the single cam application for configuring an imager in the port 1 of CSI2-Rx 0th instance.

    The patch is created on SDK 8.6 for TDA4VM.

    Solution:

    In order to avoid the blocking of the task, it would be better to configure the imager in a lower priority task for the required sensor.

    The patch below should be applied in the ${PSDKRA}/imaging/ directory.

    /cfs-file/__key/communityserver-discussions-components-files/791/sensor_5F00_config_5F00_task.patch

    The patch is created on SDK 8.6 for TDA4VM.

    Here, a task with priority "3" (low priority) is created in which the sensor configure would occur.

    When the remote service is called from the application, the remote service handler on MCU2_0 (R5) would trigger this task and return.

    Hence, this would not block any other lower priority tasks in the graph.

    Regards,

    Nikhil