KS0108

[doc_rob]

I have an old 128x64 monochrome Display with KS0107/0108 controller. Is this supported? I didn't find a driver. It uses 8bit parallel interface with two CS Lines because it is divided in half. Left 64pixel is one controller, right 64pixel the other one. Which is the best driver to start with if i have to develop a new one?

best regards,

Robert

[Joel Bodenmann]

Hi,

There's currently no driver for that display from our side. However, writing one is very easy. I once wrote one for that display controller but that was for a paying customer that didn't allow us to put it into the public repository.
The split areas (two controllers) are not a problem either. Write a driver that handles the full display area and then simply check for the X coordinate and select the appropriate controller to talk to.

[doc_rob]

I'll get right on that....

 

[doc_rob]

Aren't there any templates? I thought i saw one, but i can't find them.

[inmarket]

At the moment the best template is the source code of another driver that operates in a similar way.

[doc_rob]

Driver is functional. It was a lot of work but also a good learning experience. I have the possibility to read back from the display (untested because as it turns out after three days debugging - my display is broken) or have an array in RAM. I guess the linebuffer can be used for this but i don't know how. Could anybody look at the code and give me feedback. Thanks.

best regards, robert

driver.mk

gdisp_lld_config.h

gdisp_lld_KS0108.c

board_KS0108.h

[inmarket]

Thank-you. We will look to adding into the official repository as quickly as possible.

[Joel Bodenmann]

Hi,

First of all, thank you for sharing your driver with us and the rest of the community.
I gave it a very quick look and these are the things that popped to my mind:

• You're using osalThreadSleepXXX() instead of gfxSleepXxx() at some locations (eg. the initialization code)
• Your framebuffer (lcdbuf) is a global variable. This won't work if you want to use multiple displays. You must not create any global variables at all. Instead, the GDisplay* struct has a void* pointer named priv that you can use to store custom information. If you need more information than what a simple void* can hold create a structure and let the priv pointer point to that. Have a look at other existing drivers to see how it's done. Take the SSD1306 and the UC8173 drivers as an example.
• There's code (that has been commented out) to clear the display. That is not necessary as the higher level GDISP stuff will take care of that and it will use the area filling if that is available so that code is really not required unless the KS0108 controller has a real "clear" hardware function.
• Some general serious clean-up is required. The function and variable naming appears to be inconsistent and the indentation is just all over the place.

Don't hesitate to ask if you have any questions. We're happy to help wherever we can  

[doc_rob]

Version 0.2 of the driver.

I addressed all points above.

Need some further testing and finetuning with readback.

best regards, robert

gdisp_lld_config.h

gdisp_lld_KS0108.c

board_KS0108.h

[Joel Bodenmann]

Good work!

One thing I'm not sure about: Could you explain what the purpose of this is in the init()?

#if (KS0108_NEED_READ == FALSE)
  uint16_t k;
  for (k=0; k<BUFFSZ; k++) {
    RAM(g)[k]=0;
  }
#endif

 

[doc_rob]

I thought i needed to intialize the array (display buffer). If not i can delete that part of the code.

robert

[Joel Bodenmann]

You don't need that. The GDISP code will clear the display after the driver has been initialized.

[doc_rob]

Version 0.3 of the driver.

 

best regards, robert

board_KS0108.h

gdisp_lld_KS0108.c

gdisp_lld_config.h

[inmarket]

This has been cleaned up a bit and added to the repository.

[Joel Bodenmann]

@doc_rob Could you please grab the latest master branch of the repository and check whether everything is working out-of-the-box?

[doc_rob]

I wiil do that as soon as i am finished with the T6963 driver.

best regards, robert

 

[doc_rob]

I got a chance to look at the code, unfortunately it does not compile.

I made some changes:

.) removed KS0108_goto altogether (there's a typo in the argments anyway)

.) had to move #define CHIPS, #define BUFFSZ  and  #define RAM(g) to board_KS0108.h

After that it will compile and it works as far as i can test (means without readback) it.

Let me know what you think about it.

best regards,

robert

EDIT.

I almost forgot, i had to remove (void)state; in setpin_reset for the if(state) to work.

 

board_KS0108.h

gdisp_lld_KS0108.c

Edited May 23, 2017 by doc_rob
forgot something

[Joel Bodenmann]

Why did you have to move the RAM(g) and other macros to the board file? That would be wrong. That is part of the generic driver. Only stuff that changes depending on your wiring must go into the board file.

To clarify: I don't say that what we have in the repository is correct right now (as apparently there are a few changes that were applied prior to that) but the framebuffer stuff definitely belongs to the driver, not to the board file.

[doc_rob]

I had to move it because i use the macro in board.h, but i see your point.

I made a different approach and moved all RAM(g) related code to gdisp_lld.

Here is v0.6

board_KS0108.h

gdisp_lld_KS0108.c