嵌入式Linux应用开发，有些坑真的没处说理去
上个月有个项目，要在i.MX6ULL上跑一个数据采集+转发的小东西。我寻思这活儿也不复杂，不就是打开串口读传感器，组个包，然后通过MQTT扔到云端么。在STM32上类似的逻辑我写过不下十个版本，半天就能搞定。
结果这一搞就是三天。
也不是代码多难写，就是整个思维方式要拧过来。今天就把那些让我"撞墙"的点掰扯掰扯。
你以为的"延时"和真正的延时
单片机里写个delay_ms(100)，那就是死等一百毫秒，CPU原地踏步啥也不干。但在Linux应用层，你敢sleep(1)——得，当前线程被操作系统挂起了，调度器决定啥时候把你换回来你说了不算。
// 你以为的1秒 sleep(1); // 实际上可能睡了1.2秒，也可能睡了0.8秒之前在一个数据采集任务里用定时器触发，每200ms读一次AD值。代码逻辑没问题，但跑了一段时间发现采集的时间戳总是漂移。嵌入式Linux不是硬实时系统，你sleep完了回来，时间误差只会累积。后来换成timerfd配合CLOCK_MONOTONIC，才算稳住。
int tfd = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK); struct itimerspec spec = { .it_interval = { .tv_sec = 0, .tv_nsec = 200 * 1000000 }, .it_value = { .tv_sec = 0, .tv_nsec = 200 * 1000000 } }; timerfd_settime(tfd, 0, &spec, NULL); // 然后丢到epoll里等就完事了坑就坑在：你得接受"差不多准"这件事，别指望200ms就是精确的200ms。
进程间通信真是个老大难
单片机项目里全局变量随便用，中断里extern一下就拿过来了。到了Linux应用层，一个功能拆成几个进程，你说这数据怎么传？
共享内存？你得处理同步。管道？数据量大了容易堵。socket？杀鸡用牛刀。
第一次搞的时候我选了消息队列，想着挺简单——一个进程往里塞，一个进程往外拿。
struct mq_attr attr = { .mq_maxmsg = 10, .mq_msgsize = sizeof(my_packet_t) }; mqd_t mq = mq_open("/sensor_data", O_CREAT | O_RDWR, 0664, &attr);看起来很美对吧？结果高负载下一测试，消息队列满了。mq_send直接阻塞住，采集线程卡死了，后面的数据全部丢了。最后发现要么开大队列深度，要么用非阻塞模式加上自己的丢弃策略，没有银弹。
其实吧，很多时候Unix domain socket反而是最稳的。看着重了点，但流控、多连接、select/epoll都给你安排得明明白白。
设备树？那玩意儿真不是驱动才用
刚转Linux的时候觉得设备树是内核驱动工程师的事，我写应用层的管它干啥。
直到有个项目GPIO死活拉不高。dmesg看内核报了个gpio_request失败，说该管脚已经被占用了。查了半天原理图，改设备树把管脚mux从某个功能切回GPIO模式，重编dtb，烧进去，好了。
你应用层再牛，底层引脚被其他模块占了你也没辙。
&i2c2 { status = "okay"; pinctrl-0 = <&pinctrl_i2c2>; mpu6050@68 { compatible = "invensense,mpu6050"; reg = <0x68>; interrupt-parent = <&gpio5>; interrupts = <7 IRQ_TYPE_EDGE_FALLING>; }; };我当时看着这堆dts代码一脸懵。后来发现跑一遍dtc -I dtb -O dts把编译好的dtb反解回dts，对着原理图一点点对引脚编号，才慢慢懂了。搞嵌入式Linux，设备树这东西你早晚得碰，躲不开。
调试方式也得变
单片机开发的时候，JLINK一挂，breakpoint一打，变量值实时看。到了Linux应用层，你还想gdb打断点？可以，但跑在ARM上的gdb远没有IDE里那么丝滑。
我最常用的三板斧：
strace简直是抓"系统调用失败"的神器。某个ioctl调用返回-1但你不知道为啥，strace -e ioctl一跑，errno都给你列出来。
# 就是这行命令救了我一下午 strace -p 1234 -e trace=read,write -o trace.logprintf大法其实在嵌入式Linux上挺好使——但不是往stdout打，而是syslog(LOG_DEBUG, "xxx")，然后tail -f /var/log/messages。比串口打印debug信息靠谱多了。
procfs读一下/proc/PID/status看看内存占用，/proc/PID/fd看看文件描述符泄漏了没。有次发现socket fd一直在涨，就是忘了close，排查起来全靠这招。
说到底
嵌入式Linux应用开发跟单片机完全是两套思维。单片机你控制一切，连着寄存器每个bit都能掐死。Linux你只是众多进程里的一个，调度器、内存管理、设备驱动全不由你说了算。你得学会跟这个操作系统"合作"，而不是"对抗"。
前几天又有新人问我：单片机裸机开发转嵌入式Linux，最难的是什么？
我说：不是你不会写代码，是你习惯了掌控一切，突然发现自己什么都掌控不了——这个心理关过了，剩下的都是语法问题。