Difference between revisions of "RTSC Ease of Use"

From Eclipsepedia

Jump to: navigation, search
(added new Summary Presentation on ease of use)
Line 73: Line 73:
== Phase 6:  Evaluation ==
== Phase 6:  Evaluation ==
[[Media:RTSC_Ease_of_Use_Summary_2009-07-15.pdf|RTSC Ease of Use Summary 2009-07-15]]
Although the effort to continue making RTSC easier to use continues, this workgroup is wrapping up.  Recommendations on how the product can be improved or made easier to use are still encouraged.  The best place for discussions are on the [http://www.eclipse.org/newsportal/thread.php?group=eclipse.dsdp.rtsc newsgroup].

Latest revision as of 19:25, 15 July 2009


[edit] Introduction

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.

[edit] 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
  • Javascript errors difficult to understand/fix
  • 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

[edit] 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.

[edit] Phase 3: Proposed actions

Solutions in Progress

  • IDE Integration - the less JavaScript written, the fewer errors novices will make
  • "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.

[edit] Phase 4: Summary Presentations

RTSC Ease of Use Update 2008-12-18

RTSC Ease of Use Update 2009-03-19

RTSC Ease of Use Update 2009-05-20

[edit] Phase 5: Implementation

Features now available in CCS4 beta 5

  • Project wizard allows creation of a "config project"
    • separation of projects gives better control of when the config step should actually run (better performance)
    • Eclipse IDE allows user to add paths through dialog boxes (less error prone, i.e. no typos!)
  • Platform Wizard
    • Find -> New -> Other… -> RTSC Wizards -> RTSC Platform Wizard
    • Use a pre-existing platform as a "seed", then modify and generate a ready-to-use platform package
    • Launches by default when opening a cfg file
    • Parameter validation, e.g. "Task priorities must be in the range of 0-31"
    • "Rich packages" will create specialized views of the config options to present the data such that it's easier to read, i.e. more logical groupings
    • Selecting a given instance in the "Outline view" will highlight the corresponding lines in the cfg file in the editor.
    • Deleting an instance will actually remove the corresponding lines rather than just adding a "delete" command in the script. This keeps the scripts much smaller, more readable, and more maintainable.

Path tool

  • Launch via command line: $XDCROOT/xs xdc.tools.path.sg
  • Select a path via dialog box and view packages contained within

[edit] Phase 6: Evaluation

RTSC Ease of Use Summary 2009-07-15

Although the effort to continue making RTSC easier to use continues, this workgroup is wrapping up. Recommendations on how the product can be improved or made easier to use are still encouraged. The best place for discussions are on the newsgroup.