光立方程序
（突然忘记markdown的各种格式怎么标了，就这么写吧，反正我也不会排版……）
自己比较菜，写的程序用的都是最最笨的方法，和我一样菜的小白如果看不懂别人写的程序可以看看我这个最笨的思路吧
一个连贯的动画是由很多个静态的图像连续播放形成的，这个道理都懂吧，所以我们要让光立方一幅一幅的图像快速切换。 而各个头文件里的各个数组存放的就是每一幅图像的数据。
888的光立方我是按 层共阴 列共阳 的方式焊接的，64个阳极脚分别接到8个74HC573上，8个锁存器控制8片； 8层每一层的阴极脚接ULN2803，一个2803控制8层。
一个数组里存放的数据是供单片机对光立方完全扫描一遍使用的，扫描一遍一共将光立方分成64束，比如573选择第一片，2803从第一层扫描到最后一层，然后573再选择下一片，2803继续从第一层扫描到最后一层，8片*8层=64束。（话说我好像没有用573的锁存功能，嗯哼，不太懂锁存之后能干嘛）
数组里一共有64个两位的十六进制数，每个数化成二进制就是8位，分别控制每一束里的8盏灯各自的亮或者灭，这样扫描一遍下来，虽然它是分64次让光立方的512个灯分别改变其亮或者灭，但是整个扫描过程非常快，人眼看上去就能感觉到整个光立方的灯是同时亮的。
这样又存在一个问题，扫描一遍的速度非常的快，如果没有采取任何措施，每一个灯被点亮的时间就非常的短，这样看上去每个灯的亮度就非常的低，所以我们需要在扫描程序里动动手脚。给每一束扫描的时候，为该束灯赋值完以后不要立马跳去下一束，设置一个延时函数，让这个灯多亮一会儿，这样扫描下来整个光立方的灯就亮多了。可知延时越长，灯越亮，但是相应扫描速度减慢，延时太长，整个扫描过程不流畅，你就能明显看出那些灯是一束一束接替点亮的。
然后各帧之间的切换速度，我是通过控制每一帧扫描的次数来控制的，每一帧的扫描次数越多，也就是显示的次数越多，这个动画的播放速度就越慢，我感觉这个方法貌似不太靠谱，不过我也还没想出别的方法来（其实是懒得想了），就将就着用吧。然后我发现扫描次数增加的话，即使程序其他地方没有任何修改，生成的HEX文件会变大，而且大得有点明显。。。我用的STC12C5A60S2，code空间貌似有60KB吧，那几个动画就差不多快把那填满了……
说到单片机的存储空间，一开始我也被搞得稀里糊涂，明明空间是够的，结果强行烧进程序后没有任何反应，结果发现它的存储空间有三种，好像分别是内部的啥，外部的啥和flash吧，懒得百度了，小伙伴自己百度去，差不多就是那么个意思。一开始我那些个大堆大堆的数组就是直接char xxx[][8]={...};这么定义的，然后生成HEX文件最后那里有个各种存储空间的使用情况，data对应内部啥啥啥，它最小，xdata对应外部啥啥啥，也不大，好像就1KB的样子吧，然后我知道的那个60K是code对应的地方，各种变量没有特殊声明都给放到xdata里了，结果xdata整的太大，超出上限了，这肯定是不行的。百度一番发现要在定义的变量之类的东西前面加一个code标识符，这样它就存到最大的那个地方里了。这一点要注意。
嗯，我的光立方2803层选信号接的是P0，573片选接的P2，数据输入接的P1. 不知道咋整的，那个什么3D8取模软件的方向和我做的光立方的方向不一样，然后我写程序取模的时候还要自己脑补旋转以后的样子。。。 差不多就这样吧，写的有点凌乱，将就着参考吧 大佬有时间可以帮忙修改修改然后pull呐，自己也才刚接触GitHub，嗯，快下晚自习了，不写了
一路摸索着做出来，花了差不多两个月的课外空闲时间，写这些个程序是真的麻烦，那个gogo动画还没写完，差不多就这样了吧。