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.

FILE HANDLING FUNCTIONS ARE VERY SLOW IN CCS v5

I m using the file handling functions of c++ namely 

file.read() and copy.write() to read and write a 800 kb file on dsk6713.(the FID.read and FID.write functions,where FID is any variable like copy,file, etc)

But the simulator takes almost 5 minutes to do so.I guess this is an not an optimized way to read and write data from file.

PLZ SUGGEST THE EFFICIENT WAY OF READING AND WRITING DATA FROM FILE THAT WUD DO THE JOB IN REAL TIME(In fraction of seconds)

Here is my code.THE CODE IS EXECUTING PERFECTLY and there are no errors or warning.Problem is the time required to execute the code.Please help me

----------------------------------------

#include<stdio.h>

#include<iostream.h>

#include<fstream.h>


int main(void)
{char *m; //pointer to buffer
fstream file,copy;

file.open("t11.bin",ios::in|ios::binary);
copy.open("t11copy.bin",ios::out|ios::binary);

file.seekg(0,ios::end);
long size=file.tellg(); //get size of file
file.seekg(0,ios::beg);

cout<<size<<endl;

m=new char[size];

file.read(m,size);



copy.write(m,size);


file.close();
copy.close();


while(1);
}
  • Which exact version of CCSv5 are you using?
    Which exact name of the simulator are you using?
    You mentioned the DSK6713 also, are you using the board to do this, too?

    What does "WUD" mean?

    Regards,
    RandyP

  • Yes, We are using CCSv5.

    version:5.1.0.09000

    The simulator is:C6713 Device Cycle Accurate Simulator,Little Endian.

    under Texas Instruments simulator.

    Yes we are using the Board TMS320C6713 DSK.It is the part of our image processing project.

    Hence we want to Open a image file containing RAW pixel data stored in our PC.

    Now we have written the above code in C++ and it works fine.The problem is that it is very slow.So we guess that this code is not the efficient way to handle a file

    The Board works on 225 MHz.Hence If our code is taking 5 minutes to read and write just 800 Kb data,i guess there must be an efficient way.

    Plz help us if u have a solution

  • Mehul,

    First, let me say that it is not clear to me if you are currently using the simulator or the EVM.  The below answers are referring to the EVM. If this is the simulator, I don't know if there is much you can do to speed it up.  It's meant to simulate the execution of the target, but can't execute in anywhere near the same time.  

    File I/O is extremely slow.  You don't want to do it this way.  

    First, here's a bit about the way it works.  When you do any type of CIO function in ccs (printf, fscanf, etc...I believe these are the underlying functions htat are used with C++ file i/o also) the application is halted.  So, what happens is CCS runs the application, and then periodically polls the target to see if it's been halted.  This happens even when you are not using File I/O.  It's just how CCS works.  The target runs independently of CCS and periodically polls it to see if it's been halted for sme reason (i.e. breakpoint, etc).  When you do any file i/o CCS winds up branching to the _CIO  symbol, which is essentially a special breakpoint.  In this case, when you call a file.read, the target jumps to this breakpoint and waits there.  When CCS sees that the target is halted and that it's at this special breakpoint, it will then take action, in this case, reading the value from the source file and putting it in memory.  Then CCS runs the application again.  There's not a specific amount of time that I can tell you for how often CCS polls, but you can be sure it's much slower than your target clock is.  

    I suspect that with the size of this file, this is broken up into many smaller chunks.  So, each time part of a buffer is read, you have a halt, wait for CCS to poll, file access to get the data, and then the emulation transport of the data from the host to the target.  Then, you have a similar action when you write data out.  

    The better way to implement this is to use some protocol other than the file i/o.  (Easier said than done).  What emulator are you using?  The on-board one?  Or an external one (560 generation)?  This would be one source of the delay.  A faster emulator would pull the data from the host more quickly and would result in a much smaller response time.  I doubt this will get you to fractions of seconds, but it might get you under a minute. The XDS560 targets can have a TCK speed of 35MHz.  

    But the best solution would be to use some other transport, which unfortunately is more difficult. You want to use one of the on-chip peripherals.  Looking at the 6713 DSK schematics, there aren't a whole lot of options.  It seems the only peripheral you really have access to is the serial port via the Audio Codec.  But even if you used that, the max sample rate is 44000.  This would take ~18 seconds to import.

    Another problem that I see is that the 6713 DSK only has 0x30000 bytes of internal memory.  Which tells me that if you're bringing this entire buffer in at the once means that you're storing it in external memory.  800KB ~ 0xC8000 bytes.  So, this is going to be another issue.  It's going to take many extra cycles to read and write these values to external memory.

    I don't know what the optimal solution is for you, as I don't have an understanding of your desired application.  You could pre-load the data into memory via CCS and then operate on the data, but with the target board that you have, I can't think of a good simple solution for you to get this data on and off the target in real time.  You could convert your data into the format of a .wav file and use the codec port to import it.  But, like I said, we're looking at 18 seconds to get the entire file on/off.  The 6713 DSK was geared more towards Audio applications.  There are other platforms that would be more conducive do doing this type of an application.  

    Regards,

    Dan

    
    
  • I am not yet sure where the problem is. In your first post, you said the simulator takes 5 minutes, but in the post above you seem to be saying that the board also takes 5 minutes. Are both of these true?

    File I/O through CCS is intended to support the capability for your convenience, but it is not a high-speed data transfer medium. The communication channel is the JTAG serial scan chain that has a lot of bits that have to be scanned for each word transferred.

    A more efficient method may be to use the Save Memory and Load Memory features of the Memory Browser window. The file to be loaded has to be in the compatible format, so please review the Help files in CCSv5 for the Load Memory feature to make sure your file is formatted correctly. If this loads more quickly, then you can just read the data from memory instead of reading it from a file over JTAG.

    Regards,
    RandyP

     

    If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

  • @Randy

    We are using the Simulator most of the time.

    The reason is that we are having the DSK6713 in our college and we are yet to emulate our code using the on board emulator.We can not do it for sometime as vacations are going on.on.

    For the time being, we are using simulator at our home.

    Ok Thanks for you suggestion.I would try the Memory load.

    I know the supported format.So that would solve our solve our simulation problem.I will give it a try and tell you.

    Thanks,

    Mehul Saxena

  • @ Dan.

    Thanks for the Explanation.That has explained us a lot.

    We have yet not tried the on board emulator.I guess it would be faster than the simulator.

    But the way u describe doing image processing for be a difficult task for dsk6713.If we can buy a daughter card that can be given to the Audio port,it would be a solution

    So we will try the Emulator first

    also simulator can simulate smaller files at the faster rate..Its when the size increases,the processing becomes slow.

    Lets wait till we can lay our hand on the on-board emulator.

  • Btw can u tell me,If i load a file in memory using Load memory option,

    How can i access my file in the software?

    Suppose i load the file at 0xffff and it takes 800kb of continuous memory,how can i read it into a variable for processing it..

  • It is not a file at this point. It is already data in memory after doing the Memory Load operation.

    If you have an array VideoFrame that can hold all of the data in external RAM, then use normal C pointers or array references to get the data.

    unsigned char VideoFrame[640][480*2];
    int nLine, nPixel;

    for ( nLine = 0; nLine < 640; nLine++ )
    {
        for ( nPixel = 0; nPixel < 480; nPixel++ )
        {
            Luma = VideoFram[nLine][nPixel*2+0];
            Chroma = VideoFram[nLine][nPixel*2+1];
        }
    }

    Just an example, but the Memory Load would be used to write the data starting at &VideoFrame[0][0].

    Regards,
    RandyP

  • Thanks a lot Randy..

    It solved our Problems to great extent.u understood wat we wanted to do.Your code is for the colour image.We made our code for grayscale image.That was pretty simple

    I made a pointer like

    char *m =(char *)0xffff;

    then during the debugging we loaded the data  at 0xffff.

    Your example program is fine.We wrote a similar program for our applicaiton for just "intensity" as be are having grayscale images..

    Works fine on simulator.Now its time to emulate on the real time data.

    I guess i have to write a program to somehow store the captured image a 0xffff (just an example location) from the audio port

    @ Dan

    Also as u pointed out that DSK6713 is for audio application and we dont have access to most of its pin,I guess we will use C2000 for further development.

    The process will still be that same with minor changes in our code and optimization on SIZE..

    I m verifying both answers.

    Anyone of u can give a FINAL TIP that may help us in our project

    Thanks,

    Mehul Saxena 

  • Mehul,

    My point about the DSK6713 being for audio was merely pointing out that the peripherals that are implemented on the board are audio based.  There may be other C6000 development platforms that have on-board peripherals that are better suited for your application.  I certainly think that any type of image processing will be more efficient on a C6000 platform than on a C2000 platform.  Before you move to any other platform, investigate the methods of getting your image on and off the device.  

    Regards,

    Dan

     

  • Yes.We can use its I2C module to Connect our Camera Module to it.

    Also we have got a DSK6416 in our college.May be we should give that a try.

    The reason of the our planning to move to C2000 because be have access to all its 40 pins.That makes the life very easy.Also the code we need to execute on the device is just a in matching algorithm that would take the image and create weights corresponding to it.Then weights will be compared from the database already trained in MATLAB.So i guess that would work just as fine.Even we can get 80MHz of device clock.

    But yeah We will investigate how to handle the image.

    everything is working pretty fine thanks to both of u.

    :)

  • This will be a good learning experience for you. Please post us here with your progress and findings and your new wisdom at each evaluation point. The Community will benefit from your posts.

    Regards,
    RandyP