Linux
-
为什么需要专门搭建便捷开发环境：交叉开发模式的痛点
对于嵌入式Linux开发者来说，最影响开发效率的往往不是代码编写本身，而是繁琐的调试流程：更新内核要反复拔插SD卡，测试应用要每次编译后手动传输文件，看日志还要一直守着串口线。一套便捷高效的开发环境，能把调试流程从十几分钟压缩到几秒钟，让开发者把精力集中在功能开发本身，而非重复的机械操作。
-
RISC-V启动的基础逻辑
当我们谈论RISC-V的设计特色，讨论得最多的往往是它开源开放的属性、模块化的指令集设计，还有灵活的特权级架构。但很少有人会深入拆解它的启动流程，去品味这套架构在启动阶段设计里藏着的巧思。我自己在做RISC-V嵌入式开发的过程里，对比过ARM、MIPS这些传统架构的启动流程，越研究越觉得RISC-V的启动设计不简单——它没有像x86那样复杂的BIOS标准，也没有走ARM那套固定BL阶段的设计路线，反而用一套极简的架构逻辑，适配了从微控制器到服务器CPU的全场景需求。
-
Linux中线程和进程到底是什么关系？
在操作系统学习和后端开发面试中，“线程间共享哪些资源、又隔离哪些资源”是一个高频问题，很多人对此一知半解：只记得“线程共享进程地址空间”，但具体到哪些内存区域、哪些资源是共享的，哪些是线程私有，总是说不清楚。实际上，理解线程的资源共享模型，是理解并发编程、线程安全、进程线程关系的核心基础——很多并发bug的根源，就是错误地认为某个资源是线程私有，实际上它是共享的，或者反过来。
-
字节对齐的本质：适配CPU内存访问特性
在Linux系统的C语言开发中，字节对齐是一个绕不开的基础话题。很多开发者都遇到过这样的困惑：明明计算结构体大小时把每个成员的字节数加起来，结果实际大小却比计算值大上好几倍，甚至修改结构体成员的排列顺序，总大小还会发生变化——这背后就是字节对齐规则在起作用。字节对齐并不是C语言凭空设计出来的规则，它从CPU访问内存的硬件特性延伸而来，最终成为Linux系统下程序运行的底层基础逻辑，深刻影响着程序的运行效率、内存占用，甚至会成为隐式崩溃bug的来源。
-
Pinctrl子系统：芯片管脚的统一管理者
在嵌入式Linux开发中，管脚配置与GPIO控制是驱动开发的核心基础工作。从嵌入式单板到桌面级服务器，几乎所有硬件交互都离不开对芯片管脚的配置与管理。早期Linux内核没有统一的管脚管理框架，各个厂商的BSP代码各自为政，大量重复冗余的配置代码散落在内核各处，不仅维护成本极高，也让驱动开发者难以统一开发。为了解决这个问题，内核引入了Pinctrl子系统和GPIO子系统，形成了一套统一、规范的管脚管理体系。如今，这两个子系统已经成为Linux内核中管脚配置的标准框架，理解它们的设计原理与工作机制，是每一个嵌入式Linux驱动开发者必须掌握的基础。
-
内存分布的完整结构详解
不管是新手入门还是开发多年的工程师，理解程序运行时的内存分布，都是读懂底层运行逻辑、排查内存问题、写出高效代码的基础。很多人只知道写代码申请变量，却不知道这些变量在内存里到底放在哪里，不同区域的特性有什么区别，遇到内存越界、栈溢出这些问题的时候就一头雾水。
-
Linux GPIO子系统的核心设计思想
GPIO(通用输入输出口)是嵌入式Linux开发中最基础也最常用的硬件资源，小到LED闪烁、按键检测，大到外设控制、引脚扩展，都离不开GPIO操作。不同于裸机开发中直接操作寄存器的方式，Linux内核提供了一套成熟的GPIO子系统框架，统一了不同平台的GPIO操作接口，开发者不需要关心硬件底层细节，只需要调用通用API就能完成GPIO驱动开发。
-
Linux字符设备的基本概念
字符设备是Linux中最基础的设备类型之一，键盘、鼠标、串口、I2C设备、LED驱动这类常用的嵌入式设备，大多都属于字符设备，掌握字符设备驱动的基本框架，是学习Linux驱动开发的第一步。Linux内核从早期的2.6版本到现在的6.x版本，字符设备驱动框架经过了多次演化，已经形成了一套成熟、规范的设计，把驱动开发中重复的通用逻辑都封装好了，开发者只需要实现硬件相关的操作即可。
-
编译工具链：匹配树莓派3B的架构选对版本
树莓派3B凭借低成本、高性能、丰富的外设资源，一直是嵌入式爱好者和开发者学习RTOS的热门平台，而RT-Thread作为国内生态最完善的开源实时操作系统，对树莓派3B有着完善的原生支持。但很多刚接触的开发者，往往卡在环境搭建这一步：不知道该选什么编译工具链、怎么配置内核、怎么烧录运行，折腾好几天都跑不起第一个示例程序。
-
如何使用 AIE DIALECTS 和 AIE API，在 AMD Ryzen AI Phoenix 上对输入信号进行频域中的相位变换
本节演示如何使用AIE DIALECTS和AIE API，在AMD Ryzen AI Phoenix中对复杂数字信号在频域进行“相位变换”。
-
从环视到监测：RK3576基于DMA-BUF零拷贝技术的车载双视觉系统
在360环视系统的初始验证阶段，我们采用了一套直观且广泛使用的技术栈：OpenCV负责从采集到显示的全部图像处理任务。功能层面，这套方案完全跑通了——四路鱼眼去畸变、透视投影、鸟瞰拼接，所有算法逻辑均正确。但当我们将目光从「能不能跑」转向「能不能用」时，一个严峻的问题浮出水面：端到端延迟高达约300ms，远超25fps对应的40ms帧预算。
-
Linux最大并发数到底受什么限制？
谈到Linux的最大并发数，很多开发者会本能想到系统配置里的ulimit -n，觉得改大这个值就能支持更多并发，甚至默认“Linux最大并发可以到几十万上百万”。但实际生产环境中，经常遇到明明把文件句柄数改到了10万，并发跑到几万系统就崩了的情况。到底Linux的最大并发数有没有固定值?它到底受哪些因素限制?我们该怎么合理规划并发数?其实这个问题没有标准答案，需要从系统资源、网络协议、应用场景多个维度拆解，才能搞清楚真正的瓶颈在哪里。
-
实际开发中，系统调用相关的常见问题
当我们在代码里调用read读取文件，调用malloc分配内存，调用socket创建网络连接的时候，最终都会落到系统调用上。但很多开发者只知道系统调用是用户程序请求内核服务的接口，却说不清系统调用到底是怎么实现的：为什么用户程序不能直接访问内核?从用户态到内核态的切换到底发生了什么?不同架构下系统调用的实现有什么区别?其实系统调用的实现逻辑，恰恰是理解操作系统隔离设计的核心入口，把这个流程拆解清楚，就能明白用户程序和内核的交互本质。
-
纳秒级抖动×24h零丢帧：米尔RK3576工业级EtherCAT主站全拆解
在工业自动化现场，我们时常听到这样的抱怨："明明 Linux 上跑个 EtherCAT 主站协议栈很简单，可一到多轴联动、精密组装这类场景，周期一不小心就'飘'了，轨迹抖得让人心慌。" 问题就出在"硬实时"三个字上。要在通用操作系统上实现微秒级的确定性与低抖动，一直是机器人、多轴运动控制、半导体设备等高精度场景落地的关键挑战。
-
容器隔离的底层逻辑与逃逸本质
在云原生技术蓬勃发展的今天，容器凭借轻量、高效、可移植的特性，成为构建现代应用的核心载体。然而，容器并非绝对安全的“隔离堡垒”——当内核存在漏洞时，攻击者可通过容器逃逸突破隔离限制，直接获取宿主机的控制权，进而威胁整个集群的安全。
-
一文深入解析Linux可执行文件如何装载进虚拟内存
在探讨Linux可执行文件如何装载进虚拟内存之前，我们首先需要理解虚拟内存这一核心概念。虚拟内存是计算机系统内存管理的一种关键技术，它为应用程序构建了一个看似连续完整的地址空间，让程序认为自己拥有一块独立且连续的内存区域。但实际上，这块"内存"可能由多个物理内存碎片组成，甚至有部分数据暂时存储在外部磁盘存储器上，当程序需要时再进行数据交换。
-
GDB调试的基础：硬件与操作系统的支撑
在软件开发过程中，调试是定位和解决问题的关键环节。GDB(GNU Debugger)作为Linux平台下最常用的调试工具，支持对C、C++等多种语言程序的调试，能够帮助开发者监控程序执行、检查变量值、定位崩溃原因。然而，GDB的强大功能背后，是一套复杂的底层实现机制。
-
Linux设备驱动开发：基于Device Tree的I2C/SPI外设驱动编写与中断线程化处理
随着嵌入式Linux系统的复杂度不断增加，设备驱动开发面临着新的挑战。传统的内核编码方式已难以满足现代SoC平台硬件配置的灵活性和可维护性需求，而设备树（Device Tree）技术的引入，彻底改变了Linux内核与硬件平台的交互方式。本文将深入探讨基于设备树的I2C/SPI外设驱动开发，并重点解析中断线程化这一提高系统实时性的关键技术。
-
Zynq/SoC开发难点：PS端Linux驱动与PL端自定义IP核的DMA数据交互实战
在Zynq/SoC异构计算平台开发中，PS（Processing System）端运行Linux系统与PL（Programmable Logic）端自定义IP核之间的高速数据交互是核心挑战之一。DMA（直接内存访问）技术作为解决这一难题的关键，能够实现不占用CPU资源的大数据量传输。本文将深入探讨基于AXI DMA的完整实现方案，分享实战中的关键步骤与常见陷阱。
-
解锁调试效率之关于GDB需要了解的技巧
在Linux环境下的C/C++开发中，程序调试是排查问题、优化性能的核心环节。GDB(GNU Debugger)作为一款功能强大的命令行调试工具，凭借其精细的控制能力和丰富的功能，成为开发者不可或缺的利器。然而，GDB的学习曲线较陡，许多开发者仅停留在基础使用阶段，未能充分发挥其潜力。
