• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 99 subscribers
  • Views 426 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

About EncodeDecode Demo

LorryAstra
Expert 1460 points


Hi,

   I have three questions about this demo. (EVM6446, Fedora 8)

1) I found that if I skip the process of Codec Engine Initialization, I could not convert virtual memory address to physical address properly by using Memory_getPhysicalAddress(Ptr virtualAddress);

   I don't know whether it is necessary to init Codec Engine if I do not need to encode or decode any video signal. Here I just want to capture something using CCD camera and then write these video signal to then DDR memory, finally to show the signal on LCD screen without encoding or decoding.

2) In ti/sdo/ce/osal/Memory.h, this file tells me that Memory_getPhysicalAddress() is deprecated, so I decide to change this function to Memory_getBufferPhysicalAddress() without revising any other code. But when I'm running this code on target$ , it tells me "Bus error", and if I change the function back, everything is running properly. So, could you tell me why?  Do I need to Memory_init() before Memory_getBufferPhysicalAddress()?

3) Does it necessary to begin "Display" thread before "Capture" thread? I try to change the order, and find that everything is running well but "DSP CPU load", it's always 99%.  Before changing the order, I find that DSP is not so "busy". Actually, the code sounds not related with DSP's running.

thank you.

  • 0
    TI__Mastermind 37340 points

    1) Memory_getPhysicalAdress is an osal (OS abstraction layer) function; this means that it maps to a corresponding BIOS, Linux, WinCe... call depending on what target you are building for.  It is part of codec engine and hence if you do not need to use codec engine at all, you can write your application entirely in Linux (Memory_getPhysicalAdress is not part of Linux).  Please note that in Linux, user space application do not have direct access to physical memory but can mmap a memory buffer and treat it like physical contiguous memory (virtual memory manager (VMM) takes care of it).  However, this can sometimes be confusing when trying to debug as developers often forget memory pointer returned by mmap is not physical memory.

    2) Yes, you do need Memory_init() before you call any Memory_xxx type functions, although I think this may be called automatically by codec engine.  As I suggested above, if you are not using codec engine, your best bet is to stick to standard Linux calls (makes you application portable across Linux platforms).

    3) This depends on how your application software is architected, for our demos, this is necessary, but this is not set in stone and could be changed with a few software modifications.  You are correct the capturing and displaying should not involve DSP, but again, our software demos are written to make use of DSP for encoding/decoding; if you have not properly removed all this code, then DSP is still being called.

    In summary, it sounds like you do not need DSP and you should be able to write an application which does not involve DSP or codec engine at all; if all you are interested is capture and display, this can all happen on ARM/Linux side.