当前位置: 代码迷 >> WinCE >> 关于18bpp的gBitMasks解决方案
  详细解决方案

关于18bpp的gBitMasks解决方案

热度:73   发布时间:2016-04-28 12:37:54.0
关于18bpp的gBitMasks
弄了好多天都搞不定。如何去定义18bpp的gBitMasks数组。16bpp和24bpp的是如下:
#if (LCD_BPP == 16)
ULONG gBitMasks[] = {0xF800, 0x07E0, 0x001F};
#elif (LCD_BPP == 32)
ULONG gBitMasks[] = {0x00ff0000, 0x0000ff00, 0x000000ff};
如果我现在修改24bpp的使之可以支持18bpp的,该怎么改??
我试过
//#elif (LCD_BPP == 18) 
//ULONG gBitMasks[] = {0x003F0000, 0x00003F00, 0x0000003F}
//#elif (LCD_BPP == 18) 
//ULONG gBitMasks[] = {0x0003F000, 0x00000FC0, 0x0000003F}
//#elif (LCD_BPP == 18) 
//ULONG gBitMasks[] = {0x00FC0000, 0x0003F000, 0x00000FC0}
感觉都不行,墙角各位大侠一下。
另外只要设置跟原来24bpp一样的,那不论怎么修改GPF寄存器的值都是一样效果。是不是修改18bpp的,最主要就是处理好gBitMasks这个数组??
------解决思路----------------------
你的内存中真的是以18bit存储的吗?硬件上阵的只是接了18根线?
------解决思路----------------------
我也一直没有搞明白RGB666在内存中式一个怎么样的方式存储的。因为在内存中存储一般都是字节的倍数,不够的就补上去。我的理解是RGB666在软件是24bit的吗?具体我也不了解。等待熟手出现啊。

我倒是最近有做过调试过一个18bit的。硬件上接了18根。但是实际上在内存中存储时RGB666的形式存储的。扔给控制器都就由控制器来去把它搞成18bit。
------解决思路----------------------
引用:
代码我都看了两个礼拜了,还是一团乱,我主要是在开发板上搞得,一开始去弄模拟器的lcd控制器去了,后来才发现那玩意根本没有用。然后硬件比较薄弱,那么多寄存器的分配,看得我头疼。我的理解是24bpp是用32位的,前面8位是dummy,而18bpp在24bpp基础上的。只要减少对寄存器的实用就行了么?


对了一般手册上会有各种格式在内存中的布局图,我刚刚看了下6410 spec,24bpp是用的32bit,18bit也是32bit的只要按照这些格式把数据堆在内存中就行。
最简单的LCD的控制器初始化就是在EBOOT里面。仔细看看EBOOT显示logo那部分的代码就OK
  相关解决方案