圆形LCD液晶屏幕像素坐标如何划分的？

1、为什么“圆形LCD像素坐标”会成为问题？

圆形LCD在消费类产品里看起来只是“外形不同”，但在工业HMI、仪表盘、医疗设备等场景里，它往往承担刻度、指针、报警区域、触控热区等强语义信息。一旦坐标体系理解错误，常见后果不是“图形歪一点”，而是更隐蔽、更难定位的系统性问题：

1·圆心不居中：同心圆/表盘刻度出现偏心，视觉上“像装配歪了”，但根因可能是 X_OFFSET/Y_OFFSET 或扫描方向配置。
2·缺边/裁切：圆周一侧被切掉一条，通常是地址窗口（Address Window）边界与有效区不匹配。
3·触控与显示不一致：显示圆心正确但触控热区偏移，导致误触；在安全相关界面里尤其不可接受。
4·量产漂移：同一套软件在不同批次模组上出现边缘黑圈厚度不均，常与贴合公差、遮罩位置、驱动IC映射有关。

在安全相关系统中，界面与交互的“可预期性”会被纳入更严格的工程约束。以功能安全通用标准 IEC 61508 的风险导向方法论为例，核心思想是用风险评估确定安全功能需要达到的完整性水平，这类框架会把“误显示/误操作”视作潜在风险链条的一环。

而在环境适应性上，MIL-STD-810 强调通过环境应力的裁剪与试验方法来验证设备在全寿命周期条件下的可靠性，实际工程中温度、湿度、振动会放大贴合/结构偏差，使坐标偏移在极端条件下更容易暴露。

所以：圆形LCD的坐标问题，本质是“显示寻址、遮罩有效区、装配偏移、触控对齐”多因素耦合后的系统工程问题。

2、核心规范：圆形LCD为什么仍用矩形 (x,y) 寻址？

绝大多数圆形LCD在控制器层面仍以矩形像素矩阵定义分辨率，典型如 240×240。以常见圆屏驱动IC GC9A01A 为例，其数据手册就以 240×RGB(H) × 240(V) 的方式定义显示分辨率与输出通道。

之所以“看起来是圆的”，通常是因为圆外区域被黑矩阵/遮光油墨或结构件遮挡，而不是像素寻址变成了“极坐标像素”。

在命令与寻址层面，很多圆屏（SPI/QSPI、部分并口）采用与 MIPI 显示体系兼容的命令风格：

1·0x2A：Column Address Set（列地址范围）
2·0x2B：Page/Row Address Set（行地址范围）
3·0x2C：Memory Write（写入像素数据流）
4·0x36：Address Mode（扫描方向/镜像/旋转相关配置）

这些命令在工程文档与实现中经常被称为 DCS（Display Command Set）/DCS layer 的通用命令语义。

关键点：控制器的显存（GRAM）是矩形的，主控写入时也是按矩形窗口推进；“圆形”是在更上层通过遮罩/裁剪实现。

3、需要同时理解的“四层坐标”

圆形LCD工业液晶屏项目里，建议把坐标分成四层来看：物理像素坐标、GRAM坐标、UI逻辑坐标、触控坐标。它们经常被混用，导致“画不准/点不准/旋转乱套”。

坐标层	典型形式	原点/方向（常见约定）	范围示例（240×240）	主要用途	与像素的关系
物理像素坐标	(x, y)	左上(0,0)，x→右，y→下（可被旋转配置改变）	x∈[0,239], y∈[0,239]	描述“你想显示在哪个像素点”	最终落点
GRAM/寻址坐标	列/行窗口 + 写入顺序	由 Address Mode/扫描方向决定	由 0x2A/0x2B 设置窗口	高效刷屏、局部刷新	定义写入映射
UI逻辑坐标	(r, θ) 或归一化坐标	以圆心为基准（cx,cy）	r∈[0,R]	表盘/环形进度/扇形等	需投影到(x,y)
触控坐标（如有）	(tx, ty)（可能是0..4095或0..W/H）	由触控IC定义	依触控IC而定	点击/滑动输入	需标定映射到(x,y)

其中“圆形有效区”的最常用工程判定是：设圆心 (cx,cy)、半径 R，像素 (x,y) 满足(x−cx)2+(y−cy)2≤R2，则在圆内可绘制，否则属于圆外区域（可选择不绘制或填充背景）。这一步就是把“矩形寻址”裁剪成“圆形可视效果”的关键。

4、核心技术深挖对比

4.1 “圆形LCD坐标”的底层真相：GRAM永远是矩形地址空间

圆形LCD工控液晶模组（如常见 240×240）之所以仍能用 (x,y) 描述，是因为显示控制器内部的 GRAM（显示数据RAM）按“页(Page)/列(Column)”组织，也就是典型的二维矩形地址空间。GC9A01 系列数据手册明确描述：GRAM 中每个像素（18-bit）由 (Page, Column) 即 (Y, X) 地址定位，并可通过设置窗口（SC/EC、SP/EP）配合 RAMWR/RAMRD 从窗口起点进行连续访问。

这意味着：

你写入像素不是“写一个圆”，而是在矩形显存里写一段连续数据流；

“圆形效果”来自上层对圆外区域的遮罩/裁剪，而不是像素寻址本身变成极坐标。

Adafruit 的圆形 1.28“ 模组介绍也直白点出：它看起来像”方屏把边角削掉“，分辨率仍是 240×240，驱动 IC 为 GC9A01A，并且与 ST7789 的使用方式非常接近（SPI 写入像素缓冲）。

4.2 Address Window 如何把“坐标”变成“像素流”

在 SPI/QSPI 圆屏里，最核心的编程模型是 Address Window（地址窗口）+ 连续像素写入：

1·设定列地址范围（x start / x end）

2·设定行地址范围（y start / y end）

3·发送 Memory Write，后续数据按控制器内部计数器自动递增写入

这套语义在 MIPI DCS（Display Command Set）里是高度标准化的：

1·0x2A Column Address Set

2·0x2B Page Address Set

3·0x2C Memory Write

4·0x36 Address Mode / MADCTL（决定扫描方向、镜像、交换XY等）

含义：你在 API 层看到的 drawPixel(x,y)，最终都会被“批量化”为 setWindow(x0,y0,x1,y1) + pushColor(stream)，否则 SPI 带宽会被指令开销吞掉。

4.3 旋转/镜像的本质：不是“坐标系变了”，是“计数器映射规则变了”

很多人画圆不居中、画图像翻转，第一反应是“坐标定义错了”。更准确的说法是：MADCTL/Address Mode 改变了 GRAM 地址计数器到物理像素的映射。

以 ST7789 数据手册为例：它描述了窗口（XS/YS/XE/YE）与写入地址递增方式，并指出 CASET/RASET/MADCTL 的 MX/MY/MV 组合允许镜像与交换寻址方向；同时区分 horizontal/vertical addressing（MV=1 时 Y 地址先递增等）。

GC9A01 的资料也给出了由 D5/D6/D7 控制的映射组合（例如“列指针映射到物理列/或映射到(239-物理列)”等），本质同样是“寻址指针如何翻转/交换”。

推荐在驱动层做一层“逻辑坐标→物理坐标”的显式变换（而不是到处 if/else）：

设逻辑分辨率 W=240, H=240，逻辑坐标 (x,y)，偏移 (xo,yo)

以 0/90/180/270 四种 rotation 举例（不含镜像）：

rot=0:   x‘ = x           y’ = y

rot=90:  x‘ = W-1-y       y’ = x

rot=180: x‘ = W-1-x       y’ = H-1-y

rot=270: x‘ = y           y’ = H-1-x

再统一加上模组偏移：x_phy = x‘ + xo, y_phy = y’ + yo。

4.4 圆形裁剪：把“矩形寻址”变成“圆形有效区”

圆形 UI 的关键不是“地址怎么写”，而是圆外区域怎么处理。最基础判定：(x−cx)2+(y−cy)2≤R2

1·cx,cy 常取 (W-1)/2,(H-1)/2

2·R 不一定等于 W/2：很多模组圆外由黑矩阵/结构遮挡，实际可视半径往往略小，留 1——3 像素黑边反而更“干净”。

但在 SPI 屏上，逐像素判定会吃 CPU；更要命的是：如果你对每个像素都 setWindow+写1点，SPI 指令开销会让帧率崩盘。正确做法是：裁剪在算法层完成，写入在窗口层批量完成。

4.5 深度对比：四种“圆形绘制/裁剪”策略怎么选

策略	核心思路	CPU开销	RAM 开销	SPI/总线效率	画质可控性	适用场景	常见坑
逐点裁剪	每个像素算 dx²+dy²，圆内才画	高	低	低（若逐点写窗更糟）	中	UI 很简单、刷新区域很小	算法对了但帧率很差
扫描线段	每行求圆与该行交点 xL/xR，一次写一段连续像素	中	低	高	中-高	环形背景、表盘底图、填充扇形	交点取整不当会出现边缘毛刺
预计算	Mask/LUT预先存每行 xL/xR 或 bitmask，运行时不再算平方	低	中按实现	高	中-高	MCU 性能紧张但需要稳定帧率	LUT 与实际圆心/偏移不一致会“越画越歪”
分块/Tile + DMA（架构级）	把屏划分为 tile，局部 dirty-rect 刷新；配合 DMA 推送	低-中	中-高（tile buffer）	很高	高	动画/指针频繁更新、需要流畅	需要严格的窗口管理与脏区合并策略

BOM/架构代价的量化：240×240×16bit 的全帧缓存约 2402402=115,200 bytes（≈112.5 KiB）。很多 MCU（无 PSRAM）放不下完整 Framebuffer，因此实际工程更偏向 Tile/局部缓冲 + Scanline/LUT 的组合：用少量 RAM 换取可接受帧率与更低指令开销。

4.6 “X_OFFSET/Y_OFFSET”为什么几乎绕不开：模组装配与有效区不完全对齐

你在项目里看到的“画面整体偏一截、边缘黑圈厚度不均”，很大概率不是圆算法问题，而是 模组的可视圆心 ≠ GRAM 的几何中心。原因包括：玻璃裁切、FPC贴合定位、黑矩阵印刷偏差、结构件压边等。工程上通常用 X_OFFSET/Y_OFFSET 把逻辑坐标系平移到“真实可视中心”。

这类“偏移参数”在不少通用显示驱动框架里是显式字段（rotation code + x offset + y offset），说明它并非个例，而是显示模组工程的常态。

校准方法（高命中率）

1·画“十字 + 同心圆 + 0/90/180/270刻度点”测试图

2·观察四象限黑边厚度是否一致：

2.1左厚右薄 → xo 方向需要修正

2.2上厚下薄 → yo 方向需要修正

3·每次修正以 1 像素为步进，先把“圆心”对齐，再谈抗锯齿与美观。

顺序建议：先做 rotation/mirror 的坐标变换，再叠加 offset（更容易把参数“直觉化”，也便于量产配置表管理）。

圆形LCD液晶屏之所以容易在项目里引发“画不准、点不准、旋转乱、量产飘”，核心原因不是“坐标体系很玄”，而是很多团队把不同层级的概念混在一起：把 UI 的极坐标表达当作像素寻址，把遮罩导致的可视圆当作真实分辨率边界，把装配带来的偏移当作算法错误。

从工程可控性来看，最稳的认知框架是：

1.像素寻址永远是矩形 (x,y)：控制器的 GRAM 以行/列地址组织，通过地址窗口（CASET/RASET）+ 连续写入（RAMWR）完成刷新，这是圆屏与方屏共用的底层模型。

2.圆形只是“有效区/可视区”：圆外区域要么被黑矩阵/结构遮挡，要么需要软件裁剪/填充来保持视觉一致。

3.旋转/镜像/偏移是“映射规则”：Address Mode 改变寻址指针与物理像素的映射；X_OFFSET/Y_OFFSET 用来修正模组实际圆心与几何中心的不一致，属于量产常态，不是“写错了”。

5.2 常见问题

1：圆形LCD为什么不是“极坐标像素”？极坐标有什么用？

LCD圆形液晶屏的像素在控制器层面仍是矩形 GRAM 地址空间，写屏也是按列/行窗口推进。极坐标更多用于 UI 表达（刻度、指针、环形进度），最终仍要通过三角函数把 (r,θ) 投影到 (x,y)，再结合圆形裁剪。也就是说：极坐标是上层几何语言，不是硬件地址语言。

2：圆心 cx,cy 和半径 R 怎么定？为什么我用 (W-1)/2 还是不准？

常规初值确实是 cx=(W-1)/2, cy=(H-1)/2，但“可视圆心”往往会因为黑矩阵印刷、玻璃裁切、贴合定位、结构压边产生 1——数像素偏移，所以你需要用 X_OFFSET/Y_OFFSET 去校准。建议用“十字+同心圆”测试图，把四象限黑边调到尽量均匀，再固化参数。R 也建议预留 1——3 像素黑边以兼容遮罩公差（看起来更圆、更干净）。

3：为什么我用 dx²+dy²≤R² 画出来圆边很锯齿，且帧率很低？

锯齿来自像素栅格离散化；帧率低通常来自两点：

- 逐像素计算与逐像素写窗导致 CPU 与 SPI 命令开销爆炸；
- 保护性裁剪写法把“面”拆成很多小窗口。

工程上推荐扫描线段（每行一段 span）或预计算每行 xL/xR 的 LUT，再用一次窗口写入连续像素流，既能显著提帧率，也更容易做抗锯齿（例如对边缘做亚像素/多采样或渐变过渡）。