Changes between Version 11 and Version 12 of Developer/SmallProjects
- Timestamp:
- 11/23/14 06:49:56 (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Developer/SmallProjects
v11 v12 13 13 14 14 * Improve the Wiki (requires Wiki editing) 15 * [wiki: BoardSupportPackageInformation_BSPs]: There are approximately 100 boards supported by RTEMS. Each board has a page in the Wiki and there is an standard Wiki Infobox. Most BSPs still do not have any information here, links to vendor information, or even a good description of the board. This effort just requires a bit of web research.15 * [wiki:TBR/Website/Board_Support_Packages BSPs]: There are approximately 100 boards supported by RTEMS. Each board has a page in the Wiki and there is an standard Wiki Infobox. Most BSPs still do not have any information here, links to vendor information, or even a good description of the board. This effort just requires a bit of web research. 16 16 * [wiki:Developer/OpenProjects Open Projects]: Create a template and prioritization for adding/updating open projects. See [wiki:TBR/Review/OpenProjectTemplate OpenProjectTemplate]. Update all projects. 17 17 … … 38 38 * There is a continual need for more test code. We would like a timing test suite for the POSIX thread support that is comparable to the current Classic API timing test suite. We expect this will eventually comprise about 50 different tests so could be tackled as a class project with the individual tests assigned to different people or groups. 39 39 40 * Write tests to improve [wiki: RTEMS_Test_CoverageTest Coverage]. We want full object coverage for as much of RTEMS as possible. In this light, there are areas which are under tested in the automated test suite. This is an ongoing project with a variety of areas that need test cases written. Please ask for a current coverage report and a recommended area you can tackle.40 * Write tests to improve [wiki:Projects/TestingImprovements Test Coverage]. We want full object coverage for as much of RTEMS as possible. In this light, there are areas which are under tested in the automated test suite. This is an ongoing project with a variety of areas that need test cases written. Please ask for a current coverage report and a recommended area you can tackle. 41 41 42 * Add example uses of each Manager to User's Guide. The C User's manual for the Classic API currently does not include example uses. One part of this is letting readers know that counting semaphores may be used to manage a pool of resources and binary may be used for mutual exclusion or condition synchronization. But the other part is moving it beyond the theoretical to show code and give examples of how this might be used in a real application. For example, condition synchronization with binary semaphore to announce that an interrupt occurred to a waiting task. = Investigate GCC Test Failures = 42 * Add example uses of each Manager to User's Guide. The C User's manual for the Classic API currently does not include example uses. One part of this is letting readers know that counting semaphores may be used to manage a pool of resources and binary may be used for mutual exclusion or condition synchronization. But the other part is moving it beyond the theoretical to show code and give examples of how this might be used in a real application. For example, condition synchronization with binary semaphore to announce that an interrupt occurred to a waiting task. 43 = Investigate GCC Test Failures = 43 44 44 45 … … 46 47 47 48 The GCC C, C++, and Ada test suites are regularly run on multiple architectures using simulators. All RTEMS tools tests reports are archived at [http://www.rtems.org/pipermail/rtems-tooltestresults/] as well as at [http://gcc.gnu.org/ml/gcc-testresults]. Pick the latest test result for your favourite target architecture and start looking at the failure cases. 48 #Make sure there isn't a PR for it already. If there is, update it to note the failure is still occurring.49 #Check out the gcc-testing CVS modules from the RTEMS CVS repository and follow the instructions to build and run the tests yourself.50 #Pick a test that fails and investigate it51 ##Some "scan assembler" tests fail because RTEMS tests are run on a particular BSP which uses specific CPU model compile options which may conflict with the CPU model the instructions would be generated on.52 ##Others may core dump. Try to get a stack backtrace in gdb.53 ##Check that the stack isn't blown or that it isn't using too much memory for the BSP. It may be "expected to fail" on this BSP.54 #In all cases, file a PR at [http://gcc.gnu.org/bugzilla] so your explanation is captured.55 #If you can provide a patch, try. Fixing test infrastructure issues is generally easier than fixing code generation problems.49 1. Make sure there isn't a PR for it already. If there is, update it to note the failure is still occurring. 50 1. Check out the gcc-testing CVS modules from the RTEMS CVS repository and follow the instructions to build and run the tests yourself. 51 1. Pick a test that fails and investigate it 52 a. Some "scan assembler" tests fail because RTEMS tests are run on a particular BSP which uses specific CPU model compile options which may conflict with the CPU model the instructions would be generated on. 53 a. Others may core dump. Try to get a stack backtrace in gdb. 54 a. Check that the stack isn't blown or that it isn't using too much memory for the BSP. It may be "expected to fail" on this BSP. 55 1. In all cases, file a PR at [http://gcc.gnu.org/bugzilla] so your explanation is captured. 56 1. If you can provide a patch, try. Fixing test infrastructure issues is generally easier than fixing code generation problems.