Framebuffer LCD驅動介紹

學習framebuffer過程中，最大的困惑不是fb層的各個資料結構的互動，而是stm32驅動lcd時的畫點，畫線，畫圈這樣的函式上哪去了。。。直到了解了lcd控制器的原理，總算知道了為什麼沒了。原來給lcd控制器承包了！

在說framebuffer之前，得先提一下lcd控制器。如下圖：

那麼我們要怎麼在應用程式設計中控制lcd呢？

這就是framebuffer的作用了。

framebuffer子系統的層次結構如下：

在應用層中反映為/dev/fbx，儲存著一幀影象，可以操作試試：

# dd if=/dev/zero of=/dev/fbx		// 清屏
# cat /dev/fbx > text				// 截圖(未編碼)
# cat text > /dev/fbx 				// 顯示text到螢幕上

從結構圖中可以看到framebuffer重要**在fbmem.c和***fb.c；

struct fb_info   *fb_info    描述了乙個framebuffer device相關一系列資訊
struct fb_ops   *fb_ops      描述了乙個framebuffer device的操作函式集合，具體到對硬體的操作，比如清屏，畫圓等
static
const
struct file_operations fb_fops   檔案操作函式集合，當應用程式開啟裝置時，使用者可以read,write,ioctl等
struct fb_var_screeninfo var      描述lcd硬體可變引數
struct fb_fix_screeninfo fix        描述lcd硬體不可變引數，如視訊記憶體的首尾位址

主要作用是

註冊占用主裝置號29，

獲得info結構體，以呼叫info->fb_ops的lcd硬體操作函式。

mmap將fb=>vma虛擬位址空間–程序空間。

首先看init函式中：

static
int __init fbmem_init
(void
)

可以看到init中用了字元裝置驅動模型：register_chrdev( 29 , 」fb」 , &fb_fops )，建立並占用主裝置號29。以fb_fops作為操作函式，主要作用是獲取info結構體,它才儲存了具體的lcd驅動函式。

static
const
struct file_operations fb_fops =
;

很典型的乙個字元裝置驅動模型。應用層對裝置檔案開啟讀寫呼叫對應函式。首先看看fb_open函式主要內容：

fb_open
(struct inode *inode,
struct file *file)

fb_mman主要內容：

fb_mmap
(struct file *file,
struct vm_area_struct * vma)
/* 將獲得的info結構體中的framebuffer空間賦給vma虛擬位址空間  */..
.}

同樣首先看到init函式：

static
int __init nxp_fb_init
(void
)

這是乙個典型的platform匯流排-裝置-驅動模型，註冊了乙個platform驅動，驅動結構如下：

static
struct platform_driver fb_plat_driver =,}
;

platform匯流排特點是當有裝置註冊並且與驅動的「dev_name_fb」相同時完成匹配，呼叫nxp_fb_probe函式，所以接下來看到這個函式：

static
intnxp_fb_probe
(struct platform_device *pdev)

這裡申請framebuffer的函式中執行了：

device_create
(fb_class, fb_info->device,
mkdev
(fb_major, i)
,null
,"fb%d"
, i)
;

在類中建立乙個裝置dev(29,i)，並且在/dev/下建立了乙個fbx**用層操作。

以上，就是對於framebuffer子系統的解釋；

後面再做一篇lcd驅動開發

Framebuffer LCD驅動介紹

FrameBuffer（LCD裝置層程式設計）

SpringCloud Stream訊息驅動概述

SpringCloud Stream訊息驅動

Framebuffer LCD驅動介紹

FrameBuffer（LCD裝置層程式設計）

SpringCloud Stream訊息驅動概述

SpringCloud Stream訊息驅動

相關推薦