hardbyte / hardbyte/python-can

PCAN MAC message ID type issue (c_ulong vs c_uint)

Open
#1,117 4 comments 0 reactions 0 assignees View on GitHub
backend:pcan bug os:macOS
Dominant language
Python
Stars
1.6k
Forks
697
PR merge metrics
No merged PRs in 30d

Description

# Description

Using PCAN interface on the mac using version >=0.9 of `libPCBUSB` results in ID and DLC errors.

The ID has unexpected bits well beyond bit 29.
And the DLC is always zero.

# Reproduce
install version >=0.9 of `libPCBUSB`.
Read a message from a connected device on a MAC using PCAN interface.

# Expected Behaviour

The ID will be 11 or 29 bits.
The DLC will be the data byte count in the message.

# Further explanation

I am using `python-can` on a MAC test some my firmware using a PEAK CANFD analyzer. The FW will loopback known messages.

The test python code is this:
```
import can

bus3 = can.interface.Bus(bustype='pcan')

def send_receive(m):
print(m)
bus3.send(m)
r = bus3.recv(1)
print(r)

messages = (
can.Message(extended_id=True, arbitration_id=0x3, is_fd=False, data=[0xf, 0, 0xf, 0]),
can.Message(extended_id=True, arbitration_id=0x1, is_fd=False, data=[]),
can.Message(extended_id=True, arbitration_id=0x4, is_fd=False, data=[]),
)

for mess in messages:
send_receive(mess)

```

The output is:

```
Timestamp: 0.000000 ID: 00000003 X DLC: 4 0f 00 0f 00
Timestamp: 128352589856006.984375 ID: 40200018000 S DLC: 0
Timestamp: 0.000000 ID: 00000001 X DLC: 0
Timestamp: 81064793768616.765625 ID: 200008000 S DLC: 0
Timestamp: 0.000000 ID: 00000004 X DLC: 0
Timestamp: 269934503141466.968750 ID: 200020000 S DLC: 0
```

`40200018000` is not a valid ID. And the DLC should be 4.

# Theory

The PCAN MACOS implementation specializes the `TPCANMsg` to use `c_ulong` instead of `c_uint`. This change was made about two years ago.

Looking at the `PCBUSB.h` file include in version 0.9 and 0.10 there is a statement to the effect that the ID has changed from 64 to 32 bits.
```
typedef struct tagTPCANMsg
{
DWORD ID; //!< 11/29-bit message identifier (ATTENTION: changed from 64-bit to 32-bit)
TPCANMessageType MSGTYPE; //!< Type of the message
BYTE LEN; //!< Data Length Code of the message (0..8)
BYTE DATA[8]; //!< Data of the message (DATA[0]..DATA[7])
} TPCANMsg;
```

To test this theory I changed `TPCANMsgMac`'s ID field to be type `c_uint`.

Rerunning the above code the result is correct:
```
Timestamp: 0.000000 ID: 00000003 X DLC: 4 0f 00 0f 00
Timestamp: 51791396190795.273438 ID: 00018000 X DLC: 4 0f 00 0f 00
Timestamp: 0.000000 ID: 00000001 X DLC: 0
Timestamp: 28710448100521.488281 ID: 00008000 X DLC: 0
Timestamp: 0.000000 ID: 00000004 X DLC: 0
Timestamp: 94294117674104.343750 ID: 00020000 X DLC: 0
```
(the ID in the response is supposed to be shifted up 15 bits).

# System

OS-version: 10.15.7
Python version: 3.7.4
python-can version: 3.3.4
python-can interface/s: PCAN

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.