关于驱动的感想（顺便拿点ＲＤ币过年：））

mikal · 发表于 2006-1-19 15:58:00

经常来这个驱动板块看看，发现自己从这里确实学到了很多知识。但是又发现这里的驱动板块对驱动的讨论非常浅，大多是一些皮毛，所以，今天我将开始谈谈自己对驱动的一些看法，可能，这些对一些人来说，也是一些皮毛，不过个人认为还算可以了：）

说到驱动，大家可能马上就想到，是什么驱动，在哪个平台上的驱动，驱动具体要做什么事情。比如说，做手机的ｌｃｄ驱动，大家可能想到的就是ｌｃｄ硬件连接电路，软件如何驱动它点亮，主ｃｐｕ如何送数据，如何提供一些接口给上层应用。其实想到上面的一些方面是做驱动的必须步骤，可是如果仅仅做这些，个人认为理解驱动的内涵还差点点。在此我要写的是除这些外，我们必须要关注的一些东西：

1、根据驱动在整个系统中的作用，而需要考虑驱动的关键
就如上面说的ｌｃｄ的驱动，如果我们想在手机上做ｌｃｄ的驱动，那么我们必须考虑ｌｃｄ在手机这个系统的作用；显然，ｌｃｄ是人机交换的一个平台，使用者需要它显示速度快，且好，不用的时候又要关掉；因此，根据这些作用，我们在做驱动的时候就要想到：ｌｃｄ的第一次点亮的时间点，刷新速度，关闭ｌｃｄ后功耗等问题。做了上述的简单分析后，在编写手机ｌｃｄ驱动的时候就要做：尽量早的让使用者在按下ｐｏｗｅｒ建后，ｌｃｄ就点亮，并显示相关的一些画面，让使用者从心理上感觉到手机很快的响应了他的操作；在给上层提供刷新ｌｃｄ的接口函数的时候，要尽量优化刷新函数，使得刷新函数以最快的速度刷新ｌｃｄ；然后就考虑在关ｌｃｄ后，使ｌｃｄ的功耗最小。[br]+3 RD币

cxin2 · 发表于 2006-1-20 15:22:00

降低功耗是必须要做的，各个模块都避免不了，否则总体功耗下不来的。
刷新函数的想法不错，不过这个很多时候要驱动和LCD本身硬件支持才行啊
至于显示的时候，先亮起来，很多要受很多因素的制约，不是lcd驱动想先起来就可以的。
不过总的来说，楼主的思路还是很好的，值得提倡[br]+5 RD币

mikal · 发表于 2006-1-23 11:33:00

2、（cxin2）你分析的更加明晰了我的思路，就是在尽可能的情况下考虑上面的问题优化。 根据驱动的类型，规划驱动程序的可替换性 大家在开发手机的时候可能都注意到，往往一个系统中对同一类别的驱动要跟据不同的项目作相应的变更；为在很好的适应这种项目的变更，而驱动的快速替换，需要编写驱动的人员首先对自己编写的驱动做一个非常合理的驱动架构管理；也就是便捷的替换管理。同样，我现在依然以手机的lcd为例子，简单讲述下lcd驱动架构的管理。我们大家在刚开始开发一个平台的一个项目的时候，可能事先并没有想到，同样的平台，同样的基本软件版本需要支持后面相当多的项目；所以杂开始第一项目的时候，可能忽略了做驱动的可替换性，就是说，把设计到驱动的所有接口函数都没有做成ＡＰＩ的形式，而是简单的做成上层应用直接调用驱动函数；其中间少了一层传递，也就是公共模块化；当要加驱动的时候，感觉有点捉襟见肘；假使现在我们已经规划了驱动的可替换性，那么我们又如何架构了，这个没有明确的答案，要看个人的编程习惯了。我就简单描述下自己的便程风格好了。我一般把不同控制器的ｌｃｄ驱动.ｃ和.ｈ按名字区分开来，当不同项目采用不同ｌｃｄ的时候，就在ｌｃｄ的控制文件中引申相应的驱动文件，然后驱动文件中的所有函数都要统一命名――这样便于移植。实际上就是这么简单，但是关键就是在于在编写驱动的时候就要考虑到这些问题。当然，或许有的人已经做了，而且做的非常好，那么也可以说出来，让大家也参考参考；互相学习嘛。[br]+5 RD币

cxin2 · 发表于 2006-1-23 12:14:00

我做的GSM通讯驱动层对不同的系统的API接口函数不一样，对下倒还好，是对虚拟串口进行操作，无论下面硬件平台怎么变化，向下的接口基本不变。向上的API，对于不同系统之间，变化很大，我在我自己的驱动上面又加上一层proxy层，这是参考微软windows mobile的做法，对于不同系统来说，我做了一个接口，可以把不同系统对通讯API的调用转化成我自己驱动里面的API，这样对公司来说，无论项目怎么改变，我只需要更换proxy层就好了，至于我自己真正的驱动层，则无需太大改变，这样核心技术牢牢掌握在自己手里，当然我说的是通讯驱动的核心技术而已，^_^，让大侠们见笑了。
我想不管是什么驱动，都存在command和resonse，严格来说，做到proxy不是特别难的事，但是这样可以减少很多重复工作量，可以将更多精力花在怎么提高驱动性能、降低功耗、提高与其他部分的协调能力上面，当然也可以花更多时间去学习其他驱动、系统、硬件、协议栈、网络传输等等上面。[br]+5 RD币

jamesbond · 发表于 2006-1-30 18:46:00

做个MID-WARE再封包一层好了，浪费点RAM

w_allen · 发表于 2006-2-2 23:17:00

偶是做笔记本的，大家知道，开机的时候要显示LOGO, 通常VGA Controller会在何时显示及何时开启LCD背光灯电压做一些控制动作：VGA Controller 先送一些Detected Frame 给LCD, 然后它Enable 开启LCD 本体的的电压，在开启背光灯的电，这样的目的在于让User看到的信息是正常的画面，具体的sequence就由VGA BIOS Control了。呵呵，扯远了。小弟的疑问是：在手机平台， LCD开机/休眠状态到正常工作状态的显示，软体驱动如何实现的，其先后顺序是为何？PS: 此BBS是否有搞Note Book 的高人，可否给小弟指点一二？[em01][em30][br]+5 RD币

jkbutton · 发表于 2006-2-7 14:00:00

1。main/sub LCD 和 Backlight的开关，folder Open/close以及sleep 的响应都是要考虑的。2。建个抽象层就好了，把和具体硬件有关的剥离出来。至于函数开销，一般读写REG都是宏的。那么几个函数出入栈，速度/空间影响几乎没有。3。优化刷新函数，这个想法很不错。要画哪个图，局部，全部，频率？但是在非smartphone上很难做到优化，这需要对平台改动很大。测试时间也应该不短吧？[br]+5 RD币

mikal · 发表于 2006-2-8 10:32:00

3、过了个春节，今天才上来。看了很多人发言；觉得各位网友的发言非常精彩啊，有些设计理念非常好。以后有机会多多交流交流！ 在OS系统中，如何规划驱动早期，一个软件仅仅是一个单任务，软件的运行都是简单的从头到尾的运行，后来提出了前后台的系统概念，再后来就有了多任务的OS概念。对于前面的单任务和前后台系统，做个驱动还是比较简单，但是如果涉及到了OS ，那么在做驱动的时候问题就比较复杂些了。或许大家现在都是在别人设计好的平台上更换驱动，所以没有太多的关注这些问题，但是如果让你来设计一个简单的带OS的平台方案，那么你又将如何考虑驱动呢？ 在这里我将以LCD为例子简单介绍下。OS将以Nucleus为例子。首先说说在Nucleus的OS中如何规划LCD的驱动和其应用。Nucleus中的硬件初始化基本上都被限制在其函数（INT_Initialize（）；INC_Initialize（）；Application_Initialize（））中处理；那么在上述的OS中我们将在那个函数中来调用我们LCD的初始化呢？简单分析上述几个函数并对Nucleus进行详细阅读后；我们就会发现，LCD的初始化程序放在Application_Initialize（）中创建的第一个空闲Task最合适，因为我们知道在Application_Initialize（）函数返回前Nucleus还没有对任务调度做初始化，所以在Application_Initialize（）函数中创建个Task,然后在Application_Initialize（）函数函数返回后，由系统做任务切换来调用LCD的初始化程序。从这里我们可以看出，LCD的初始化程序其实还是放在OS中的一个Task中，且这个Task是在开始的时候被调用一次，在以后将永远不被运行了。把LCD的初始化程序放在任务中的原因在于LCD的初始化程序比较长，耗时间也比较长，所以放在Task中运行比较合理，当然这里又有个问题就是，LCD的初始化程序是放在Task中的，那么就会涉及到函数的可重如性等问题，所以在编写这样的驱动时候要特别注意。LCD的初始化程序的位置已经定位了，那么它的应用函数，比如刷新函数将如何定位呢？同样，刷新函数是有上层应用Task决定的，一般系统平台在对刷新函数的处理各有个的方法，比如上海的展讯，采用的是在应用层Task中轮循刷新，而有些平台采用的是独立创建一个刷新函数的Task;以上方法各有个的优点和缺点，但关键一点是在不同的平台采用的方案需要此方案是此平台的最佳解决方案。好了，关于在OS中编写驱动及其应用函数的时候需要注意的问题就先说到这里。 关于驱动的感想，在此就全部结束了。我这里只是抛砖引玉；关键还是要大家一起来讨论。当然要做好驱动，考虑的东西也比较多，需要对整个系统的东西都要有所了解，包括OS,硬件电路，软件设计思想等。最后祝贺大家都能成为驱动的高手啊！ ps:在此贴中提到的问题，我会找个时间给予答复。[br]+5 RD币

Evonlin1227 · 发表于 2006-2-9 17:16:00

我倒覺得手機驅動工程師真正的價值並不在於大家所言. 其最大價值在於如何以最短的時間評斷一顆新的元件在開發平台上是否可用於量產, 能迅速釐清問題是驅動本身或是來自軟體上層(MMI or 演算法), 並且要對先進技術有掌握, 對其市場以及供應鏈充分掌握, 如此才能比競爭對手早一步開發出新產品. 元件的省電與否, 基本上90%決定在硬件, 省電模式只是軟件去設定元件寄存器的基本步驟而已, 一套驅動軟件系統在開發階段變要考量元件操作的各種狀態, 例如sleep mode, active mode, data transfer mode..等. 每一種狀態下都有對應的 API 讓 CPU 可以控制元件. 以省電模式為例, 只要在此 API 設定元件的寄存器即可, 而這些設定通常只要照著供應商建議即可達到規格書規範標準內, 而能省多少電也取決於該元件供應商的設計技術. 以在下公司而言, 完成元件驅動的時間也被用來評斷工程師的績效, 通常1~2小時內可以將LCD屏完成, 若硬件有問題也能在一天內找出問題, 超過一天的情況往往是該驅動IC有嚴重問題, 最後將不被採用. 因此, 驅動工程師必須要很快評斷元件是否能用？若拖延到採購之後才發現有重大問題, 肯定丟飯碗. 如此迅速的速度跟先前軟體架構設計得好有很大的關聯, 這才是驅動工程師更高的價值所在.[br]+5 RD币

mikal · 发表于 2006-2-9 17:45:00

<DIV class=quote>以下是引用Evonlin1227在2006-2-9 17:16:43的发言：
我倒覺得手機驅動工程師真正的價值並不在於大家所言. 其最大價值在於如何以最短的時間評斷一顆新的元件在開發平台上是否可用於量產, 能迅速釐清問題是驅動本身或是來自軟體上層(MMI or 演算法), 並且要對先進技術有掌握, 對其市場以及供應鏈充分掌握, 如此才能比競爭對手早一步開發出新產品. 元件的省電與否, 基本上90%決定在硬件, 省電模式只是軟件去設定元件寄存器的基本步驟而已, 一套驅動軟件系統在開發階段變要考量元件操作的各種狀態, 例如sleep mode, active mode, data transfer mode..等. 每一種狀態下都有對應的 API 讓 CPU 可以控制元件. 以省電模式為例, 只要在此 API 設定元件的寄存器即可, 而這些設定通常只要照著供應商建議即可達到規格書規範標準內, 而能省多少電也取決於該元件供應商的設計技術. 以在下公司而言, 完成元件驅動的時間也被用來評斷工程師的績效, 通常1~2小時內可以將LCD屏完成, 若硬件有問題也能在一天內找出問題, 超過一天的情況往往是該驅動IC有嚴重問題, 最後將不被採用. 因此, 驅動工程師必須要很快評斷元件是否能用？若拖延到採購之後才發現有重大問題, 肯定丟飯碗. 如此迅速的速度跟先前軟體架構設計得好有很大的關聯, 這才是驅動工程師更高的價值所在.</DIV>

这位老兄说的很有道理。不过对于这句话，我有不同的建议（完成元件驅動的時間也被用來評斷工程師的績效, 通常1~2小時內可以將LCD屏完成, 若硬件有問題也能在一天內找出問題, 超過一天的情況往往是該驅動IC有嚴重問題, 最後將不被採用. ）
按照你的意思来分析，你们的手机上市周期估计是2个月啊。厉害：）

Evonlin1227 · 发表于 2006-2-10 14:23:00

手機上市週期有很多因素, 相信各位都知道. 但我的意思是說, 工程面的問題必須要最小化, 敝公司企業文化(或主管的心態)是認為若因為工程因素導致量產延後, 或無法上市, 均是不可被原諒的, 而工程問題當中, 又以驅動這部分要求最為嚴格, 因為牽涉到眾多元件, 如果是在量產前才發現某處的硬件有瑕疵無法大量生產, 改一次版重新打件的時間多長？每家公司不一樣, 但至少一個月吧？而且還有採購和其他元件因此成庫存問題..等. 其他應用面的軟件即使有問題, 上市之後都還有機會改正, 唯獨驅動部分必須要在開發初期就確保無慮, 時間拖越長將壓縮後期驗證以及改善效能的時間. 例如: 以目前最流行的影像感測元件來說, 驅動工程師務必最早驗證完, 並確認該元件無重大功能面或效能面的問題會導致無法量產, 或有可能不被客戶接受, 驅動工程師這關過了, 後續才可能花時間去繼續調整後級影像處理器的自動曝光、白平衡、飽和度..等色彩處理部分.[br]+5 RD币

mikal · 发表于 2006-2-10 16:07:00

<DIV class=quote>以下是引用Evonlin1227在2006-2-10 14:23:54的发言：
手機上市週期有很多因素, 相信各位都知道. 但我的意思是說, 工程面的問題必須要最小化, 敝公司企業文化(或主管的心態)是認為若因為工程因素導致量產延後, 或無法上市, 均是不可被原諒的, 而工程問題當中, 又以驅動這部分要求最為嚴格, 因為牽涉到眾多元件, 如果是在量產前才發現某處的硬件有瑕疵無法大量生產, 改一次版重新打件的時間多長？每家公司不一樣, 但至少一個月吧？而且還有採購和其他元件因此成庫存問題..等. 其他應用面的軟件即使有問題, 上市之後都還有機會改正, 唯獨驅動部分必須要在開發初期就確保無慮, 時間拖越長將壓縮後期驗證以及改善效能的時間. 例如: 以目前最流行的影像感測元件來說, 驅動工程師務必最早驗證完, 並確認該元件無重大功能面或效能面的問題會導致無法量產, 或有可能不被客戶接受, 驅動工程師這關過了, 後續才可能花時間去繼續調整後級影像處理器的自動曝光、白平衡、飽和度..等色彩處理部分.</DIV>

看了看，觉得你前面说的我都同意，可后面说的我不同意，就如sensor来说，驱动好了，就认为sensor是好的吗？不调下影像质量，你怎么能知道sensor的ｍｏｄｕｌｅ是好的？？

Evonlin1227 · 发表于 2006-2-10 17:17:00

我的意思是, 第一步要先確認驅動部分沒有大問題, 在這個階段應該就可以把影響量產的問題找出來, 如果真有問題, 就不需要浪費時間進行影像部分的調整了. 至於 module 的問題, 您指的應該是大量生產下良率的問題吧?每家公司都有IQC(進貨標準流程), 制度好、規模大的公司一般都會把關好sensor module進貨的品質, 如果不幸公司為了貪小便宜, 買進了一堆良率不佳的module, 有一定比例的module出現影像品質的問題, 那就要想辦法去解決了, 但是這與驗證sensor能否採用無關, sensor若真有設計缺陷, module製造技術再佳都隱藏不了, 是屬於共通問題, 例如低環境光源下雜訊甚大, 曝光穩定度不佳..等. 這些是需要修改sensor設計才有辦法解決的, 而module部分品質不佳的原因, 常常是因為電壓源或clock訊號不穩定讓部分可靠度較差的module出現問題, 此時可以靠加強訊號的品質去避免問題, 若是遇到像是鏡頭裝歪或是連接版品質..等無法以軟件解決的問題, 一般強勢且重視品質的公司都以退貨方式處理, 而已我所知, 這些module廠會以更低廉的價格賣給其他公司, 像是不重視品質的水貨商, 或是IQC不甚嚴格的小公司.[br]+5 RD币

mikal · 发表于 2006-2-13 09:44:00

呵呵，看来Evonlin1227老兄所在的公司应该是做平台提供方案级别的啊；我前面说的的module指的是sensor　module厂商提供的sensor对封装的具体参数有一定的规定，比如焦距，光圈，景深等对图像都非常重要的参数，你认为这和IQC有关系吗，与驱动有关系吗？其实我不是反对你说的，因为就我所知道的，目前国内涉及到手机驱动这块，基本上是不太考虑驱动是否通不通的问题，因为如你说的每个公司都有IQC,他们产品都是先保证能用的情况下才出货的。当然或许你说的驱动主要指自己这端对被驱动芯片的支持问题，这可能是比较重要的，因为没有用，你也不知道自己的芯片是否能驱动被驱动的芯片。从我目前的经验看，不要怀疑别人产品是否能不能用？而是要弄清楚他的产品品质问题，比如sensor来说，我们关注的是他封装后成像的图像品质到底能达到什么水平，因为这和他的封装水平是有很大关系的。至于是驱动方面，和封装厂商基本没有任何关系，比如我们选OV的COMS　sensor，那么驱动其实是和OV公司有关系，再如果你选了OV9650，假如你用了是A厂商对OV9650的封装的产品，而调了两天没有成功，你认为这是A厂商的错呢还是OV的错？实际上他们都没有错，错的在你这边。当然具体问题要具体分析，关键是要在主次问题上把握住。通常在设计手机过程中，对于关键的器件的选择是非常谨慎的，通常都是按照平台方案来选的，自己一般不敢造次：）[br]+5 RD币

Evonlin1227 · 发表于 2006-2-21 17:38:00

Hi Mikal,我舉個簡單的例子來說, 假設您發現某一顆 sensor 只能提供 39Mhz 的 clock 給它, 可是在您的平台上沒有辦法提供這種 clock, 或者只能提供比 39MHz 大很多或小很多的 clock, 大很多的 clock 肯定行不通的, 可是小很多的 clock 會使得 sensor data rate 降低, 已經可以料想到實現出來的 camera 預覽的 frame rate 會大打折扣. 如此情況, 還有必要在去看這一家 sensor 的影像品質跟 lens/module 製造的好壞嗎？這只是一個很明顯可以看出的問題, 但是有些二線的 sensor 廠會有一些設計上的問題, 而且不太容易發現也無法以軟體的方式迴避, 這些都是應該在調整影像前過濾的. 另外, 您指的驅動屬於sensor 廠端的問題, 事實上並不見得, sensor 只有寄存器的設置而已, 並沒有驅動程式在上面執行, 所有的驅動程式都是由 multimedia IC 或 host 這邊控制的, sensor 若具有的問題都是要靠後端的 ISP 或 multimedia IC 的 firmware 來迴避, 尤其是只有使用 sensor raw data 的情況下, 這時 AE/AWB 都不是 sensor 控制的.[br]+5 RD币

bvg · 发表于 2006-2-27 16:24:00

iflyinwater · 发表于 2007-5-9 10:07:00

很好 ,学习这种精神.从不同的角度看问题.

jorners · 发表于 2007-5-9 16:12:00

(不过对于这句话，我有不同的建议（完成元件驅動的時間也被用來評斷工程師的績效, 通常1~2小時內可以將LCD屏完成.)

按这位兄弟的话,我应该都失业了N次.哪个驱动工程师拿到一个LCD两个小时内就能做完.?我们驱动组定的是三天做完LCD.其实如果LCD接口不同于以往的LCD接口,硬件工程师飞线就至少半天,碰到哪儿飞错了,你一检查又一天过去了,再碰到编译程序验证又半天过去,三天时间作完都只是在你一切还较顺畅的情况..

这位老兄不知道1~2个小时是怎么计算出来的?不敢苟同.

harbincampus · 发表于 2007-7-19 15:08:00

这样的文章，要是多一点该多好啊！
感觉驱动这个版块讨论的东西都是驴头不对马嘴。

man_in_man · 发表于 2007-9-6 09:45:00

<DIV class=quote>以下是引用cxin2在2006-1-23 12:14:00的发言：
我做的GSM通讯驱动层对不同的系统的API接口函数不一样，对下倒还好，是对虚拟串口进行操作，无论下面硬件平台怎么变化，向下的接口基本不变。向上的API，对于不同系统之间，变化很大，我在我自己的驱动上面又加上一层proxy层，这是参考微软windows mobile的做法，对于不同系统来说，我做了一个接口，可以把不同系统对通讯API的调用转化成我自己驱动里面的API，这样对公司来说，无论项目怎么改变，我只需要更换proxy层就好了，至于我自己真正的驱动层，则无需太大改变，这样核心技术牢牢掌握在自己手里，当然我说的是通讯驱动的核心技术而已，^_^，让大侠们见笑了。
我想不管是什么驱动，都存在command和resonse，严格来说，做到proxy不是特别难的事，但是这样可以减少很多重复工作量，可以将更多精力花在怎么提高驱动性能、降低功耗、提高与其他部分的协调能力上面，当然也可以花更多时间去学习其他驱动、系统、硬件、协议栈、网络传输等等上面。

+5 RD币</DIV>

觉得手机这块驱动就是作不深入，都有些不想做了。。。
想请教个问题，怎么把通信系统作成异步的，就是说把command和response分开，
但是当response出错时能够知道是哪个command出的错，
最近在写下载程序，如果采用同步的方法，影响速度，但异步的话，又没有办法保证数据传输不会出错。

		自动登录	找回密码
密码			注册

[讨论] 关于驱动的感想（顺便拿点ＲＤ币过年：））