RTSC Ease of Use
A recurring comment that came from a recent TI software meeting was that RTSC should be easier to use. A small workgroup has been formed, mostly consisting of TI engineers that are not part of the RTSC development team. The purpose of this group is to work with the RTSC developers in order to make a better, easier-to-use product. The workgroup is not meant to necessarily implement changes, but rather to assist the RTSC developers in identifying key areas for improvement.
Phase 1: Definition of Problem
Goal: We need to give RTSC users “gradual entitlement” to the features/benefits of RTSC. That is, with a little effort they should get a little benefit and with increasing effort they should get increasing benefit. Currently it seems that immense effort is required to use this product at all.
- Difficult for users to get started (confusion due to deluge of files, directories, options, etc.)
- Common error: users get the XDCPATH wrong
- Confusion as to which things are specific to XDC and which things are specific to an XDC package (e.g. Codec Engine). Users don’t understand where to get information such as config options available, etc. Some things might be Codec Engine specific (e.g. user.bld) whereas other things are general to all RTSC packages (e.g. package.xdc).
- Changes to the RTSC implementation have caused all the package providers to go in and make changes (getLibs, GCArmv5T, etc.). This relates to our “API religion” workgroup.
- We need a method of quality control for RTSC package producers.
- More tools for component producers.
- Why is it so big? 100MB+, ~4000 files
Phase 2: Metrics to declare an issue resolved
From the perspective of the RTSC development team, "Ease of Use" is an on-going effort and will likely never truly end.
From the perspective of this workgroup the issue will be resolved once it no longer consistently comes up as a top frustration for RTSC users. Furthermore, it is our intent that by starting these discussions on the RTSC Eclipse web page that these efforts will help spur further discussions directly with other users. In that way the effort of improving RTSC's ease of use will transfer from this workgroup directly to the community and the RTSC developers, which is the way it should work in an open source project.
Phase 3: Proposed actions
Solutions in Progress
- "Package not found errors" - unique error messages for path problems and package-not-built problems
- "Type" errors - better messages as to what the problem is
- Build trace like makefiles to track down build errors
- Run-time trace for software issues
- Closure tool for delivering lib and headers to app developer
- ROV graphical tool
- platform wizard - need a unified memory map
Other Proposed Solutions
- Wizards for wrapping legacy libs
- Wizard to build components
- RTSC best practices documentation
- Need the RTSC team to give more assistance to groups inside TI to properly use RTSC
- Need more examples available for people to get comfortable with RTSC (e.g. BIOS6)
- Print error message when path added to XDCPATH that contains no valid packages
- Error for package referenced by cfg but not added to XDCPATH
- Validation tool to check packages against the TI packaging standard
- Better evangelization of the RTSC benefits, comparison of tools users are already familiar with (GNU make, auto-make, etc.)
- Create wiki page on rtsc.eclipse that details some use cases and corresponding tools, tutorial video would be a plus
- Get TI SW components to use RTSC features, e.g. configuration parameters (at build time) for drivers; enforcement of version compatibility checks etc.