㈠ ssd1306和sh1106的區別
ssd1306和sh1106的區別如下:
1、解析度不同
ssd1306:支持最大128×64點陣面板。
sh1106:支持最大132×64點陣面板。
2、封裝不同
ssd1306:提供兩種封裝COG和COF。
sh1106:提供COG形式。
3、嵌入式SRAM不同
ssd1306:嵌入式128×64位SRAM顯示緩存。
sh1106:嵌入式132×64位SRAM顯示緩存。
4、介面不同
ssd1306:8位6800/8000串口、3/4線SPI介面、I2C介面。
sh1106:8位6800系列並行介面、8位8080系列並行介面、3線和4線串列外設介面、400KHz快速I2C匯流排介面。
5、對比度控制器顯示不同
ssd1306:顯示RAM振盪器和片上晶振。
sh1106:顯示RAM振盪器和高效的DC-DC轉換器。
求SPI的SSD1306在linux下的測試程序理解SPI的驅動框架,還是從最基本的三個入口點觸發,platform_device,platform_bus,platform_driver。
其中內核一提供給platform_bus,platform_driver在spi_s3c24xx_gpio.c和spi_s3c24xxc.c中,其中spi_s3c24xx_gpio.c用於IO模擬SPI (本例討論的是IO模擬SPI),spi_s3c24xxc.c用於s3c24xx的硬體SPI。因此,我們需要動手寫一個platform_device。
看看spi_s3c24xx_gpio.c做了些什麼。
static int s3c2410_spigpio_probe(struct platform_device *dev)
{
... ...
/* [cgw]: 分配一個SPI主機 */
master = spi_alloc_master(&dev->dev, sizeof(struct s3c2410_spigpio));
... ...
sp = spi_master_get_devdata(master);
platform_set_drvdata(dev, sp);
/* [cgw]: 分配與spi硬體相關的配置,如指定哪些IO為MISO,MOSI,SCLK,CS,SPI工作模式,最大時鍾等等 */
/* in the plkatform data */
sp->info = dev->dev.platform_data;
/* [cgw]: 提供實現SPI各種模式的時序的基本方法,和CS的激活方法 */
/* setup spi bitbang adaptor */
sp->bitbang.master = spi_master_get(master);
sp->bitbang.chipselect =
㈢ Linux 內核驅動介面詳解
寫作本文檔的目的,是為了解釋為什麼Linux既沒有二進制內核介面,也沒有穩定 的內核介面。這里所說的內核介面,是指內核里的介面,而不是內核和用戶空間 的介面。內核到用戶空間的介面,是提供給應用程序使用的系統調用,系統調用 在 歷史 上幾乎沒有過變化,將來也不會有變化。我有一些老應用程序是在0.9版本 或者更早版本的內核上編譯的,在使用2.6版本內核的Linux發布上依然用得很好 。用戶和應用程序作者可以將這個介面看成是穩定的。
你也許以為自己想要穩定的內核介面,但是你不清楚你要的實際上不是它。你需 要的其實是穩定的驅動程序,而你只有將驅動程序放到公版內核的源代碼樹里, 才有可能達到這個目的。而且這樣做還有很多其它好處,正是因為這些好處使得 Linux能成為強壯,穩定,成熟的操作系統,這也是你最開始選擇Linux的原因。
只有那些寫驅動程序的「怪人」才會擔心內核介面的改變,對廣大用戶來說,既 看不到內核介面,也不需要去關心它。
既然只談技術問題,我們就有了下面兩個主題:二進制內核介面和穩定的內核源 代碼介面。這兩個問題是互相關聯的,讓我們先解決掉二進制介面的問題。
假如我們有一個穩定的內核源代碼介面,那麼自然而然的,我們就擁有了穩定的 二進制介面,是這樣的嗎?錯。讓我們看看關於Linux內核的幾點事實:
對於一個特定的內核,滿足這些條件並不難,使用同一個C編譯器和同樣的內核配 置選項來編譯驅動程序模塊就可以了。這對於給一個特定Linux發布的特定版本提 供驅動程序,是完全可以滿足需求的。但是如果你要給不同發布的不同版本都發 布一個驅動程序,就需要在每個發布上用不同的內核設置參數都編譯一次內核, 這簡直跟噩夢一樣。而且還要注意到,每個Linux發布還提供不同的Linux內核, 這些內核都針對不同的硬體類型進行了優化(有很多種不同的處理器,還有不同 的內核設置選項)。所以每發布一次驅動程序,都需要提供很多不同版本的內核 模塊。
相信我,如果你真的要採取這種發布方式,一定會慢慢瘋掉,我很久以前就有過 深刻的教訓…
如果有人不將他的內核驅動程序,放入公版內核的源代碼樹,而又想讓驅動程序 一直保持在最新的內核中可用,那麼這個話題將會變得沒完沒了。 內核開發是持續而且快節奏的,從來都不會慢下來。內核開發人員在當前介面中 找到bug,或者找到更好的實現方式。一旦發現這些,他們就很快會去修改當前的 介面。修改介面意味著,函數名可能會改變,結構體可能被擴充或者刪減,函數 的參數也可能發生改變。一旦介面被修改,內核中使用這些介面的地方需要同時 修正,這樣才能保證所有的東西繼續工作。
舉一個例子,內核的USB驅動程序介面在USB子系統的整個生命周期中,至少經歷 了三次重寫。這些重寫解決以下問題:
這和一些封閉源代碼的操作系統形成鮮明的對比,在那些操作系統上,不得不額 外的維護舊的USB介面。這導致了一個可能性,新的開發者依然會不小心使用舊的 介面,以不恰當的方式編寫代碼,進而影響到操作系統的穩定性。 在上面的例子中,所有的開發者都同意這些重要的改動,在這樣的情況下修改代 價很低。如果Linux保持一個穩定的內核源代碼介面,那麼就得創建一個新的介面 ;舊的,有問題的介面必須一直維護,給Linux USB開發者帶來額外的工作。既然 所有的Linux USB驅動的作者都是利用自己的時間工作,那麼要求他們去做毫無意 義的免費額外工作,是不可能的。 安全問題對Linux來說十分重要。一個安全問題被發現,就會在短時間內得到修 正。在很多情況下,這將導致Linux內核中的一些介面被重寫,以從根本上避免安 全問題。一旦介面被重寫,所有使用這些介面的驅動程序,必須同時得到修正, 以確定安全問題已經得到修復並且不可能在未來還有同樣的安全問題。如果內核 內部介面不允許改變,那麼就不可能修復這樣的安全問題,也不可能確認這樣的 安全問題以後不會發生。 開發者一直在清理內核介面。如果一個介面沒有人在使用了,它就會被刪除。這 樣可以確保內核盡可能的小,而且所有潛在的介面都會得到盡可能完整的測試 (沒有人使用的介面是不可能得到良好的測試的)。
如果你寫了一個Linux內核驅動,但是它還不在Linux源代碼樹里,作為一個開發 者,你應該怎麼做?為每個發布的每個版本提供一個二進制驅動,那簡直是一個 噩夢,要跟上永遠處於變化之中的內核介面,也是一件辛苦活。 很簡單,讓你的驅動進入內核源代碼樹(要記得我們在談論的是以GPL許可發行 的驅動,如果你的代碼不符合GPL,那麼祝你好運,你只能自己解決這個問題了, 你這個吸血鬼把Andrew和Linus對吸血鬼的定義鏈接到這里>)。當你的代碼加入 公版內核源代碼樹之後,如果一個內核介面改變,你的驅動會直接被修改介面的 那個人修改。保證你的驅動永遠都可以編譯通過,並且一直工作,你幾乎不需要 做什麼事情。
把驅動放到內核源代碼樹里會有很多的好處: