LOG_printf vs printf vs SYS_printf to print a variable string to a file

Have you tried to use the File I/o functions? With fopen you can specify the path to the file, than you can use fread, fwrite, fprintf.

 FILE *filePtr;

filePtr = (FILE *) fopen("C:/file.txt","r");  

// operations


 fclose(filePtr);

Hi,

There's not much to add to your approach. From the software execution standpoint, LOG_printf() is the less disruptive way to print characters to an output, since the data is transferred to the host PC only when no other threads are running in your system, and the PC is in charge of formatting and displaying (or copying to a file in your case). Therefore you adopted the best way to do it in your target system.

All the standard lib C functions you mentioned (as well as the minimized SYS_printf and its variants) perform the entire string formatting on the target and set a software breakpoint to allow transferring the data to the host PC, therefore having a huge performance penalty and causing disruption in the software execution. Their main advantage is flexibility, since you can print entire strings and formatted floating point numbers if using a fixed-point DSP (LOG_printf only prints floating-point numbers in a floating-point processor).

I am assuming you are using CCSv3.3. If so, I could not find any way to script the MessageLog window properties, however by saving the workspace it stores these properties, saving you some time in the initial setup.

Hope this helps,

Rafael

thanks for the quick response, no i haven't tried file i/o functions yet but will do so shortly. In previous integrations with CCS we found that printf() would appear in the output window inside the debugger. These build configurations did not however have the DSP/BIOS linked in. Where would we expect to see the printf() output when the DSP/BIOS is linked in?

The printf() output would be in the same window (stdout) as in a non-BIOS program.

Check some details about using printf() with BIOS-based programs here: http://tiexpressdsp.com/index.php/DSP_BIOS_FAQ#Q:_Why_does_my_printf.28.29_not_work.3F

Best regards,

Rafael

Rafael,

yes i'm using CCSv3.3. Given that the application here is for a software unit testing tool, i'm willing to sacrifice performance in favor of functionality/flexibility. Much of this test case code is run in a batch mode overnight, where performance is not a primary concern. Also, the implementation i'm working on now uses the simulator, so everything is on the host PC, so in the simulator mode, with the DSP/BIOS linked in, are the standard C lib functions like printf() handled differently? When i start running on the target (Spectrum Digital TMS320C6713 DSK), i imagine the software breakpoint method you describe to transfer data to the host PC would get invoked... is that right?

thanks

rob

Rob,

According to this article, the simulator did not implement the software breakpoint, however I verified and it was recently implemented in CCSv3.3 SR12 for the C6000 family of devices, so I suggest you to update your copy of CCS. This way you will have the exact behaviour of calling printf() between hardware emulation and software simulation.

Since you are using heavily the simulator, I suggest you to take a look at the Simulation category in the Mediawiki. You may find good information there about limitations and features.

Best regards,

Rafael

Rafael,

i still don't see any output from my printf() calls in the output window. I assume the window in the IDE where you would expect to see the printf() output (stdout) is displayed by selecting View->Output Window ??  I found a reference on the TI support site that details possible problem in not seeing printf output as insufficient heap. Can you point me to an example of a tcf file that configures a heap. Also, assuming that there was insufficient heap when printf() tried to malloc some memory from the heap, should i expect to see some sort of error/exception occur instead of it silently failing?

i tried stepping into the printf call, which i don't have source for, but it does step in assembler thru the printf() function that i can determine from the map file is from the rts6700.lib that gets linked in. is that the appropriate library that you would expect the printf to be resolved for in my 6713 simulator environment?

As a side note of additional information, we build the executable image by invoking the compiler and linker from the command line inside our test tool instead of building inside the IDE. I have a separate sample project that i use to generate a .tcf file, which in turn creates a linker command file that i then copy to my build environment and reference in the linker options when building from the command line.

Rob

thanks

Rob

This:

(LOG_printf only prints floating-point numbers in a floating-point processor)

is the kind of information I wished you could enclose within your main documents - It needed some time for me to realize that this, from http://focus.ti.com/lit/ug/spruex4/spruex4.pdf:

LOG_print(), which is designed for arbitrary C code. The Log_print[0-6]()
functions allow up to 6 values to be passed along with a printf-like format
string to the logger. They handle printf-style formatting.

is a wrong information. LOG_print does NOT like printf. Okay, there is written: "printf-like", which means all or nothing. Okay, YOU wrote about LOG_printf. By the way, where is that function to be found?

I find this kind of stumbling stones and also more or less serious type errors within descriptions and code samples within the TI documents each hour at least twice. Is there any point where easily I could put this kind of information in? Until now I didn't found a clear system within the TI documents and am not sure about the update ways and cycles of the TI documents. Some days this gets me really down.

But, nevertheless, much thanks for your helpful incidental remark.