I'm curious..... how do you manage compiler updates during the development cycle?

Hi Lori,

Lori Heustess said:

How long do you lock your development onto a single release for?

I'm not sure whether I got this question correctly, but here's what I followed:

I started my work with CCS v5.1 compiler, followed the sample codes and started developing code for my projects. Updated my compiler without hesitation whenever they were available as they were all minor revisions. This went on till v5.5. When CCS v6 was released I downloaded and installed the same immediately but in a different folder. Hence I'd both v5.5 and v6 running together. I ported my projects to the later version and verified the same for around couple of months. When I was sure about that migration to CCS v6 had no bugs/glitches I uninstalled CCS v5.5. It seemed to be a very smooth transition.

Lori Heustess said:

How frequently (on average) do you update your compiler tools?

As soon as they're available.

Lori Heustess said:

For a incremental release (example 6.0.0 to 6.0.1) would you expect only bug fixes? or would you be ok with bug fixes + new features?

Both fixes and features :)

Lori Heustess said:

Same question for a release like 6.0.0 to 6.1.0?

Same answer as above. But logically speaking it would make more sense if 6.0.1 had bug fixes and 6.1.0 had feature updates.

Lori Heustess said:

Anything else you would like me to know about your workflow and tools (in particular the compiler)

Nothing as of now.

Regards,

Gautam

Thank you Gautam!   Often compiler releases (compiler, assembler, linker...) are made available on a different schedule than Code Composer Studio updates. For example very soon codegen 6.4 will become available as a update to the current CCS. 

It sounds like in your development work you update when there is a new CCS version available but don't necessarily pickup codegen updates in-between.   But you are not against updating minor revisions of the compiler at any time to pickup bug fixes. Have I understood correctly?

Thank you for your inputs!

Lori

Lori Heustess said:

It sounds like in your development work you update when there is a new CCS version available but don't necessarily pickup codegen updates in-between. 

Exactly, now in CCS v6 it keeps reminding you for the updates available regularly. I don't have to click on Check for updates tab anymore. Also, I thought that codegen versions get updated when I update from "Check for updates"; am I correct?

Lori Heustess said:

But you are not against updating minor revisions of the compiler at any time to pickup bug fixes.

Not at all! Bug fixes are most welcome as soon as possible :)

Regards,

Gautam

Gautam Iyer said:

Exactly, now in CCS v6 it keeps reminding you for the updates available regularly. I don't have to click on Check for updates tab anymore. Also, I thought that codegen versions get updated when I update from "Check for updates"; am I correct?

Yes, codegen updates to the same production compiler (ex: 6.4.1 to 6.4.2) will be caught by "Check for Updates".  I think you may still need to specifically update the project itself to use the new compiler (both will be available for you to use).  Major updates are considered "new features" like 6.x.x. to 7.x.x would require "check for new features".

I've asked the CCS team to confirm that this is still the case in CCS 6 :) 

Yes, Lori is correct. One small correction:

Lori Heustess said:

Major updates are considered "new features" like 6.x.x. to 7.x.x would require "check for new features".

The menu item is "Install New Software" under the "Help" menu.

More details on updating your compiler version is in the below wiki article:

http://processors.wiki.ti.com/index.php/Compiler_Updates

Lori Heustess said:

I've asked the CCS team to confirm that this is still the case in CCS 6 :) 

Everything is still the same for v6. One extra thing in v6 is that you can get the latest version of the "y" version of the compiler (x.y.z.) via the App Center also. Otherwise everything in the above wiki article is the same.

Thanks

ki

Thank you Ki-Soo!

Thanks for all the info Ki-Soo & Lori.

Regards,

Gautam

No other feedback?   

How about this question:

Right now we release a new production compiler about once a year.  What if you could get new features or performance improvements earlier in a fully-tested short term release (i.e. no bug fixes to this release) instead of waiting a whole year for these improvements. Then once a year move development to a long term release.  This long term release which would roll-in all the improvements made over the year and would be maintaned and patched for the duration of your development?

Hi Lori

1. How long do you lock your development onto a single compiler release for?

I develop across several machines, so usually when a new release is available I let CCS install it and run a build and test on my working projects. If everything goes fine, I update the other machines whenever I next use them.

2. How frequently (on average) do you update your compiler tools?

I used to just update them whenever I updated CCS, which was usually every few minor revision s of CCS. With the better updating and notifications recently, I have moved to updating as Im notified and time allows.

3.For a incremental release (example 6.0.0 to 6.0.1) would you expect only bug fixes? or would you be ok with bug fixes + new features?

I would normally *expect* bug fixes only, but I guess new features would be OK, provided backwards compatibility was not broken by the new features.

4. Anything else you would like me to know about your workflow and tools (in particular the compiler)

Has there been any decision/date on MISRA 2012 rule checking adoption?

For your added question:

This sounds very similar to the stable/canary channels run by Chrome or the LTS/Standard releases of Ubuntu. Two important points I believe would be: to have a well -defined and fixed release period for both channels and to make switching between using one or the other a painless process, e.g. If I want to just use the long term releases, the update checker (in CCS or etc) should only be notified of the longer term releases instead of asking to install each short term release as well.

Another example of such a system to bear in mind might be the MS Windows Service Packs. Installing only the service packs always seemed to work a lot better (install ran better & resulting system ran better) than installing the incremental updates, even thought they are purportedly just the same software.

T

Toby,

Thank you so much for your response. 

Toby Mole said:

Has there been any decision/date on MISRA 2012 rule checking adoption?

For the compiler being able to detect these rules I'm not sure of a schedule.  Let me check with the compiler team.

For example code generated by TI we are starting to use MISRA 2012 rule checking just this year for our own collateral (using a 3rd party tool). 

Lori,

How long do you lock your development onto a single compiler release for?

This answer is coming from about 30 years at different companies doing embedded firmware mostly with TI processors.

This can vary some by company, but once products get released to customers, the code and the build tools are usually frozen unless we have a bug fix or a new feature request.

Large changes in tools can be prohibited by project costs, learning curve.

On some projects with small early prototype budgets and well known tools, the tools can be frozen from the start. Also some defense projects where the managing companies are staying up with the same tool set and verifying builds, permission may be required.

I have seen tool sets frozen for years (CC on OS/2) on naval contracts that start with early prototypes then engineering models before years later becoming shipboard production. On some defense contracts the build computers may not be allowed to have internet access for updates.

For contracts without special requirements I would say in the beginning tools can be very fluid (updates checked for almost daily) until things start getting to near full power or near full speed (6 to 18 months) then tool changes become less and less fluid as milestones are met and glacial as delivery approaches.

Hope this helps…John

Thank you John! 

Toby Mole said:

Has there been any decision/date on MISRA 2012 rule checking adoption?

Toby - I have gotten feedback on this and there is currently no current plan to update to the MISRA 2012 standard.

as long as there is an option not to update (especially not to automatically update)..

the other important thing is to have complete documentation on the known bugs that are either fixed or not. given that information, we can decide if a workaround is possible without upgrading the tool.. because side effects of a new version may not be exactly predictable.