定时器精度：QTimer就是个幌子
QTimer本质是依赖事件循环的，一旦界面有重绘、日志打印或者GC（别笑，QObject也有类似机制），触发就滞后。实测50ms间隔，抖动能到±8ms，这在工业上根本不能用。
先看失败的写法：
```cpp
// 错误示例：纯QTimer发送
QTimer *timer = new QTimer(this);
connect(timer, &QTimer::timeout, this() {
sendFrame(); // 实际触发时刻不可控
});
timer->start(10); // 标称10ms，实际12~18ms乱跳
```
坑点提醒：QTimer的精度取决于操作系统调度和事件循环负载，而且`Qt::CoarseTimer`（默认）精度是±5%，你设10ms它可能跑出15ms。
硬件定时器：Linux下用POSIX Timer
要稳定，得上硬件或系统级定时器。Linux环境用`timerfd_create`，它直接绑定内核高精度定时器，精度到纳秒级，不依赖Qt事件循环。
```cpp
#include <sys/timerfd.h>
#include <unistd.h>
#include <QSocketNotifier>
class CanSender : public QObject {
Q_OBJECT
public:
explicit CanSender(QObject *parent = nullptr) : QObject(parent) {
timer_fd = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK);
startPeriodic(10); // 10ms周期
notifier = new QSocketNotifier(timer_fd, QSocketNotifier::Read, this);
connect(notifier, &QSocketNotifier::activated, this, &CanSender::onTimer);
}
void startPeriodic(int ms) {
struct itimerspec spec;
spec.it_value.tv_sec = ms / 1000;
spec.it_value.tv_nsec = (ms % 1000) * 1000000L;
spec.it_interval = spec.it_value; // 周期触发
timerfd_settime(timer_fd, 0, &spec, nullptr);
}
private slots:
void onTimer() {
uint64_t expirations;
read(timer_fd, &expirations, sizeof(expirations)); // 清空计数器
sendFrame();
}
private:
int timer_fd;
QSocketNotifier *notifier;
};
```
坑点提醒：`timerfd_create`必须用`CLOCK_MONOTONIC`，别用`CLOCK_REALTIME`，否则系统改时间会打断你的周期。另外`read()`必须调用，否则事件永远触发。
时间戳补偿：别再打点发，要打点补
即使有硬件定时器，CAN总线本身也有仲裁延迟和从站处理时间。方案是：发送时记录系统时间戳，接收端用时间差做补偿，而不是硬等。
```cpp
#include <QElapsedTimer>
struct CanFrameWithTimestamp {
QCanBusFrame frame;
qint64 timestamp_ms; // 发送时刻的系统时间
};
void CanSender::sendFrame() {
QCanBusFrame frame;
frame.setFrameId(0x123);
QByteArray payload = "AT"; // 模拟数据
frame.setPayload(payload);
CanFrameWithTimestamp wrapped;
wrapped.frame = frame;
wrapped.timestamp_ms = QElapsedTimer::currentTime(); // 记录发送瞬间
pending_queue.enqueue(wrapped);
// 实际通过SocketCan发送
socket->writeFrame(frame);
}
```
然后在接收端，用收到时间减去发送时间，算出实际延迟：
```cpp
void CanReceiver::onFrameReceived(const QCanBusFrame &frame) {
qint64 recv_ms = QElapsedTimer::currentTime();
if (pending_queue.isEmpty()) return;
auto expected = pending_queue.head().timestamp_ms;
qreal jitter = recv_ms - expected - 10; // 10ms是理想周期
// 如果抖动 > 2ms，补偿下一帧发送时刻
if (jitter > 2.0) {
sender->nextDelay_ms = jitter * 0.5; // 简单PID里的P
}
}
```
坑点提醒：计算补偿时别用`QTime::currentTime()`，它是墙钟时间，单位是毫秒但精度差且受系统时间调整影响。要用`QElapsedTimer`或者`std::chrono::steady_clock`，单调递增不跳变。
实测数据：校准前后对比
我这边用USB-CAN适配器+示波器抓波形，跑了一个小时：
| 方案 | 平均周期（ms） | 最大抖动（±ms） |
|------|---------------|----------------|
| QTimer | 12.3 | 8.7 |
| timerfd | 10.02 | 0.8 |
| timerfd+补偿 | 9.98 | 0.3 |
补偿后基本贴合10ms，跑24小时无漂移累积。注意别在槽函数里做耗时操作，`sendFrame`要直接写SocketCan，别做拷贝或日志。
结尾总结
-
别用QTimer做硬实时，它就是玩具
-
`timerfd_create` + `QSocketNotifier`是Linux下最优解
-
时间戳用`QElapsedTimer`，别用墙钟时间
-
补偿用简单比例控制就行，PID调不好反而振荡
-
实测前先在示波器上校准，别信软件日志的时间