I want to read from 3 files for my decoder implementation on c6713. These file
foramts are in .cfg and .26l bitstream and .cfg formats. Also I want to write
decoded yuv format file.
Can anybody suggest me suitable method. I heard of file I\Os. But not used
this before. And unaware of weather I can do this from my host pc. Just now
started from help. But still confused for best way to achieve this.
Needed helpful suggestions kindly..
Regards,
Nilesh
---------------------------------
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
Suggestions needed for file I\Os
Started by ●January 23, 2007
Reply by ●January 23, 20072007-01-23
Nilesh-
> I want to read from 3 files for my decoder implementation on c6713. These
> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
> to write decoded yuv format file.
> Can anybody suggest me suitable method. I heard of file I\Os. But not used
> this before. And unaware of weather I can do this from my host pc. Just
> now started from help. But still confused for best way to achieve this.
> Needed helpful suggestions kindly..
Suggest:
-use standard C code file I/O functions at start of
main(), prior to algorithm processing
-read bitstream and config files and store in external
mem (SDRAM)
-don't use file I/O functions during algorithm
processing; instead refer to stored data in memory
-use file I/O functions again at end of main() to
send results back to PC
This creates a simple, easy-to-debug environment for you to get your algorithm
working. It also keeps the C code easy to read. Overall very appropriate for
student level. The disadvantage is it's not suitable for real-time, streaming
implementation. But for real-time video processing, you can't use DSK 6713 anyway so
that's a different issue.
-Jeff
> I want to read from 3 files for my decoder implementation on c6713. These
> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
> to write decoded yuv format file.
> Can anybody suggest me suitable method. I heard of file I\Os. But not used
> this before. And unaware of weather I can do this from my host pc. Just
> now started from help. But still confused for best way to achieve this.
> Needed helpful suggestions kindly..
Suggest:
-use standard C code file I/O functions at start of
main(), prior to algorithm processing
-read bitstream and config files and store in external
mem (SDRAM)
-don't use file I/O functions during algorithm
processing; instead refer to stored data in memory
-use file I/O functions again at end of main() to
send results back to PC
This creates a simple, easy-to-debug environment for you to get your algorithm
working. It also keeps the C code easy to read. Overall very appropriate for
student level. The disadvantage is it's not suitable for real-time, streaming
implementation. But for real-time video processing, you can't use DSK 6713 anyway so
that's a different issue.
-Jeff
Reply by ●January 24, 20072007-01-24
Hello Sir,
I was thinking likewise only. But then certain things are still not clear.
When we say standard C I\O file functions things that come to mind are:
fopen, fscanf, fputc these are used in my c code.
It is OK to say read from PC using these functions and store them to SDRAM. But can we do this directly? I think we may not... because when i run my code on DSK it gives me FILE NOT FOUND kind of error. So i think i need to configure something for this prior.
## Can u elaborate more clearly as what to do for this error?
## If i am not wrong this is not real time RTDX kind of thing... am i right?
## Is this better option than probe points? In probe point we can have COFF and .DAT files as I\P .... then can i convert my files to these formats?
Thanking You,
Nilesh
Jeff Brower wrote:
Nilesh-
> I want to read from 3 files for my decoder implementation on c6713. These
> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
> to write decoded yuv format file.
> Can anybody suggest me suitable method. I heard of file I\Os. But not used
> this before. And unaware of weather I can do this from my host pc. Just
> now started from help. But still confused for best way to achieve this.
> Needed helpful suggestions kindly..
Suggest:
-use standard C code file I/O functions at start of
main(), prior to algorithm processing
-read bitstream and config files and store in external
mem (SDRAM)
-don't use file I/O functions during algorithm
processing; instead refer to stored data in memory
-use file I/O functions again at end of main() to
send results back to PC
This creates a simple, easy-to-debug environment for you to get your algorithm
working. It also keeps the C code easy to read. Overall very appropriate for
student level. The disadvantage is it's not suitable for real-time, streaming
implementation. But for real-time video processing, you can't use DSK 6713 anyway so
that's a different issue.
-Jeff
---------------------------------
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
I was thinking likewise only. But then certain things are still not clear.
When we say standard C I\O file functions things that come to mind are:
fopen, fscanf, fputc these are used in my c code.
It is OK to say read from PC using these functions and store them to SDRAM. But can we do this directly? I think we may not... because when i run my code on DSK it gives me FILE NOT FOUND kind of error. So i think i need to configure something for this prior.
## Can u elaborate more clearly as what to do for this error?
## If i am not wrong this is not real time RTDX kind of thing... am i right?
## Is this better option than probe points? In probe point we can have COFF and .DAT files as I\P .... then can i convert my files to these formats?
Thanking You,
Nilesh
Jeff Brower wrote:
Nilesh-
> I want to read from 3 files for my decoder implementation on c6713. These
> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
> to write decoded yuv format file.
> Can anybody suggest me suitable method. I heard of file I\Os. But not used
> this before. And unaware of weather I can do this from my host pc. Just
> now started from help. But still confused for best way to achieve this.
> Needed helpful suggestions kindly..
Suggest:
-use standard C code file I/O functions at start of
main(), prior to algorithm processing
-read bitstream and config files and store in external
mem (SDRAM)
-don't use file I/O functions during algorithm
processing; instead refer to stored data in memory
-use file I/O functions again at end of main() to
send results back to PC
This creates a simple, easy-to-debug environment for you to get your algorithm
working. It also keeps the C code easy to read. Overall very appropriate for
student level. The disadvantage is it's not suitable for real-time, streaming
implementation. But for real-time video processing, you can't use DSK 6713 anyway so
that's a different issue.
-Jeff
---------------------------------
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
Reply by ●January 24, 20072007-01-24
Hello Sir,
Thank you for your guidance. I have resolved thi error and everything is working perfectly.
But now strange thing i have observed. My cycle count in functional simulation mode is
63,195,122 while for real time DSK cycle count shown are 609,820,832. I could not understand why it is so.
I am writing file each frame as it is decoded to yuv file. And this is what i expect to be. Because i want to have another vc application which can show decoded yuv frame as it is decoded by DSK. Also my code is outputting standard o\p console macroblock no that is decoded.
For your ready ref. my .cmd file is==>
-c
-heap 0x1F4FFFF
-stack 0x2000000
-l rts6700.lib
MEMORY
{
L2SRAM0: origin = 0x00000000 length = 0x5700
L2SRAM1: origin = 0x00005700 length = 0x2900 /*L2SRAM0 + L2SRAM1 = 0x8000*/
CE0: origin = 0x80000000 length = 0xB0000
CEO: origin = 0x800B0000 length = 0x3F4FFFF
}
SECTIONS
{
.sysmem > CEO
.stack > CEO
.far > CE0
.external > CE0
.text > CE0
.cinit > L2SRAM0
.bss > L2SRAM0
.const > L2SRAM0
.cio > L2SRAM0
.switch> L2SRAM0
.data > L2SRAM0
.tables> L2SRAM0
}
My heap and stack are on SDRAM because of large size needed. Suggest some performance improving mapping technique.
Regards,
Nilesh
Jeff Brower wrote:
Nilesh-
> I was thinking likewise only. But then certain things are still not clear.
>
> When we say standard C I\O file functions things that come to mind are:
> fopen, fscanf, fputc these are used in my c code.
>
> It is OK to say read from PC using these functions and store them to SDRAM. But can we do this directly? I think we
> may not...
Sure you can do it. Read the file data into an array that is located in SDRAM. You can use the "section" pragma and
linker directives to locate memory in a specific external address range.
> because when i run my code on DSK it gives me FILE NOT FOUND kind of error. So i think i need to
> configure something for this prior.
>
> ## Can u elaborate more clearly as what to do for this error?
No. You have to debug it.
> ## If i am not wrong this is not real time RTDX kind of thing... am i right?
As far as I know, basic C code file I/O functions do not use RTDX. That's one reason why file I/O should be done at
start or end of main(), or when code is "paused", but not during real-time processing.
> ## Is this better option than probe points? In probe point we can have COFF and .DAT files as I\P .... then can i
> convert my files to these formats?
.dat files are Ok, but not COFF files. COFF files are executable DSP code.
Nilesh, I recommend that you do some reading and experimenting and figure this out.
-Jeff
> Jeff Brower wrote:
> Nilesh-
>
>> I want to read from 3 files for my decoder implementation on c6713. These
>> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
>> to write decoded yuv format file.
>> Can anybody suggest me suitable method. I heard of file I\Os. But not used
>> this before. And unaware of weather I can do this from my host pc. Just
>> now started from help. But still confused for best way to achieve this.
>> Needed helpful suggestions kindly..
>
> Suggest:
>
> -use standard C code file I/O functions at start of
> main(), prior to algorithm processing
>
> -read bitstream and config files and store in external
> mem (SDRAM)
>
> -don't use file I/O functions during algorithm
> processing; instead refer to stored data in memory
>
> -use file I/O functions again at end of main() to
> send results back to PC
>
> This creates a simple, easy-to-debug environment for you to get your algorithm
> working. It also keeps the C code easy to read. Overall very appropriate for
> student level. The disadvantage is it's not suitable for real-time, streaming
> implementation. But for real-time video processing, you can't use DSK 6713 anyway so
> that's a different issue.
>
> -Jeff
---------------------------------
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
Thank you for your guidance. I have resolved thi error and everything is working perfectly.
But now strange thing i have observed. My cycle count in functional simulation mode is
63,195,122 while for real time DSK cycle count shown are 609,820,832. I could not understand why it is so.
I am writing file each frame as it is decoded to yuv file. And this is what i expect to be. Because i want to have another vc application which can show decoded yuv frame as it is decoded by DSK. Also my code is outputting standard o\p console macroblock no that is decoded.
For your ready ref. my .cmd file is==>
-c
-heap 0x1F4FFFF
-stack 0x2000000
-l rts6700.lib
MEMORY
{
L2SRAM0: origin = 0x00000000 length = 0x5700
L2SRAM1: origin = 0x00005700 length = 0x2900 /*L2SRAM0 + L2SRAM1 = 0x8000*/
CE0: origin = 0x80000000 length = 0xB0000
CEO: origin = 0x800B0000 length = 0x3F4FFFF
}
SECTIONS
{
.sysmem > CEO
.stack > CEO
.far > CE0
.external > CE0
.text > CE0
.cinit > L2SRAM0
.bss > L2SRAM0
.const > L2SRAM0
.cio > L2SRAM0
.switch> L2SRAM0
.data > L2SRAM0
.tables> L2SRAM0
}
My heap and stack are on SDRAM because of large size needed. Suggest some performance improving mapping technique.
Regards,
Nilesh
Jeff Brower wrote:
Nilesh-
> I was thinking likewise only. But then certain things are still not clear.
>
> When we say standard C I\O file functions things that come to mind are:
> fopen, fscanf, fputc these are used in my c code.
>
> It is OK to say read from PC using these functions and store them to SDRAM. But can we do this directly? I think we
> may not...
Sure you can do it. Read the file data into an array that is located in SDRAM. You can use the "section" pragma and
linker directives to locate memory in a specific external address range.
> because when i run my code on DSK it gives me FILE NOT FOUND kind of error. So i think i need to
> configure something for this prior.
>
> ## Can u elaborate more clearly as what to do for this error?
No. You have to debug it.
> ## If i am not wrong this is not real time RTDX kind of thing... am i right?
As far as I know, basic C code file I/O functions do not use RTDX. That's one reason why file I/O should be done at
start or end of main(), or when code is "paused", but not during real-time processing.
> ## Is this better option than probe points? In probe point we can have COFF and .DAT files as I\P .... then can i
> convert my files to these formats?
.dat files are Ok, but not COFF files. COFF files are executable DSP code.
Nilesh, I recommend that you do some reading and experimenting and figure this out.
-Jeff
> Jeff Brower wrote:
> Nilesh-
>
>> I want to read from 3 files for my decoder implementation on c6713. These
>> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
>> to write decoded yuv format file.
>> Can anybody suggest me suitable method. I heard of file I\Os. But not used
>> this before. And unaware of weather I can do this from my host pc. Just
>> now started from help. But still confused for best way to achieve this.
>> Needed helpful suggestions kindly..
>
> Suggest:
>
> -use standard C code file I/O functions at start of
> main(), prior to algorithm processing
>
> -read bitstream and config files and store in external
> mem (SDRAM)
>
> -don't use file I/O functions during algorithm
> processing; instead refer to stored data in memory
>
> -use file I/O functions again at end of main() to
> send results back to PC
>
> This creates a simple, easy-to-debug environment for you to get your algorithm
> working. It also keeps the C code easy to read. Overall very appropriate for
> student level. The disadvantage is it's not suitable for real-time, streaming
> implementation. But for real-time video processing, you can't use DSK 6713 anyway so
> that's a different issue.
>
> -Jeff
---------------------------------
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
Reply by ●January 24, 20072007-01-24
Nilesh-
> I was thinking likewise only. But then certain things are still not clear.
>
> When we say standard C I\O file functions things that come to mind are:
> fopen, fscanf, fputc these are used in my c code.
>
> It is OK to say read from PC using these functions and store them to SDRAM. But can we do this directly? I think we
> may not...
Sure you can do it. Read the file data into an array that is located in SDRAM. You can use the "section" pragma and
linker directives to locate memory in a specific external address range.
> because when i run my code on DSK it gives me FILE NOT FOUND kind of error. So i think i need to
> configure something for this prior.
>
> ## Can u elaborate more clearly as what to do for this error?
No. You have to debug it.
> ## If i am not wrong this is not real time RTDX kind of thing... am i right?
As far as I know, basic C code file I/O functions do not use RTDX. That's one reason why file I/O should be done at
start or end of main(), or when code is "paused", but not during real-time processing.
> ## Is this better option than probe points? In probe point we can have COFF and .DAT files as I\P .... then can i
> convert my files to these formats?
.dat files are Ok, but not COFF files. COFF files are executable DSP code.
Nilesh, I recommend that you do some reading and experimenting and figure this out.
-Jeff
> Jeff Brower wrote:
> Nilesh-
>
>> I want to read from 3 files for my decoder implementation on c6713. These
>> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
>> to write decoded yuv format file.
>> Can anybody suggest me suitable method. I heard of file I\Os. But not used
>> this before. And unaware of weather I can do this from my host pc. Just
>> now started from help. But still confused for best way to achieve this.
>> Needed helpful suggestions kindly..
>
> Suggest:
>
> -use standard C code file I/O functions at start of
> main(), prior to algorithm processing
>
> -read bitstream and config files and store in external
> mem (SDRAM)
>
> -don't use file I/O functions during algorithm
> processing; instead refer to stored data in memory
>
> -use file I/O functions again at end of main() to
> send results back to PC
>
> This creates a simple, easy-to-debug environment for you to get your algorithm
> working. It also keeps the C code easy to read. Overall very appropriate for
> student level. The disadvantage is it's not suitable for real-time, streaming
> implementation. But for real-time video processing, you can't use DSK 6713 anyway so
> that's a different issue.
>
> -Jeff
> I was thinking likewise only. But then certain things are still not clear.
>
> When we say standard C I\O file functions things that come to mind are:
> fopen, fscanf, fputc these are used in my c code.
>
> It is OK to say read from PC using these functions and store them to SDRAM. But can we do this directly? I think we
> may not...
Sure you can do it. Read the file data into an array that is located in SDRAM. You can use the "section" pragma and
linker directives to locate memory in a specific external address range.
> because when i run my code on DSK it gives me FILE NOT FOUND kind of error. So i think i need to
> configure something for this prior.
>
> ## Can u elaborate more clearly as what to do for this error?
No. You have to debug it.
> ## If i am not wrong this is not real time RTDX kind of thing... am i right?
As far as I know, basic C code file I/O functions do not use RTDX. That's one reason why file I/O should be done at
start or end of main(), or when code is "paused", but not during real-time processing.
> ## Is this better option than probe points? In probe point we can have COFF and .DAT files as I\P .... then can i
> convert my files to these formats?
.dat files are Ok, but not COFF files. COFF files are executable DSP code.
Nilesh, I recommend that you do some reading and experimenting and figure this out.
-Jeff
> Jeff Brower wrote:
> Nilesh-
>
>> I want to read from 3 files for my decoder implementation on c6713. These
>> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
>> to write decoded yuv format file.
>> Can anybody suggest me suitable method. I heard of file I\Os. But not used
>> this before. And unaware of weather I can do this from my host pc. Just
>> now started from help. But still confused for best way to achieve this.
>> Needed helpful suggestions kindly..
>
> Suggest:
>
> -use standard C code file I/O functions at start of
> main(), prior to algorithm processing
>
> -read bitstream and config files and store in external
> mem (SDRAM)
>
> -don't use file I/O functions during algorithm
> processing; instead refer to stored data in memory
>
> -use file I/O functions again at end of main() to
> send results back to PC
>
> This creates a simple, easy-to-debug environment for you to get your algorithm
> working. It also keeps the C code easy to read. Overall very appropriate for
> student level. The disadvantage is it's not suitable for real-time, streaming
> implementation. But for real-time video processing, you can't use DSK 6713 anyway so
> that's a different issue.
>
> -Jeff
Reply by ●January 24, 20072007-01-24
hai friends ,
i am also trying something like this i/o operation,
i am trying to read bmp file from file saved in the working folder
i had written fread command in C at the begning of main function
but fread function is not working , nothing is read from the file and
also a message box pop outs and asksing " enter the input" . this is
something strange for me
while building the project using a cmd file it gives error " cannot
open MEMORY.obj "
why this error happens?
On 24/01/07, H.264encoderondm642 wrote:
> Hello Sir,
>
> Thank you for your guidance. I have resolved thi error and everything is
> working perfectly.
>
> But now strange thing i have observed. My cycle count in functional
> simulation mode is
> 63,195,122 while for real time DSK cycle count shown are 609,820,832. I
> could not understand why it is so.
>
> I am writing file each frame as it is decoded to yuv file. And this is
> what i expect to be. Because i want to have another vc application which can
> show decoded yuv frame as it is decoded by DSK. Also my code is outputting
> standard o\p console macroblock no that is decoded.
>
> For your ready ref. my .cmd file is==>
> -c
> -heap 0x1F4FFFF
> -stack 0x2000000
> -l rts6700.lib
> MEMORY
> {
> L2SRAM0: origin = 0x00000000 length = 0x5700
> L2SRAM1: origin = 0x00005700 length = 0x2900 /*L2SRAM0 + L2SRAM1 = 0x8000*/
> CE0: origin = 0x80000000 length = 0xB0000
> CEO: origin = 0x800B0000 length = 0x3F4FFFF
> }
> SECTIONS
> {
> .sysmem > CEO
> .stack > CEO
>
> .far > CE0
> .external > CE0
> .text > CE0
>
> .cinit > L2SRAM0
> .bss > L2SRAM0
> .const > L2SRAM0
> .cio > L2SRAM0
> .switch> L2SRAM0
> .data > L2SRAM0
> .tables> L2SRAM0
> }
>
> My heap and stack are on SDRAM because of large size needed. Suggest some
> performance improving mapping technique.
>
> Regards,
> Nilesh
> Jeff Brower wrote:
> Nilesh-
>
> > I was thinking likewise only. But then certain things are still not clear.
> >
> > When we say standard C I\O file functions things that come to mind are:
> > fopen, fscanf, fputc these are used in my c code.
> >
> > It is OK to say read from PC using these functions and store them to
> SDRAM. But can we do this directly? I think we
> > may not...
>
> Sure you can do it. Read the file data into an array that is located in
> SDRAM. You can use the "section" pragma and
> linker directives to locate memory in a specific external address range.
>
> > because when i run my code on DSK it gives me FILE NOT FOUND kind of
> error. So i think i need to
> > configure something for this prior.
> >
> > ## Can u elaborate more clearly as what to do for this error?
>
> No. You have to debug it.
>
> > ## If i am not wrong this is not real time RTDX kind of thing... am i
> right?
>
> As far as I know, basic C code file I/O functions do not use RTDX. That's
> one reason why file I/O should be done at
> start or end of main(), or when code is "paused", but not during real-time
> processing.
>
> > ## Is this better option than probe points? In probe point we can have
> COFF and .DAT files as I\P .... then can i
> > convert my files to these formats?
>
> .dat files are Ok, but not COFF files. COFF files are executable DSP code.
>
> Nilesh, I recommend that you do some reading and experimenting and figure
> this out.
>
> -Jeff
>
> > Jeff Brower wrote:
> > Nilesh-
> >
> >> I want to read from 3 files for my decoder implementation on c6713. These
> >> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
> >> to write decoded yuv format file.
> >> Can anybody suggest me suitable method. I heard of file I\Os. But not
> used
> >> this before. And unaware of weather I can do this from my host pc. Just
> >> now started from help. But still confused for best way to achieve this.
> >> Needed helpful suggestions kindly..
> >
> > Suggest:
> >
> > -use standard C code file I/O functions at start of
> > main(), prior to algorithm processing
> >
> > -read bitstream and config files and store in external
> > mem (SDRAM)
> >
> > -don't use file I/O functions during algorithm
> > processing; instead refer to stored data in memory
> >
> > -use file I/O functions again at end of main() to
> > send results back to PC
> >
> > This creates a simple, easy-to-debug environment for you to get your
> algorithm
> > working. It also keeps the C code easy to read. Overall very appropriate
> for
> > student level. The disadvantage is it's not suitable for real-time,
> streaming
> > implementation. But for real-time video processing, you can't use DSK 6713
> anyway so
> > that's a different issue.
> >
> > -Jeff
> ---------------------------------
> We won't tell. Get more on shows you hate to love
> (and love to hate): Yahoo! TV's Guilty Pleasures list.
>
--
regards,
Joshy m. Jose
kerala , India
91-9447976001
i am also trying something like this i/o operation,
i am trying to read bmp file from file saved in the working folder
i had written fread command in C at the begning of main function
but fread function is not working , nothing is read from the file and
also a message box pop outs and asksing " enter the input" . this is
something strange for me
while building the project using a cmd file it gives error " cannot
open MEMORY.obj "
why this error happens?
On 24/01/07, H.264encoderondm642 wrote:
> Hello Sir,
>
> Thank you for your guidance. I have resolved thi error and everything is
> working perfectly.
>
> But now strange thing i have observed. My cycle count in functional
> simulation mode is
> 63,195,122 while for real time DSK cycle count shown are 609,820,832. I
> could not understand why it is so.
>
> I am writing file each frame as it is decoded to yuv file. And this is
> what i expect to be. Because i want to have another vc application which can
> show decoded yuv frame as it is decoded by DSK. Also my code is outputting
> standard o\p console macroblock no that is decoded.
>
> For your ready ref. my .cmd file is==>
> -c
> -heap 0x1F4FFFF
> -stack 0x2000000
> -l rts6700.lib
> MEMORY
> {
> L2SRAM0: origin = 0x00000000 length = 0x5700
> L2SRAM1: origin = 0x00005700 length = 0x2900 /*L2SRAM0 + L2SRAM1 = 0x8000*/
> CE0: origin = 0x80000000 length = 0xB0000
> CEO: origin = 0x800B0000 length = 0x3F4FFFF
> }
> SECTIONS
> {
> .sysmem > CEO
> .stack > CEO
>
> .far > CE0
> .external > CE0
> .text > CE0
>
> .cinit > L2SRAM0
> .bss > L2SRAM0
> .const > L2SRAM0
> .cio > L2SRAM0
> .switch> L2SRAM0
> .data > L2SRAM0
> .tables> L2SRAM0
> }
>
> My heap and stack are on SDRAM because of large size needed. Suggest some
> performance improving mapping technique.
>
> Regards,
> Nilesh
> Jeff Brower wrote:
> Nilesh-
>
> > I was thinking likewise only. But then certain things are still not clear.
> >
> > When we say standard C I\O file functions things that come to mind are:
> > fopen, fscanf, fputc these are used in my c code.
> >
> > It is OK to say read from PC using these functions and store them to
> SDRAM. But can we do this directly? I think we
> > may not...
>
> Sure you can do it. Read the file data into an array that is located in
> SDRAM. You can use the "section" pragma and
> linker directives to locate memory in a specific external address range.
>
> > because when i run my code on DSK it gives me FILE NOT FOUND kind of
> error. So i think i need to
> > configure something for this prior.
> >
> > ## Can u elaborate more clearly as what to do for this error?
>
> No. You have to debug it.
>
> > ## If i am not wrong this is not real time RTDX kind of thing... am i
> right?
>
> As far as I know, basic C code file I/O functions do not use RTDX. That's
> one reason why file I/O should be done at
> start or end of main(), or when code is "paused", but not during real-time
> processing.
>
> > ## Is this better option than probe points? In probe point we can have
> COFF and .DAT files as I\P .... then can i
> > convert my files to these formats?
>
> .dat files are Ok, but not COFF files. COFF files are executable DSP code.
>
> Nilesh, I recommend that you do some reading and experimenting and figure
> this out.
>
> -Jeff
>
> > Jeff Brower wrote:
> > Nilesh-
> >
> >> I want to read from 3 files for my decoder implementation on c6713. These
> >> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
> >> to write decoded yuv format file.
> >> Can anybody suggest me suitable method. I heard of file I\Os. But not
> used
> >> this before. And unaware of weather I can do this from my host pc. Just
> >> now started from help. But still confused for best way to achieve this.
> >> Needed helpful suggestions kindly..
> >
> > Suggest:
> >
> > -use standard C code file I/O functions at start of
> > main(), prior to algorithm processing
> >
> > -read bitstream and config files and store in external
> > mem (SDRAM)
> >
> > -don't use file I/O functions during algorithm
> > processing; instead refer to stored data in memory
> >
> > -use file I/O functions again at end of main() to
> > send results back to PC
> >
> > This creates a simple, easy-to-debug environment for you to get your
> algorithm
> > working. It also keeps the C code easy to read. Overall very appropriate
> for
> > student level. The disadvantage is it's not suitable for real-time,
> streaming
> > implementation. But for real-time video processing, you can't use DSK 6713
> anyway so
> > that's a different issue.
> >
> > -Jeff
> ---------------------------------
> We won't tell. Get more on shows you hate to love
> (and love to hate): Yahoo! TV's Guilty Pleasures list.
>
--
regards,
Joshy m. Jose
kerala , India
91-9447976001
Reply by ●January 29, 20072007-01-29
Nilesh-
> Thank you for your guidance. I have resolved thi error and everything is working perfectly.
Ok that sounds like good progress. So now you know something about DSP coding and CCS!
> But now strange thing i have observed. My cycle count in functional simulation mode is
> 63,195,122 while for real time DSK cycle count shown are 609,820,832. I could not understand why it is so.
>
> I am writing file each frame as it is decoded to yuv file. And this is what i expect to be. Because i want to have
> another vc application which can show decoded yuv frame as it is decoded by DSK. Also my code is outputting standard
> o\p console macroblock no that is decoded.
Does your per-frame cycle count include file I/O? If so then DSK version will slower due to DSK 6713 JTAG + USB
communication required for the file I/O. Suggest that your measurement not include file I/O.
If the DSK version is still slower, then I suggest to carefully compare L2 cache and external SDRAM settings. For
example, possibly you have cache enabled only in your simulation. Do you have L2 cache enabled in your DSK project?
If so how much?
-Jeff
> For your ready ref. my .cmd file is==>
> -c
> -heap 0x1F4FFFF
> -stack 0x2000000
> -l rts6700.lib
> MEMORY
> {
> L2SRAM0: origin = 0x00000000 length = 0x5700
> L2SRAM1: origin = 0x00005700 length = 0x2900 /*L2SRAM0 + L2SRAM1 = 0x8000*/
> CE0: origin = 0x80000000 length = 0xB0000
> CEO: origin = 0x800B0000 length = 0x3F4FFFF
> }
> SECTIONS
> {
> .sysmem > CEO
> .stack > CEO
>
> .far > CE0
> .external > CE0
> .text > CE0
>
> .cinit > L2SRAM0
> .bss > L2SRAM0
> .const > L2SRAM0
> .cio > L2SRAM0
> .switch> L2SRAM0
> .data > L2SRAM0
> .tables> L2SRAM0
> }
>
> My heap and stack are on SDRAM because of large size needed. Suggest some performance improving mapping technique.
>
> Regards,
> Nilesh
> Jeff Brower wrote:
> Nilesh-
>
>> I was thinking likewise only. But then certain things are still not clear.
>>
>> When we say standard C I\O file functions things that come to mind are:
>> fopen, fscanf, fputc these are used in my c code.
>>
>> It is OK to say read from PC using these functions and store them to SDRAM. But can we do this directly? I think we
>> may not...
>
> Sure you can do it. Read the file data into an array that is located in SDRAM. You can use the "section" pragma and
> linker directives to locate memory in a specific external address range.
>
>> because when i run my code on DSK it gives me FILE NOT FOUND kind of error. So i think i need to
>> configure something for this prior.
>>
>> ## Can u elaborate more clearly as what to do for this error?
>
> No. You have to debug it.
>
>> ## If i am not wrong this is not real time RTDX kind of thing... am i right?
>
> As far as I know, basic C code file I/O functions do not use RTDX. That's one reason why file I/O should be done at
> start or end of main(), or when code is "paused", but not during real-time processing.
>
>> ## Is this better option than probe points? In probe point we can have COFF and .DAT files as I\P .... then can i
>> convert my files to these formats?
>
> .dat files are Ok, but not COFF files. COFF files are executable DSP code.
>
> Nilesh, I recommend that you do some reading and experimenting and figure this out.
>
> -Jeff
>
>> Jeff Brower wrote:
>> Nilesh-
>>
>>> I want to read from 3 files for my decoder implementation on c6713. These
>>> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
>>> to write decoded yuv format file.
>>> Can anybody suggest me suitable method. I heard of file I\Os. But not used
>>> this before. And unaware of weather I can do this from my host pc. Just
>>> now started from help. But still confused for best way to achieve this.
>>> Needed helpful suggestions kindly..
>>
>> Suggest:
>>
>> -use standard C code file I/O functions at start of
>> main(), prior to algorithm processing
>>
>> -read bitstream and config files and store in external
>> mem (SDRAM)
>>
>> -don't use file I/O functions during algorithm
>> processing; instead refer to stored data in memory
>>
>> -use file I/O functions again at end of main() to
>> send results back to PC
>>
>> This creates a simple, easy-to-debug environment for you to get your algorithm
>> working. It also keeps the C code easy to read. Overall very appropriate for
>> student level. The disadvantage is it's not suitable for real-time, streaming
>> implementation. But for real-time video processing, you can't use DSK 6713 anyway so
>> that's a different issue.
>>
>> -Jeff
>
> Thank you for your guidance. I have resolved thi error and everything is working perfectly.
Ok that sounds like good progress. So now you know something about DSP coding and CCS!
> But now strange thing i have observed. My cycle count in functional simulation mode is
> 63,195,122 while for real time DSK cycle count shown are 609,820,832. I could not understand why it is so.
>
> I am writing file each frame as it is decoded to yuv file. And this is what i expect to be. Because i want to have
> another vc application which can show decoded yuv frame as it is decoded by DSK. Also my code is outputting standard
> o\p console macroblock no that is decoded.
Does your per-frame cycle count include file I/O? If so then DSK version will slower due to DSK 6713 JTAG + USB
communication required for the file I/O. Suggest that your measurement not include file I/O.
If the DSK version is still slower, then I suggest to carefully compare L2 cache and external SDRAM settings. For
example, possibly you have cache enabled only in your simulation. Do you have L2 cache enabled in your DSK project?
If so how much?
-Jeff
> For your ready ref. my .cmd file is==>
> -c
> -heap 0x1F4FFFF
> -stack 0x2000000
> -l rts6700.lib
> MEMORY
> {
> L2SRAM0: origin = 0x00000000 length = 0x5700
> L2SRAM1: origin = 0x00005700 length = 0x2900 /*L2SRAM0 + L2SRAM1 = 0x8000*/
> CE0: origin = 0x80000000 length = 0xB0000
> CEO: origin = 0x800B0000 length = 0x3F4FFFF
> }
> SECTIONS
> {
> .sysmem > CEO
> .stack > CEO
>
> .far > CE0
> .external > CE0
> .text > CE0
>
> .cinit > L2SRAM0
> .bss > L2SRAM0
> .const > L2SRAM0
> .cio > L2SRAM0
> .switch> L2SRAM0
> .data > L2SRAM0
> .tables> L2SRAM0
> }
>
> My heap and stack are on SDRAM because of large size needed. Suggest some performance improving mapping technique.
>
> Regards,
> Nilesh
> Jeff Brower wrote:
> Nilesh-
>
>> I was thinking likewise only. But then certain things are still not clear.
>>
>> When we say standard C I\O file functions things that come to mind are:
>> fopen, fscanf, fputc these are used in my c code.
>>
>> It is OK to say read from PC using these functions and store them to SDRAM. But can we do this directly? I think we
>> may not...
>
> Sure you can do it. Read the file data into an array that is located in SDRAM. You can use the "section" pragma and
> linker directives to locate memory in a specific external address range.
>
>> because when i run my code on DSK it gives me FILE NOT FOUND kind of error. So i think i need to
>> configure something for this prior.
>>
>> ## Can u elaborate more clearly as what to do for this error?
>
> No. You have to debug it.
>
>> ## If i am not wrong this is not real time RTDX kind of thing... am i right?
>
> As far as I know, basic C code file I/O functions do not use RTDX. That's one reason why file I/O should be done at
> start or end of main(), or when code is "paused", but not during real-time processing.
>
>> ## Is this better option than probe points? In probe point we can have COFF and .DAT files as I\P .... then can i
>> convert my files to these formats?
>
> .dat files are Ok, but not COFF files. COFF files are executable DSP code.
>
> Nilesh, I recommend that you do some reading and experimenting and figure this out.
>
> -Jeff
>
>> Jeff Brower wrote:
>> Nilesh-
>>
>>> I want to read from 3 files for my decoder implementation on c6713. These
>>> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
>>> to write decoded yuv format file.
>>> Can anybody suggest me suitable method. I heard of file I\Os. But not used
>>> this before. And unaware of weather I can do this from my host pc. Just
>>> now started from help. But still confused for best way to achieve this.
>>> Needed helpful suggestions kindly..
>>
>> Suggest:
>>
>> -use standard C code file I/O functions at start of
>> main(), prior to algorithm processing
>>
>> -read bitstream and config files and store in external
>> mem (SDRAM)
>>
>> -don't use file I/O functions during algorithm
>> processing; instead refer to stored data in memory
>>
>> -use file I/O functions again at end of main() to
>> send results back to PC
>>
>> This creates a simple, easy-to-debug environment for you to get your algorithm
>> working. It also keeps the C code easy to read. Overall very appropriate for
>> student level. The disadvantage is it's not suitable for real-time, streaming
>> implementation. But for real-time video processing, you can't use DSK 6713 anyway so
>> that's a different issue.
>>
>> -Jeff
>
Reply by ●January 29, 20072007-01-29
Hello Sir,
I will find out cause as you told.
But I could not understand L2 cache enabling in simuator and in project is different matter. I have used following lines of code in my main file beginning:
CSL_init();
CACHE_enableCaching(CACHE_CE00);
CACHE_setL2Mode(CACHE_64KCACHE);
Do i need to configure something else?
Please Guide...
Regards And Thanks.
Nilesh
Jeff Brower wrote: Nilesh-
> Thank you for your guidance. I have resolved thi error and everything is working perfectly.
Ok that sounds like good progress. So now you know something about DSP coding and CCS!
> But now strange thing i have observed. My cycle count in functional simulation mode is
> 63,195,122 while for real time DSK cycle count shown are 609,820,832. I could not understand why it is so.
>
> I am writing file each frame as it is decoded to yuv file. And this is what i expect to be. Because i want to have
> another vc application which can show decoded yuv frame as it is decoded by DSK. Also my code is outputting standard
> o\p console macroblock no that is decoded.
Does your per-frame cycle count include file I/O? If so then DSK version will slower due to DSK 6713 JTAG + USB
communication required for the file I/O. Suggest that your measurement not include file I/O.
If the DSK version is still slower, then I suggest to carefully compare L2 cache and external SDRAM settings. For
example, possibly you have cache enabled only in your simulation. Do you have L2 cache enabled in your DSK project?
If so how much?
-Jeff
> For your ready ref. my .cmd file is==>
> -c
> -heap 0x1F4FFFF
> -stack 0x2000000
> -l rts6700.lib
> MEMORY
> {
> L2SRAM0: origin = 0x00000000 length = 0x5700
> L2SRAM1: origin = 0x00005700 length = 0x2900 /*L2SRAM0 + L2SRAM1 = 0x8000*/
> CE0: origin = 0x80000000 length = 0xB0000
> CEO: origin = 0x800B0000 length = 0x3F4FFFF
> }
> SECTIONS
> {
> .sysmem > CEO
> .stack > CEO
>
> .far > CE0
> .external > CE0
> .text > CE0
>
> .cinit > L2SRAM0
> .bss > L2SRAM0
> .const > L2SRAM0
> .cio > L2SRAM0
> .switch> L2SRAM0
> .data > L2SRAM0
> .tables> L2SRAM0
> }
>
> My heap and stack are on SDRAM because of large size needed. Suggest some performance improving mapping technique.
>
> Regards,
> Nilesh
> Jeff Brower wrote:
> Nilesh-
>
>> I was thinking likewise only. But then certain things are still not clear.
>>
>> When we say standard C I\O file functions things that come to mind are:
>> fopen, fscanf, fputc these are used in my c code.
>>
>> It is OK to say read from PC using these functions and store them to SDRAM. But can we do this directly? I think we
>> may not...
>
> Sure you can do it. Read the file data into an array that is located in SDRAM. You can use the "section" pragma and
> linker directives to locate memory in a specific external address range.
>
>> because when i run my code on DSK it gives me FILE NOT FOUND kind of error. So i think i need to
>> configure something for this prior.
>>
>> ## Can u elaborate more clearly as what to do for this error?
>
> No. You have to debug it.
>
>> ## If i am not wrong this is not real time RTDX kind of thing... am i right?
>
> As far as I know, basic C code file I/O functions do not use RTDX. That's one reason why file I/O should be done at
> start or end of main(), or when code is "paused", but not during real-time processing.
>
>> ## Is this better option than probe points? In probe point we can have COFF and .DAT files as I\P .... then can i
>> convert my files to these formats?
>
> .dat files are Ok, but not COFF files. COFF files are executable DSP code.
>
> Nilesh, I recommend that you do some reading and experimenting and figure this out.
>
> -Jeff
>
>> Jeff Brower wrote:
>> Nilesh-
>>
>>> I want to read from 3 files for my decoder implementation on c6713. These
>>> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
>>> to write decoded yuv format file.
>>> Can anybody suggest me suitable method. I heard of file I\Os. But not used
>>> this before. And unaware of weather I can do this from my host pc. Just
>>> now started from help. But still confused for best way to achieve this.
>>> Needed helpful suggestions kindly..
>>
>> Suggest:
>>
>> -use standard C code file I/O functions at start of
>> main(), prior to algorithm processing
>>
>> -read bitstream and config files and store in external
>> mem (SDRAM)
>>
>> -don't use file I/O functions during algorithm
>> processing; instead refer to stored data in memory
>>
>> -use file I/O functions again at end of main() to
>> send results back to PC
>>
>> This creates a simple, easy-to-debug environment for you to get your algorithm
>> working. It also keeps the C code easy to read. Overall very appropriate for
>> student level. The disadvantage is it's not suitable for real-time, streaming
>> implementation. But for real-time video processing, you can't use DSK 6713 anyway so
>> that's a different issue.
>>
>> -Jeff
>
I will find out cause as you told.
But I could not understand L2 cache enabling in simuator and in project is different matter. I have used following lines of code in my main file beginning:
CSL_init();
CACHE_enableCaching(CACHE_CE00);
CACHE_setL2Mode(CACHE_64KCACHE);
Do i need to configure something else?
Please Guide...
Regards And Thanks.
Nilesh
Jeff Brower wrote: Nilesh-
> Thank you for your guidance. I have resolved thi error and everything is working perfectly.
Ok that sounds like good progress. So now you know something about DSP coding and CCS!
> But now strange thing i have observed. My cycle count in functional simulation mode is
> 63,195,122 while for real time DSK cycle count shown are 609,820,832. I could not understand why it is so.
>
> I am writing file each frame as it is decoded to yuv file. And this is what i expect to be. Because i want to have
> another vc application which can show decoded yuv frame as it is decoded by DSK. Also my code is outputting standard
> o\p console macroblock no that is decoded.
Does your per-frame cycle count include file I/O? If so then DSK version will slower due to DSK 6713 JTAG + USB
communication required for the file I/O. Suggest that your measurement not include file I/O.
If the DSK version is still slower, then I suggest to carefully compare L2 cache and external SDRAM settings. For
example, possibly you have cache enabled only in your simulation. Do you have L2 cache enabled in your DSK project?
If so how much?
-Jeff
> For your ready ref. my .cmd file is==>
> -c
> -heap 0x1F4FFFF
> -stack 0x2000000
> -l rts6700.lib
> MEMORY
> {
> L2SRAM0: origin = 0x00000000 length = 0x5700
> L2SRAM1: origin = 0x00005700 length = 0x2900 /*L2SRAM0 + L2SRAM1 = 0x8000*/
> CE0: origin = 0x80000000 length = 0xB0000
> CEO: origin = 0x800B0000 length = 0x3F4FFFF
> }
> SECTIONS
> {
> .sysmem > CEO
> .stack > CEO
>
> .far > CE0
> .external > CE0
> .text > CE0
>
> .cinit > L2SRAM0
> .bss > L2SRAM0
> .const > L2SRAM0
> .cio > L2SRAM0
> .switch> L2SRAM0
> .data > L2SRAM0
> .tables> L2SRAM0
> }
>
> My heap and stack are on SDRAM because of large size needed. Suggest some performance improving mapping technique.
>
> Regards,
> Nilesh
> Jeff Brower wrote:
> Nilesh-
>
>> I was thinking likewise only. But then certain things are still not clear.
>>
>> When we say standard C I\O file functions things that come to mind are:
>> fopen, fscanf, fputc these are used in my c code.
>>
>> It is OK to say read from PC using these functions and store them to SDRAM. But can we do this directly? I think we
>> may not...
>
> Sure you can do it. Read the file data into an array that is located in SDRAM. You can use the "section" pragma and
> linker directives to locate memory in a specific external address range.
>
>> because when i run my code on DSK it gives me FILE NOT FOUND kind of error. So i think i need to
>> configure something for this prior.
>>
>> ## Can u elaborate more clearly as what to do for this error?
>
> No. You have to debug it.
>
>> ## If i am not wrong this is not real time RTDX kind of thing... am i right?
>
> As far as I know, basic C code file I/O functions do not use RTDX. That's one reason why file I/O should be done at
> start or end of main(), or when code is "paused", but not during real-time processing.
>
>> ## Is this better option than probe points? In probe point we can have COFF and .DAT files as I\P .... then can i
>> convert my files to these formats?
>
> .dat files are Ok, but not COFF files. COFF files are executable DSP code.
>
> Nilesh, I recommend that you do some reading and experimenting and figure this out.
>
> -Jeff
>
>> Jeff Brower wrote:
>> Nilesh-
>>
>>> I want to read from 3 files for my decoder implementation on c6713. These
>>> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
>>> to write decoded yuv format file.
>>> Can anybody suggest me suitable method. I heard of file I\Os. But not used
>>> this before. And unaware of weather I can do this from my host pc. Just
>>> now started from help. But still confused for best way to achieve this.
>>> Needed helpful suggestions kindly..
>>
>> Suggest:
>>
>> -use standard C code file I/O functions at start of
>> main(), prior to algorithm processing
>>
>> -read bitstream and config files and store in external
>> mem (SDRAM)
>>
>> -don't use file I/O functions during algorithm
>> processing; instead refer to stored data in memory
>>
>> -use file I/O functions again at end of main() to
>> send results back to PC
>>
>> This creates a simple, easy-to-debug environment for you to get your algorithm
>> working. It also keeps the C code easy to read. Overall very appropriate for
>> student level. The disadvantage is it's not suitable for real-time, streaming
>> implementation. But for real-time video processing, you can't use DSK 6713 anyway so
>> that's a different issue.
>>
>> -Jeff
>
Reply by ●January 29, 20072007-01-29
Nilesh-
> I will find out cause as you told.
> But I could not understand L2 cache enabling in simuator and in project is different matter. I have used following lines of code in my main file beginning:
>
> CSL_init();
> CACHE_enableCaching(CACHE_CE00);
> CACHE_setL2Mode(CACHE_64KCACHE);
If you run this on both projects then I suppose it should be Ok. I don't know enough
about simulator to recommend additional settings you should check; I prefer to use
real-time measurement methods with the DSK board as I typically need actual I/O to be
working.
-Jeff
> Jeff Brower wrote: Nilesh-
>
> > Thank you for your guidance. I have resolved thi error and everything is working perfectly.
>
> Ok that sounds like good progress. So now you know something about DSP coding and CCS!
>
> > But now strange thing i have observed. My cycle count in functional simulation mode is
> > 63,195,122 while for real time DSK cycle count shown are 609,820,832. I could not understand why it is so.
> >
> > I am writing file each frame as it is decoded to yuv file. And this is what i expect to be. Because i want to have
> > another vc application which can show decoded yuv frame as it is decoded by DSK. Also my code is outputting standard
> > o\p console macroblock no that is decoded.
>
> Does your per-frame cycle count include file I/O? If so then DSK version will slower due to DSK 6713 JTAG + USB
> communication required for the file I/O. Suggest that your measurement not include file I/O.
>
> If the DSK version is still slower, then I suggest to carefully compare L2 cache and external SDRAM settings. For
> example, possibly you have cache enabled only in your simulation. Do you have L2 cache enabled in your DSK project?
> If so how much?
>
> -Jeff
>
> > For your ready ref. my .cmd file is==>
> > -c
> > -heap 0x1F4FFFF
> > -stack 0x2000000
> > -l rts6700.lib
> > MEMORY
> > {
> > L2SRAM0: origin = 0x00000000 length = 0x5700
> > L2SRAM1: origin = 0x00005700 length = 0x2900 /*L2SRAM0 + L2SRAM1 = 0x8000*/
> > CE0: origin = 0x80000000 length = 0xB0000
> > CEO: origin = 0x800B0000 length = 0x3F4FFFF
> > }
> > SECTIONS
> > {
> > .sysmem > CEO
> > .stack > CEO
> >
> > .far > CE0
> > .external > CE0
> > .text > CE0
> >
> > .cinit > L2SRAM0
> > .bss > L2SRAM0
> > .const > L2SRAM0
> > .cio > L2SRAM0
> > .switch> L2SRAM0
> > .data > L2SRAM0
> > .tables> L2SRAM0
> > }
> >
> > My heap and stack are on SDRAM because of large size needed. Suggest some performance improving mapping technique.
> >
> > Regards,
> > Nilesh
> > Jeff Brower wrote:
> > Nilesh-
> >
> >> I was thinking likewise only. But then certain things are still not clear.
> >>
> >> When we say standard C I\O file functions things that come to mind are:
> >> fopen, fscanf, fputc these are used in my c code.
> >>
> >> It is OK to say read from PC using these functions and store them to SDRAM. But can we do this directly? I think we
> >> may not...
> >
> > Sure you can do it. Read the file data into an array that is located in SDRAM. You can use the "section" pragma and
> > linker directives to locate memory in a specific external address range.
> >
> >> because when i run my code on DSK it gives me FILE NOT FOUND kind of error. So i think i need to
> >> configure something for this prior.
> >>
> >> ## Can u elaborate more clearly as what to do for this error?
> >
> > No. You have to debug it.
> >
> >> ## If i am not wrong this is not real time RTDX kind of thing... am i right?
> >
> > As far as I know, basic C code file I/O functions do not use RTDX. That's one reason why file I/O should be done at
> > start or end of main(), or when code is "paused", but not during real-time processing.
> >
> >> ## Is this better option than probe points? In probe point we can have COFF and .DAT files as I\P .... then can i
> >> convert my files to these formats?
> >
> > .dat files are Ok, but not COFF files. COFF files are executable DSP code.
> >
> > Nilesh, I recommend that you do some reading and experimenting and figure this out.
> >
> > -Jeff
> >
> >> Jeff Brower wrote:
> >> Nilesh-
> >>
> >>> I want to read from 3 files for my decoder implementation on c6713. These
> >>> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
> >>> to write decoded yuv format file.
> >>> Can anybody suggest me suitable method. I heard of file I\Os. But not used
> >>> this before. And unaware of weather I can do this from my host pc. Just
> >>> now started from help. But still confused for best way to achieve this.
> >>> Needed helpful suggestions kindly..
> >>
> >> Suggest:
> >>
> >> -use standard C code file I/O functions at start of
> >> main(), prior to algorithm processing
> >>
> >> -read bitstream and config files and store in external
> >> mem (SDRAM)
> >>
> >> -don't use file I/O functions during algorithm
> >> processing; instead refer to stored data in memory
> >>
> >> -use file I/O functions again at end of main() to
> >> send results back to PC
> >>
> >> This creates a simple, easy-to-debug environment for you to get your algorithm
> >> working. It also keeps the C code easy to read. Overall very appropriate for
> >> student level. The disadvantage is it's not suitable for real-time, streaming
> >> implementation. But for real-time video processing, you can't use DSK 6713 anyway so
> >> that's a different issue.
> >>
> >> -Jeff
>
> I will find out cause as you told.
> But I could not understand L2 cache enabling in simuator and in project is different matter. I have used following lines of code in my main file beginning:
>
> CSL_init();
> CACHE_enableCaching(CACHE_CE00);
> CACHE_setL2Mode(CACHE_64KCACHE);
If you run this on both projects then I suppose it should be Ok. I don't know enough
about simulator to recommend additional settings you should check; I prefer to use
real-time measurement methods with the DSK board as I typically need actual I/O to be
working.
-Jeff
> Jeff Brower wrote: Nilesh-
>
> > Thank you for your guidance. I have resolved thi error and everything is working perfectly.
>
> Ok that sounds like good progress. So now you know something about DSP coding and CCS!
>
> > But now strange thing i have observed. My cycle count in functional simulation mode is
> > 63,195,122 while for real time DSK cycle count shown are 609,820,832. I could not understand why it is so.
> >
> > I am writing file each frame as it is decoded to yuv file. And this is what i expect to be. Because i want to have
> > another vc application which can show decoded yuv frame as it is decoded by DSK. Also my code is outputting standard
> > o\p console macroblock no that is decoded.
>
> Does your per-frame cycle count include file I/O? If so then DSK version will slower due to DSK 6713 JTAG + USB
> communication required for the file I/O. Suggest that your measurement not include file I/O.
>
> If the DSK version is still slower, then I suggest to carefully compare L2 cache and external SDRAM settings. For
> example, possibly you have cache enabled only in your simulation. Do you have L2 cache enabled in your DSK project?
> If so how much?
>
> -Jeff
>
> > For your ready ref. my .cmd file is==>
> > -c
> > -heap 0x1F4FFFF
> > -stack 0x2000000
> > -l rts6700.lib
> > MEMORY
> > {
> > L2SRAM0: origin = 0x00000000 length = 0x5700
> > L2SRAM1: origin = 0x00005700 length = 0x2900 /*L2SRAM0 + L2SRAM1 = 0x8000*/
> > CE0: origin = 0x80000000 length = 0xB0000
> > CEO: origin = 0x800B0000 length = 0x3F4FFFF
> > }
> > SECTIONS
> > {
> > .sysmem > CEO
> > .stack > CEO
> >
> > .far > CE0
> > .external > CE0
> > .text > CE0
> >
> > .cinit > L2SRAM0
> > .bss > L2SRAM0
> > .const > L2SRAM0
> > .cio > L2SRAM0
> > .switch> L2SRAM0
> > .data > L2SRAM0
> > .tables> L2SRAM0
> > }
> >
> > My heap and stack are on SDRAM because of large size needed. Suggest some performance improving mapping technique.
> >
> > Regards,
> > Nilesh
> > Jeff Brower wrote:
> > Nilesh-
> >
> >> I was thinking likewise only. But then certain things are still not clear.
> >>
> >> When we say standard C I\O file functions things that come to mind are:
> >> fopen, fscanf, fputc these are used in my c code.
> >>
> >> It is OK to say read from PC using these functions and store them to SDRAM. But can we do this directly? I think we
> >> may not...
> >
> > Sure you can do it. Read the file data into an array that is located in SDRAM. You can use the "section" pragma and
> > linker directives to locate memory in a specific external address range.
> >
> >> because when i run my code on DSK it gives me FILE NOT FOUND kind of error. So i think i need to
> >> configure something for this prior.
> >>
> >> ## Can u elaborate more clearly as what to do for this error?
> >
> > No. You have to debug it.
> >
> >> ## If i am not wrong this is not real time RTDX kind of thing... am i right?
> >
> > As far as I know, basic C code file I/O functions do not use RTDX. That's one reason why file I/O should be done at
> > start or end of main(), or when code is "paused", but not during real-time processing.
> >
> >> ## Is this better option than probe points? In probe point we can have COFF and .DAT files as I\P .... then can i
> >> convert my files to these formats?
> >
> > .dat files are Ok, but not COFF files. COFF files are executable DSP code.
> >
> > Nilesh, I recommend that you do some reading and experimenting and figure this out.
> >
> > -Jeff
> >
> >> Jeff Brower wrote:
> >> Nilesh-
> >>
> >>> I want to read from 3 files for my decoder implementation on c6713. These
> >>> file foramts are in .cfg and .26l bitstream and .cfg formats. Also I want
> >>> to write decoded yuv format file.
> >>> Can anybody suggest me suitable method. I heard of file I\Os. But not used
> >>> this before. And unaware of weather I can do this from my host pc. Just
> >>> now started from help. But still confused for best way to achieve this.
> >>> Needed helpful suggestions kindly..
> >>
> >> Suggest:
> >>
> >> -use standard C code file I/O functions at start of
> >> main(), prior to algorithm processing
> >>
> >> -read bitstream and config files and store in external
> >> mem (SDRAM)
> >>
> >> -don't use file I/O functions during algorithm
> >> processing; instead refer to stored data in memory
> >>
> >> -use file I/O functions again at end of main() to
> >> send results back to PC
> >>
> >> This creates a simple, easy-to-debug environment for you to get your algorithm
> >> working. It also keeps the C code easy to read. Overall very appropriate for
> >> student level. The disadvantage is it's not suitable for real-time, streaming
> >> implementation. But for real-time video processing, you can't use DSK 6713 anyway so
> >> that's a different issue.
> >>
> >> -Jeff
>
