Q1>>如果目标网段的某CAN报文周期突然加快变成1ms的超快周期,LLCE是否会毫无管控的向目标网段透传该报文,意味着,目标网段该CAN报文周期也成为1ms,当然,也就意味着,整车所有网段可能都会因为负载率爆棚而无法工作。同时,LLCE本身或者S32G本身是否会因为这样的超快的转发任务而导致无法正常工作?
Q2>>源网段是64Byte的CANFD报文,LLCE能否拆分后向目标网段发送成8个8Byte的CAN报文?
Q3>>与Q2相反,源网段有8个CAN报文,LLCE能否组合后向目标网段发送成1个64Byte的CANFD报文?
Q4>>源网段是一个12Byte的Secured CAN报文(其中8个Byte为受保护的数据,另外4个Byte为SecOC信息,或称为SecOC外壳),而目标网段ECU的需求并不需要12Byte完整的CAN报文,仅需要里面的8Byte受保护的Payload,即8Byte的CAN报文,那么LLCE会如何处理?如何实现快速转发出去?与HSE如何配合?
Q5>>如果我当前得到的网关配置文件arxml是传统的路由配置(即,PDU路由),我该如何对这份arxml文件进行操作,将PDU路由转换成LLCE的Frame路由?NXP贵司是否有相应的工具支持?
Q6>>【Convert a CAN FD frame to CAN frame if payload length is less than 8 bytes.】这个feature从字面理解,如果payload刚好是8Byte的CANFD,就不能转成CAN了?因为你们材料上使用的词语为【is less than 8 bytes】
Q7>> LLCE的初始化时间是多少?会不会增加节点的启动时间
Q8>>S32G的LLCE数量是多少个?例如,我有1000个CAN报文直接转发的需求,S32G的LLCE都能支持
可以把这些问题的回答分享在这里吗?
Hi,
We see that you have created a case under the NXP online services with what it seems to be similar if not the same questions.
We have provided a follow-up under the case.
Please, let us know if you would like for us to mirror the information.
hi Daniel,
Yes i have push these questions into the 【Case: 00560433】
And today i translate the Chinese again to the English:>>>
Q1>>如果目标网段的某CAN报文周期突然加快变成1ms的超快周期,LLCE是否会毫无管控的向目标网段透传该报文,意味着,目标网段该CAN报文周期也成为1ms,当然,也就意味着,整车所有网段可能都会因为负载率爆棚而无法工作。同时,LLCE本身或者S32G本身是否会因为这样的超快的转发任务而导致无法正常工作?
Q1>>If a CAN message’s Cycle Time of the source BUS be accelerated to 1ms, will the LLCE transmit this CAN message to the target BUS without any control? And maybe all the target BUS will block. And at the same time, will the S32G can’t response the super fast [transmit task] ?
Q2>>源网段是64Byte的CANFD报文,LLCE能否拆分后向目标网段发送成8个8Byte的CAN报文?
Q2>> A source CAN message is CANFD format(64 Bytes),and now I want to split it to 8 CAN messages(each CAN message is 8 Bytes payload),so will LLCE can do it ?
Q3>>与Q2相反,源网段有8个CAN报文,LLCE能否组合后向目标网段发送成1个64Byte的CANFD报文?
Q3>>Contrary to Q2, the source BUS has 8 CAN messages, can LLCE combine them and send them to the target BUS as one 64Byte CANFD message?
Q4>>源网段是一个12Byte的Secured CAN报文(其中8个Byte为受保护的数据,另外4个Byte为SecOC信息,或称为SecOC外壳),而目标网段ECU的需求并不需要12Byte完整的CAN报文,仅需要里面的8Byte受保护的Payload,即8Byte的CAN报文,那么LLCE会如何处理?如何实现快速转发出去?与HSE如何配合?
Q4>>There is a 12Byte Secured CAN message (where 8 Bytes → bytes are protected data and the other 4 Bytes → bytes are SecOC information, or called SecOC shell) in the source BUS, while the target BUS ECU requirement does not need a 12 Byte complete CAN message, but only 8 Bytes → bytes of protected Payload → payload, i.e. 8Byte CAN message, how will LLCE handle it? How to realize fast forwarding out? How to cooperate with HSE?
Q5>>如果我当前得到的网关配置文件arxml是传统的路由配置(即,PDU路由),我该如何对这份arxml文件进行操作,将PDU路由转换成LLCE的Frame路由?NXP贵司是否有相应的工具支持?
Q5>>If the gateway configuration file arxml I got is a traditional routing configuration (i.e., PDU routing), how can I manipulate this arxml file to convert the PDU routing to LLCE Frame → Frame routing, and do you have any tools to support this? Because I don’t wanna Config again in the original arxml tools(now I used the PREEvision,you know that this PREEvision is so much tedious details need to do)
Q6>>【Convert a CAN FD frame to CAN frame if payload length is less than 8 bytes.】这个feature从字面理解,如果payload刚好是8Byte的CANFD,就不能转成CAN了?因为你们材料上使用的词语为【is less than 8 bytes】
Q6>>[Convert a CAN FD frame to CAN frame if payload length is less than 8 bytes.] This feature literally means that if the payload happens to be 8Byte CANFD, it cannot be converted to CAN? Because the words used in your material are [is less than 8 bytes],I guess it’s a little mistake description,the correction is 【Convert a CAN FD frame to CAN frame if payload length is ≤ 8 bytes.】
Q7>> LLCE的初始化时间是多少?会不会增加节点的启动时间
Q7>> What is the initialization time of LLCE? Will it increase the startup time of the S32G?
Q8>>S32G的LLCE数量是多少个?例如,我有1000个CAN报文直接转发的需求,S32G的LLCE都能支持?
Q8>> How many LLCE source for S32G? For example, I have a need for 1000 CAN messages to be forwarded directly, can all be supported by S32G's LLCE?
Hi,
Thanks for the update. We have provided feedback under the NXP internal case.
Please, let us know.