In the code can be found that msrp is not completely supported yet,
While in the document
"ERIKA Enterprise Manual for the Altera
Nios II target" is suggested that it is supported.
Do you have already implemented it in some new version?
If so could you point me to the correct files?
Or can you explain me how to solve the problem?
#ifdef __MSRP__
#warning "MSRP multiprocessor kernel protocol is not completly supported!"
static void EE_oo_unlock_others(EE_UREG ResID)
{*/
/* TODO Understand what I need to do for global resources
* PSEUDO code:
* if(EE_oo_isGlobal(ResID))
* EE_hal_spin_out((EE_TYPESPIN)ResID);
* but i cannot rely on EE_GLOBAL_MUTEX flag!
* EG:
* Global resources are going to disappear!
*/
/*}
#else
#define EE_oo_unlock_others(ResID) ((void)0)
#endif
MSRP not completely supported?
Moderator: paolo.gai
Re: MSRP not completely supported?
Hi!
Long story here
- the MSRP algorithm I defined in the paper
Minimizing memory utilization of real-time task sets in single and multi-processor systems-on-a-chip, P Gai, G Lipari, M Di Natale, Real-Time Systems Symposium, 2001.
is implemented in the Nios II version available on the wiki. That version is a refinement of the initial version i implemented in 2001 on the Janus multicore.
- your note refer to the current SVN, which is NOT the code for Nios II. In fact...
- A few years after the writing of the Nios II support (2004-2006, then refined up to 2009 in the FRESCOR Project), people started to ask for AUTOSAR compliancy. that made us change the implementation in various ways:
- we had to remove the G-T implementation of queuing spinlocks, because there is an AUTOSAR requirement about removing tasks which are inside a spin lock
- no more "global" and "local" resources automatically defined by rt-druid depending on the mapping of tasks and their resource usage, because AUTOSAR has 2 separate APIs for resources and spin locks. My original implementation in 2001 redefined the getresource/releaseresource to behave differently on global resources. We used the MSBit (the mask is named EE_GLOBAL_MUTEX) to detect if it was a local resource (MSBit 0) or it was a global resourec (MSBit 1).
- synchronous and not asynchronous activations. --> This means using kernel/rpc instead kernel/rn directories. In my opinion the asynchronous implementation is the one which makes sense, the synchronous implementation however you make it is too slow.
The code you cite covers one of these problems that you start to have when trying to maintain MSRP "compatibility". sometimes we arrive to a point where... the AUTOSAR requirements are simply different or difficult to implement in the original MSRP implementation. The choice done in this case is to favour the AUTOSAR implementation, because that is what the user want.
Note also that the local/global automatic generation had reason to be there in 2002 because there was no RTE. nowadays, the spin-locks whould be generated by the RTE, and are transparent to the user. but if you do not use the RTE, then you have the same problem I had in 2002 that I solved in the way you know.
Finally note that tyhe OO/AS directopries will go towards a mimic of the AUTOSAR API. If you do research take a look at FP/EDF/FRSH/HR kernels, which are simpler to manage for a student IMHO (but they lack all the OSEK/AUTOSAR bell & wistles).
I hope this helps...
PJ
Long story here
- the MSRP algorithm I defined in the paper
Minimizing memory utilization of real-time task sets in single and multi-processor systems-on-a-chip, P Gai, G Lipari, M Di Natale, Real-Time Systems Symposium, 2001.
is implemented in the Nios II version available on the wiki. That version is a refinement of the initial version i implemented in 2001 on the Janus multicore.
- your note refer to the current SVN, which is NOT the code for Nios II. In fact...
- A few years after the writing of the Nios II support (2004-2006, then refined up to 2009 in the FRESCOR Project), people started to ask for AUTOSAR compliancy. that made us change the implementation in various ways:
- we had to remove the G-T implementation of queuing spinlocks, because there is an AUTOSAR requirement about removing tasks which are inside a spin lock
- no more "global" and "local" resources automatically defined by rt-druid depending on the mapping of tasks and their resource usage, because AUTOSAR has 2 separate APIs for resources and spin locks. My original implementation in 2001 redefined the getresource/releaseresource to behave differently on global resources. We used the MSBit (the mask is named EE_GLOBAL_MUTEX) to detect if it was a local resource (MSBit 0) or it was a global resourec (MSBit 1).
- synchronous and not asynchronous activations. --> This means using kernel/rpc instead kernel/rn directories. In my opinion the asynchronous implementation is the one which makes sense, the synchronous implementation however you make it is too slow.
The code you cite covers one of these problems that you start to have when trying to maintain MSRP "compatibility". sometimes we arrive to a point where... the AUTOSAR requirements are simply different or difficult to implement in the original MSRP implementation. The choice done in this case is to favour the AUTOSAR implementation, because that is what the user want.
Note also that the local/global automatic generation had reason to be there in 2002 because there was no RTE. nowadays, the spin-locks whould be generated by the RTE, and are transparent to the user. but if you do not use the RTE, then you have the same problem I had in 2002 that I solved in the way you know.
Finally note that tyhe OO/AS directopries will go towards a mimic of the AUTOSAR API. If you do research take a look at FP/EDF/FRSH/HR kernels, which are simpler to manage for a student IMHO (but they lack all the OSEK/AUTOSAR bell & wistles).
I hope this helps...
PJ