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.

OMAP-L137 - Real-Time File System - File Read

Other Parts Discussed in Thread: OMAP-L137

Hi everybody,

I'm using the C6747 core inside the OMAP-L137 to perform image processing. I'm using the RTFS from Code Composer Studio by using RTFS 1.10 API Reference Guide (SPRUGM0A).

I need to read a binary file which contained 1 x 262144 Uint16 variable, and there will be less than 60 files to read. The binary files are actually images that I need to read from the MMC/SD to process.

I've tried using fopen/fread command and open/read as well to read the files. I've found that fopen/fread is slower, whereas open/read only read in 8-bit chunks (char). I've tried to combined two 8-bit chunks to get the 16-bits data however this is extremely slow.

Does anyone have suggestion?

Thanks in advance

Rizuan

  • Rizuan,

    The fastest way is always going to be to read a block of data rather than a word at a time.

    "read" can read more than a single byte at a time.

    I would experiment declaring different sizes of buffers of unsigned ints, then use read to fill the buffer in chunks.

    http://www.opengroup.org/onlinepubs/000095399/functions/read.html shows an example, but you may need to change char buf[20];;
     to Uint16 buf[20] depending on the endian-ness of your file. Alternatively you can use pointers and malloc instead of fixed arrays. Typically powers of 2 will also tend to be slightly quicker in some cases.

    If you are reading the file into memory rather than processing it on the fly, then you could define the buffer to be the size of your image and read it in one big chunk.

    BR,

    Steve

  • Hi Steve,

    Thanks for your fast reply. I've followed exactly what you have instructed me from the link you provided, and my code is as follows:

    #include <ti/rtfs/posix/sys/types.h>

    #include <ti/rtfs/posix/unistd.h>

     

    .........

     

    Uint16   readbuf[262144];

    Int         fptr, ret;

    size_t    nbytes;

     

    .........

     

     fptr      = open(ImagePath, (O_BINARY|O_RDONLY), 0);

     nbytes = sizeof(readbuf);
     ret       = read(fptr, readbuf, nbytes);

     

    and I still got the error argument of type "Uint16 *" is incompatible with parameter of type "char *"

     

    Then, I changed the type of variable ret to ssize_t and I received the following error:

                identifier "ssize_t" is undefined.

     

    For your information, I’m using RTFS 1.10.01.31. Is there any way to change the buffer type to 16 bits from 8 bits ?

     

    Thanks for your kind help.

     

    Best regards,

    Rizuan

     

  • Rizuan,

    These are now really C language specific questoins.

    What you need to do is typecast the read function parameters.

    I suggest doing some web research on 'C typecasting', but basically you need to tell the compiler to 'pretend' that the pointer you are giving the read function points to characters rather than Uint16.

    Try this...

    ret       = read(fptr, (char*)readbuf, nbytes);

    BR,

    Steve

  • Thanks Steve. It works! Here, I reattached again the code snippet as reference for others. Sorry for asking about the C language. Really appreciate your suggestion.

    #include <ti/rtfs/posix/sys/types.h>

    #include <ti/rtfs/posix/unistd.h>

     

    .........

     

    Uint16   readbuf[262144];

    Int         fptr, ret;

    size_t    nbytes;

     

    .........

     

     fptr      = open(ImagePath, (O_BINARY|O_RDONLY), 0);

     nbytes = sizeof(readbuf);
     ret       = read(fptr, (char*)readbuf, nbytes);

    Best regards,

    Rizuan

  • Excellent :)

    You are more than welcome my friend.

    Are you getting the performance you need now?

    BR,

    Steve

  • Yes, Steve. It is the time for me to focus on my algorithm development. Thanks to all TI employee because of this useful forums.

    Thanks,

    Rizuan