• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 100 subscribers
  • Views 111 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TDA4VM: VPAC TIOVX target kernel instances have redundant storage

Max Geiselbrechtinger
Intellectual 420 points
Part Number: TDA4VM

Hello,
I am adapting the VPAC VISS target kernel (ti-processor-sdk-rtos-j784s4-evm-08_06_01_03/tiovx/kernels_j7/hwa/vpac_viss/vx_vpac_viss_target.c) to use the second VPAC on the same MCU and wondered why there is a global variable to store the vissObj structs (ie. gTivxVpacVissInstObj) when they are also registered with the kernel (ie. contexttivxSetTargetKernelInstanceContext) at instance creation. Isn't one of the two redundant?

Furthermore I would like to differentiate the VPAC instances at runtime with the tivxGetTargetKernelTargetId() API. However, the defines for the target ids are not really accessible from the target kernels as they require the header file i-processor-sdk-rtos-j784s4-evm-08_06_01_03/tiovx/source/platform/psdk_j7/common/soc/tivx_platform_psdk_j784s4.h which in turn forces me to included several other headers such as tivx_queue.h etc.. Is it not intended to use those defines on target kernel side or can i get these values elsewhere?

I hope somebody can help me clarify these points.

best regards,

Max

  • 0
    TI__Guru**** 398480 points

    Hi Max,

    gTivxVpacVissInstObj object contains a pool of instance objects from which instance object is allocated whenever we create new instance of this kernel/node, We store this allocated instance object in the kernel instance context so that we can get it in every kernel function, without need to always extract from the pool.. So both have different purpose and are required. When you want to support two instances of the VPAC, we just need a way to identify the VPAC instance and store somewhere in the instance object.

    Instead of using this API GetTargetKernelTargetId, probably, you can store the instance id in the instance object, so it can be available to all kernel APIs.. 

    Regards,

    Brijesh 

  • 0 in reply to Brijesh Jadav
    Intellectual 420 points

    Hi Brijesh,

    thanks for the clarification. The instances in gTivxVpacVissInstObj are allocated in the ttivxVpacVissCreate callback. This callback has a tivx_target_kernel_instance parameter and I figured this can be used with tivxGetTargetKernelTargetId to check which target has been specified for the node with vxSetNodeTarget. According to this information I would set the driver parameter in the instance structure vissObj->viss_drv_inst_id to VHWA_M2M_VPAC_0_VISS_DRV_INST_ID_0 or VHWA_M2M_VPAC_1_VISS_DRV_INST_ID_0.

    Do you think this change will be sufficient to select the VPAC instance at runtime or is there more to it than the viss_drv_inst_id and hw_perf_id parameters to distinguish between the HW instances?

    best regards, Max

  • 0 in reply to Max Geiselbrechtinger
    TI__Guru**** 398480 points

    Hi Max,

    Yes, you could use this API to get the target ID and then to identify the VISS instance from this target id. Also please note that since both the VISS instances can run in parallel, it is better to create two two targets. In this case, framework will create two tasks and both can run in parallel. 

    The other way is, you can store the returned target_kernel pointer in your local data structures, while creating target kernels and then use it to identify the targets. This is how it is done in the MSC kernel in the file tiovx\kernels_j7\hwa\vpac_msc\vx_vpac_msc_scale_target.c.

    Regards,

    Brijesh