| 4 | | This page captures ideas for RTEMS projects. They range from OS projects to development environment to testing to just about anything else. If you like one of the ideas, you can pitch in and tackle it. If you aren't able to code and test it yourself, consider sponsoring one of the core RTEMS developers to do it for you. This is really the only way things get done -- USERS LIKE YOU KEEP RTEMS DEVELOPMENT ALIVE!!! |
| 5 | | |
| 6 | | The projects on this page are lumped into broad categories but there is no prioritization applied to the order. It is just an organized dump of ideas. :) |
| 7 | | |
| 8 | | Most of the projects are feasible as a Google [wiki:Summer_of_Code Summer of Code] project. A few have multiple steps and a [wiki:Summer_of_Code Summer of Code] participant should work with us to size up how much is doable. |
| | 4 | This page captures ideas for RTEMS projects. They range from OS projects |
| | 5 | to development environment to testing to just about anything else. |
| | 6 | If you like one of the ideas, you can pitch in and tackle it. If you |
| | 7 | aren't able to code and test it yourself, consider sponsoring one of |
| | 8 | the core RTEMS developers to do it for you. This is really the only |
| | 9 | way things get done -- USERS LIKE YOU KEEP RTEMS DEVELOPMENT ALIVE!!! |
| | 10 | |
| | 11 | The projects on this page are lumped into broad categories but there is |
| | 12 | no prioritization applied to the order. It is just an organized dump |
| | 13 | of ideas with enough details to give an outline of the effort required. |
| | 14 | |
| | 15 | We do not provide time estimates on these because the time depends |
| | 16 | on the experience and skill of the developer. Most of these projects |
| | 17 | will fall between a few weeks and a few months of effort by a |
| | 18 | person who is not completely unfamiliar with the general use of GNU/Linux |
| | 19 | and GNU tools. Some of these projects may consist of multiple steps. In |
| | 20 | this case, each step is defined to fall into short discrete steps. |
| | 21 | |
| | 22 | Many RTEMS projects are done as student or volunteer efforts in a person's |
| | 23 | spare time or as a hobby. This means it is imperative that projects be |
| | 24 | either relatively small or divided into steps that can be considered |
| | 25 | complete and committed to the main RTEMS source base. Thus we have |
| | 26 | lots of experience in defining useful projects that are sized to be |
| | 27 | doable and useful to the community in relatively small work packages. |
| | 28 | |
| | 29 | Most of the projects are feasible as a Google [wiki:Summer_of_Code Summer of Code] project. |
| | 30 | Since some projects have multiple steps, a [wiki:Summer_of_Code Summer of Code] participant |
| | 31 | should work with us to size up how many of those steps to undertake. |
| 12 | | Remember that RTEMS is a real-time operating system targeting embedded applications. Applications are cross-compiled on a development host to produce executables that are transferred to and executed on target systems. The projects in this section are more focused on the host side of that equation. This means they will run on GNU/Linux or MS-Windows and possibly communicate with embedded hardware. |
| 13 | | |
| 14 | | RTEMS is a free real-time operating system that must compete against commercial closed source offerings that have very impressive looking GUI oriented Development Environments. The RTEMS Project has spent years honing RTEMS and tuning it to be a competitive run-time and it certainly the technical capabilities to compete. But often RTEMS gets dinged for not having a "pretty face". Some of the projects in this category address that deficiency. |
| | 35 | Remember that RTEMS is a real-time operating system targeting embedded |
| | 36 | applications. Applications are cross-compiled on a development host |
| | 37 | to produce executables that are transferred to and executed on target |
| | 38 | systems. The projects in this section are more focused on the host side |
| | 39 | of that equation. This means they will run on GNU/Linux or MS-Windows |
| | 40 | and possibly communicate with embedded hardware. |
| | 41 | |
| | 42 | RTEMS is a free real-time operating system that must compete against |
| | 43 | commercial closed source offerings that have very impressive looking |
| | 44 | GUI oriented Development Environments. The RTEMS Project has spent |
| | 45 | years honing RTEMS and tuning it to be a competitive run-time and it |
| | 46 | certainly the technical capabilities to compete. But often RTEMS gets |
| | 47 | dinged for not having a "pretty face". Some of the projects in this |
| | 48 | category address that deficiency. |
| 20 | | [http://www.eclipse.org Eclipse] is an open source Integrated Development Environment (IDE) which has become very popular in the real-time embedded systems community. For RTEMS to continue to compare favorably against its commercial proprietary competition, Eclipse support is an important feature. Eclipse has a plug-in architecture and there are already multiple plug-ins and add-ons for embedded development. |
| 21 | | |
| 22 | | This is a very open ended project which has a number of steps based upon subprojects or plugins which need to be made available to RTEMS developers. |
| | 54 | [http://www.eclipse.org Eclipse] is an open source Integrated Development |
| | 55 | Environment (IDE) which has become very popular in the real-time embedded |
| | 56 | systems community. For RTEMS to continue to compare favorably against |
| | 57 | its commercial proprietary competition, Eclipse support is an important |
| | 58 | feature. Eclipse has a plug-in architecture and there are already |
| | 59 | multiple plug-ins and add-ons for embedded development. |
| | 60 | |
| | 61 | This is a very open ended project which has a number of steps based |
| | 62 | upon subprojects or plugins which need to be made available to RTEMS |
| | 63 | developers. |
| 28 | | See http://www.eclipse.org/home/categories/embedded_device.php as a reference. |
| 29 | | |
| 30 | | Since RTEMS has multiple targets, this project would focus on getting Eclipse working nicely with multiple targets. There are over half a dozen simulators which are capable of supporting a multithreaded RTEMS application and a few of those simulate target hardware with networking capabilities. There are existing RTEMS BSPs that run on simulators so the person(s) working on this project would not require special target hardware or anything that costs to verify that their implementation works with multiple hardware configurations. |
| | 69 | See http://www.eclipse.org/home/categories/embedded_device.php as |
| | 70 | a reference. |
| | 71 | |
| | 72 | Since RTEMS has multiple targets, this project would focus on getting |
| | 73 | Eclipse working nicely with multiple targets. There are over half a |
| | 74 | dozen simulators which are capable of supporting a multithreaded RTEMS |
| | 75 | application and a few of those simulate target hardware with networking |
| | 76 | capabilities. There are existing RTEMS BSPs that run on simulators so |
| | 77 | the person(s) working on this project would not require special target |
| | 78 | hardware or anything that costs to verify that their implementation |
| | 79 | works with multiple hardware configurations. |
| 34 | | Status: [wiki:ChrisJohns ChrisJohns] has started this effort. Contact him for information on how you can help. |
| 35 | | |
| 36 | | 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. |
| 37 | | |
| 38 | | [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. |
| 39 | | |
| 40 | | |
| 41 | | 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. |
| | 83 | Status: [wiki:ChrisJohns ChrisJohns] has started this effort. Contact him for |
| | 84 | information on how you can help. |
| | 85 | |
| | 86 | The goal of this project is to integrate CEXP into the main RTEMS Project. |
| | 87 | By integrating CEXP into the main RTEMS Project, it can more easily be |
| | 88 | updated to stay in sync with the main code base and re-released as new |
| | 89 | RTEMS versions come out. |
| | 90 | |
| | 91 | [http://www.slac.stanford.edu/comp/unix/package/rtems/doc/ CEXP] in |
| | 92 | conjunction with GeSYS provide RTEMS with capabilities long familiar to |
| | 93 | VxWorks users. They provide a base system and the ability to dynamically |
| | 94 | load software modules onto the embedded system. Without this system, |
| | 95 | RTEMS can only be used with statically linked executables in which |
| | 96 | the entire application is linked together with RTEMS and loaded onto |
| | 97 | the board. |
| | 98 | |
| | 99 | |
| | 100 | Till Straumman wrote CEXP and GeSYS anbd provides instructions and a |
| | 101 | Live CD to demonstrate it running with the target environment on qemu. |
| | 102 | This would be useful to someone on this project because it provides a |
| | 103 | baseline reference for what the software does. |
| 47 | | 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 release 4.8.0 are documented in the [http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.8.0/share/rtems/html/c_user/c_user00400.html Configuring a System] chapter in the User's Guide. |
| | 109 | The goal is to have a graphical tool to configure RTEMS for a certain |
| | 110 | Application e.g. max number of tasks, semaphores etc. It could |
| | 111 | generate a userconf.h which includes confdefs.h. The complete list |
| | 112 | of RTEMS configuration parameters for release 4.8.0 are documented in the |
| | 113 | [http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.8.0/share/rtems/html/c_user/c_user00400.html |
| | 114 | Configuring a System] chapter in the User's Guide. |
| 54 | | [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. One possibility is to write a GUI program in Python which parses the same configuration information and provides a portable GUI interface. |
| | 121 | [wiki:TBR/User/JoelSherrill JoelSherrill] has used the GNU/Linux kernel config infrastructure for |
| | 122 | similar jobs in the past and things it is likely the best alternative |
| | 123 | as a baseline. This would certainly provide multiple interfaces on |
| | 124 | GNU/Linux hosts (e.g. X11, menu, command line). But we would like |
| | 125 | a solution that also addresses MS-Windows users. One possibility is |
| | 126 | to write a GUI program in Python which parses the same configuration |
| | 127 | information and provides a portable GUI interface. |
| 58 | | Status: No active volunteers. |
| 59 | | |
| 60 | | Automate gcc testing on RTEMS targets. |
| | 131 | Status: [wiki:TBR/User/JoelSherrill JoelSherrill] is slowly building test scripts. He has reported |
| | 132 | gcc results on mulitiple targets but there is still a lot to do. |
| | 133 | |
| | 134 | This project broadly consists of doing whatever is required to automate |
| | 135 | testing of GNU tools on RTEMS targets. The first steps are to be able |
| | 136 | to automate the building of binutils, gcc/newlib, and gdb from source |
| | 137 | using either released versions of the tools or the development version |
| | 138 | checked out and updated from the source code control repositories of |
| | 139 | those projects. |
| | 140 | |
| | 141 | Since there are approximately a dozen active RTEMS targets, this |
| | 142 | effort will have to be able to support all targets. Some of the targets |
| | 143 | have simulators. If there are executable tests, then the project will |
| | 144 | have to address being able to run those executable tests on the simulators |
| | 145 | capturing the output and verifying tests do not run too long. |
| | 146 | |
| | 147 | The RTEMS Project has been offered access to the GCC Compile Farm for |
| | 148 | the purpose of testing GNU tools and providing automated reports. This |
| | 149 | is a collection of high power servers and our intent is to do as much |
| | 150 | of the automated tools testing as possible on those machines. But the |
| | 151 | scripting needed to drive this will be portable to other environments. |
| | 152 | |
| | 153 | The RTEMS Project has a lab or test hardware hosted at OAR Corporation |
| | 154 | which includes multiple target boards and infrastructure to remotely |
| | 155 | access as well as power on/off each board. Once the simulator targets |
| | 156 | have been completely exercised, we will want support running executable |
| | 157 | tests on real embedded hardware targets -- with highest priority going |
| | 158 | to those with no simulator. |
| 66 | | TBD |
| | 164 | Pre-compiled versions of the RTEMS tools are currently available for |
| | 165 | RPM-based GNU/Linux distributions such as Fedora, RedHat Enterprise |
| | 166 | Linux, CentOS, and SUSE as well as MS-Windows via MinGW. This project |
| | 167 | consists of the development of comparable .deb package specifications |
| | 168 | and build scripts. The resulting packaging and infrastructure should |
| | 169 | be suitable for at least GNU/Debian and Ubuntu distributions. As the |
| | 170 | RTEMS toolset updates frequently, there must be scripting infrastructure |
| | 171 | developed to build these tools easily when updates are required. |
| | 172 | |
| | 173 | [wiki:RalfCorsepius RalfCorsepius] is the RPM builder and maintainer. He uses Mock |
| | 174 | to use a single development machine to build binaries for a variety |
| | 175 | of distributions. He is a good resource or mentor for this project. |
| | 176 | |
| | 177 | The RTEMS Project currently does not have a computer running a |
| | 178 | Debian based GNU/Linux distribution and would have to have one |
| | 179 | before these could be supported long term. |
| 72 | | TBD |
| | 185 | The goal of this project is to provide precompiled versions of the |
| | 186 | RTEMS tools for the x86 MacOS. As the RTEMS toolset updates frequently, |
| | 187 | there must be scripting infrastructure developed to build these tools |
| | 188 | easily when updates are required. |
| | 189 | |
| | 190 | Little is know by those who currently build RTEMS tool binaries about |
| | 191 | the packaging and legal requirements associated with providing |
| | 192 | MacOS binaries. |
| | 193 | |
| | 194 | The RTEMS Project currently does not have a MacOS X computer and would |
| | 195 | have to have one before these could be supported long term. |
| 78 | | Implement Multilib support for GNU Ada (GNAT) run-time libraries in GCC. |
| | 201 | The goal of this project is to implement Multilib support |
| | 202 | for GNU Ada (GNAT) run-time libraries in GCC. This primary |
| | 203 | focus of this project will be to augment the existing |
| | 204 | configure and Makefile infrastructure for the GNU Ada run-time |
| | 205 | libraries in GCC to build multilib rather than a single library |
| | 206 | variant. |
| | 207 | |
| | 208 | Multilib is a GNU term for building a single source library to be |
| | 209 | tailored for multiple CPU variants within a single architecture. |
| | 210 | This is done because even within a CPU architecture, not every |
| | 211 | CPU model is object code compatible. For example, on the RTEMS |
| | 212 | SPARC tools, we provide four libc.a versions -- SPARC V7 and V8 |
| | 213 | with and without hardware floating point support. Similarly, |
| | 214 | the m68k target supports many m680x0 and Coldfire core |
| | 215 | implementations with and without hardware floating point. |
| 84 | | Get GJC (GNU Java Compiler) to work out of the box with RTEMS |
| 85 | | = Visual Studio Integration = |
| 86 | | |
| 87 | | |
| 88 | | Status: No active volunteers. |
| 89 | | |
| 90 | | Integrate RTEMS Development Environment with [http://msdn2.microsoft.com/en-us/vstudio/bb510103.aspx Visual Studio 2008 Shell]. This would ideally allow project level target configuration, code development, building with GCC backend, deployment, and debugging. |
| | 221 | The purpose of this project is to make the GJC (GNU Java Compiler) |
| | 222 | work with RTEMS. RTEMS is supported as a target in GCC so it is |
| | 223 | expected that the primary focuses of this project are to adapt |
| | 224 | the run-time library to RTEMS and make sure as many tests as possible |
| | 225 | run correctly. |
| | 226 | |
| | 227 | There was a previous effort to do this but it was not submitted |
| | 228 | to the GCC Maintainers. At this point, it was against such |
| | 229 | an old version of gcc that it would probably have to be used as |
| | 230 | a reference more than a code base. |
| | 231 | = eVisual Studio Integration == |
| | 232 | |
| | 233 | |
| | 234 | Status: No active volunteers. |
| | 235 | |
| | 236 | Integrate RTEMS Development Environment with |
| | 237 | [http://msdn2.microsoft.com/en-us/vstudio/bb510103.aspx Visual Studio |
| | 238 | 2008 Shell]. This would ideally allow project level target configuration, |
| | 239 | code development, building with GCC backend, deployment, and debugging. |
| | 240 | |
| | 241 | [wiki:ChrisJohns ChrisJohns] is a good resource for this project because he is |
| | 242 | the maintainer for the RTEMS MinGW hosted tools |
| 100 | | Prior to the RTEMS 4.8 Releases, RTEMS based all timing on clock ticks. At each clock tick, the current time of day was updated. This meant that the granularity of all time stamps and statistics on per-thread CPU usage were constrained to that of the clock tick. In RTEMS 4.8.0, the lowest level of RTEMS -- the SuperCore (e.g. rtems/cpukit/score) was converted to use POSIX ''struct timespec'' as the format for all timestamps. In conjunction with the addition of the ability of a BSP to report "nanoseconds since last clock tick", RTEMS could now provide nanosecond accurate timestamps and CPU usage statistics. |
| 101 | | |
| 102 | | Unfortunately, performing mathematical operations on ''struct timespec'' is painful and slow. This project will consist of the following work: |
| 103 | | |
| 104 | | * Baseline Testing |
| 105 | | * Verify all test cases work as baseline. |
| 106 | | * Capture execution times of RTEMS Timing Tests on reference hardware. |
| 107 | | * Capture sizes of sample tests. |
| 108 | | |
| 109 | | * Add a SuperCore object "ScoreTimestamp". |
| 110 | | * This is an opaque class which will be used by all SuperCore time related functions. |
| 111 | | * Methods will be provided to convert timespec and other standard time formats to and from ScoreTimestamp. |
| 112 | | * RTEMS has a class to operate upon timespec's so this will be implemented in terms of this. |
| 113 | | * Direct operations on timespec's will be eliminated throughout RTEMS except as necessary near API calls which operate upon struct timespec arguments. |
| 114 | | * Initial implementation will be using struct timespec and all methods should be simple pass throughs or wrapper of existing functionality in the Timespec math helper class. |
| | 253 | Prior to the RTEMS 4.8 Releases, RTEMS based all timing on clock ticks. |
| | 254 | At each clock tick, the current time of day was updated. This meant |
| | 255 | that the granularity of all time stamps and statistics on per-thread |
| | 256 | CPU usage were constrained to that of the clock tick. In RTEMS 4.8.0, |
| | 257 | the lowest level of RTEMS -- the SuperCore (e.g. rtems/cpukit/score) |
| | 258 | was converted to use POSIX ''struct timespec'' as the format for all |
| | 259 | timestamps. In conjunction with the addition of the ability of a BSP |
| | 260 | to report "nanoseconds since last clock tick", RTEMS could now provide |
| | 261 | nanosecond accurate timestamps and CPU usage statistics. |
| | 262 | |
| | 263 | Unfortunately, performing mathematical operations on ''struct timespec'' |
| | 264 | is painful and slow. This project will consist of the following work: |
| | 265 | |
| | 266 | # Baseline Testing |
| | 267 | #* Verify all test cases work as baseline. |
| | 268 | #* Capture execution times of RTEMS Timing Tests on reference hardware. |
| | 269 | #* Capture sizes of sample tests. |
| | 270 | |
| | 271 | # Add a SuperCore object "ScoreTimestamp". |
| | 272 | #* This is an opaque class which will be used by all SuperCore time related functions. |
| | 273 | |
| | 274 | #* Methods will be provided to convert timespec and other standard time formats to and from ScoreTimestamp. |
| | 275 | |
| | 276 | #* RTEMS has a class to operate upon timespec's so this will be implemented in terms of this. |
| | 277 | |
| | 278 | #* Direct operations on timespec's will be eliminated throughout RTEMS except as necessary near API calls which operate upon struct timespec arguments. |
| | 279 | |
| | 280 | #* Initial implementation will be using struct timespec and all methods should be simple pass throughs or wrapper of existing functionality in the Timespec math helper class. |
| 118 | | * Verify all existing test cases still work. |
| 119 | | |
| 120 | | * Implement alternate version of SuperCore object "ScoreTimestamp" which uses unsigned sixty-four bit integers to represent nanoseconds since the POSIX epoch. |
| 121 | | * This implementation should be fairly simple as you can do direct math on 64-bit integers. |
| 122 | | |
| 123 | | * Post Testing |
| 124 | | * Verify all test cases work as they did baseline. |
| 125 | | * Capture execution times of RTEMS Timing Tests again on reference hardware for both implementations. |
| 126 | | * Capture sizes of sample tests. |
| 127 | | |
| 128 | | * Evaluation |
| 129 | | * We anticipate that most of the target architectures RTEMS supports will benefit from using the 64-bit integer version. But RTEMS supports over a dozen architectures so this is certainly not guaranteed. |
| 130 | | * Work with RTEMS Community to run tests on as many targets as possible to decide which is best choice on each architecture. |
| 131 | | * Simulators are available for most of the primary target architectures so we will be able to judge the impact of your work. |
| | 284 | # Verify all existing test cases still work. |
| | 285 | # Implement alternate version of SuperCore object "ScoreTimestamp" |
| | 286 | which uses unsigned sixty-four bit integers to represent nanoseconds |
| | 287 | since the POSIX epoch. |
| | 288 | #* This implementation should be fairly simple as you can do direct math on 64-bit integers. |
| | 289 | |
| | 290 | # Post Testing |
| | 291 | #* Verify all test cases work as they did baseline. |
| | 292 | #* Capture execution times of RTEMS Timing Tests again on reference hardware for both implementations. |
| | 293 | #* Capture sizes of sample tests. |
| | 294 | |
| | 295 | # Evaluation |
| | 296 | #* We anticipate that most of the target architectures RTEMS supports will benefit from using the 64-bit integer version. But RTEMS supports over a dozen architectures so this is certainly not guaranteed. |
| | 297 | #* Work with RTEMS Community to run tests on as many targets as possible to decide which is best choice on each architecture. |
| | 298 | #* Simulators are available for most of the primary target architectures so we will be able to judge the impact of your work. |
| 145 | | Chris and Joel have done some initial work and prototyping has been done on the first four parts of this. Chris wrote the capture engine and together Chris and Joel believe that the bulk of the work adding trace points can be done automatically using the GNU ld "wrap capability". In addition, we believe that a simple text dump of the trace log on the host side can be derived in a highly automated manner. The code to transmit data from the RTEMS system and to receive the data on the host computer will have to be written. |
| 146 | | |
| 147 | | Once data has been received on the host side, the next logical step is to display the timeline of events in a graphical fashion. This may include the development of the visualization tool or an existing may be able to be leveraged. |
| 148 | | |
| 149 | | Greg Menke of NASA has used GNU plot to do a simple version of this and may have advice. |
| | 314 | Chris and Joel have done some initial work and prototyping has been done |
| | 315 | on the first four parts of this. Chris wrote the capture engine and |
| | 316 | together Chris and Joel believe that the bulk of the work adding trace |
| | 317 | points can be done automatically using the GNU ld "wrap capability". |
| | 318 | In addition, we believe that a simple text dump of the trace log on |
| | 319 | the host side can be derived in a highly automated manner. The code to |
| | 320 | transmit data from the RTEMS system and to receive the data on the host |
| | 321 | computer will have to be written. |
| | 322 | |
| | 323 | Once data has been received on the host side, the next logical step |
| | 324 | is to display the timeline of events in a graphical fashion. This may |
| | 325 | include the development of the visualization tool or an existing may be |
| | 326 | able to be leveraged. |
| | 327 | |
| | 328 | Greg Menke of NASA has used GNU plot to do a simple version of this and |
| | 329 | may have advice. |
| 184 | | Reimplement Classic API notepads and POSIX keys using code like std::map but in C. I think an implementation of the map code is available under an appropriate license as a starting point. |
| | 373 | Reimplement Classic API notepads and POSIX keys using code like std::map |
| | 374 | but in C. The current implementation requires that enough memory |
| | 375 | be reserved for every task to have memory for all notepads and |
| | 376 | every key whether they use them or not. This results in simple and fast |
| | 377 | array lookups to access individual values but is obviously heavy on memory. |
| | 378 | It is hoped that a hash/map algorithm can be found or designed which |
| | 379 | reduces the memory overhead without adding excessive lookup overhead |
| | 380 | or heavy handed O(n) algorithms for management of the entries. This |
| | 381 | is particularly important because tasks and keys can be dynamically |
| | 382 | created and deleted. |
| | 383 | |
| | 384 | [wiki:TBR/User/JoelSherrill JoelSherrill] and [wiki:PavelPisa PavelPisa] are good resources for this. Joel |
| | 385 | can answer questions about the rationale driving this need and help |
| | 386 | evaluate algorithms. The run-time behavior of the algorithm is very |
| | 387 | important because RTEMS strives to be as predictable in run-time |
| | 388 | execution times and memory usage as possible. Pavel is very |
| | 389 | knowledgable about hash algorithms. |
| 190 | | Reduce footprint of minimum RTEMS application. Currently a minimum RTEMS application assumes that you want items like a reentrant C library, shutdown code and a minimal filesystem infrastructure. Some ideas in this area are captured at [wiki:Projects/TinyRTEMS TinyRTEMS]. The project would focus on breaking linkages between components so they can be configured out by the user, dropped out automatically at link time, or other mechanisms. The goal is to be able to provide the user with a full featured RTEMS library and defer as much configuration as possible to application configuration and link time. |
| | 395 | Reduce footprint of minimum RTEMS application. Currently a minimum RTEMS |
| | 396 | application assumes that you want items like a reentrant C library, |
| | 397 | shutdown code and a minimal filesystem infrastructure. Some ideas in |
| | 398 | this area are captured at [wiki:Projects/TinyRTEMS TinyRTEMS]. The project would focus on |
| | 399 | breaking linkages between components so they can be configured out by |
| | 400 | the user, dropped out automatically at link time, or other mechanisms. |
| | 401 | The goal is to be able to provide the user with a full featured RTEMS |
| | 402 | library and defer as much configuration as possible to application |
| | 403 | configuration and link time. |
| 202 | | Add an ordered constructor type system for automatic manager initialization. This should be general enough to support RTEMS managers, drivers and BSD sysctl type nodes. This is expected to significantly impact the [wiki:Projects/TinyRTEMS TinyRTEMS] effort as it would provide a central mechanism to eliminate code. If you don't reference it, the initialization code would automatically drop out. |
| | 418 | Add an ordered constructor type system for automatic manager |
| | 419 | initialization. This should be general enough to support RTEMS managers, |
| | 420 | drivers and BSD sysctl type nodes. This is expected to significantly |
| | 421 | impact the [wiki:Projects/TinyRTEMS TinyRTEMS] effort as it would provide a central mechanism |
| | 422 | to eliminate code. If you don't reference it, the initialization code |
| | 423 | would automatically drop out. |
| 206 | | Status: Please ask for detailed information on the particular BSP/simulator combination you are interested in. There are lots of combinations available and the status changes frequently. |
| 207 | | |
| 208 | | There are a variety of potential projects listed on the [wiki:Emulator Emulator] and [wiki:Skyeye Skyeye] pages. Some of these involve addressing issues in the simulator itself. Others involve developing BSPs for specific simulators. This is an important area of work since any target that can be tested easily and in an automated fashion on a simulator is always in better shape. |
| 209 | | |
| 210 | | [wiki:TBR/User/JoelSherrill JoelSherrill] hopes someone will tackle RTEMS support for the ARM PXA models and edp9312 as supported by [wiki:Skyeye Skyeye]. This would benefit RTEMS testing a lot. |
| | 427 | Status: Please ask for detailed information on the particular |
| | 428 | BSP/simulator combination you are interested in. There are lots of |
| | 429 | combinations available and the status changes frequently. |
| | 430 | |
| | 431 | There are a variety of potential projects listed on the [wiki:Emulator Emulator] |
| | 432 | and [wiki:Skyeye Skyeye] pages. Some of these involve addressing issues in the |
| | 433 | simulator itself. Others involve developing BSPs for specific simulators. |
| | 434 | This is an important area of work since any target that can be tested |
| | 435 | easily and in an automated fashion on a simulator is always in better |
| | 436 | shape. |
| | 437 | |
| | 438 | [wiki:TBR/User/JoelSherrill JoelSherrill] hopes someone will tackle RTEMS support for the ARM |
| | 439 | PXA models and edp9312 as supported by [wiki:Skyeye Skyeye]. This would benefit |
| | 440 | RTEMS testing a lot. |
| 216 | | RTEMS based RT-VMM (Real-Time Virtual Machine Monitor). Current RTEMS can not support to run another OS (such as Linux or uClinux). We want to add hypervisor (or Virtual Machine Monitor) function on RTEMS, then RTEMS has the power like XEN that can run Linux or other OS, but RTEMS also maintain original hard Real-Time funtions. First, we will try to make RTEMS run uClinux on ARM simulator SkyEye( http://www.skyeye.org ), then we will try to make RTEMS run ARM Linux on XSCALE CPU based board or SkyEye simulator. We consider virtualization techs on Embedded RTOS area has potential value. (from chyyuu@gmail.com) |
| | 446 | RTEMS based RT-VMM (Real-Time Virtual Machine Monitor). Current RTEMS |
| | 447 | can not support to run another OS (such as Linux or uClinux). We want |
| | 448 | to add hypervisor (or Virtual Machine Monitor) function on RTEMS, then |
| | 449 | RTEMS has the power like XEN that can run Linux or other OS, but RTEMS |
| | 450 | also maintain original hard Real-Time funtions. First, we will try to |
| | 451 | make RTEMS run uClinux on ARM simulator SkyEye( http://www.skyeye.org ), |
| | 452 | then we will try to make RTEMS run ARM Linux on XSCALE CPU based board |
| | 453 | or SkyEye simulator. We consider virtualization techs on Embedded RTOS |
| | 454 | area has potential value. (from chyyuu@gmail.com) |
| 222 | | Update the RTEMS port of LWIP. Provide reproducible test cases so we can be sure it stays in working condition. |
| 223 | | |
| 224 | | A goal of this effort is to be able to use the standard TCP/IP NIC drivers already in RTEMS. If this is feasible, then a user could switch between the full-featured BSD TCP/IP stack in RTEMS or the LWIP stack to save memory at the expense of reduced functionality. |
| | 460 | Update the RTEMS port of LWIP. Provide reproducible test cases so we |
| | 461 | can be sure it stays in working condition. |
| | 462 | |
| | 463 | A goal of this effort is to be able to use the standard TCP/IP NIC drivers |
| | 464 | already in RTEMS. If this is feasible, then a user could switch between |
| | 465 | the full-featured BSD TCP/IP stack in RTEMS or the LWIP stack to save |
| | 466 | memory at the expense of reduced functionality. |
| 244 | | By default, RTEMS limits the amount of memory and number of operating system object instances that can be created. By merging the C Program Heap and RTEMS Workspace, all usable memory available could be used by RTEMS to allocate objects. This would make RTEMS be able to behave like VxWorks in regards to limits on object instances while still preserving the hard limits which are needed by many RTEMS users. |
| 245 | | = Memory Management = |
| 246 | | |
| 247 | | |
| 248 | | Status: No active volunteers. |
| 249 | | |
| 250 | | Add advance memory management feature in RTEMS. |
| 251 | | The memory management in current RTEMS is fast and simple. But for a complex embedded systems, a page based memory systems is more preferable. other feature like runtime memory compression, memory tracer(for leak detection), DMA and cache management interface is also preferable. |
| | 487 | By default, RTEMS limits the amount of memory and number of operating |
| | 488 | system object instances that can be created. By merging the C Program |
| | 489 | Heap and RTEMS Workspace, all usable memory available could be used by |
| | 490 | RTEMS to allocate objects. This would make RTEMS be able to behave like |
| | 491 | VxWorks in regards to limits on object instances while still preserving |
| | 492 | the hard limits which are needed by many RTEMS users. |
| 261 | | There are very few tests in the RTEMS source base which benchmark the POSIX Threading API and other POSIX services. The first step in this project would be to develop POSIX API Timing Tests which test the same logical tests cases as the existing Classic API Timing Tests. After that is complete, we would want to see Timing Tests for POSIX specific objects such as conditional variables and keys. |
| 262 | | |
| 263 | | RTEMS does not use Timing Tests as much for comparison with other operating systems but as a ruler for self-improvement. Each RTEMS version should maintain or exceed the performance characteristics of previous versions. |
| 264 | | = =Coverage Analysis == |
| | 506 | There are very few tests in the RTEMS source base which benchmark the |
| | 507 | POSIX Threading API and other POSIX services. The first step in this |
| | 508 | project would be to develop POSIX API Timing Tests which test the same |
| | 509 | logical tests cases as the existing Classic API Timing Tests. After that |
| | 510 | is complete, we would want to see Timing Tests for POSIX specific objects |
| | 511 | such as conditional variables and keys. |
| | 512 | |
| | 513 | RTEMS does not use Timing Tests as much for comparison with other |
| | 514 | operating systems but as a ruler for self-improvement. Each RTEMS |
| | 515 | version should maintain or exceed the performance characteristics of |
| | 516 | previous versions. |
| | 517 | = Coverage Analysis = |
| 269 | | This task consists of performing automated coverage testing using an open source simulator. The [wiki:Skyeye Skyeye] project is currently adding coverage analysis capabilities per our specifications. When those are available, the person(s) undertaking this project could analysis the binary object level coverage provided by the RTEMS Test Suites on any target BSP supported by the [[Skyeye]]/RTEMS combination. |
| | 522 | This task consists of performing automated coverage testing using an open |
| | 523 | source simulator. The [wiki:Skyeye Skyeye] project is currently adding coverage |
| | 524 | analysis capabilities per our specifications. When those are available, |
| | 525 | the person(s) undertaking this project could analysis the binary object |
| | 526 | level coverage provided by the RTEMS Test Suites on any target BSP |
| | 527 | supported by the [wiki:Skyeye Skyeye]/RTEMS combination. |
| | 528 | |
| | 529 | The resulting analysis is expected to provide a report on individual |
| | 530 | assembly instructions within RTEMS subsystems which are not currently |
| | 531 | exercised by existing tests. Each case has to be individually analyzed |
| | 532 | and addressed. Historically, we have identified multiple categories |
| | 533 | for code being uncovered: |
| | 534 | |
| | 535 | * Needs a new test case |
| | 536 | |
| | 537 | * Unreachable in current RTEMS configuration. For example, the SuperCore |
| | 538 | could have a feature only exercised by a POSIX API object. It could |
| | 539 | be disabled when POSIX is not configured. |
| | 540 | |
| | 541 | * Debug or sanity checking code which can be placed inside an RTEMS_DEBUG |
| | 542 | conditional. |
| | 543 | |
| | 544 | * Unreachable paths generated by gcc for switches. Sometimes you |
| | 545 | have to restructure switches to avoid unreachable object code. |
| | 546 | |
| | 547 | * Critical sections which are synchronizing actions with ISRs. Most of these are very hard to hit and may require very specific support from a simulator environment. OAR has used tsim to exercise these paths but this is not reproducible in a BSP independent manner. Worse, there is often no external way to know the case in question has been hit and no way to do it in a one shot test. |
![[RTEMS Logo]](/images/logo.png){kind=logo}
