• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 372 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.

Newbie fastcopy question (dm6446 evm)

Orjan Friberg
Expert 1385 points

Hi,

I'm evaluating the 6446 for an application where we need to handle in the order of a few MB/s and also want to do lots of calculations.

I modified the readwrite example (from the dsplink package) to not do any writes/verifications of the data sent.  With an 8 kB buffer I got 12 MB/s (with a 32 kB buffer 23 MB/s) which limits the amount of MMACs I can crank out.  Ideally, I'd like to get close to the peak ~2400 MMAC/s for the 16-bit case.

I then turned to look at the fastcopy example (from the framework components package).  Having looked at the sanity_test example (from the codec engine release notes) which ran just fine I expected to find a codec package (.x64P), and an ARM application that creates the engine and loads the codec into it, but can't find one.  Do I need to write one?  I searched the forums but couldn't find a fastcopy usage example.  What am I missing here?

(All components are from the 2.00.00.22 DVSDK.)

Thanks,

Orjan

  • 0
    Expert 1385 points

    I'm still at a complete loss on what to do or how to proceed.  The goal is still to run the DMA fastcopy example on a 6446 EVM board.

    I can build framework_components/examples successfully, but I only find ARM binaries in DM355 and DM365 subdirs (i.e. none for dm6446), and none of those relate to fastcopy example.

    Switching over to codec_engine/examples I'm getting various build errors in the apps/codecs/servers dirs which I haven't sorted out yet.  Is there a difference between the fastcopy stuff in  framework_components and in codec_engine?

    I'd be grateful for any help.  I'm going back to reading the Using DMA with Framework Components for ‘C64x+, maybe that will clear things up.

    Thanks,

    Orjan

  • 0 in reply to Orjan Friberg
    Expert 1385 points

    One piece of information that I forgot to include: so far I'm doing this under Linux.  I noticed there are a lot of .pjt files; is this something that require I build through CCS?

  • 0 in reply to Orjan Friberg
    TI__Mastermind 37340 points

    You are correct that pjt files are associated with CCS;  many of these components were originally developed under CCS.  However, before being integrated into DVSDK, xdc packages were created for each of these components to allow building of the components via Linux command prompt (no CCS required); therefore you should be able to build the examples.  I just checked my directory and was able to find fastcopytest_dm6446.x64P binary files (x = executable, 64P= 64x+ DSP core found in DM6446). 

  • 0 in reply to Juan Gonzales
    Expert 1385 points

    Right; I see now my original description was misleading: I did manage to build the .x64P file, but I couldn't find a corresponding ARM application to load and run the DSP executable.  I.e., I don't know what to do with the fastcopytest_dm6446.x64P file.

    Since then I found that there are "full" versions of codec_engine and framework_components for download (with the cetools subdir for codec_engine, not sure what the difference is for framework_components) which both build fine under Linux.

    In the codec engine, under examples/ti/sdo/ce/examples I can build all of the apps, servers and codecs dirs. If I look in apps/video_copy/dualcpu/evmDM6446, sure enough, there is an application named app.out (just like in the sanity_test example). Looking in the fastcopy dir under codec_engine I find no way to build that (no makefile) however.  Turning to framework components instead, building directly from the top examples dir, again I can build the .x64P file but there's no ARM application.

    I'm pretty sure I'm missing something fairly obvious here.

    Thanks for any help,

    Orjan