Hi There,
I need some informations about Real Time Enviroment (RTE) SchM_<driver>.c, present in S32k RTDs.
In particular, I noticed that, instead of a simple "enable interrupt/disable interrupt" -critical section approach, a more complex one is used:
in particular: SchM_Enter_<driver>_<DRIVER>_EXCLUSIVE_AREA_<xx>() and SchM_Exit_<driver>_<DRIVER>_EXCLUSIVE_AREA_<xx>() methods are implemented (where <driver> is the driver name and <xx> is an incrementing number
1) could you explain me the ratio under this implementation ? How have I use these functions in my code ? Why the suddivision for <drivers> and for <xx>
2) If I use this in application, which <driver>/<xx> ones shall I use? shall I check the implemented ones, in the RTD, before choosing one?,
Best Regards.
Fabio
Solved! Go to Solution.
Hello,
NXP provides stubs for AUTOSAR SchM integration. If you are targeting AUTOSAROS, these will need to be replaced by the BSW integrator.
These numbers do not have a meaning other than indicating which register/variable accesses are being protected - See the Integration Manual for the respective module:
In the most simple case, this can simply disable/enable interrupts. See the Baremetal implementation. In the FreeRTOS case, these map to taskENTER_CRITICAL() and taskEXIT_CRITICAL() but this will be updated in the future as this is not sufficient for critical sections in interrupt context.
Best,
Bryan
Hello,
NXP provides stubs for AUTOSAR SchM integration. If you are targeting AUTOSAROS, these will need to be replaced by the BSW integrator.
These numbers do not have a meaning other than indicating which register/variable accesses are being protected - See the Integration Manual for the respective module:
In the most simple case, this can simply disable/enable interrupts. See the Baremetal implementation. In the FreeRTOS case, these map to taskENTER_CRITICAL() and taskEXIT_CRITICAL() but this will be updated in the future as this is not sufficient for critical sections in interrupt context.
Best,
Bryan