CCS/LAUNCHXL-CC1310: Is there any way to make CCS's build/run cycle faster?

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

I am using parallel build, and the build time is a fraction of the total cycle time anyway (~10-20s) so reducing it won't have much effect.

It takes CCS longer to switch from edit to debug perspective than it does to build (the whole application deadlocks in GUI thread for a good 5-10s before it even starts rearranging windows), longer again to actually flash the code to the target, and also a rather long time to load symbols and work out what's happening when it breaks on main.

I'm looking forward to CCS7.2 if it'll speed up this cycle!

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

Hi John,

I found an update for CCS (7.1.0.00016) on the wiki (even though CCS's update manager said no updates available) and disabled perspective switch (I told it to stay in debug perspective all the time) and now my time from F11 to seeing code output is down to 45-50s which is a significant improvement but still slower than I'd like.

The majority of time now seems to be spent loading the code into the target - I read elsewhere that CCS7.2 may have something to speed that along

We have implemented flashing speed improvements for a few devices already and CCSv7.2 is expected to have them deployed for CC13xx devices. CCSv7.2 is set to be released in 2 months.

Regards,
John

Unrelated but tiny, is there any plan to fully support UTF8 in CCS?

In debug console, all my non-ascii characters just show up as �� although the editor seems to handle them well enough.

Perhaps TI-RTOS/SysMin is mangling them rather than CCS? How could I find out?

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

It's already set to UTF8 - in fact it's set to "Default - inherited (UTF8)" as I've set the top-level CCS setting to UTF8

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 didn't realise normal printf was available, I'll play with it soon and let you know.

Why would System_printf mangle them? Aren't printf implementations supposed to just pass characters verbatim unless it's NUL or '%'? Why would TI add a special case to mangle non-ascii characters?

Michael Moon said:

Why would System_printf mangle them?

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:

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

By using UART console and logging to a file, I confirmed that the firmware side is sending the UTF8 characters correctly.

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.

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.

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.

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.

I can't repeat that exactly, but got an extra Â displayed:

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.

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.

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:

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.

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:

-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.

Michael,

Did the workaround suggested by Chester work for you?

John

I have stopped using the CCS console as I find it far too inflexible compared to debug over UART which allows me to do highlighting, selective data display, collective logging, ISR-driven auto flush, vastly higher data rates (running at 2MBaud currently), and other fun stuff like that.

Before switching, I tried Chester's fixes to no avail, however one of my coworkers gets UTF8 characters in his CCS console on windows using the same firmware - perhaps it's a linux-specific issue?