| 70 | | The projects in this category are more focused on the development of |
| 71 | | software that runs on RTEMS on target hardware. |
| 72 | | = Run-Time Tracing = |
| 73 | | |
| 74 | | |
| 75 | | |
| 76 | | '''Status:''' [wiki:ChrisJohns ChrisJohns] and [wiki:TBR/User/JoelSherrill JoelSherrill] have done initial work on adding trace points to RTEMS. This is still work in progress. |
| 77 | | |
| 78 | | Instrument RTEMS so that a timeline visualization tool can be used to "place a scope" on a running RTEMS system. This project has multiple parts. |
| 79 | | |
| 80 | | * Addition of trace points to generate log entries |
| 81 | | * Transmission of logged data to host |
| 82 | | * Receipt of logged data on host |
| 83 | | * Decoding of logged data on host |
| 84 | | * GUI Timeline Visualization tool |
| 85 | | |
| 86 | | The requirements of the Run-Time tracing is to provide a common means audit an RTEMS application for conformance of input/output parameters and/or timing, or to debug an application. The auditing process typically uses a static configuration the user manages. The debugging process usually targets a standard set of calls such as the RTEMS Classic API and uses dynamic filtering to control what is looked at as the debugging session unfolds. |
| 87 | | |
| 88 | | The current status of this project can be found [wiki:RTEMS_Trace_Tool_ here]. |
| 89 | | = Implement POSIX Asynchronous and List IO = |
| 90 | | |
| 91 | | |
| 92 | | |
| 93 | | '''Status:''' No active volunteers. |
| 94 | | |
| 95 | | RTEMS does not currently support POSIX Asynchronous IO as defined by |
| 96 | | OpenGroup. These methods and associated constants are prototyped by |
| 97 | | the [http://www.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html |
| 98 | | <aio.h>] header file which is ''cpukit/posix/include/aio.h'' in the |
| 99 | | RTEMS source tree. The following methods would have to be implemented: |
| 100 | | |
| 101 | | * [http://www.opengroup.org/onlinepubs/009695399/functions/aio_read.html aio_read()] |
| 102 | | * [http://www.opengroup.org/onlinepubs/009695399/functions/aio_write.html aio_write()] |
| 103 | | * [http://www.opengroup.org/onlinepubs/009695399/functions/aio_cancel.html aio_cancel()] |
| 104 | | * [http://www.opengroup.org/onlinepubs/009695399/functions/aio_error.html aio_error()] |
| 105 | | * [http://www.opengroup.org/onlinepubs/009695399/functions/aio_return.html aio_return()] |
| 106 | | * [http://www.opengroup.org/onlinepubs/009695399/functions/lio_listio.html lio_listio()] |
| 107 | | |
| 108 | | All methods currently are implemented in RTEMS as stubs which return ENOSYS. |
| 109 | | |
| 110 | | It is assumed that the implementation would have to have one or more |
| 111 | | server threads and these methods would interact with that server thread |
| 112 | | by enqueueing operation requests and checking on the completion status. |
| 113 | | The number of server threads along with characteristics such as stack |
| 114 | | size and priority would need to be application configurable. |
| 115 | | = Use Map/Hashes = |
| 116 | | |
| 117 | | |
| 118 | | |
| 119 | | '''Status:''' No active volunteers. |
| 120 | | |
| 121 | | Reimplement Classic API notepads and POSIX keys using code like std::map |
| 122 | | but in C. The current implementation requires that enough memory |
| 123 | | be reserved for every task to have memory for all notepads and |
| 124 | | every key whether they use them or not. This results in simple and fast |
| 125 | | array lookups to access individual values but is obviously heavy on memory. |
| 126 | | It is hoped that a hash/map algorithm can be found or designed which |
| 127 | | reduces the memory overhead without adding excessive lookup overhead |
| 128 | | or heavy handed O(n) algorithms for management of the entries. This |
| 129 | | is particularly important because tasks and keys can be dynamically |
| 130 | | created and deleted. |
| 131 | | |
| 132 | | [wiki:TBR/User/JoelSherrill JoelSherrill] and [wiki:PavelPisa PavelPisa] are good resources for this. Joel |
| 133 | | can answer questions about the rationale driving this need and help |
| 134 | | evaluate algorithms. The run-time behavior of the algorithm is very |
| 135 | | important because RTEMS strives to be as predictable in run-time |
| 136 | | execution times and memory usage as possible. Pavel is very |
| 137 | | knowledgable about hash algorithms. |
| 138 | | = TinyRTEMS = |
| 139 | | |
| 140 | | |
| 141 | | See [wiki:Projects/TinyRTEMS TinyRTEMS] for details on the status of this project and remaining activities. |
| | 70 | The projects in this category are more focused on the development of software that runs on RTEMS on target hardware. |
| | 71 | |
| | 72 | The following projects have had no work: |
| | 73 | |
| | 74 | * Implement [wiki:POSIX_Asynchronous_IO_ POSIX Asynchronous and List IO] |
| | 75 | * Use [wiki:UseHashOrMapInNotepadsAndKeys_ Maps or Hashes] in the implementation of Classic API Notepads and POSIX API Keys. |
| | 76 | * RTEMS can always use [wiki:TBR/Delete/MoreBSPsForSimulators more BSPs for Simulators]. Being able to test, debug, and perform coverage analysis on simulators is critical to the ongoing success of the project. |
| | 77 | |
| | 78 | The following projects have had some work on them but are not complete. The remaining activities could be large of small: |
| | 79 | |
| | 80 | * [wiki:RTEMS_Trace_Tool_ Run-Time Tracing] - includes gathering, capturing, and displaying information to the user. |
| | 81 | * [wiki:Projects/TinyRTEMS TinyRTEMS] is an umbrella term that corresponds to any activities or ideas that could shrink the code and data space requirements for RTEMS. The goal is to progressively lower the minimum CPU requirements. |
| | 82 | * [wiki:Projects/SequencedInitialization RTEMS Sequenced Initialization] is a project to allow RTEMS initialization to be dynamically constructed based upon user requirements. It would be like C++ global constructors conceptually. |
| | 83 | * See [wiki:Projects/libdl Dynamic Object File Loading] for detail on the status of this project. |
| 151 | | = RTEMS Sequenced Initialization = |
| 152 | | |
| 153 | | |
| 154 | | See [wiki:Projects/SequencedInitialization RTEMS Sequenced Initialization] for details on this project. |
| 155 | | = BSPs for CPU Simulators = |
| 156 | | |
| 157 | | |
| 158 | | '''Status:''' Please ask for detailed information on the particular |
| 159 | | BSP/simulator combination you are interested in. There are lots of |
| 160 | | combinations available and the status changes frequently. |
| 161 | | |
| 162 | | See the [wiki:Open_Projects#Automated_GNU_Tools_Testing GNU Tools Testing] project for information on which targets need simulator BSPs to aid in tool testing. |
| 163 | | |
| 164 | | There are a variety of potential projects listed on the [wiki:Emulator Emulator] |
| 165 | | and [wiki:Developer/Simulators/SkyEye SkyEye] pages. Some of these involve addressing issues in the |
| 166 | | simulator itself. Others involve developing BSPs for specific simulators. |
| 167 | | This is an important area of work since any target that can be tested |
| 168 | | easily and in an automated fashion on a simulator is always in better |
| 169 | | shape. Here is a list of BSPs on simulators that are currently thought |
| 170 | | to be of high interest because they would add significantly to our |
| 171 | | testing infrastructure: |
| 172 | | |
| 173 | | * a BSP for a QEMU Coldfire target |
| 174 | | * a BSP for a QEMU SuperH target |
| 175 | | * a BSP for a QEMU or [wiki:Developer/Simulators/SkyEye SkyEye] ARM PXA target. |
| 176 | | * a BSP for [wiki:Developer/Simulators/SkyEye SkyEye] edp9312 target configured to match the < USD200 Olimex board. |
| 177 | | |
| 178 | | The [http://gavare.se/gxemul/ GXEmul SkyEye] project emulates a number of ARM-, PPC-, MIPS-, and SH4- based platforms, including [http://gavare.se/gxemul/gxemul-stable/doc/experiments.html#expdevices "test-machines" SkyEye] which may be good targets for RTEMS. |
| 179 | | |
| 180 | | Where available please include support for networking and graphics. The RTEMS Project uses simulators for automated testing as well as for manual testing of features like graphics and network application behavior. Full featured simulator BSPs make this much easier. It also provides more BSPs which anyone on the project has access to free with no need for special hardware to be purchased. |
| 181 | | |
| 182 | | [wiki:TBR/User/JoelSherrill JoelSherrill] hopes someone will tackle RTEMS support for the ARM |
| 183 | | PXA models and edp9312 as supported by [wiki:Developer/Simulators/SkyEye SkyEye]. This would benefit |
| 184 | | RTEMS testing a lot. |
![[RTEMS Logo]](/images/logo.png){kind=logo}
