Linux driver for ST7565

Hello

Today I will describe my LCD module driver for ST7565. This driver based on fbtft library solution created by Noralf Tronnes.

As I mentioned in a previous post the frame buffer is the intermediate layer between higher kernel layers and video drivers. The frame buffer provider general abstraction to handle all forms of video device.

Our device can communicate with system via different types of bus ( eg. SPI, I2C or parallel ) therefore we have to link specific bus driver with frame buffer interface.  Below we can see "par" structure where "xxx platform device" or "xxx spi device" can be plug in. 

"xxx platform device" is a device defined in platform specific files, used to parallel bus connection.
"xxx spi device" is a spi device driver. 

The Linux device model is based on bus and device concepts.  More information you can find o

Linux Device Drivers.

The frame buffer is a platform specific segment of the system.  The most popular implementation for Raspberry Pi is Fbtft created by Noralf Tronnes. More information you can find here https://github.com/notro/fbtft/wiki

I decided to use fbtft because all frame buffer interface methods are implemented and my job was only to create a new device file with a few methods to implement a specialized interface for st7565 driver.

The most important methods are:

- static int init_display(struct fbtft_par *par) - executed during initialization in fbtft_register_framebuffer implemented in fbtft library.  

- static int write_vmem(struct fbtft_par *par, size_t offset, size_t len) - executed

during screen refreshing process. This function is taking a picture image from video memory buffer and convert it to appropriate to display device format. In my case video memory buffer have a format RGB 565 (16 bpp) with screen resolution 132 x 64. Because my LCD has only two colors I convert 16 bpp video memory format to 2bpp device format black and white. Conversion RGB 565 to 2bpp pattern is simple: zero values cast to black pixels and all the other to white pixels.

Last thing to do is prepare fbtft_display structure, in this structure we define parameters which are passed to fb_var_screeninfo and fb_fix_screeninfo structures. Second thing is our device specific operation which are assigned to fbtftops structure:

static struct fbtft_display display = {

        .regwidth = 8,

        .width = WIDTH,

        .height = HEIGHT,

        .txbuflen = TXBUFLEN,

        .gamma_num = 1,

        .gamma_len = 1,

        .gamma = DEFAULT_GAMMA,

        .fbtftops = {

                .init_display = init_display,

                .set_addr_win = set_addr_win,

                .set_var = set_var,

                .write_vmem = write_vmem,

                .set_gamma = set_gamma,

        },

        .backlight = 1,

};

You can find all code on this repository : 
https://github.com/zanaster/fbtft

Ok - and this is result of my work :  

 

An introduction and the frame buffer theory

My adventure with Raspberry Pi was started by chance. Some time ago my friend Maciek showed me Raspberry Pi and say that I can lend it for some time.I wondered about Raspberry application. First thought was a radio device with some 802.15.04 transceiver connected via SPI with the board. But then I found one LCD COG display with st7565r controller that I have used for some old project. I resigned from transsiver project and I decide to make some experiments with LCD and spi driver.

I began with little knowledge about Linux driver development. I had experience only with simple character device driver. Linux drivers seemed to be complicated to me. Therefore I decided to overcome my fear of Linux driver and create own from a scratch. I was starting read about Linux and device drivers.

I have read Essential Linux DeviceDrivers by Sreekrishnan Venkateswaran – is was a great introduction to my adventure with Linux drivers, there is a very good chapter about video driver with suitable information about frame buffer.

My LCD has a graphical display with 132x64 resolution. St7565r controller can be connected by SPI or parallel port. Here is a very nice page about it.

If I had a character LCD display it would be the best option to create a simple character device driver with supported file operations eg. open(), close(), write() and maybe ioctl for device specific operations like contrast setup. 

Yeah - but I wondered about something more and I have found information about frame buffer. 

Most device drivers are not directly implemented as character devices or block devices. They are implemented under a framework , specic to a device type (frame buffer, V4L, serial, etc.). The framework allows to factorize the common parts of drivers for the same type of devices. From userspace, they are still seen as normal character devices. The framework allows to provide a coherent userspace interface (ioctl numbering and semantic, etc.) for every type of device, regardless of the driver. 

The frame buffer is intermediate layer between higher kernel layers and video drivers. To present something on display with frame buffer support we need to implement specific programing interface. I think that frame buffer can consider as a proxy design pattern. The frame buffer provider general abstraction to handle all forms of video device.

User's applications can interface with the frame buffer by file operations or in other way (using mmap for example). The frame buffer has own ioctl method to set up video devices. All of structures are defined in include/linux/fb.h, fb_ioctl is defined in drivers/video/fbmem.c.
Fb_info is the main structure with all information about frame buffer. I prepare simplified diagram of it.

 
Now we have enough information to move forward. In the next post I will describe driver implementation details.

Hello All

I am an engineer from Poland. I think that I can share my knowledge about computer science and embedded systems with the world. I am intending to post some articles about Linux drivers, Raspberry Pi , microcontrollers and wireless technologii.