Hi,
All questions probably already have been answered. But I would like to provide some additional comments. Please see inline below.
/Peter Cigéhn
From: papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ernesto Posse
Sent: den 8 november 2017 16:25
To: papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Cc: lars.luthmann@xxxxxxxxxxxxxxxxxx
Subject: Re: [papyrus-rt-dev] Code generation questions (Papyrus-RT used in lecture)
A couple more comments in-line below:
Some answers inline below.
Charles Rivet
Senior Product Manager, Papyrus-RT product leader
Dear all,
the university of Darmstadt plans to use Papyrus-RT instead of a commercial tool in a lecture about real-time systems.
They asked me the following questions that they could not figure out in the documentation
- How to specify synchronous (blocking) invocations ?
As a general note, one must be careful in the use of synchronous signals in real-time embedded systems because of their blocking behavior.
That being said, there are “invoke” methods defined in UML-RT, but they are not implemented in the Papyrus-RT Runtime Services Library (RTS).
-
int invoke ( UMLRTMessage * replyMsgs );
-
int invokeAt ( int index, UMLRTMessage * replyMsg );
The stubs are there, but they are not implemented. If you want to write code these operations, we would be happy to incorporate it in the Papyrus-RT code base!
A workaround does exist in that you can boost the priority of the signals sent and received to simulate this functionality.
A “send” operation does have a field for the priority of the message:
-
bool send ( UMLRTPriority priority = PRIORITY_NORMAL ) const;
Where priority can be any of:
-
PRIORITY_SYNCHRONOUS = 0,
-
PRIORITY_SYSTEM,
-
PRIORITY_PANIC,
-
PRIORITY_HIGH,
-
PRIORITY_NORMAL,
-
PRIORITY_LOW,
-
PRIORITY_BACKGROUND,
-
PRIORITY_MAXPLUS1
By setting the priority at a high level, e.g., SYNCHRONOUS, the message will be one of the first processed as message queues as first processed in order of priority.
[epp] Indeed, you can use the PRIORITY_SYNCHRONOUS approach but you have to be aware that it isn't really synchronous. It just means that it is the highest possible priority.
[epp] Since 'invoke' is not yet implemented, the user has to manually do a send/acknowledgment protocol, e.g.: Capsule Sender sends a message in state S1 to capsule Receiver and waits for an acknowledgement reply with a transition from
S1 triggered by the reply message. The Receiver will have a transition for that message, and in the action of that transition, it sends back the acknowledgement.
[Peter Cigéhn] As already indicated, it is not really recommended to use the synchronous invoke/reply construct. There are numerous aspects to consider and
it causes a tight coupling between the capsules, e.g. the invoked capsule needs to know that it has to perform a reply and not a normal send. Depending on how the invoke/reply will be implemented in the run-time, there are few other aspects to consider. In
the legacy run-time you have the limitation that the sender and receiver must be allocated to the same physical thread, i.e. you cannot perform synchronous invocations between capsules mapped on different physical thread, which is probably something that should
be considered when implementing this in the run-time for Papyrus-RT.
- Is it possible to add additional #include to certain files?
Yes there is. There are stereotype properties that allow you to do this. If you add the “CapsuleProperties” stereotype, you will find the ability to specify include files (header/implementation preface/ending).
[epp] This assumes that the RtCppProperties profile is applied to the model. If the model was created with the wizard, selecting "UML-RT for C++" as the template in the "Initialization Information" dialog, will automatically apply this
stereotype.
[epp] I'm not sure if we have documentation on applying stereotypes, but just in case, the user needs to select a capsule in the Model Explorer, and go to the "Profile" tab in the "Properties" view, then click the [+] button and double-click the stereotype
to apply (e.g. CapsuleProperties) and click [OK]. Then the stereotype will appear under "Applied stereotypes". Unfold the stereotype and you will see all the properties that could be customized. Typically, additional #include statements are added under "headerPreface".
[epp] If you are using some class A in some capsule or class B, both defined in the same model, there is no need to manually add the inclusion of A.hh into the definition of B. This is done automatically. However, if you want to include
files defined as UML Artifacts, you can create a class diagram, drag-and-drop the client class and the artifact into the diagram and draw a Dependency between them. The include will be generated. Furthermore, there is a "DependencyProperties" stereotype which
can be used to control whether you want an #include or a forward reference.
- Is it possible to add additional code that is executed at the beginning of the generated main method?
If you mean before the main method is started, I don’t think so.
However, you can run code as part of the top capsule’s initial transition. At that point, the runtime system has been initialized and you would have access to all its services, but no other execution would have started.
This is the typical approach, for example, to read in command line parameters that could affect the system’s running configuration. There should be an example available on how to do this - let me know if this is of interest and I’ll find
it for you.
[epp] Indeed, modifying the main.cc is not supported, and I wouldn't recommend doing this, as the code in the main initializes the runtime system. Having said that, Papyrus-RT is open source, so you can always modify the main generator
(see org.eclipse.papyrusrt.codegen.cpp.structure.CppMainGenerator). Otherwise, you can write action code in the Top Capsule's state-machine's initial transition as Charles suggests.
[Peter Cigéhn] I assume that apart from these proposals, there is also the possibility of customizing the run-time itself. It has already been designed for
customization and when it comes to customizing the startup of the run-time you have the method UMLRTMain::targetStartup. The implementation of this method is kept in a separate source file, so it should be fairly easy to override and provide your own implementation
of this method. This could be useful if you want to make a target specific version of the run-time where you for example need to perform platform specific initialization, e.g. hardware drivers. Please check $UMLRTS_ROOT/umlrt/umlrtmaintargetstartup.cc. With
this approach it should be no need to modify the code generator as Ernesto proposed.
[epp] And one more thing, these sort of questions are great to ask in the Papyrus-RT forum [1].
I would encourage the prof at Darmstadt and his students to post their questions there.
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|
