ucgui液晶显示深度优化篇

《ucgui液晶显示深度优化篇》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、UCGUI液晶显示深度优化篇Author：wzt2012年7月21日10:55:12前一段进行了ucgui的移植,但是移植后续还是存在很多问题,比如液晶刷新速率慢,横竖屏切换不支持等，所以针对这些问题进行了一次彻底的优化，现在刷新能够达到20帧的速度对于50mhz的io口来说已经相当可以了。下面就进行一次彻底的剖析，看究竟是那些问题占用了宝贵的百万分之一秒：一、速度优化篇：1.我用的是stm32的处理器，stm32公司为了让使用者加快项目开发速度和便于日后对整个软件部分的维护管理编写了一套标准库。这个库用起来确实很方便也另学习简化了很多，但是它也有缺点所在：就是效率问题。我

2、之前用的液晶屏驱动就是基于库函数编写的，所以第一步就是液晶驱动全部换为直接对寄存器操作，经实践确实刷新率成好几倍的增长。这个代码比较长，这里就不贴出来的，这里仅仅指点下思路，具体请看源代码。2.深入液晶驱动内部：液晶屏刷新可不是像我们眼睛看到的一样瞬间整个屏幕同时更新。实际上一个一个像素更新的：也就是说我的屏幕分辨率是320*240就要更新320*240=76800个点。每一个点更新时都要调用一个写数据函数。所以接下来要做的就是提高调用这个函数的速度。有两种解决办法：使用宏定义函数或者内敛函数。我使用的是内敛函数：如下定义：__inlinevoidLCD_WR_DATA(u

3、16data){LCD_RS_SET;LCD_CS_CLR;DATAOUT(data);LCD_WR_CLR;LCD_WR_SET;LCD_CS_SET;}可以看到和普通函数区别就在于前面增加了__inline关键字。它有什么作用？为什么可以提高速度？下面讲解一下它是如何起作用的：假如现在我们定义了两个函数A，函数B，函数A调用函数B：正常情况下如下图所示：A函数在运行过程中掉用了函数B这时候地址指针就会跳转到函数B的位置，而A中的内容暂时压入栈中，B运行完后再返回A继续运行。所以可以看到时间浪费在了入栈出栈过程中。再看如果把B声明为内敛函数后如下图所示：这时候B在编译时就

4、内嵌入函数A中成为A的一部分所以可以免去调用而直接顺序执行下去。宏定义函数和内敛函数功能差不多，就是宏定义在编译时不参与语法检测一旦出问题很难查找，所以还是建议大家用内敛函数。当然好处得到了也总要付出代价的，我们再假设现在有一个函数C也调用了函数B，如果不是内敛的话，整个内存空间中就只有一个函数B，谁用谁就调用它。而如果是内敛的话A中和C中都各自内嵌一个函数B，这时候等于代码中说多了一个函数B占用rom就要多了。很明显这就是拿空间去换取时间。所以在嵌入式系统空间很有限的情况下也不要滥用内敛函数。有的同学可能会发现一个问题就是加不加__inline结果一样，这就是你编译器优化

5、设置的问题，根据你的优化等级编译器可能会把内敛函数转化为非内敛。这时有两个解决方案：一个修改编译器优化设置，另一个就是把__inline换为__forceinline即强制性置为内敛函数。3.优化lcd液晶驱动和ucgui的接口函数。我这里使用的是LCDDummy.c上一节我们将乐在该文件下修改两个函数：voidLCD_L0_SetPixelIndex(intx,inty,intPixelIndex)；unsignedintLCD_L0_GetPixelIndex(intx,inty)；具体修改内容请参考移植篇。（当然按上次的方法还会就是不支持横竖屏转化，下面会讲到具体办法

6、）。还有这个函数：voidLCD_L0_FillRect(intx0,inty0,intx1,inty1){//#if!LCD_SWAP_XY//for(;y0<=y1;y0++)//{//LCD_L0_DrawHLine(x0,y0,x1);//}//#else//for(;x0<=x1;x0++)//{//LCD_L0_DrawVLine(x0,y0,y1);//}//#endifLCD_Fill(x0,y0,x1,y1,LCD_COLORINDEX);}这个函数的作用是填充一个矩形区域。红色的字体就是原来的内容。可以看到它是先调用画线函数，而画线函数又是调用画点函数，

7、因为每填充一个点就要设定一次点的位置。测试发现GUI_Clear();清屏调用的就是这个函数，所以这就是液晶刷屏慢的最主要因素。用它的算法优化空间实在很小，干脆不用他的另外用自己lcd底层驱动中的一个函数LCD_Fill();这个函数的好处就是直接设置好一个矩形区域的起点和终点坐标，就不断的往里面送数据就可以填充一个个像素点，从而免去了每个像素都要设置坐标的时间。同时gui绘制填充的矩形时候也是用这个函数，所以速度的增加也是很明显啊的……到这里我们已经把可以优化的的优化的差不多了，整体的结构性也遭到了一定的破坏性。