Version 25 (modified by ChrisJohns, on Apr 28, 2009 at 10:44:59 AM) (diff)

BSP Command line.

4.10 Release Notes

Table of Contents

    Error: Page TBR/UserManual/4.10_Release_Notes does not exist

Open Ideas are are: RTEMS410Ideas?

This page lists the changes and improvements that are planned and/or have been made to the RTEMS development source since the 4.9 release branch was made. As usual, there will be submissions that are not expected and incorporated as ready into the 4.10 releases. In keeping with project history, the feature set of the 4.10 release series will be largely be driven by user submissions and requests.

<blockquote> Any snapshots made during this development effort are numbered 4.9.99.x. </blockquote>

<blockquote> The RTEMS project provides built tools sets that are available for download. For Linux the RPM package formater is support and avaliable from the APT/Yum Repository. For Windows MinGW Executable Installers are available. </blockquote>

If any changes or enhancements are missing in this list, feel free to add them. After all, that's why this is a Wiki.

Tool Improvements

  • TBD
  • Thanks again to Ralf, it is possible to provide target specific versions of the development tools. This is important when GCC drops support for an old architecture or we are avoiding target specific bugs in a particular tool version. Nominally, most RTEMS targets will use the same tools and they have been upgraded to the following versions:
    • autoconf 2.63
    • automake 1.10.1
    • binutils 2.19
    • gcc 4.4.x (expected) for C/C++ with newlib 1.17.0
    • gdb 6.8

The latest patch for each tools is in rtems/contrib/crossrpms/patches.

RTEMS Improvements

In this section, we discuss public API level changes as well as improvements to the implementation of those API routines.

Public API changes usually fall into one of the following categories:

  • Addition of new methods
  • Modifications to prototypes
  • Deletion of obsoleted methods

Implementation improvements usually fall into one of the following categories:

  • Algorithm improvements in execution time or memory usage
  • Critical section reduction

API Changes

  • A number of RTEMS specific types have been deprecated which are no longer necessary based upon the types provided by C99. user is encouraged to use C99 types. If you have application that uses these types, you can defined (RTEMS_DEPRECATED_TYPES when building your application to enabled them. They will be removed completely in a future release series and this is intended to be a transition release. The following types have been deprecated:
    • boolean, rtems_boolean (use bool, instead)
    • single_precision, rtems_single (use float, instead)
    • double_precision, rtems_double (use double, instead)
  • rtems_initialize_data_structures() now takes no arguments. This should impact no application or BSP as this was only referenced in shared framework code.
  • Region Manager directives now use intptr_t instead of size_t. The size_t type is defined to be able to represent the size of a SINGLE allocatable object. A region instance is intended to be able to hold multiple allocatable object instances and allocations from it should be able to represent pools of objects. This change should be transparent to the user. This impacted the following directives:
    • rtems_region_create
    • rtems_region_extend
    • rtems_region_get_segment

API Additions

  • Wei Shen submitted an implementation of POSIX pipes.
  • JoelSherrill submitted an implementation of getrusage().

API Implementation Improvements

  • TBD

Configuration Changes

  • The capability to have RTEMS operate with the RTEMS Workspace and C Program Heap as a combined pool. Historically, RTEMS has had separate memory pools for the RTEMS Workspace and C Program Heap. Having separate pools does have some advantages in the event a task blows a stack or writes outside its memory area. However, in low memory systems the overhead of the two pools plus the potential for unused memory in either pool is very undesirable. Similarly, in high memory environments, this is desirable when you want to use the RTEMS "unlimited" objects option. You will be able to create objects until you run out of all available memory rather then just until you run out of RTEMS Workspace. Define CONFIGURE_UNIFIED_WORK_AREAS to enable this configuration.
  • Filesystem support can be controlled by the user. By default, filesystem infrastructure is included, define CONFIGURE_APPLICATION_DISABLE_FILESYSTEM to disable filesystem support.
  • RTEMS now has a device-only filesystem which is smaller in size than miniIMFS and IMFS, define CONFIGURE_USE_DEVFS_AS_BASE_FILESYTEM to enable this configuration.
  • The Configuration Table has had the pointers to the Classic, POSIX, and ITRON API Configuration Tables removed. RTEMS now directly references the configuration information using variables which are assumed to have the names generated by confdefs.h. This resulted in a small reduction in data space and about 4.5% off the code space for minimum and hello on the SPARC with lesser reductions on the Thumb.
  • Provide a C linkage Init task prototype. By default the Init task now expects a pointer to a global command line string. Set this pointer to NULL is no command line is present. A shared BSP Init task is also provided with weak external linkage so you can now write an application that enters with main rather Init.
  • TBD

RTEMS Shell Improvements

The following improvements were made to the RTEMS Shell:

  • Reduced non constant memory usage.


  • SuperCore? Timestamp Handler added. This includes the capability to select struct timespec or int64_t as the data type used for internal RTEMS time management.
  • Heap and region now use intptr_t for size of memory pools and individual allocations. size_t is only defined to have a range large enough to represent the size of a SINGLE allocated object so this is necessary for correctness and to fix breakages on 16-bit targets.
  • RTEMS now supports configuring less than 256 priorities. During the 4.10 development cycle, all tests were run in a configuration that had a maximum of 16 priorities. This involved improvements to the tests to react to the number of priority levels not being a static value and fixed some bugs in the POSIX and ITRON API implementations.

BSPs and Device Drivers

  • General
    • Consolidation of various bsp_cleanup() implementations and a general push for as many BSPs as possible to use shared implementations. [Effort underway]
    • All BSPs have been modified to use the BSP Framework to allocate memory to RTEMS and the C Program Heap. It is now assumed that each BSP will provide an implementation of bsp_get_work_area() and it is HIGHLY encouraged that you use the shared one in libbsp/shared.
    • With the move to have more BSPs provide bsp_get_work_area() and use more of the BSP Framework, some BSPs no longer required BSP specific actions in bsp_start(). Now there is a stub implementation of this method for BSPs not requiring it.
    • Similarly, with the move to have more BSPs use more of the BSP Framework, most BSPs no longer require a BSP specific implementation of bsp_pretasking_hook() and can use the shared stub implementation.
  • LibI2C: Bus mutexes will be created now once during registration and not on the fly. Maybe addition of an asynchronous data transfer API.
  • SD Card Driver: Overall cleanup.
  • New BSPs
    • ARM/LPC24XX
      • Working: Startup, Exceptions, IRQ, Clock, Console
      • Testing: SSP (SPI)
      • Development: Network (This is currently delayed due to the <sarcasm>excellent</sarcasm> NXP support.)
  • Significant updates to existing BSPs
    • PowerPC/MPC55XX - Overall cleanup and improvements.

Test Suites

  • TBD


This section covers the API changes between the 4.9 and 4.10 release series which are expected to have an impact on application source code. This section does NOT cover additions to the API.

  • TBD

=Changes Per Point Release=

==Release 4.10.0 Changes==

When this happens, you will be the first to know. :)