no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
— | cybiko:directaccessoflcd [2009/11/27 17:54] (current) – created - external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ======Direct LCD access====== | ||
+ | The cybiko LCD can be controlled directly by accessing the memory areas that are mapped to the driver chip. | ||
+ | Device specifications can be found here {{hd66421.pdf}} | ||
+ | < | ||
+ | #define IO_LCD_REG | ||
+ | #define IO_LCD_DATA *(volatile u8*)0x00600001 | ||
+ | </ | ||
+ | There are 17 useful registers that can be manipulated at the IO_LCD_REG address. | ||
+ | < | ||
+ | #define LCD_REG_CR1 | ||
+ | #define LCD_REG_CR2 | ||
+ | #define LCD_REG_ADDR_X | ||
+ | #define LCD_REG_ADDR_Y | ||
+ | #define LCD_REG_RAM | ||
+ | #define LCD_REG_START_Y | ||
+ | #define LCD_REG_BLINK_START | ||
+ | #define LCD_REG_BLINK_END | ||
+ | #define LCD_REG_COLOR_1 | ||
+ | #define LCD_REG_COLOR_2 | ||
+ | #define LCD_REG_COLOR_3 | ||
+ | #define LCD_REG_COLOR_4 | ||
+ | #define LCD_REG_CONTRAST | ||
+ | </ | ||
+ | The CR1 (control register 1) is manipulated to power up the LCD unit. Here are some defines for various functions that can be performed by manipulating the control registers. | ||
+ | < | ||
+ | // R0 - control register 1 | ||
+ | #define LCD_CR1_RMW | ||
+ | #define LCD_CR1_DISP | ||
+ | #define LCD_CR1_STBY | ||
+ | #define LCD_CR1_PWR | ||
+ | #define LCD_CR1_AMP | ||
+ | #define LCD_CR1_REV | ||
+ | #define LCD_CR1_HOLT | ||
+ | #define LCD_CR1_ADC | ||
+ | // R1 - control register 2 | ||
+ | #define LCD_CR2_BIS1 | ||
+ | #define LCD_CR2_BIS0 | ||
+ | #define LCD_CR2_WLS | ||
+ | #define LCD_CR2_GRAY | ||
+ | #define LCD_CR2_DTY1 | ||
+ | #define LCD_CR2_DTY0 | ||
+ | #define LCD_CR2_INC | ||
+ | #define LCD_CR2_BLK | ||
+ | </ | ||
+ | |||
+ | A structure to hold information about the LCD device, this will be passed around to various functions. | ||
+ | <code c> | ||
+ | typedef unsigned char * ADDR8; | ||
+ | typedef struct _mwscreendevice *PSD; | ||
+ | typedef struct _mwscreendevice { | ||
+ | MWCOORD xres; // X screen res | ||
+ | MWCOORD yres; // Y screen res | ||
+ | int bpp; | ||
+ | int linelen; | ||
+ | int size; | ||
+ | ADDR8 addr; | ||
+ | } SCREENDEVICE; | ||
+ | </ | ||
+ | A small helper routine to bundle up the common access that we use when talking to the LCD memory addresses. | ||
+ | < | ||
+ | #define lcd_regdata(rg, | ||
+ | </ | ||
+ | Now we are ready to power up and initialise the LCD structure. | ||
+ | To power up the unit we can do something like the following. | ||
+ | <code c> | ||
+ | static init(PSD psd) { | ||
+ | | ||
+ | </ | ||
+ | This will enable power and enable the display. | ||
+ | |||
+ | Compute some other values for the struct from what we know; that is the X resolution, Y resolution and the BPP. (160x100x2) | ||
+ | <code c> | ||
+ | psd-> | ||
+ | psd-> | ||
+ | psd-> | ||
+ | bzero(psd-> | ||
+ | </ | ||
+ | X address is incremented for each access (raster access). | ||
+ | <code c> | ||
+ | lcd_regdata( LCD_REG_CR2, | ||
+ | } | ||
+ | </ | ||
+ | Drawing a pixel requires computing the offset in the memory segment and enabling the correct bit to represent 1 of 4 possible colours. | ||
+ | To render a pixel on the device we must convert the X,Y coordinate to a 2 bit packed byte. As the display is a 2 Bit Per Pixel (bpp) device. | ||
+ | <code c> | ||
+ | static unsigned char notmask[4] = { 0x3f, 0xcf, 0xf3, 0xfc}; | ||
+ | |||
+ | /* Set pixel at x, y, to pixelval c*/ | ||
+ | static void drawpixel(PSD psd, int x, int y, u8 c) | ||
+ | { | ||
+ | ADDR8 addr = psd-> | ||
+ | addr += (x>> | ||
+ | *addr = (*addr & notmask[x& | ||
+ | } | ||
+ | </ | ||
+ | The only thing that remains is to render the memory address to the LCD unit. Somewhere in the LCD initialization routine we would need to indicate to the control register 2 that each access to LCD_REG_RAM will automatically increment the X address. | ||
+ | <code c> | ||
+ | void lcd_render( PSD psd ) | ||
+ | { | ||
+ | u8 x, y; | ||
+ | u8 xend; | ||
+ | ADDR8 addr = psd-> | ||
+ | |||
+ | xend = psd-> | ||
+ | for (y=psd-> | ||
+ | { | ||
+ | lcd_regdata( LCD_REG_ADDR_Y, | ||
+ | // Unrolled loop x2 (for performance) | ||
+ | IO_LCD_REG = LCD_REG_RAM; | ||
+ | for (x=0; x < xend; x++) { | ||
+ | IO_LCD_DATA = *addr++; | ||
+ | IO_LCD_DATA = *addr++; | ||
+ | } | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | So putting it all together with some sort of access might look something like this: | ||
+ | <code c> | ||
+ | SCREENDEVICE screen; | ||
+ | |||
+ | screen.xres = 160; | ||
+ | screen.yres = 100; | ||
+ | screen.bpp = 2; | ||
+ | init(& | ||
+ | for(i=0; | ||
+ | drawpixel(& | ||
+ | } | ||
+ | lcd_render(& | ||
+ | </ | ||
+ | Hope these little code fragments give you some ideas about how to get direct screen access and by-pass the cybiko API. | ||
+ | |||
+ | I have implemented a basic LCD driver using native H8 code and pieces of the cyborn project to get it to boot and run on the cybiko. There should be no reason why this sort of code won't run under the bytcode interpretter but I have not tested it. I can make the full source and .boot image available if people are interested in more details. | ||
+ | {{tag> |