Andre, If you are going to make a lot of small DSP procedure calls then DSPLINK is not the way to go. If I remember correctly the overhead to call (and do the return) a DSP function from the ARM side using DSPLINK is in the order of 900 usecs. I think DSPLINK is OK (and meant for) calling one (1) frame resize and encode or decode operation per 33 or 40 msec video frame.
Regards, Arie de Muijnck -----Original Message----- <snip> in the previous weeks I have been working on porting OpenCV to the DM6446. The main target is to make (i) Opencv work on the ARM-montavista-linux (which I did quite quickly) (ii) Opencv use some DSP power, namely for those very basic matrix operations. If anybody does not know Opencv, its basically a computer vision C library originally made for i86. It both provides basic math and matrix operations and very newly researched computer vision algorithms. For now, my main target is to allocate opencv matrix data in common memory of the DM6446 and rewrite and encapsulate i.e. the matrix multiplication function of opencv so it calls a procedure on DSP side (pointers to the matrices by-reference). So, basically I only need (i) remote procedure calls and (ii) nice access to common memory. For the former, I am experimenting with DSPLINK that seems to serve nice remote procedure calls. Do you think it is right not to use the Codec Engine. What Ive heard CE is specialized on stream processind and DSPLINK with its modules PROC and NOTIFY/MSGQ is more appropriate for "normal" RPCs. For the latter, I cannot really agree with the tools TI provides. I tested DSPLINK POOL, that only serves fixed size pools that have to be determines at boot/compile time. The same goes for CMEM (which DSPLINK uses I think(?)). The memory pools are a good idea for DSP algorithms with fixed worst-case memory requirements. But not for usual computer vision algorithms that firstly use *lots* of structures you are not going to allocate pools for and secondly, do not have fixed requirements in general. My most important questions are - do think its a good idea in general to port opencv to the DM6446 - is there *anything* that can *dynamically* allocate memory (not in pre-defined pools) so both ARM and DSP can work on it without copying??? Ive got the impression since the DSP does not have a memory management unit it has got to work on (huge) chunks of continuous physical memory. Because if there is no means for dynamically allocate continuous physical memory I will write a linux kernel module for that (that replaces CMEM). Andre _______________________________________________ -------------------------------------------------------- CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify Arie de Muijnck by telephone or [EMAIL PROTECTED] and delete the original transmission and its attachments without reading or saving in any manner. _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
