Inconsistent handling of 29-bit CAN frame IDs in LISPBM

[gowrav]

There seems to be an issue with how LISPBM handles 29-bit CAN frame IDs. According to the documentation, LISPBM is capable of storing a maximum of 28 bits properly. However, CAN communication protocols sometimes require 29-bit frame IDs.

Currently, when LISPBM processes a 29-bit CAN frame ID, it loses the resolution, and sometimes the frame is interpreted incorrectly, particularly with the most significant bit (MSB) being dropped or misinterpreted. This results in potentially critical miscommunication between devices relying on these 29-bit CAN frames.

Steps to Reproduce:

Send a 29-bit CAN frame ID via the LISPBM.
Observe that the MSB of the frame ID is not correctly handled, leading to incorrect interpretations or data loss.

Expected Behavior: LISPBM should be able to handle the full 29-bit CAN frame IDs without losing resolution or misinterpreting the MSB. Proper resolution and interpretation should be implemented to support full CAN frame functionality.

Actual Behavior: The 29-bit CAN frame ID is not fully supported, leading to a loss in resolution, particularly with the MSB being dropped or misinterpreted.

Possible Solution: Expand the current bit storage capability in LISPBM to fully support 29-bit CAN frame IDs, ensuring that no bits are lost or misinterpreted, especially the MSB.

Environment:

LISPBM Version: V6.05
Hardware: Generic
Operating System: MACOS

Additional Context: This issue could have significant implications in applications where precise CAN communication is critical, particularly in automotive and industrial environments where 29-bit CAN IDs are commonly used.

[vedderb]

You can use 32-bit numbers by adding i32 to the end. For example 2345i32 and 0xF56ACBi32. When doing operations wit 32-bit numbers the result will be 32 bits.