Context:
We are using the MCAL drivers with our own system, which does not AUTOSAR. I’m trying to understand exactly how we can handle errors from the MCAL layer using the following AUTOSAR modules:
In the paper attached to this post “SDK/MCAL to Real Time Drivers”, the following statement is made in Section 3.6
“The RTD provide a “stub” implementation of these ASR modules, which can be used or overwritten by the customer application”
We are currently using the SDK version below:
In that folder, there are all the MCAL drivers offered by the platform, as well as the stub files for the DET & DEM modules (DEM example shown below)
These files have stub functions in them, as mentioned, but this raises several questions that we would like to ask:
Questions:
1.Do I have to implement these stub files & modules at all?
2. If I were to Implement these files, would I do so in the location of the stub files?
Thanks in advance for your time and help!
Solved! Go to Solution.
Hello @MateoSegura413,
1. Some drivers would report errors through DEM/DET according to their AUTOSAR requirements. It's up to application layer to whether implement its own custom errors report mechanism, or take advantage of DEM/DET error reporting. I would suggest to use the DEM/DET error reporting, since these DEM/DET APIs provide hints of errors (e.g. in case of an inappropriate configuration structure is put into the function, an E_PARAM_POINTER will be reported to DET, with corresponding module ID)
2. Because DEM/DET are stubs in RTD package, eventually you wouldn't have to update them, or just would have to modify some minor changes regarding the file versions, if there are new upcoming release. You can even create your own DEM/DET drivers: it's not mandatory to implement directly inside the DEM/DET stub location.
Best Regards,
Nam
Hello @MateoSegura413,
1. Some drivers would report errors through DEM/DET according to their AUTOSAR requirements. It's up to application layer to whether implement its own custom errors report mechanism, or take advantage of DEM/DET error reporting. I would suggest to use the DEM/DET error reporting, since these DEM/DET APIs provide hints of errors (e.g. in case of an inappropriate configuration structure is put into the function, an E_PARAM_POINTER will be reported to DET, with corresponding module ID)
2. Because DEM/DET are stubs in RTD package, eventually you wouldn't have to update them, or just would have to modify some minor changes regarding the file versions, if there are new upcoming release. You can even create your own DEM/DET drivers: it's not mandatory to implement directly inside the DEM/DET stub location.
Best Regards,
Nam
Thank you for your help Nam.