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
IO routines (fread/fwrite) with CCS--C55x
Started by ●December 16, 2003
Reply by ●December 16, 20032003-12-16
>>>>> "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
Reply by ●December 16, 20032003-12-16
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 workproperly on> Bawr> CCS 2.12 on the C55x platform. It seems to be reading andwriting byte by> Bawr> byte even if you specify the right size. > Bawr> Has anybody else run into the same pbm? If so, is there anypatch 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
Reply by ●December 16, 20032003-12-16
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 properlyon> 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 > >
Reply by ●December 19, 20032003-12-19
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
Reply by ●December 20, 20032003-12-20
Bawr wrote:> Here is a document that addresses the pbm. > http://focus.ti.com/lit/an/spra757/spra757.pdfIt 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
Reply by ●December 20, 20032003-12-20
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. �����������������������������������������������������������������������
Reply by ●December 20, 20032003-12-20
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 � the number of bits needed to contain a system character � the smallest addressable storage element � 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. �����������������������������������������������������������������������
Reply by ●December 21, 20032003-12-21
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