Restrictions

• modelling. Rhapsody in C supports the so-called Operating System Abstraction Layer, but OSAL also includes services for which no code is generated like semaphores. In a product which uses the OO RTX without extentions for an RTOS, real task switching and preemptive scheduling is not possible, but scheduling is done on statechart level by using messages and by using a heartbeat like for example a timer interrupt. As a consequnce, no active classes are supported, but we will come back on this later.
• generated C code. The C code generated by Rhapsody is not using the Object eXecution Framework by IBM Rational, but the OO RTX with optional extentions for an RTOS instead. The Framework by Willert Software Tools uses slightly different data structures and a different organized set of include files, which is why we need to use those instead.
• files for properties and profiles.
• if this product comes with an implemented IDE interface the generated files will be deployed into your IDE project.

Modelling

• Active Classes:
  The OO RTX does not support preemptive multitasking. Thus it is not allowed to use active objects in the UML model. Scheduling between the UML model objects is done event driven (via the event queue). This mechanism is based on the run-to-complesion approach (e.g. a state's entry action commands need to be finished before another event can be consumed by any object).
• Activity Diagrams associated to Operations:
  Code generation is only supported for activity diagrams and statecharts which are associated with a class, an object or a file. Activity diagrams can also be assigned to operations, but no C code can be generated from them.
• Ports:
  Communication via UML ports is not yet implemented for C code generation in Rhapsody 6.2, but as of Rhapsody 7.0. Depending on your product, the property CPPCompileSwitches sets the constant WST_PORTS_DISABLED by default, to disable support for UML ports in the OO RTX to prevent extra code overhead.
  
  • The usable ports are restricted to simple behavioral ports. Through these ports it is possible to send events from one object to another without a tight coupling meeting defined interfaces.
  
  
  
  • the macro RiCGEN_PORT_ISR( Port, Event ) should not be used. The event is allocated dynamically which results to crashes when done within a ISR.

 Renesas M16C only

• Known Issue #1355: the IBM Rational Container Class RiCString does not support far string constants for M16C. As a workaround, the macros STR_ARGUMENT_TYPE and STR_RETURN_TYPE are introduced in WSTCompiler.h. The use of the RiCString Class is disencouraged.
• Known Issue #1440: the Renesas toolchain uses the keyword _far for dynamic memory using malloc(), free() etc. We advice to use the StaticComponent stereotype which prevents usage of these dynamic memory functions
  

OO RTX

• Timer objects
  Timeouts still can be modelled using timeout transitions like tm(...) and are implemented using events. There is no RiCOSTimer class.
• Semaphores
  There is no support as Rhapsody will not generate code needing them and you can not use them in your project code as well. In an event driven, mostly asynchronous software architecture there is no need to use semaphores. This also has the advantage that you will not run in typical semaphore problems like deadlocks and priority inversion. There is no RiCOSSemaphore class.
• Event Flags
  There is no RiCOSEventFlag class.
• Mutexes
  There is no support as Rhapsody will not generate code needing them and you can not use them in your project code as well. The OO RTX does not support preemptive multitasking and therefore does not need mutexes. This also has the advantage you will not run in typical mutex problems like deadlocks and priority inversion. There is no RiCOSMutex class.
• Tasks
  The OO RTX does not support preemptive multitasking. Thus it is not allowed to use active objects in the UML model. There is a RiCOSTask class, but it is only used internally by the OO RTX itself and may not be referenced by user code.
• Message Queues
  Events with arguments can be passed within your Rhpasody model. These are passed internally via pointers (call by reference). However, there is no RiCOSMessageQueue class.
• Sockets
  The OO RTX does not support communication via TCP/IP due to the heavy overhead. As a consequence there is no support for animation. There is no RiCOSSocket class. But it might be an alternative to use the Embedded UML Target Debugger.
• some UML elements can't be used together with C code generation. These are:
• Inheritance
  To allow inheritance in the C language, all operations would need to be implemented as callbacks or in a virtual function table. This would increase the code size, RAM needs, runtime and calling operations from user code would be more complicated. Thus no inheritance is available in Rhapsody in C.
• Active Classes
  The OO RTX does not support preemptive multitasking. Thus it is not allowed to use active objects in the UML model. Scheduling between the UML model objects is done event driven (via the event queue). This mechanism is based on the run-to-completion approach (e.g. a state's entry action commands need to be finished before another event can be consumed by any object).
• Activity Diagrams associated to operations:
  Code generation is only supported for activity diagrams and statecharts which are associated with a class, an object or a file. Activity diagrams can also be assigned to operations, but no C code can be generated from them by Rhapsody.
• Ports
  Communication via UML ports is not yet implemented for C code generation in Rhapsody 6.2, but as of Rhapsody 7.0.
  The property CPPCompileSwitches may set the constant WST_PORTS_DISABLED to disable support for UML ports in the OO RTX in a profile which comes with your release.
• Dynamic memory management.
  Use of malloc() and free() is not supported when the OO RTX is used in the form of a Shared Library PMF even when the constant NO_MALLOC is not set.

Animation

• Only instances of "Object" with the same name of the object are supported. This means if struct "Object_t" exists, the instance must be named "Object".
• Class instances daclared statically inside a user function will not be animated correctly. If a user does something like this:
  
  
  void Object_anyUserFunc( struct Object_t* const me )
  {
          Class myLocalInstance;
          Class_foo( &myLocalInstance );
  }
  
  
  it will not be animated correctly, as we do not parse the generated sources when generating the XML intermediate file.
  
• Only rective classes (with statecharts) can be animated.
• Statically preallocated event arrays are not supported for animation. These are used for example for calling CGEN_ISR to send an event from an interrupt.

IDE

All IDEs except uVision

CodeComposer and MPLAB IDEs only

Renesas HEW only

IAR Embedded Workbench only