hardbyte / hardbyte/python-can

PCAN MAC message ID type issue (c_ulong vs c_uint)

Đang mở
#1,117 4 bình luận 0 reaction 0 người được giao Xem trên GitHub
backend:pcan bug os:macOS
Ngôn ngữ chính
Python
Star
1.6k
Fork
697
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Mô tả

# 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

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.