The issues described in this topic might be applicable
when you open projects that were created in the previous version of IBM® Rational® Rhapsody®.
Code Generation
- C, C++
- In previous versions of Rational Rhapsody,
global variable declarations appeared after function declarations
in generated code. Now, global variable declarations appear before
function declarations.
- The Embeddable property
now affects code generation
as it should. Previously, the relevant code was generated in the specification
file even in cases where it was supposed to be generated in the implementation
file.
- In certain situations, after roundtripping changes to
code, you
might find that the location of forward declarations in the generated
code is different than in the code generated by previous versions
of Rational Rhapsody.
- C
- In generated code, you
might find instances of previously uninitialized
variables being initialized.
- Animation
- When you generate code for animation with the current
version
of Rational Rhapsody,
the _OMINSTRUMENT ifdef that ordinarily surrounds
animation code now appears in a number of locations where it did not
previously.
- In order to improve the readability of animated
sequence diagrams,
the function OMADD_OMSER that is generated in animated
code now uses a second argument in addition to the single argument
that was generated in previous versions of Rational Rhapsody.
- Code-centric
- When working
with the CodeCentric settings, the Include Path you
specify during reverse engineering is now added to the makefile as
well.
- SDL_Suite Profile
- If you
are using the SDL_Suite profile in your project, you will find
changes in the code generated by Rational Rhapsody,
relative to the code that was generated previously for this profile.
- MicroC Profile
- When using the MicroC
profile, the function RiCTaskEM_init now
includes an additional parameter used to provide a pointer to a mutex.
Frameworks
For
Microsoft environments, RiCOSMutex implementation
in RiCOSNT.h and RiCOSNT.c is
now based on CriticalSection usage, as was already the case for C++.
(Ada still uses previous mechanism.)
In the C++ OXF, a number
of constant declarations in OMReactive.cpp were
modified in order to improve MISRA compliance.
As part of improvements
to the target monitoring feature, the following changes were made
to the C OXF:
- In the file RiCOxf.c,
a Boolean flag was
added to the function init to indicate whether the application should
exit if the animation connection is terminated. (No change was made
to the function called in user code, RiCOXFInit.)
- In the file RiCOxf.c, a new function
called RiCOXFInit_NoExitOnDisconnect was
added.
In the MXF, the following type definitions were
added to RiCTypes.h:
- typedef
signed char RiC_CHAR8; /* character ASCII128 */
- typedef
unsigned long int RiCUnLgInt;
- typedef const
void* RiCVtbl;
In this version of Rational Rhapsody,
changes were made in the MXF to RiCEvent, and to the way that code
is generated to represent events. These changes were made in order
to improve MISRA compliance:
- Previously, events were represented
by structs that contained
an RiCEvent struct and individual members that represented
each of the event arguments. Now, events are represented by RiCEvent structs,
and these structs now contain a pointer to a struct that contains
the event arguments.
- A similar change was made to RiCTimeout and
to
the code generated to represent timeouts. Previously, RiCTimeout contained
an RiCEvent struct as well as timeout-related data.
Now, timeouts are represented by an RiCEvent struct.
In this case, the pointer to the event data points to a RiCTimeout struct
that stores the timeout-related data.
In connection with
the RiCEvent-related changes,
a change has been made to the memory management for events in the
generated code. Instead of using RiCMemoryManager as
previously, each RiCEvent is allocated memory from
the pool whose size is determined by the value of the C_CG::Configuration::FrameworkEventsPoolSize property.
If the event has arguments, memory is allocated from the pool whose
size is determined by the value of the CPP_CG::Event::BaseNumberOfInstances property.
OSEK
adaptor enhancement - Instead of using RES_SCHEDULER
as a single mutex in an OSEK application, a dedicated mutex is now
used for each of the OSEK tasks defined in the model and in the MXF.
The
MXF Mainloop adaptor files previously found under $OMROOT\LangC\mxf\Adaptors\MainLoop\S12\Freescale are
now found under $OMROOT\LangC\mxf\Adaptors\MainLoop\Freescale\S12.
In
the various frameworks, the following new type has been added: typedef
const char* Rhp_const_char_pt This new type is now used frequently
in the frameworks.
The multimedia-timer-based implementation
of the OXF timer, which was introduced in version 7.5, is now used
by default. If you do not want to use this timer implementation, comment
out the appropriate macro definition:
- for C++, comment
out #define OM_USE_MULTIMEDIA_TIMER in ..\Share\LangCpp\osconfig\WIN32\omosconfig.h
- for C, comment out #define RIC_USE_MULTIMEDIA_TIMER in ..\Share\LangC\osconfig\WIN32\ricosconfig.h
In the OXF for C++, some identifier names were truncated to
satisfy the 31-character limit required for MISRA-compliance.
In
order to implement specific bug fixes and enhancements, changes were
made to the following framework methods:
- C
- RiCOSMessageQueue_get
- RiCDefaultReactiveOutbound_gen
- C++
- ~LinuxThread (destructor)
- getThreadEndClbk
- NTOSMessageQueue::get (in ntos.cpp)
- OMOS::endApplication (in VxOS.cpp and linuxos.cpp)
- OMThread::execute
- OXF::end
- AOM Library
- The
following changes were made to the AOM in order to deal with
the changes made to the structure of RiCEvent and
memory allocation for events in the MXF. All the changes made are
demarcated by the compilation flag #ifdef MICROC_OXF:
- Changes were made to the macros: RICE, OM_INSTRUMENT_EVENT,
OM_INSTRUMENT_EVENT_INSTANCE, NOTIFY_TAKE_EVENT
- Minor
code changes such as removing references to the RiCEvent member
of an event.
- TOM Library
- The method tomTrimCarriageReturn() was added
to toxf.cpp.
- In order to implement specific
enhancements, changes were made
to the method TOMInstance::notifyFlowDataReceive.
MXF Adaptors
A
number of methods have been
added to the API for the MXF adaptors (RiCOSOsek, RiCOSMainloop and
RiCOSAutosarRte).
If you have existing adaptors you have built,
you must implement these new methods as well in order to prevent compilation
problems.
The new methods fall into the following categories:
- to increase AUTOSAR compliance, methods were added for locking
and freeing a mutex used by the Timer Manager (as opposed to the general
RiCOSMutex_lock/free methods):
- RhpBoolean RiCOSTimerManagerMutex_lock(const
RiCOSMutex
*me)
- RhpBoolean RiCOSTimerManagerMutex_free(const
RiCOSMutex
*me)
- a number of methods were added for
locking/freeing a mutex that
is used to ensure mutual exclusion regarding access to the static
events pool. These methods were added as part of the Event-related
changes that were introduced to increase MISRA compliance.
- RhpVoid
RiCOSEventsPoolMutex_init(RhpVoid)
- RhpVoid
RiCOSEventsPoolMutex_lock(RhpVoid)
- RhpVoid
RiCOSEventsPoolMutex_free(RhpVoid)
XMI
When importing XMI data into Rational Rhapsody,
or exporting models to XMI, warnings and errors are now displayed
in the Rational Rhapsody Output
window, rather than in an external console window.