你看到的
日志中：
```
*data
:0x1d
215dbe
Get data from wiegand driver model
:1d
215dbe
wiegand card number
:1d
215dbe
val string BE5D
211D00000000
```
这些输出看似矛盾，但其实背后是 **数据在内存中的表示方式不同** 所导致的，核心原因是：
---
## 🔍 为什么是 `0x1d
215dbe` 而数据库中是 `BE5D
211D00000000`？
### ✅ 1. **`0x1d
215dbe` 是整数在小端系统下的值**
你执行了：
```c
memcpy(&uid_data, mbuf, sizeof(unsigned long));
```
假设 `mbuf` 的前4个字节是：
```c
{0xBE, 0x5D, 0x
21, 0x1D}
```
在 **小端（Little Endian）系统**（如 x86/x64）上，这会被解释为：
```c
uid_data = 0x1D
215DBE
```
所以你用 `%x` 输出就是：
```
1d
215dbe
```
这是整数的“逻辑值”。
---
### ✅ 2. **`BE5D
211D00000000` 是原始字节顺序的十六进制字符串表示**
你执行了：
```c
memcpy(msg.card_number_hex, mbuf, mlen);
```
假设 `mbuf` 是一个 8 字节数组：
```c
{0xBE, 0x5D, 0x
21, 0x1D, 0x00, 0x00, 0x00, 0x00}
```
然后你把这个字节数组按 **每个字节转成大写十六进制字符** 的方式写入数据库，结果就是：
```
BE5D
211D00000000
```
这是原始字节的“物理顺序”。
---
### ✅ 3. **hid
:0x1d
21 和 pid
:0x5dbe 的由来**
你在解析 Wiegand 数据时，可能将 `mbuf` 的前两个字节作为 `hid`，后两个作为 `pid`：
```c
hid = (mbuf[0] << 8) | mbuf[1]; // 0x1D
21
pid = (mbuf[2] << 8) | mbuf[3]; // 0x5DBE
```
这也解释了为什么：
```
hid
:0x1d
21
pid
:0x5dbe
```
---
### 🔄
小结对比表：
| 输出内容 | 来源 | 数据含义 | 字节顺序 |
|----------|------|-----------|------------|
| `0x1d
215dbe` | `uid_data` 整数输出 | `mbuf` 前4字节的小端整数表示 | 小端 |
| `1d
215dbe` | `snprintf("%x", uid_data)` | 整数转字符串，小写 | 小端 |
| `BE5D
211D00000000` | `memcpy(mbuf, ...)` 后转字符串 | 原始字节顺序，按大写输出 | 大端风格 |
| `hid
:0x1d
21` | `mbuf[0] << 8 | mbuf[1]` | 手动拼接高位在前 | 大端风格 |
---
### ✅ 如何统一输出？
如果你希望输出一致，比如都为 `BE5D
211D`，你有两种选择：
#### 方法一：保持字节顺序不变，直接转字符串
```c
char hex_str[
9];
for (int i = 0; i < 4; i++) {
sprintf(hex_str + i * 2, "%02X", mbuf[i]);
}
```
输出就是：`BE5D
211D`
#### 方法二：使用 htonl 统一整数顺序
```c
#include <arpa/inet.h>
uint
32_t uid_data;
memcpy(&uid_data, mbuf, 4);
uid_data = ntohl(uid_data); // 或 htonl(uid_data)，根据需求选择
snprintf(buf, 64, "%08X", uid_data);
```
输出为：`BE5D
211D`
---
###
作者分享了两个月以来学习ZYNQ的经验，涉及Linux、AXI、HLS、SDSoC等技术。面对OpenCV函数无法在HLS中使用的挑战，预示著一场艰苦的编码战役即将展开。
扫一扫
850
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
