- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Tool/software: Code Composer Studio
Hi,
I'm noticing more and more how much of my time is spent waiting for CCS to build and run my code.
It takes between 65 and 90 seconds from me pressing F11 to actually seeing the output from my code, and I need to do this cycle a LOT since I'm wrestling with TI-RTOS doing random weird stuff all the time, and thus having to do tiny incremental changes while I try and work out what it's doing.
Exiting debug mode so I can try another iteration takes 20-40 seconds, so even changing a single number and testing takes at least 2 minutes.
I'm used to simply having makefile rules for upload and console output which take mere seconds.
Is there some way I can shorten the development cycle time?
Michael,
One thing to try would be to enable parallel builds. This should be on by default in our latest tools but it is worth checking. Go to the properties of the project and check the settings below.
If the optimizer is on this will also increase install time.
We are working on some improvements to the flashing performance which would be a big benefit here. Hoping to deploy those in CCSv7.2.
Regards,
John
Michael,
The perspective switch should be fast. One thing we could try is to disable the switch. There are a couple ways to do this is to enable Simple mode. Go to the View menu and select Getting Started. There is a selection to enable Simple Mode.
Mostly what this does is open a simplified perspective that is used for both Editing and Debugging. Thus there will be no perspective switch. I am curious to see if it makes a difference.
Regards,
John
Michael,
I remember looking into this once a few years ago.
Try going to the little down arrow beside the Bug button. Select Debug Configurations. Select your Debug Configuration on the left (typically your project name). Then click on the "Common" tab. There are options there for the encoding. I believe this impacts the console.
Give that a try and let me know if it does the trick.
Regards,
John
Michael,
I realized we never closed off on this. I did a little test with a normal printf today and that works fine with UTF8 characters:
Since the console can handle this ok I believe your earlier thought about it being a limitation in system_printf is likely bang on. I have asked someone to confirm. The system_printf is a subset of printf for size/performance reasons.
Regards,
John
I created a test case which passed UTF8 characters to both print() and System_printf() in a SYS/BIOS program for a Cortex-M4F (TM4C1294NCDPT). The program was:Michael Moon said:Why would System_printf mangle them?
Where the two strings use the UTF8 characters as described by UTF-8 encoding table and Unicode characters as:
- "VERTICAL LINE" "VULGAR FRACTION THREE QUARTERS" "VERTICAL LINE" "newline"
- "VERTICAL LINE" "INVERTED QUESTION MARK" "VERTICAL LINE" "newline"
The encoding for the source file and debug configuration was set to UTF8.
The CCS 7.1.0.00016 CIO console output was:
The CIO console output shows the same output from both printf() and System_printf(). The problem is that a spurious "LATIN CAPITAL LETTER A WITH CIRCUMFLEX" UTF8 character is displayed as the 2nd character in the output in the CIO console.
Inspecting the assembler listing from the compiler showed the expected UTF8 characters had been encoded.
A breakpoint was set on the xdc_runtime_SysMin_output__I function which is the SYS/BIOS function which is called to pass the formated string to the HOSTwrite function used to pass CIO output to the CCS debugger. The buffer contained the expected UTF8 characters. Stepping through the xdc_runtime_SysMin_output__I function function showed the expected UTF8 characters written to the __CIOBUF_ array which is where the CCS debugger reads the data to be displayed in the CIO console. Therefore, in my test case I can't see any error in how the target is handling UTF8 strings, and so the spurious "LATIN CAPITAL LETTER A WITH CIRCUMFLEX" UTF8 character which appears in the CIO console must be a problem in CCS debugger end.
What specific UTF8 character(s) are you having problems with?
I note that the thread What type of character encoding can we write source comments in japanese at CCSv5.3? says that "For the TI compiler, you must restrict your input to US ASCII characters". Not sure if some UTF8 characters in the source file could cause the TI compiler to misbehave.
My test project is attached TM4C1294_system_printf_utf8.zip
I can't repeat that exactly, but got an extra  displayed:Michael Moon said:I'm trying to send the degree symbol (°) which I enter simply by pressing shift+altgr+semicolon on my keyboard, and CCS debug console simply displays a couple of question marks instead of the symbol.
For my Windows 7 system the default encoding is Cp1252 which is maybe why I got an extra  displayed, rather than a couple of question marks.
By inserting a compiler error on a line containing a UTF-8 character string, and setting the compiler to report Verbose diagnostics which echos the line with the error found the same incorrect UTF-8 characters were displayed in the build console as well as the CCS CIO debug console:Michael Moon said:Curiously, CCS is quite happy to have this symbol in the code editor (and the compiler seems quite happy with it too), only CCS's debug console doesn't handle it correctly.
I added the following to the CCS 7.1.0.00016 <install_root>\ccsv7\eclipse\ccstudio.ini file, which sets the default Eclipse encoding to UTF-8:Michael Moon said:The issue must then be with CCS debug console as you describe, even though I've set every encoding setting I can find to UTF8.
-Dfile.encoding=UTF-8
With that change the CCS CIO console, and build console, then displayed the correct UTF-8 characters.
I suspect there is a bug which causes the CCS 7.1.0.00016 console to use the default (inherited) encoding, rather the encoding set in the Debug Configurations.
I did find some references to a console.encoding option in the Eclipse .ini file, but attempts to add just -Dconsole.encoding=UTF-8 to the ccstudio.ini file had no effect.
