AD535 | BIOS | Booting | Bootloader | C621 | C6211 | C6415 | C671 | C6711 | C6711DSK | C6713 | CCS | Chassaing | COFF | DAT | DM64 | DM642 | DMA | DSK671 | DSK6711 | EDM | EDMA | EMIF | Emulator | EVM | EVM620 | FFT | FIR | GPIO | Halting | HPI | HWI | IDK | JTAG | LDB | LDH | LDW | Linker | LMS | LOG_printf | Matlab | McBSP | MEM_alloc | MIPS | PCI | PCM3003 | Pipeline | Profiling | QDM | Reset | ROM | RTDX | Sampling | SDRAM | Stack | TEB | THS1206 | TMS320C621 | TMS320C6416 | TMS320C6711 | TMS320C6713 | UART | Vector Table | XBUS | XDS560

Hi guys, iam having an argument with some friends on whats the role of RTS library in programming in c with CCS.My understanding is that RTS files are like header files ,as in stdio.h when we program in say,VC++...if say, we are writing 1.c, it first gets converted 1.0bj and when that is fed to the linker, it combines(relocates?) 1.0bj with other OBJ's(is this where RTS library comes into picture?) and creates a whole 1.out,which combines all the library codes along with it? is that a correct assumption? i guess,then that would mean that if we write a code which doesnt use printf, but because RTS library is "linked" even printf code will be dumped in your 1.out, irrespective of whether u use it or not? that sounds bad? And, as far as using printf is concerned,the doubt i have is,is the printf code being executed wholly and completely in the host? or, is it only the "string formatting" part that is carried out in the host? and i read somewhere else that RTS conatins all bootloading codes... all seems a lill confusing on the whole!

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Bhooshan iyer schrieb: > Hi guys, > iam having an argument with some friends on whats the role of RTS > library in programming in c with CCS.My understanding is that RTS files are > like header files ,as in stdio.h when we program in say,VC++...if say, we > are writing 1.c, it first gets converted 1.0bj and when that is fed to the > linker, it combines(relocates?) 1.0bj with other OBJ's(is this where RTS > library comes into picture?) and creates a whole 1.out,which combines all > the library codes along with it? is that a correct assumption? The linker will extract the RTS functions you are reference in your c-code and will place them with your code in the *.out. > i guess,then that would mean that if we write a code which doesnt use > printf, but because RTS library is "linked" even printf code will be dumped > in your 1.out, irrespective of whether u use it or not? that sounds bad? Using the above assumption, it won`t link printf code if you don´t use it. > And, as far as using printf is concerned,the doubt i have is,is the printf > code being executed wholly and completely in the host? or, is it only the > "string formatting" part that is carried out in the host? Hi Bhooshan Using printf from the RTS results in a hug code size and performance overhead on the target. I'm not sure where the formating is done but assuming you send strings then the whole string is send via serial JTAG chain to the host for output. That's bad indeed. In contrast, if you´re using DSP/BIOS LOG_printf then only references to the strings are send via JTAG and the CCS host performs the ASCI formating and output. Thus, you should use LOG_printf and BIOS instead of printf. > and i read somewhere else that RTS conatins all bootloading codes... > all seems a lill confusing on the whole! Well, the RTS lib contains the code for _c_int00. This is the function which is executed after Reset to init your C-code environment, constants etc. You can find this code in the file boot.c which should be located under c:\ti\c6000\cgtools\lib \src or similar. Rgds. Phil -- Dipl.-Inf. Phil Alder - Field Application Engineer ------------------------------------------------------------------ DSPecialists GmbH Rotherstr. 22 10245 Berlin, Germany http://www.DSPecialists.de ------------------------------------------------------------------ DSPecialists - Making the impossible work!

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

> I am having an argument with some friends on whats the role of RTS > library in programming in c with CCS. My understanding is that RTS files are > like header files, as in stdio.h when we program in say, VC++...if say, we > are writing 1.c, it first gets converted 1.0bj and when that is fed to the > linker, it combines(relocates?) 1.0bj with other OBJ's(is this where RTS > library comes into picture?) and creates a whole 1.out,which combines all > the library codes along with it? is that a correct assumption? The "RTS Files" are composed of two parts: - The header files (*.h), which act just like the header files of any other project, i.e. they define the interface to all the functions contained in the *.c files - The source files (*.c), which are usually pre-compiled and placed in a *.lib file. The purpose of the linker is to take all your object files, which have unresolved references to functions in other files and which all usually start at address zero, and to move (relocate) them in memory to their final address (after allocating all the sections in memory) and to find all the functions (resolve) that are not defined in your source files, but are in the library instead. After reading in all your project options files, it will find all the references to functions in other files and replace their reference with their (now allocated) address. When this is all done, there may still be some unresolved names (such as printf, memcpy, etc), so it keep searching for these names, usually by looking through the library. As it find object files in the library that satisfy references, it extract them, allocates them to memory, and then adds any additional unresolved references in those new object files (for example, when it reads in printf, it may get a new references to sprintf or memcpy or something that printf uses, and so it will have to resolve that reference too). So the linker reallocates and resolves. > i guess,then that would mean that if we write a code which doesnt use > printf, but because RTS library is "linked" even printf code will be dumped > in your 1.out, irrespective of whether u use it or not? that sounds bad? I believe that is false for every linker I've ever seen, including TI's linkers. The linker will only include those portions of the library that contains definitions of unresolved references that it can satisfy at the point that the library is processed. (This is important! It means the order that libraries and object files are linker can affect which of same named functions is chosen!) > And, as far as using printf is concerned,the doubt i have is,is the printf > code being executed wholly and completely in the host? or, is it only the > "string formatting" part that is carried out in the host? > and i read somewhere else that RTS conatins all bootloading codes... On TI devices using the RTS provided with the compiler (i.e. not BIOS, etc.) the printf code is wholly executed on the target; only very minimal support is required in the emulator/simulator devices. That built in support, however, can be extended to drive any device you desire. For instance, you can extend it to drive some attached digital display by writing only the low level interface functions. Might not be the fastest, but it's quick and gives you the full support of the RTS string/print functions.

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

> After reading in all your project options files, it will find all the > references to functions in other files and replace their reference > with their (now allocated) address. When this is all done, there may > still be some unresolved names (such as printf, memcpy, etc), so it > keep searching for these names, usually by looking through the > library. As it find object files in the library that satisfy > references, it extract them, allocates them to memory, and then adds > any additional unresolved references in those new object files (for > example, when it reads in printf, it may get a new references to > sprintf or memcpy or something that printf uses, and so it will have > to resolve that reference too). By the way, here's all the letter s's that I forgot above: ssssss Insert them where necessary.

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )