LddKentDisplaySpec

about

This specification describes how the Kent Displays ChLCD driver is implemented.

Ideally this will be modeled to act as a framebuffer driver.

20,000 ft

do i have the polarity of read/write correct? or is it wrt user space?

1. init
   • kmalloc 160x120 bytes of memory (38.4kbytes)
   • really could be bits but this should be easier to implement as /dev/fb style device
2. read
   • dummy function
     • could be implemented later but not needed since kernel memory and display memory should always be the same
     • could be useful in testing for getting fw rev and reading back written values (unittests arg)
3. write
   • Pack screen data in 160x120 bit array (4800 bytes)
     • while(*byte in screen){for(0 to 7; byte++){ (thisByte>0x7f)?bit=1:bit=0; screenByte << bit;}
   • Copy screen data array to display RAM via SPI
     • any value over 0x7f is a 1, any value under 0x7f is a 0 (wrt kent pixels)
   • Wipe whole page, later versions can support pseudo-blitting but not 1.0
4. unload
   • Free memory

display struct

This structure describes all of the data and control logic associated with the display. This is the answer to the question "What does it mean to be a Kent Display" ;-D

Member	Type	Description	Action
upToDate	uint8_t	boolean variable that determines whether to repaint the display or not	if(upToDate){ refreshScreen; }

-- ChristopherPepe - 13 Oct 2006