本文结论：它用的是拧巴的、极简版的rgb555，不是常规意义上的rgb565，虽然它的驱动里是那么写的。

它的蓝色在高位，绿色在低位，红色在中间，所以用正常的rgb565就没一个颜色对得上。淦！

它的rgb三个分量只能接收0~7的值，超过7，高位舍弃，比如8=0、9=1

心路历程：

从来没有接触过开发板，然后树莓派这几年价格有成为理财产品的趋势。

之前在橙色软件冲浪的时候偶然发现了这款RP2040-LCD-1.28，他自带mcu rp2040，支持micropython。与官方版的差距是：增加了一块GC9A01A（圆形 240×240 RGB），一个QMI8658C六轴传感器（与本文无关），一个重启按钮，usb-typec接口（woc什么领先业界）。一眼就看中了，不到90块直接买一个来玩。

看了一眼人家自带的源码，其中在屏幕驱动部分有一句

super().__init__(self.buffer, self.width, self.height, framebuf.RGB565)

哇，好大一个rgb565，因为从来没接触过，板子没到，我先去学习了rgb565相关知识。

简单地说，rgb565与rgb555色彩每个像素转换为二进制后，定义如下，左边为高位，右边为低位。

所以，我为了方便，还去用js写了个24位的rgb888转rgb565工具，但其实这个东西后面已经意义不大了==

然后，板子就到了，上电之后，除了人家的实例程序，我就开始摸索自己控制显示屏。在驱动部分我看不懂，数据手册英文啃不动，电路那些我文科生完全不能理解，所以也没法改。但在颜色方面，当我把正常的、正经的、rgb565传进去后，发现基本上除了黑色和白色，其他颜色基本都是乱的。

在测试过程中去了几个理论上的rgb十六进制极限值（纯蓝纯红纯绿），隐约的发现，它这个rgb565的rgb顺序不是常规意义上的那种。蓝色在高位，绿色在低位，红色在中间,于是写了个拧巴函数，把rgb顺序拧过来。

接下来发现，蓝色和红色基本还可以，绿色还是有偏差，基于上面的顺序拧巴，我就在想它会不会用的也不是565，而是555，于是在转换函数上，去掉了绿色低一位。终于三原色众神归位（我要哭了，鼓捣一天，又写js又写py，狂查资料，恶补各种rgb定义……

做到这里，我只是找对了三原色，天真的我以为有了三原色，颜色这方面不就拿捏了。

但我发现基本上除了三原色其它颜色依旧是乱序，于是我重新从0x0001开始测试，结果发现，三个分量它分别只能接受0~7，二进制最大111，超过的高位舍弃，即8=0，9=1……

虽然只能接收到111，但依旧要按rgb555的位移去操作这三个量：

def b_rgb2(r5:int,g5:int,b5:int):        #r5,g5,b5取值范围0~7

    return (b56)&31    b5=rgb_565&31    return (b5