记2020.10.28
今天心血来潮想把上学期末计划做的用STM32在LCD上播放Bad Apple，需要用到的东西包括：FatFs文件系统、LCD显示驱动，以及视频转二进制文件的工具。
FatFs及LCD驱动都是直接拿教程的源代码改的（毕竟我懒，and时间也有限……），视频转二进制的工具是我上学期末写的一个脚本（Github：https://github.com/Floral/MyGadgets），今天遇到的问题主要就是跟这个脚本及LCD显示的程序有关。
这个脚本目前只支持黑白视频的转换（毕竟是是根据Bad Apple来写的嘛），并且我在今天发现了一个问题，就是python的二进制写入文件模式是以字节为单位的，即假设一个bool数组只有一个True，我原本想的是写入后文件只含有一位二进制，而实际是这个bool被扩展为了一个字节，最终的结果就是0x01（想想也是，毕竟所有的汇编语言的读写最小单位都是byte，而不是bit）。所以该脚本目前的版本中生成的结果bin文件中也是按照一个像素对应一个字节的，在嵌入式程序中，显示控制程序也很简单，一个byte用来决定一个像素的值。这种方案的实验结果很成功，让我开心了一小会儿，可惜快乐总是短暂的。
由于这个视频只是一个黑白视频，所以一个像素所需要的位数并不要一个字节，一位就够了，可以节省大量空间。于是强迫症的我一下午的时间就花在了怎么按位写入。查阅资料后得到的结论是，并不能按位写入，只能通过转换的手段，一组一组地把八位转换为一个byte再写入。
改好脚本后，本以为大功告成，上板子一实验，问题大了，画面纵向割裂，分成10列（整体是80×60像素），仔细观察，造成这一现象的原因是某些列被“镜像”了（如图），由程序中的显示流程大致可以判断，这个错误与生成的bin文件的大小端存储方式、STM32读取文件的大小端存储方式以及STM32的C语言中一个字节中访问LSB和MSB的先后有关。
经过多次检查及修改测试，发现python脚本生成过程并没有问题，于是针对c语言程序进行排查，尝试了几种大小端读取的组合后，还是没有解决，甚至怀疑是不是STM32的程序中途错乱了（毕竟有跑飞的可能）。一晃时间就到了晚上九点多。。。一天其他啥事都没干，于是决定把这个问题暂时放下，先记录下这个现象，等待以后或许某一天再跑的时候能奇迹般地正常！或者有时间系统地测试一下问题。
不过这次经历也提醒了我，在用不同平台或不同语言读写二进制文件的时候，需要格外注意大小端的字节序和一个字节中的比特序。