LCDInfo.com

hey guys, i just found this forum yesterday, and already ive learned a lot, so props for that already

im currently working on my graduation project, writing a SPI driver for a Philips platform (specificly a custom setup using a arm7tdmi cpu). the driver is practicly finished, and my coach wanted us to improve the demonstrator for the platform, by adding a LCD display, which has to be SPI driven (to make it project related)

now we have chosen the nokia knock off (6610 style) display from jelu.se with the carier board (to prevent microsoldering) and ive started to think about the software, mainly the 9 bit thing.

the point is, the software of this platform does not permit an application or high level driver to acces the hardware directly, you have to use all the driver layers in between (its a portability thing) so i dont have direct hardware control, in fact all i can use for the LCD is our SPI driver. the hardware allows only for 8, 16, 24 or 32 bit transfer.


now ive come up with this idea:

send all data in blocks of 8 commands/data bytes, which makes it 72 bits, which is 9 bytes. this way you can still use normal 8 bit spi hardware and you wont need to do weird I/O pin tricks or anything

what do you guys think of this? i do realise it will encurr a rather sizeable loss of performance, but without direct hardware acces or 9 bit support, this is the best i can think off

thanks for any comments

Thats how a number of people on the board do it, a pretty standard affair.

_________________
myLCD - An LCD framebuffer library
(KS0108, PCD8544, SED1565, SED1335,
Nokia Colour LCD's, T6963C, TCP/IP, etc..)
http://mylcd.sourceforge.net/

oh, right, i hadnt read about anyone doing that yet

is there another way around it without tricks like bitbanging the last bit or something?