Changes between Version 141 and Version 142 of Developer/OpenProjects

Timestamp:

01/26/10 04:08:00 (14 years ago)

Author:

JoelSherrill

Comment:

/* Development Environment Oriented */ Shortened some

Developer/OpenProjects

@@ -187 +187 @@
 dinged for not having a "pretty face".  Some of the projects in this
 category address that deficiency.
-= Eclipse Integration =
-
-
-See also: [wiki:Developer/Eclipse/Information RTEMS Eclipse Page].
-= CEXP =
-
-
-'''Status:''' [wiki:ChrisJohns ChrisJohns] has started this effort.  Contact him for
-information on how you can help.
-
-The goal of this project is to integrate CEXP into the main RTEMS Project.
-By integrating CEXP into the main RTEMS Project, it can more easily be
-updated to stay in sync with the main code base and re-released as new
-RTEMS versions come out.
-
-[http://www.slac.stanford.edu/comp/unix/package/rtems/doc/ CEXP] in
-conjunction with GeSYS provide RTEMS with capabilities long familiar to
-VxWorks users.  They provide a base system and the ability to dynamically
-load software modules onto the embedded system.  Without this system,
-RTEMS can only be used with statically linked executables in which
-the entire application is linked together with RTEMS and loaded onto
-the board.
-
-
-Till Straumman wrote CEXP and GeSYS anbd provides instructions and a
-Live CD to demonstrate it running with the target environment on qemu.
-This would be useful to someone on this project because it provides a
-baseline reference for what the software does.
-= Application Configuration GUI =
-
-
-'''Status:''' No active volunteers.
-
-'''Status:''' Sebastian Huber
-
-The goal is to have a graphical tool to configure RTEMS for a certain
-Application e.g. max number of tasks, semaphores etc. It could
-generate a userconf.h which includes confdefs.h. The complete list
-of RTEMS configuration parameters for version 4.9.1 of RTEMS are documented in the 
-[http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.9.1/share/rtems/html/c_user/c_user00039.html
-Configuring a System] chapter in the User's Guide.
-
-There are a variety of ways to approach this project.
-
- *  One solution is to write a GUI in Python.  This should be cross-platform.
- *  Another solution could be a Wizard/Editor for Eclipse.  
- *  Another solution is to use the config infrastructure used by the GNU/Linux kernel.
- *  Another approach would be to use the configuration GUI from eCos and NutOS: http://www.ethernut.de/en/software/nutconf.html
-
-[wiki:TBR/User/JoelSherrill JoelSherrill] has used the GNU/Linux kernel config infrastructure for
-similar jobs in the past and things it is likely the best alternative
-as a baseline.  This would certainly provide multiple interfaces on
-GNU/Linux hosts (e.g. X11, menu, command line).  But we would like
-a solution that also addresses MS-Windows users.  
-
-A better possibility is to write a GUI program in Python which reads an XML format file describing the RTEMS configuration parameters.  As the user set values, the program would store this information in another XML format file.  When it was time to write the C code to use with the RTEMS application, the GUI application would write that.  So we would have:
-
- *  XML file describing RTEMS configuration parameters
- *  XML save file with user settings
- *  C/H file output for use with RTEMS application
-= Automated GNU Tools Testing =
-
-
-'''Status:''' 
- *  [wiki:TBR/User/JoelSherrill JoelSherrill] is slowly building test scripts. He has reported gcc results on mulitiple targets.
- *  The CVS module gcc-testing has the support infrastructure.
- *  Some targets are not tested on simulators yet.
- *  Skyeye has some bugs preventing testing on Coldfire and Blackfin.
- *  There seem to be regression checking scripts we need to utilize to help reduce the burden of tracking results.
- *  There are tests which spuriously fail due to the test infrastructure issues.
-  *  not knowing we add specific CPU options which prevent generating expected instructions on "scan assembly" tests 
-  *  missing instructions in simulators
- *  Want to eventually run on multiple BSPs inside a single target architecture to cover more code generation possibilities.
-
-
-This project broadly consists of doing whatever is required to automate testing of GNU tools on RTEMS targets.  The first steps are to be able
-to automate the building of binutils, gcc/newlib, and gdb from source using either released versions of the tools or the development version
-checked out and updated from the source code control repositories of those projects.  This step is largely complete with the test scripts
-in the CVS module ''gcc-testing''.
-
-Since there are approximately a dozen active RTEMS targets, this ultimate goal of this effort is to be able to test at least one BSP on all targets.  Some of the targets
-have simulators.  If there are executable tests, then the project will have to address being able to run those executable tests on the simulators capturing the output and 
-verifying tests do not run too long.
-
-The volume of test data generated is very high with GCC having over 60,000 tests.  We need to be able to generate deviation reports which highlight changes between subsequent test runs.  We believe a script to do this exists although the integration of that into the overall test system needs to occur.  Also the deviation report should be emailed to the RTEMS Tool Test Results mailing list (http://www.rtems.org/pipermail/rtems-tooltestresults).
-
-The RTEMS Project has access to the GCC Compile Farm for the purpose of testing GNU tools and providing automated reports.  This is a collection of high power servers and our intent is to do as much of the automated tools testing as possible on those machines.  But the scripting needed to drive this will be portable to other environments.
-
-The RTEMS Project has a lab or test hardware hosted at OAR Corporation which includes multiple target boards and infrastructure to remotely
-access as well as power on/off each board.  Once the simulator targets have been completely exercised, we will want support running executable
-tests on real embedded hardware targets -- with highest priority going to those with no simulator.
+
+The following areas have been identified for projects:
+
+ *  Improvements in the [wiki:Developer/Eclipse/Information RTEMS Eclipse Integration] 
+ *  [wiki:Projects/CEXP CEXP] integration into main RTEMS distribution.
+ *  Implement a cross-platform [wiki:Projects/GSoC/ApplicationConfigurationGUI  Application Configuration GUI].
+ *  Improve [wiki:Projects/GNUToolsTesting  Testing of the GNU Tools] on RTEMS targets
+ *  TBD Move other descriptions to their own page and list here.  Shorten master page.
 = RTEMS Tool Support on Debian =
 
@@ -355 +272 @@
 
 The contributor MUST have or file Free Software Foundation paperwork and it is assumed that this code will be contributed to GCC.
-= =eVisual Studio Integration ==
+= eVisual Studio Integration =
 
 
@@ -368 +285 @@
 the maintainer for the RTEMS MinGW hosted tools
 
-=  ==ArgoUML for RTEMS===
+= =ArgoUML for RTEMS ==