Forums

IO routines (fread/fwrite) with CCS--C55x

Started by Bawr December 16, 2003
Hi,
    I found that file IO routines (fread and fwrite) don't work properly on
CCS 2.12 on the C55x platform. It seems to be reading and writing byte by
byte even if you specify the right size.
Has anybody else run into the same pbm? If so, is there any patch to get
around this quickly?
TIA.
LB


>>>>> "Bawr" == Bawr <lba@step.polymtl.ca> writes:
Bawr> Hi, Bawr> I found that file IO routines (fread and fwrite) don't work properly on Bawr> CCS 2.12 on the C55x platform. It seems to be reading and writing byte by Bawr> byte even if you specify the right size. Bawr> Has anybody else run into the same pbm? If so, is there any patch to get Bawr> around this quickly? Yes, I've run into that problem. I don't know of any patch. I just gave up and used probe points. Which was actually good because probe points run MUCH faster because the DSP isn't running fread/fwrite code. Ray
I agree, it runs much FASTER with probe points but I'd like to keep my code
portable as much as possible. I am running the same C code on different
platforms at the same time. Using probe points will make my code platform
depend. I am running out of time to write a fix.  There must be a patch
somewhere unless TI really wants us to use those probe points but I see no
reason why

ThanX 4 u help.

LB

"Raymond Toy" <toy@rtp.ericsson.se> wrote in message
news:4nznds4j7t.fsf@edgedsp4.rtp.ericsson.se...
> >>>>> "Bawr" == Bawr <lba@step.polymtl.ca> writes: > > Bawr> Hi, > Bawr> I found that file IO routines (fread and fwrite) don't work
properly on
> Bawr> CCS 2.12 on the C55x platform. It seems to be reading and
writing byte by
> Bawr> byte even if you specify the right size. > Bawr> Has anybody else run into the same pbm? If so, is there any
patch to get
> Bawr> around this quickly? > > Yes, I've run into that problem. I don't know of any patch. I just > gave up and used probe points. Which was actually good because probe > points run MUCH faster because the DSP isn't running fread/fwrite > code. > > Ray
Here is a document that addresses the pbm.
http://focus.ti.com/lit/an/spra757/spra757.pdf


"Bawr" <lba@step.polymtl.ca> wrote in message
news:brnnof$ic1$1@zcars0v6.ca.nortel.com...
> Hi, > I found that file IO routines (fread and fwrite) don't work properly
on
> CCS 2.12 on the C55x platform. It seems to be reading and writing byte by > byte even if you specify the right size. > Has anybody else run into the same pbm? If so, is there any patch to get > around this quickly? > TIA. > LB > >
Raymond Toy wrote:

>>>>>>"Bawr" == Bawr <lba@step.polymtl.ca> writes: > > > Bawr> Hi, > Bawr> I found that file IO routines (fread and fwrite) don't work properly on > Bawr> CCS 2.12 on the C55x platform. It seems to be reading and writing byte by > Bawr> byte even if you specify the right size. > Bawr> Has anybody else run into the same pbm? If so, is there any patch to get > Bawr> around this quickly? > > Yes, I've run into that problem. I don't know of any patch. I just > gave up and used probe points. Which was actually good because probe > points run MUCH faster because the DSP isn't running fread/fwrite > code.
I have not noticed a difference, and it sure is convenient to be able to load the code and run without having to pull up several menus and fill out parameters (yes, you could write a gel file, but that's work too), especially when you have to restart CCS often. -- % Randy Yates % "...the answer lies within your soul %% Fuquay-Varina, NC % 'cause no one knows which side %%% 919-577-9882 % the coin will fall." %%%% <yates@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO http://home.earthlink.net/~yatescr
Bawr wrote:

> Here is a document that addresses the pbm. > http://focus.ti.com/lit/an/spra757/spra757.pdf
It is interesting to note the following statement in this reference: The alternative option, which is not implemented in the RTS library, is to split each target char into multiple host bytes (when writing from target to host), and pack multiple host bytes into each target char (when reading from host to target). This has the advantage that the data is preserved intact without truncation. This advantage is evident for programs that run only on the target and need to read data files written by other programs that run only on the target. In the example above, the result file would contain the 4 bytes (0xAA, 0xBB, 0xCC, 0xDD). *The primary disadvantage of this approach is that the number of bytes in the file does not equal the number of chars written.* As far as I know, the C standard never did require a "char" to be 1 byte. To assume such a thing is a fairly serious error in the interpretation of the operation of the C language. Thus their "primary disadvantage" is no disadvantage whatsoever. -- % Randy Yates % "...the answer lies within your soul %% Fuquay-Varina, NC % 'cause no one knows which side %%% 919-577-9882 % the coin will fall." %%%% <yates@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO http://home.earthlink.net/~yatescr
Randy Yates wrote:

> Bawr wrote: > >> Here is a document that addresses the pbm. >> http://focus.ti.com/lit/an/spra757/spra757.pdf > > > It is interesting to note the following statement in > this reference: > > The alternative option, which is not implemented in the RTS library, > is to split each target char > into multiple host bytes (when writing from target to host), and pack > multiple host bytes into each > target char (when reading from host to target). This has the advantage > that the data is preserved > intact without truncation. This advantage is evident for programs that > run only on the target and > need to read data files written by other programs that run only on the > target. In the example > above, the result file would contain the 4 bytes (0xAA, 0xBB, 0xCC, > 0xDD). > > *The primary disadvantage of this approach is that the number of bytes > in the file does not equal > the number of chars written.* > > As far as I know, the C standard never did require a "char" to be 1 > byte. To assume such > a thing is a fairly serious error in the interpretation of the operation > of the C > language. Thus their "primary disadvantage" is no disadvantage whatsoever.
-- Engineering is the art of making what you want from things you can get. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
Randy Yates wrote:

   ...

> As far as I know, the C standard never did require a "char" to be 1 > byte. ...
ANSI C defines a byte as the larger of &#2013266103; the number of bits needed to contain a system character &#2013266103; the smallest addressable storage element &#2013266103; eight bits. When an architecture allows octet-addressable storage and the C implementation uses eight-bit characters, a C byte is eight bits. By definition in C, sizeof(char) is always 1, even if, as on a 'C30, it is 32 bits. To avoid C's dilution of the meaning of "byte", use "octet". Jerry -- Engineering is the art of making what you want from things you can get. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
Randy Yates wrote:

(snip)

> As far as I know, the C standard never did require a
> "char" to be 1 byte. To assume such
> a thing is a fairly serious error in the interpretation
> of the operation of the C language. > Thus their "primary disadvantage" is no disadvantage whatsoever. C does require char to be one byte, but that byte doesn't have to have 8 bits. It has to have at least 8 bits. -- glen