Regarding CanIfTxPduRef & CanIfRxPduRef Parameters, in CanIfTxPduCfg & CanIfRxPduCfg respectively:
Discussion Date: Discussed in 05/01/2020 in the Meeting before merging the DevCan to the main branch and the CanIf_Containers branch to the DevCanIf branch.
Description in SWS: These parameters are reference to the "global" Pdu structure to allow harmonization of handle IDs in the COM-Stack.
Brief of our Discussion: We discussed for this part that for the CanIf and COM Stack whenever they need to be in sync and know what are the used IDs right now (i.e: when the COM Stack wants to know what is the ID that the CanIf is using now), so they have a reference that the CanIf points by it to the ID in the a global PDU structure and then, whenever the COM stack needs, the COM Stack checks this reference and sees what it is pointing to, in order to be in sync and harmonization with the CanIf.
and we do so because there is a Global PDU structure that has all the Msg IDs used in the whole project so whenever the CanIf is using one of them, it uses this reference to point to the used ID and then whenever the COM Stacks needs to know what the CanIf is using, it goes check for this reference.
Regarding including CanIfCtrlCfg Container in the CanIfCtrlDrvCfg Container:
Discussion Date: Discussed in 05/01/2020 in the Meeting before merging the DevCan to the main branch and the CanIf_Containers branch to the DevCanIf branch.
Description in SWS: This container contains the configuration (parameters) of an adressed CAN controller by an underlying CAN Driver module. This container is configurable per CAN
controller.Brief of our Discussion: in CanIfCtrlDrvCfg container, the included CanIfCtrlCfg container has to be configured for each CAN Controller used in our project (as mentioned in the description in the SWS).
so we should define this parameter's variable to be, for example, array of the number of used controllers. so it should be like this in the implementation:
CanIfCtrlCfgType CanIfCtrlCfgObj[USED_CONTROLLERS_NUMBER];
Where USED_CONTROLLERS_NUMBER has number of controllers in the project.
Regarding the CanIfTxPduCanIdMask, CanIfTxPduCanId & CanIfTxPduCanIdType Parameters and CanIfRxPduCanIdMask & CanIfRxPduCanId & CanIfRxPduCanIdType Parameters:
Discussion Date: Discussed in 05/01/2020 in the Meeting before merging the DevCan to the main branch and the CanIf_Containers branch to the DevCanIf branch.
Description in SWS: Identifier mask which denotes relevant bits in the CAN Identifier. This parameter may be used to keep parts of the CAN Identifier of dynamic transmit L-PDUs static. Range: 11 bits for Standard CAN Identifier, 29 bits for Extended CAN Identifier.
Brief of our Discussion: For the Msgs IDs, in order to know if this Msg ID is for Standard or Extended or FD. we use this mask to check for the MSB of the Msg ID, if its (For example) 1 so this means that this id is for Extended Can, if not so its for normal Can.
So we will use the Most Significant Half Byte (Most Significant 4 Bits) in the Msg ID to put the ID type in the MSB and Meta Data in the rest bits of the Last Most significant Half Byte (the 3 Bits before the MSB).
CanIf To Do List:
Regarding CanIfTxPduRef & CanIfRxPduRef Parameters, in CanIfTxPduCfg & CanIfRxPduCfg respectively: Discussion Date: Discussed in 05/01/2020 in the Meeting before merging the DevCan to the main branch and the CanIf_Containers branch to the DevCanIf branch. Description in SWS: These parameters are reference to the "global" Pdu structure to allow harmonization of handle IDs in the COM-Stack. Brief of our Discussion: We discussed for this part that for the CanIf and COM Stack whenever they need to be in sync and know what are the used IDs right now (i.e: when the COM Stack wants to know what is the ID that the CanIf is using now), so they have a reference that the CanIf points by it to the ID in the a global PDU structure and then, whenever the COM stack needs, the COM Stack checks this reference and sees what it is pointing to, in order to be in sync and harmonization with the CanIf. and we do so because there is a Global PDU structure that has all the Msg IDs used in the whole project so whenever the CanIf is using one of them, it uses this reference to point to the used ID and then whenever the COM Stacks needs to know what the CanIf is using, it goes check for this reference.
Regarding including CanIfCtrlCfg Container in the CanIfCtrlDrvCfg Container: Discussion Date: Discussed in 05/01/2020 in the Meeting before merging the DevCan to the main branch and the CanIf_Containers branch to the DevCanIf branch. Description in SWS: This container contains the configuration (parameters) of an adressed CAN controller by an underlying CAN Driver module. This container is configurable per CAN controller. Brief of our Discussion: in CanIfCtrlDrvCfg container, the included CanIfCtrlCfg container has to be configured for each CAN Controller used in our project (as mentioned in the description in the SWS). so we should define this parameter's variable to be, for example, array of the number of used controllers. so it should be like this in the implementation: CanIfCtrlCfgType CanIfCtrlCfgObj[USED_CONTROLLERS_NUMBER]; Where USED_CONTROLLERS_NUMBER has number of controllers in the project.
Regarding the CanIfTxPduCanIdMask, CanIfTxPduCanId & CanIfTxPduCanIdType Parameters and CanIfRxPduCanIdMask & CanIfRxPduCanId & CanIfRxPduCanIdType Parameters: Discussion Date: Discussed in 05/01/2020 in the Meeting before merging the DevCan to the main branch and the CanIf_Containers branch to the DevCanIf branch. Description in SWS: Identifier mask which denotes relevant bits in the CAN Identifier. This parameter may be used to keep parts of the CAN Identifier of dynamic transmit L-PDUs static. Range: 11 bits for Standard CAN Identifier, 29 bits for Extended CAN Identifier. Brief of our Discussion: For the Msgs IDs, in order to know if this Msg ID is for Standard or Extended or FD. we use this mask to check for the MSB of the Msg ID, if its (For example) 1 so this means that this id is for Extended Can, if not so its for normal Can. So we will use the Most Significant Half Byte (Most Significant 4 Bits) in the Msg ID to put the ID type in the MSB and Meta Data in the rest bits of the Last Most significant Half Byte (the 3 Bits before the MSB).