RTEMS Centre
  RTEMS Centre
User Login  
RTEMS Centre

Support

Downloads

Users
There are 1 unlogged user and 0 registered users online.

You can log-in or register for a user account here.

RTEMS Super Core

The following sections describe some of the main handlers files that belong to the supercore of the RTEMS, each section represent each component. A brief description is provided, a rough class diagram of the component, each file associated with the component, function description, definitions, enumerations and type definitions.

1 - Address Handler

This handler encapsulates functionality which abstracts address manipulation in a portable manner.

Figure 1: Address Handler Class Diagram.

  1. address.inl (macro and inline)
    • _Addresses_Add_offset: This function is used to add an offset to a base address. It returns the resulting address. This address is typically converted to an access type before being used further.
    • _Addresses_Is_aligned: This function returns TRUE if the given address is correctly aligned for this processor and FALSE otherwise. Proper alignment is based on correctness and efficiency.
    • _Addresses_Is_in_range: This function returns TRUE if the given address is within the memory range specified and FALSE otherwise.
    • uint32_t _Addresses_Subtract: This function is used to subtract two addresses. It returns the resulting offset.
    • _Addresses_Subtract_offset: This function is used to subtract an offset from a base address. It returns the resulting address. This address is typically converted to an access type before being used further.

  2. address.h
    • This file contains the information required to manipulate physical addresses.

2 - API Extensions Handler

This handler encapsulates functionality which provides mechanisms for the SuperCore to perform API specific actions without there being "up-references" from the SuperCore to APIs. If these references were allowed in the implementation, the cohesion would be too high and adding an API would be more difficult. The SuperCore is supposed to be largely independent of any API.

Figure 2: API Extensions Handler Class Diagram

  1. apiext.h
    • API_extensions_Postdriver_hook: This type defines the prototype of the Postdriver Hook.
    • API_extensions_Postswitch_hook: This type defines the prototype of the Postswitch Hook.
    • API_extensions_Predriver_hook: This type defines the prototype of the Predriver Hook
    • _API_extensions_List: This is the list of API extensions to the system initialization.

  2. apiext.c
    • _API_extensions_Add: This routine adds an extension to the active set of API extensions.
    • _API_extensions_Initialization: This routine initializes the API extension handler.
    • _API_extensions_Run_postdriver: This routine executes all of the postdriver callouts.
    • _API_extensions_Run_postswitch: This routine executes all of the post context switch callouts.
    • _API_extensions_Run_predriver: This routine executes all of the predriver callouts.

3 - Internal Error Handler

This handler encapsulates functionality which provides the foundation internal error services used in all of the APIs supported by RTEMS.

Figure 4: Internal Error Handler Class Diagram

  1. interr.h
    • Internal_errors_Core_list: A list of errors which are generated internally by the executive core.
      • INTERNAL_ERROR_NO_CONFIGURATION_TABLE;
      • INTERNAL_ERROR_NO_CPU_TABLE;
      • INTERNAL_ERROR_INVALID_WORKSPACE_ADDRESS;
      • INTERNAL_ERROR_TOO_LITTLE_WORKSPACE;
      • INTERNAL_ERROR_WORKSPACE_ALLOCATION;
      • INTERNAL_ERROR_INTERRUPT_STACK_TOO_SMALL;
      • INTERNAL_ERROR_THREAD_EXITTED;
      • INTERNAL_ERROR_INCONSISTENT_MP_INFORMATION;
      • INTERNAL_ERROR_INVALID_NODE;
      • INTERNAL_ERROR_NO_MPCI;
      • INTERNAL_ERROR_BAD_PACKET;
      • INTERNAL_ERROR_OUT_OF_PACKETS;
      • INTERNAL_ERROR_OUT_OF_GLOBAL_OBJECTS;
      • INTERNAL_ERROR_OUT_OF_PROXIES;
      • INTERNAL_ERROR_INVALID_GLOBAL_ID;
      • INTERNAL_ERROR_BAD_STACK_HOOK;
      • INTERNAL_ERROR_BAD_ATTRIBUTES.
    • Internal_errors_Source: This type lists the possible sources from which an error can be reported.
      • INTERNAL_ERROR_CORE;
      • INTERNAL_ERROR_RTEMS_API;
      • INTERNAL_ERROR_POSIX_API;
      • INTERNAL_ERROR_ITRON_API.
    • Internal_errors_What_happened: When a fatal error occurs, the error information is stored here.

  2. interr.c
    • _Internal_error_Occurred: This routine is invoked when the application or the executive itself determines that a fatal error has occurred.

4 - ISR Handler

This handler encapsulates functionality which provides the foundation ISR services used in all of the APIs supported by RTEMS.

Figure 5: ISR Handler Class Diagram 1

Figure 6: ISR Handler Class Diagram 2

Figure 7: ISR Handler Class Diagram 3

Figure 8: ISR Handler Class Diagram 4

Figure 9: ISR Handler Class Diagram 5

  1. isr.h
    • _ISR_Disable: This routine disables all interrupts so that a critical section of code can be executing without being interrupted. Upon return, the argument _level will contain the previous interrupt mask level.
    • _ISR_Enable: This routine enables interrupts to the previous interrupt mask LEVEL. It is used at the end of a critical section of code to enable interrupts so they can be processed again.
    • _ISR_Flash: This routine temporarily enables interrupts to the previous interrupt mask level and then disables all interrupts so that the caller can continue into the second part of a critical section. This routine is used to temporarily enable interrupts during a long critical section. It is used in long sections of critical code when a point is reached at which interrupts can be temporarily enabled. Deciding where to flash interrupts in a long critical section is often difficult and the point must be selected with care to ensure that the critical section properly protects itself.
    • _ISR_Get_level: This routine returns the current interrupt level.
    • _ISR_Install_vector: This routine installs new_handler as the interrupt service routine for the specified vector. The previous interrupt service routine is returned as old_handler.
    • _ISR_Set_level: This routine sets the current interrupt level to that specified by new_level. The new interrupt level is effective when the routine exits.
    • ISR_INTERRUPT_MAXIMUM_VECTOR_NUMBER: This constant promotes out the highest valid interrupt vector number.
    • ISR_NUMBER_OF_VECTORS: This constant promotes out the number of vectors truly supported by the current CPU being used. This is usually the number of distinct vectors the cpu can vector.
    • ISR_Handler: Return type for ISR Handler.
    • ISR_Handler_entry: Pointer to an ISR Handler.
    • ISR_Level: The following type defines the control block used to manage the interrupt level portion of the status register.
    • ISR_Vector_number: The following type defines the type used to manage the vectors.
    • _ISR_Nest_level: The following contains the interrupt service routine nest level. When this variable is zero, a thread is executing.
    • _ISR_Signals_to_thread_executing: The following is TRUE if signals have been sent to the currently executing thread by an ISR handler.
    • _ISR_Vector_table: The following declares the Vector Table. Application interrupt service routines are vectored by the ISR Handler via this.
  2. isr.c
    • _ISR_Handler_initialization: This routine performs the initialization necessary for this handler.
  3. isr.inl
    • _ISR_Is_valid_user_handler: This function returns TRUE if handler is the entry point of a valid use interrupt service routine and FALSE otherwise.
    • _ISR_Is_vector_number_valid: This function returns TRUE if the vector is a valid vector number for this processor and FALSE otherwise.

 

For more information contact by mail to: info@rtemscentre.edisoft.pt

[Printer friendly page]
  RTEMS Centre 2010