TI OMAP3 DM3730 USB host controller high full low speed?

因為 TI OMAP3 DM3730 在 USB host controller 上偵測不到 full/low speed USB device，經查之後發現目前的硬體接線 ULPI 因為 DM3730 跟選用的 USB transceiver 的ULPI phy 的 serial 排線順序不一樣，在設定為外接 USB transceiver phy，而非 TLL 的接線方式時，無法使用 full/low speed mode，選用 device 時必須注意只能接 high speed device，如果要保持原有 

USB host controller ---phy--- USB transceiver --D+D-

接法， ulpi phy 線路不改而想要使用 full/low speed USB device，可以再外接一顆 high speed USB hub 解決。

2012/02/24

今天又花了些時間跟 Ken，還有 EE 確定 USB 問題，有些地方一開始誤解，因為是從軟體驅動程式行為，發現硬體有問題，一開始以為是目前元件接法

USB host controller ---phy--- USB transceiver --D+D-

無法實作， EE 在我提出有問題後就進行調查，發現是 ulpi serial 無法對應，其實並非這樣子的元件接法問題，而是 DM3730 的輸出分 ulpi parallel, ulpi serial, TLL 三種，因為我們有接 transceiver，就只能選擇 transceiver 有支援的 ulpi parallel 或 ulpi serial二擇一，high speed 的接法是 ulpi parallel，而 full/low speed 的 ulpi serial 接法，因需要接腳比 parallel 少，原本可以使用同一組硬體排線，但是因為 DM3730 跟所用 transceiver 的 ulpi serial 接腳順序與 transceiver 不同，造成無法使用現有的線路，待跳線驗證後可確定。

結論：

跳線加上 ohci driver 實測驗證後發現以 3 wire 的 ulpi serial 對 usb transceiver 就已經會發生誤判為有 USB low device (MiniPCI-E 上沒插卡)，但我們 usb host port 的 transceiver 又沒有介面控制調整為 3-wire serial, 6-wire serial 或 12(8+4) parallel(預設)，再加上 DM3730 SoC 原有的 ehci 轉換到 ohci 就會鎖死的 bug，最後確定無法使用原來的 

DM3730 USB host controller -- phy -- USB transceiver -- D+D- 

的接法，必須要再外接一個 USB hub 在 MiniPCI-E 上才能使用 USB full/low speed device.

相關文章：

linux USB hid driver cypress_m8.c

ARM Linux kernel 記憶體配置

摘譯這篇由 Russell King 在 2005 年 11 月 17 日針對 2.6.15 Linux kernel 撰寫的 ARM Linux kernel 記憶體配置。

裡面指的是 linux kernel 使用 arm cpu 的虛擬記憶體的位址配置與排列方式

arm cpu 的虛擬記憶體定址空間: 4GB (32 位元的定址空間, 0000,0000 ~ FFFF,FFFF)

沒有遵循這個記憶體配置的 kernel 可能無法開機或發生隨機當機


===========開始=========針對 user space 的加入內容==========================

針對每個 user space 程式而言，其實都跟硬體裝置的記憶體映射空間， kernel 使用的記憶體空間，三者共用整個 4GB 的虛擬記憶體。

user space 程式這個區塊內部的記憶體配置如下：
   +----------------------+---------------------+-----------+------------+------------+
    | Code segment(r+x) | Data segment(r+w) | BSS(r+w)  | Heap(r+w) | Stack(r+w) |
   +-------------------------------------------------------------------------------------+

Code segment 是 instruction memory，儲存程式碼
Data segment 是 data memory，使用 brk(), sbrk() system call 改變或查詢 Program break 大小
BSS segment 是未初始化的 global 變數存放位置
Heap segment 儲存程式執行期產生的動態變數、記憶體區塊由 malloc() 取用，free()  釋放
Stack segment 使用 SP stack pointer 暫存器輔助 IP instrcution pointer 指定，由 function call, 與其 local 變數使用 

註：參考 Memory Management for System Programmers (pdf)

在 Linux 系統底下我們可以藉由 /proc/some_pid/maps 看到執行檔與 library memory map，另外 smaps 則詳列各區段 memory map 的使用狀態。其中可以看到從  0x0000,1000~0xBF00,0000 的載入函式庫與 heap, stack, 其中 stack 與 TASK_SIZE 相鄰

舉某個 android process 為例：
其中

    0xBEBE,9000- 0xBEBF,E00 是 stack 使用
    0xB000,0000 ~ 0xB001,0000 是 linker 載入位置, Thread 0 Stack
    0x8000,0000 ~ 0xAFE46000  是 Non-prelinked libraries
    0x4154,C000 ~ 0x8000,0000 是 mmap'd 記譯體，Java jar library, apk 檔案
    0x4000,0000 ~ 0x4154,C000 是 mmaped open file
    0x0000,A000 ~ 0x003C,4000 用在 heap
    0x0000,1000~0x0000, A000 佔用 .text (code segment) / .data 

Android 2.3 以前的 prelink library build/core/prelink-linux-arm.map 裡面除了重述 Russel King 的 ARM Linux kernel memory 的記憶體配置，Android 的記憶體配置中，包含兩塊系統預設的 library memory mapping:

    其中 Android prelink 定義了以下兩大塊記憶體對應：

    # 0xA0000000 - 0xBFFFFFFF Prelinked System Libraries
    # 0x90000000 - 0x9FFFFFFF Prelinked App Libraries
    可以在 prelink-linux-arm.map 中找到或新增你要加入的 library 記憶體對應。

    # 0xA0000000 - 0xBFFFFFFF Prelinked System Libraries
    0xAEF00000  - 0xAFF00000 # core system libraries
    0xAE700000 - 0xAEE00000 # bluetooth libraries
    0xAE300000 - 0xAE600000 # extended system libraries
    0xACA00000 - 0xAE200000 # core dalvik runtime support

    0xA9C00000 - 0xAC900000 # graphics

    0xA8D00000 - 0xA9B00000 # audio

    0xA7000000 - 0xA8B00000 # assorted system libraries

    0xA4800000 - 0xA6F00000 # pv libraries

    0xA4000000 - 0xA4700000 # opencore hardware support

    0xA3800000 - 0xA3900000 # pv libraries

    0xA2F00000 - 0xA3700000 # stagefright libraries

    0xA2A00000 - 0xA2E00000 # libraries for specific hardware

    # 0x90000000 - 0x9FFFFFFF Prelinked App Libraries
    0x9CA00000 - 0x9F000000 # libraries for specific apps or temporary libraries

# 0xC0000000 - 0xFFFFFFFF Kernel
# 0xB0100000 - 0xBFFFFFFF Thread 0 Stack
# 0xB0000000 - 0xB00FFFFF Linker
# 0xA0000000 - 0xBFFFFFFF Prelinked System Libraries
# 0x90000000 - 0x9FFFFFFF Prelinked App Libraries
# 0x80000000 - 0x8FFFFFFF Non-prelinked Libraries
# 0x40000000 - 0x7FFFFFFF mmap'd stuff
# 0x10000000 - 0x3FFFFFFF Thread Stacks
# 0x00000000 - 0x0FFFFFFF .text / .data / heap

====================針對 user space 的加入內容==========結束================

因為 cpu 架構的發展變化可能影響 kernel 記憶體位置的配置，user space 程式應該只使用到 0000,1000 ~ TASK_SIZE -1 這段記憶體。請使用 open(), mmap() 系統呼叫使用這段記憶體。

    FFFF,8000 ~ FFFF,FFFF           copy_user_page/clear_user_page 使用
    SA11xx 跟 Xscale cpu 建立 minicache 的記憶體位址

    FFFF,1000 ~ FFFF,7FFF           保留
    各平台禁止使用這塊記憶體配置

    FFFF,0000 ~ FFFF,0FFF           cpu vector page
    如果 cpu 支援改變中斷向量位址 (control register V bit), 會把中斷向量映射到這
    4K bytes 區塊

    FFC0,0000 ~ fffe,ffff           DMA 記憶體映射區塊，由 dma_alloc_xxx 的
    函式呼叫都使用這塊記憶體動態配置，總共 0x003F,0000 佔 4MB

    FF00,0000 ~ FFBFF,FFFF          保留給 DMA 記憶體映射擴充使用 佔 12MB

    VMALLOC_END ~ feff,ffff         平台自由運用的記憶體區塊都建議用這段
    VMALLOC_END 必須對齊 2MB 的記憶體區塊
    在 arch/arm/mach-pxa/include/mach/memory.h 中定義

    #define ARM_DMA_ZONE_SIZE SZ_64M 除了以上 16MB 保留給 DMA 另外用了 48 MB
    使用 FBC0,0000~fffe,ffff
    在 arch/arm/mach-pxa/include/mach/vmalloc.h 定義
    #define VMALLOC_END       (0xE8000000UL)

    VMALLOC_START ~ VMALLOC_END - 1 vmalloc() / ioremap() space
    由 vmalloc() 及 ioremap() 取得的記憶體會動態配置在這區塊，VMALLOC_START 相依
    於 high_memory(不能有重疊)
    在 arch/arm/include/asm/pgtable.h 中註解有說明留 8MB 給誤動作的記憶體錯誤緩衝空間，
    定義如下：
    #ifndef VMALLOC_START
    #define VMALLOC_OFFSET      (8*1024*1024)
    #define VMALLOC_START       (((unsigned long)high_memory + VMALLOC_OFFSET) &
                                                      ~(VMALLOC_OFFSET-1))
    #endif

其中 high_memory 在 arch/arm/mm/init.c 的 void __init bootmem_init(void) 計算：
    high_memory = __va(((phys_addr_t)max_low << PAGE_SHIFT) - 1) + 1;

    PAGE_OFFSET ~ high_memory - 1   Kernel direct-mapped RAM region
    這段記憶體對應到平台上的實體記憶體，通常跟系統記憶體是 1:1 的對應
    (direct addressing) 在 arch/arm/include/asm/memory.h 看到 PAGE_OFFSET 定義為
    UL(CONFIG_PAGE_OFFSET)
    也因此我們可以在 arch/arm/include/asm/memory.h 看到以下 virtual, physical 記憶體互轉的
    巨集定義：
    #define __virt_to_phys(x)   ((x) - PAGE_OFFSET + PHYS_OFFSET)
    #define __phys_to_virt(x)   ((x) - PHYS_OFFSET + PAGE_OFFSET)

    其中的 PHYS_OFFSET 實體記憶體在 cpu 定址的記憶體初始(start of bank 0 dram)位址
    ，是定義在同檔案的以下巨集：
    #define PHYS_OFFSET UL(CONFIG_DRAM_BASE) 與
    #define PHYS_OFFSET PLAT_PHYS_OFFSET
    CONFIG_DRAM_BASE 是實體記憶體起始的 offset 值，在 pxa 平台可以
    在 arch/arm/mach-pxa/include/mach/memory.h 中看到定義為：
    #define PLAT_PHYS_OFFSET    UL(0xa0000000)
    我們可以對照 pxa270 spec memory map 章節的 dram map 起始位址
    0xa000,0000 作為實體記憶體的起始位址得到驗證。
    再配合 arch/arm/Makefile 定義的 Linux kernel image text area 值
    TEXT_OFFSET := $(textofs-y)
    而 textofs-y   := 0x00008000 是預設值。
    arch/arm/boot/Makefile 告訴我們 zImage 等 target 就是
     21 #   ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)
    因此可以算出：ZRELADDR = PHYS_OFFSET + TEXT_OFFSET = 0xA000,8000 (physical)
    而虛擬位置是 0xC000,8000(virtual)，這個計算結果可以跟 Makefile include 的
    include $(srctree)/$(MACHINE)/Makefile.boot 檔案，在 pxa 平台就是
    arch/arm/mach-pxa/Makefile.boot 檔案裡面定義的 zreladdr-y
    zreladdr-y   := 0xa0008000
    在實務上我們也可以修改 zreladdr-y 定義的實體記憶體位址，來改成我們想要把 linux kernel
    起始點放在 physical memory 的哪一個位置上。這也就是為何我們從 boot loader 載入 linux
    kernel 都要指定到某個固定實體記憶體位址的原因，因為在 make kernel 時就決定了這個位址。

    PAGE_OFFSET 也就是 linux kernel image 的虛擬位址起始點, 0xC000,0000 3GB 的 user address
    space

    TASK_SIZE ~ PAGE_OFFSET - 1     Kernel module space
    使用 insmod 動態載入的 kernel modules 會在這段記憶體使用動態配置
    arch/arm/include/asm/memory.h 定義
    #define PAGE_OFFSET     UL(CONFIG_PAGE_OFFSET)

    0000,1000 ~ TASK_SIZE - 1       User space mapping
    每個 thread 使用 mmap 對應到這段位置
    arch/arm/include/asm/memory.h 定義
    #define TASK_SIZE         (UL(CONFIG_PAGE_OFFSET) - UL(0x01000000))
    如果 PAGE_OFFSET = 0xC000,0000，則 TASK_SIZE = 0xBF00,0000 (3GB - 16MB)

    0000,0000 ~ 0000,0FFF           cpu vector page, null pointer trap
    不支援中斷向量重新映射的 cpu 會把中斷向量 page 放在這 4K bytes

關於以上作業系統的 Virtual address map 我們可以使用 arch/arm/mach-pxa/generic.c 與 arch/arm/mach-pxa/include/mach/hardware.h 的建立 memory mapped device 跟 chip select memory mapped device 的 Virtual -> Physical mapping

arm 因為使用到 co processor 15，controller register(1th), v bit (13th), 因此用到 vector page relocate 功能，原本會到 0x0000, 0000 找 vector table 的動作改為到 0xffff, 0000 找 vector table，而我們在 mmu 啟動後使用的 0xffff,0000 Virtual address 就是在 arch/arm/mm/mmu.c 的 devicemaps_init() 中將 Linux kernel 開機時在 arch/arm/kernel/entry-armv.S 建立的 vector table 存在 SDRAM 後，建立一組 0xffff, 0000 high vector page 對映到實體記憶體的 vector table，因此 Linux kernel 開機啟動 mmu 進入 virtual address mode 後才能在硬體發出 exception 中斷時，找到 vector table 處理中斷。

Jonathan Danylko 二十年來的程式設計心得

Jonathan Danylko 寫了一篇 Top 20 Programming Lessons I've learned in 20 years

摘譯如下：

Jonathan Danylko 自十一歲起就已經愛上科技與程式設計。他發現從事程式設計二十年來有許多困難與容易的課題，也許同樣身為程式設計師的你沒有經歷過，接下來將要分享他的經歷與心得(以下的我，如無特別註記，代表 Jonathan Danylko 先生)：

我會隨著時間修改內容，也許以後會想到更多的事，但目前這二十條心得已經足以包含所有的程式設計大小事。以下就是記憶最深的部份：

一、設定你認為解決這個問題要花的時間。不管設定半小時或一小時都好，當你在自己設定的時間內無法解決某個問題，就找人問吧，不然趕快上網查資料也好。

二、一個程式語言就只是個語言。當你對單一個程式語言夠熟，就很容易對其他程式語言觸類旁通，學習效果越來越好。你用來解決問題的程式語言要讓自己有相當的"舒適"感，不影響邏輯思緒，可以產生有效率而且簡潔的程式碼，最重要的是挑一個最適合解決這個問題的程式語言。

三、不要過度強迫自己使用設計模式。有時候一個簡單的演算法就足夠，不需要再去勉強套上 singleton, facade 設計模式。對大部份的情況來說，簡潔的寫法最容易懂。

四、永遠要記得備份程式碼。我記得當發生硬碟全毀，資料完全救不回來的情景，並對曾經發生的慘劇永保警惕之心。當你忘記備份時，可能就在要交程式的前夕發生悲劇，不管某一版本程式碼(snapshot)或版本控管紀錄都需要備份。

五、面對現實吧！你不是最強的程式設計師。我以前常認為自己很瞭解程式設計，但事實上你總是會遇到比你強的程式設計師。請向他們學習。

六、增進你的學習能力。因為第五項的緣故，我總是手邊帶著一份電腦書籍或雜誌（我的朋友可以幫我作證），的確目前電子科技日新月異，要真的完全趕流行可是一份全職工作才做得來的。當你有足夠聰明的學習媒介與方法，就可能一直乘著浪頭走。

七、變化是常態。你的科技知識跟程式設計能力應該像投資股票一樣：分散風險。不要一直專注在單一項目自我感覺良好。

如果某個程式語言與科技的支援不足，你也可能需要更新履歷，開始重新練功。讓我保持一直向前的原則：至少要會兩到三種不同類別的程式語言，當其中一項開始被取代，失去應用場合，至少你還有可以撐場面的第二專長，並開始繼續學習新專長，隨時保持熟悉兩、三種程式語言的程度。

八、支援新進人員。幫助並訓練新進開發人員，教導程式設計原則與技巧。你永遠無法預測下一步...你可能陞官，此時你會慶幸自己有對新進人員傾囊相授，因為你陞官空缺的位子將有人幫你抬轎。

九、簡化演算法。撰寫程式時可以窮盡你的能力寫出複雜的程式，當完成後記得回去檢視你的程式碼進行改善。一點一滴的程式改進讓你日後可以愉快的維護這份程式碼。

十、為程式碼撰寫文件。不管是網站服務的 API 或是單一類別的文件，凡寫過的程式必留下文件。我常被批評寫太多註解，但這卻是我引以為傲之處，為兩三行程式碼註解可能只要幾秒鐘，如果是用了非常規的解決辦法，則更需要註解清楚你在寫什麼。

如果文件寫得好，將可以嘉惠設計架構、接手的程式設計師、技術支援部門的人。

十一、測試、測試、測試。我是黑箱測試的擁護者。當你完成程式後，就開始要對這段程式負責了，如果你們有品保部門，你將需要跟品保部門解釋更多程式錯誤。如果你不完整的測試程式，除了需要改善程式碼以外，還會得到壞名聲。

十二、慶祝每次成功。我看到很多程式設計師解決令人頭痛的問題，他們會跟同事慶祝，不論是簡單的搖擺、擊掌或是一段舞動。每個人在生命中遇到美好的事物，寫程式時也可能因為寫出得意的程式碼想分享喜樂，也許你已經看過類似的解決方法上百次，還是要記得跟你的同事同慶第一百零一次的歡樂。

十三、不論是專案或個人的程式，頻繁檢視程式碼。在公司中你總是有機會檢視程式碼，讓人評鑑你的程式碼品質。不要認為別人故意惹惱你，把建議當作建設性批評。就個人而言，永遠都要重新檢視程式碼，並總是自問：

我要如何寫得更好？這將加速你的學習，讓你成為更好的程式設計師。

十四、回憶自己的程式碼。有兩種看以前程式碼的方式：

我不敢相信以前寫這麼差。

跟

我不敢相信以前寫這麼好。

第一種是覺得以前寫得很差，想知道如何改進。你將知道舊的程式碼可以如何重構成更好的函式，或甚至改善整個專案的程式碼。

第二種是驚訝於自己以前的成就，開發者會有一兩個完成的專案，讓同事對你肅然起敬。當然這是來自你的絕佳的程式設計能力，你可以拿出以前的函式庫或專案計劃，並改進成為更好的產品或創意。

十五、培養幽默感。在二十年的開發經驗中，所有同事都抱著一定的幽默感，事實上幽默感是你在這行業生存的必備技能。

十六、小心自稱全知、最懂的同事，佔有慾強，與沒經驗的程式設計師。遇到這些人你反而要表現謙虛。自稱全知、最懂的人只是想吸引你的注意力，無法成為團隊成員。佔有慾強的同事完成工作後，不會跟任何人分享。沒經驗的同事每十分鐘就會問你一個問題，到最後他的程式都是你幫他完成的，而非他自己寫的。

十七、沒有簡單的專案。我常遇到朋友、家人、夥伴說：幫我寫個簡單的程式。要寫個簡單的程式或網站，實際上需要雙方共同規劃，才可能完成一個雙方都滿意的產品。如果有人說需要使用微軟 Access 寫三頁網頁，實際上他要的可能需要十五個網頁才能完成的功能，並且需要使用 SQL server、還有討論區、客製化的內容管理系統。

十八、沒有理所當然的事。當你接下簡易的專案，可能會發現有些部份很容易解決。別這樣想。在你沒有一份已經完成的類別、元件、或一段函式，並且經過完整測試，在成功加入現有專案的產品之後，你再這樣想吧。

十九、軟體沒有完成的一天。曾經有同事告訴我軟體沒有完成的一天，只有暫時結案。非常棒的建議。只要客戶還在使用你寫的程式，在經過一段時日的驗證後，大部份情況是你還在繼續維護同一份程式碼。當然這並非壞事，這樣我們才有工作。

;-)

二十、耐心是一項美德。當客戶、朋友、家人使用電腦遇到挫折，最後對電腦元件莫可奈何時。我總是告訴他們：是人在控制電腦，不要讓電腦反客為主。寫電腦程式時也同樣需要足夠的耐心，當程式設計師知道自己犯錯，並從電腦的角度理解之後，就會知道錯誤在哪裡。

希望以上的心得能夠啟發你，或讓你會心一笑。

;-)

Javascript 語法蜜糖 CoffeeScript

摘譯 CoffeeScript 維基百科：

CoffeeScript 是用 ruby 寫的一種 Javascript 程式碼產生器。其中採用了 Ruby 與 Python
(比如 indent 取代大括號) 兩種程式語言的特性來簡化撰寫 Javascript 的語法，另外也
增加陣列轉換 (Array Comprehension)與正規表示(Pattern Matching) 的擴充語法。

使用 CoffeeScript 的好處是可以用更簡潔的程式碼，達到原本用 Javascript 寫出的
同樣功能，而不影響到執行期效能。Javascript 之父 Brendan Eich 表示 CoffeeScript
也影響到他對 Javascript 語言將來的發展規劃。

Ruby on Rails 預計在 3.1 版將會支援 CoffeeScript 。

CoffeeScript 可以在瀏灠器直接執行或透過 Node.js (Server side 執行的 Javascript 程式
,event driven I/O framework for V8 Javascript engie on Unix)執行。

 讀完維基百科後，可以繼續看 PragProg Magazine 的 CoffeeScript 五項改進：
一、變數宣告依所在的 namespace 為全域或區域變數，不再因為宣告變數忘記加
var 而覆蓋已經宣告過的全域變數。CoffeeScript 也會將變數限定在單一檔案的匿名
函式中。

二、ajax call 中的 this 在 CoffeeScript 中同樣指到目前 context 的物件，this 關鍵字
也可以用符號 @ 代替

三、CoffeeScript 繼承 ruby 慣例將函式最後的 expression 自動當函式返回值，也可
以在變數賦值的語法 a = 後加上 '->' 自動將 a 由變數改為函式

四、CoffeeScript 在迴圈中使用 do 關鍵字，可以更容易為迴圈加入需取值的函式。

五、提供語法蜜糖，讓程式碼更簡潔

另外據說現在 GitHub 的開放源碼存量已經超過 SourceForge，再來是 Google Code 
第四是微軟的 CodePlex，另外還有支援 Mercurial distributed version control system (DVCS)
的 BitBucket 可以參考。

CoffeeScript 官網
CoffeeScript@Gihub 
A CoffeeScript Intervension

寫驅動程式的工作流程

常聽別人說寫驅動程式很簡單，但自己卻偶而才有這種感覺，因此整理至今為止，
在寫驅動程式可能需要注意，檢查的部份，若有新的心得再繼續更新修正與補充。

standard operating procedure(sop), work flow to write a device driver:

hardware
1. power on? reset timing sequence. study device spec, platform cpu/soc spec.
2. bus interface: host and device part, study bus spec
3. clock for device or device interface bus, study bus spec
4. power pin voltage in device datasheet spec?, study device spec

use multimeter(三用電表) to check voltage, current or resistance
use oscilloscope (示波器) to study and check clock timing, signal sequence and timing，
use Logic Analyzer(邏輯分析儀) to study and check bus protocol

software

5. board initial code:
struct machine_desc in arch/arm/include/asm/mach/arch.h
for example:
arch/arm/mach-s3c64xx/mach-smdk6410.c
search for MACHINE_START()
.init_irq for irq initialization
.map_io for memory mapped address space
.init_machine for board initial startup code and some early driver power on

6. gpio setting or multi-function pin, study soc spec, device spec

gpio_request() to reserve our gpio pins to prevent other drivers' disturbance

memory mapped i/o chip select timing setting, study device read/write timing
and SoC memory mapped timing sequence, memory mapped address space
assignment (resource in platform device)

use iotable_init() to define .virtual, .pfn, .length, .type in struct map_desc
irq(interrupt pin) from gpio pin (use gpiolib and resource in platform device)

use gpio_to_irq(), set_irq_handler(), enable platform interrupt vectors
assign platform_driver name to corresponding platform_device

use platform_add_devices() to add platform device drivers

7. device power/reset sequence, study device spec

8. device initial command, study device spec, sample driver reference

9. device register read/write verify, device register interace
(memory mapped i/o chip select setting, bus procotol spec, device init
command)

10. device setting command, study device spec

11. device driver export device node in /dev, information in /sys, /proc

12. make device nodes in /dev, by driver or mknod
check device file major/minor number in ~linux/Documentation/devices.txt

13. library cross compile, setting matched to /dev path?
export CC=/path/to/cross/tools; ./configure --build=x86-linux,
--host=arm-linux

14. application cross compile, set correct link path to library(prefix)
export CC=/path/to/cross/tools; ./configure --build=x86-linux,
--host=arm-linux --with_lib=/path/to/cross/compiled/lib

inspired by jserv: 分享是最好的記憶

希望人人都會寫驅動程式，只要有硬體設備，Linux 都可以支援。

別當自作聰明的程式設計師(我認錯)

Bruce Sterling 轉貼了一篇標題為 Mea Culpa (我認錯) 的程式設計師反省文。並重新定標題為別當自作聰明的程式設計師。原作者是從 1969 年就開始進入程式設計領域，已有超過四十年程式設計經驗的 Jonathan Edwards。Bruce Sterling 認為文中的反省並不只是作為單一程式設計師的反省文，而是整個軟體產業需要一起面對的共業。

摘譯如下：

程式設計因為需要高度的分析能力，常常讓我們陷入一個誤區，為了提高程式設計能力，而不斷讓優秀的程式設計師擁有強大的優越感，自認為高人很多等，特別是相對於平庸的程式設計師，我們都希望盡情炫耀自己的聰明才智，得到同儕的仰慕眼光。但在之後的大半輩子裡，我痛苦的領悟到程式設計的重點在於態度、而非聰明才智。

現實問題的磨難最容易激發出聰明才智的創意靈感，但結果的表象雖然讓人驚喜於充滿創意的解決方案，實際上卻是後續長期維護災難的開端。一個讓人眼睛一亮的程式設計方式，但卻可能深藏著無數的深層炸彈，在日後一一引爆。

而在日後維護過程中，可能我們又會自我優越的認為，只有我才能解決其他平庸者無法解決的精密設計疏失，比如特製的資料庫系統，多線程(multi-threaded)的作業系統。

後來我把整個系統轉移到新框架上，解決掉讓人困擾了二十年的長期維護工作。這痛苦的領悟與經驗讓我瞭解，程式設計不是當最聰明的人，程式設計告訴我的是軟體是如此的複雜，讓全世界最聰明的菁英都顯得微不足道；不要想單靠一己之力解決所有複雜的問題。程式設計的重點在於簡化與慣例。把這句話倒著刺青到你的額頭上，這樣每次看到螢幕中的你都可以提醒自己這項原則。其中最重要的是態度：努力工作、負責任、專注在實際問題，而非未經驗證的猜測。

程式設計其實跟其他的工程與設計不盡相同。其中的主流文化常常陷在前面說的自我感覺良好誤區。就像是格列佛遊記般，只是多了大括號，中括號，縮排位置，要不要加小括號等議題。我們唯一同意的是其他程式設計師有多愚蠢，但我們應該自己試著 Google 一下"愚蠢的程式設計師"，就會看到自己也名列其中。

程式設計技術的提升仰賴於文化的提升，我們能做的就是在自己的工作中耐心、持續的付出、分享交流我們學習到的經驗與心得。

參考文獻：

1. Programmers should stop being such smart-alecks
2. Mea Culpa

OpenBSD 開發與版本控管流程

要如何做才能真正在每次版本發行時，能夠不再因為重大軟體瑕疵
而延遲、改變時程？

OpenBSD 的開發流程，告訴我們的是開發流程與軟體品質的密切關
係，OpenBSD 團隊如何克服開發、測試時人性懶惰的弱點？以及他
們考量哪些重點？做了什麼？80 位開發成員如何互動來確保軟體品
質。

首先是對發行版本這項工程的定義：用科學方法設計、開發結構、
機械、裝置或製造過程；不論是處理個別單一項工作，或是整合成
一體的工作；也是對於建構、操作有完整認知的過程；在特定控制
變因內預測行為；所有針對特定功能、經濟運作、保全生命財產安
全等都算是工程的定義。

一般商業公司有足夠的人力、資金、時間可以同時有開發、測試團
隊一起運作，但是開放源碼軟體在這種執行模式下會有問題...發行
的軟體版本通常是未經完整測試的產品，需要持續修正。

發行版本的理想程序是：全部程式碼都經過測試、經過最多人測試
、最短的測試時間、最少的痛苦除錯...當然實際上我們只能取到折
衷方案。

完美的發行理想程序可以帶給我們：沒有重大錯誤造成使用者退回
上一版、大部份的新開發功能都可正常使用、開發者開心、使用者
歡喜、可以在發行版本後快速回到功能開發。

但實際上常是發行版本後，進入維護版本的除錯無間地獄...

最常見的流程就是：開發 --> 準備發行版本放慢開發腳步 -->
Tag/branch release tree --> Test & Fix --> Product N
通常是在 branch 之後交由發行版本的團隊進行 build/test，然後發
現錯誤需要 bug fix merge 回 trunk，或需要由 trunk merge 到發
行的 branch，就一直循環....直到真正修完錯誤，或是大家都精疲力
盡，結果通常是：好吧，只能出這版了！

其中的問題點在於：
一、只有少數人在測試
二、開發者在要發行版本的 branch 除錯修改程式
三、發行後的重點變成維護產品 branch
四、流程容易拖延
五、許多開發者陣亡(指對這個產品的心靈已死)

OpenBSD 進入 Tag/branch 之前的開發流程：

減慢開發速度，進行回歸測試-->鎖定 API/ABI 不再變更-->
早期套件 build test -->鎖定 tree(需經認可後才能再更動)-->
開發者執行測試工作-->Tag/Branch-->解除鎖定-->修改細項-->
正常開發步調-->重大更新-->六月個的開發週期-->減慢開發速度

1.
其中的發行版本修改，都只需要做到微調的動作。並且我們會使
用自己的產品來進行開發(Eat our own dog food)。

2.
鎖定 API/ABI 的原因：此時上層軟體套件才可以編譯，並可同時
發現影響版本發行的重大議題。每天都會編譯程式碼。Daily snapshot.
在編譯軟體套件時發現的回歸測試錯誤，在此時就已經開始修正。
修正完畢後才進行 tag/branch, 接著 unlock 後就可以回到 mainline
持續開發。

3.
鎖定的動作是不預警的，因為人們容易忽略行事曆中的例行事項，
針對測試週期的結果，降低過多錯誤的開發者修改程式的權利。

4.
所有工程師都會參與發行版本時的每一步流程。這可以避免短缺的
測試人力。

5.
作者也承認是因為 OpenBSD 的管理作風比較接近獨裁(theo)，因
此其他開放源碼專案可能無法直接套用這個方法，但是對於軟體開
發公司就相當有用了。

相關連結：

The OpenBSD release process, A success story

linux USB hid driver cypress_m8.c

參考 USB Device Class Definition for Human Interface Devices(HID)
firmware spec version 1.11，範例 driver 是 USB Cypress M8 driver
~linux/drivers/usb/serial/cypress_m8.c，source code 中說有
文件就在 ~linux/Documentation/usb/usb-serial.txt。

主要是看 DeLorme Earthmate USB 的 usb hid 如何設定，她使用的
是 feature report 的方式，在 control pipe 傳送 5 bytes 資料。
對應到 USB HID spec 的 7.2 Class-specific Requests 裡面的 7.2.1
Get_Report Request 跟 7.2.2 Set_Report Request，透過 control
pipe 傳送 host <-> device 資料。

呼叫 usb_control_msg()，定義在 USB core 的實作中
~linux/drivers/usb/core/message.c：


/**
* usb_control_msg - Builds a control urb, sends it off and waits for completion
* @dev: pointer to the usb device to send the message to
* @pipe: endpoint "pipe" to send the message to
* @request: USB message request value
* @requesttype: USB message request type value
* @value: USB message value
* @index: USB message index value
* @data: pointer to the data to send
* @size: length in bytes of the data to send
* @timeout: time in msecs to wait for the message to complete before timing
* out (if 0 the wait is forever)
*
* Context: !in_interrupt ()
*
...
*/
int usb_control_msg(struct usb_device *dev, unsigned int pipe, __u8 request,
__u8 requesttype, __u16 value, __u16 index, void *data,
__u16 size, int timeout)



有兩種用法，差異在於傳輸方向，是以 host 為主體而有 in/out, set/get 不同。
一個是 host 傳到 device(out/set)，另一個是 device 到 host(in/get)。

host->device 是 USB_DIR_OUT，使用 HID_REQ_SET_REPORT request
建立 send endpoint pipe 是用 usb_sndctrlpipe()

device->host 是 USB_DIR_IN，使用 HID_REQ_GET_REPORT request
建立 receive endpoint pipe 是用 usb_rcvctrlpipe()


retval = usb_control_msg(port->serial->dev,
usb_sndctrlpipe(port->serial->dev, 0),
HID_REQ_SET_REPORT,
USB_DIR_OUT | USB_RECIP_INTERFACE | USB_TYPE_CLASS,
0x0300, 0, feature_buffer,
feature_len, 500);

retval = usb_control_msg(port->serial->dev,
usb_rcvctrlpipe(port->serial->dev, 0),
HID_REQ_GET_REPORT,
USB_DIR_IN | USB_RECIP_INTERFACE | USB_TYPE_CLASS,
0x0300, 0, feature_buffer,
feature_len, 500);


第一個參數就是 struct usb_device *dev，probe 時就可以取到
第二個是利用 MACRO 從 usb device 找到 usb device 的 endpoint pipe
第三個參數是 message request value，HID_REQ_SET_REPORT 或
HID_REQ_GET_REPORT
第四個是 message request type value，
USB_DIR_OUT | USB_RECIP_INTERFACE | USB_TYPE_CLASS, 或
USB_DIR_IN | USB_RECIP_INTERFACE | USB_TYPE_CLASS,

第五個參數是 message value 看 device hard code: 0x0300
第六個參數是 message index value hard code: 0

因為採用的是 feature report 的方式傳送 5 bytes 資料存在
第七個參數 feature_buffer 中，
第八個參數是 feature_len 是資料長度。
第九個參數是 500 micro seconds 的 timeout。

相關文章：

TI OMAP3 DM3730 USB host controller high full low speed?

相關連結：

http://www.usb.org/developers/devclass_docs/HID1_11.pdf

~linux/drivers/usb/serial/cypress_m8.c

~linux/drivers/usb/core/message.c

linux kernel read_proc() in procfs

在 ~linux/fs/proc/generic.c 中找 __proc_file_read() 的實作可以看到相關說明：
/*
* How to be a proc read function
* ------------------------------
* Prototype:
* int f(char *buffer, char **start, off_t offset,
* int count, int *peof, void *dat)
*
* Assume that the buffer is "count" bytes in size.
*
裡面有三種讀 read_proc 的方式說明，底下就是說明的程式碼，
也可以搜尋其他 driver使用 read_proc 的範例。
比如 ~linux/drivers/char/efirtc.c。
*/
n = dp->read_proc(page, &start, *ppos,
count, &eof, dp->data);
...
這邊是當 kernel 讀取 proc 檔呼叫 driver read_proc callback 的地方，也就是用法。因此可以倒推回去我們的 callback function 如何實作：

第一種是 driver 要回傳的資料量小於 read_proc 中的 buffer size(PAGE_SIZE)。

此時不管 *start，將 driver 要傳給 filesystem 的資料擺在 buffer 的 offset 位置，我們只看 offset 跟上次 callback 讀到的 buffer size, n 的差值，在接到的 offset 跟剩餘要傳的 n 差值(n - offset) 為零時，告知 filesystem 我們的 driver 已經傳完資料，才設定 *peof = 1; 否則繼續 callback。

第二種是當你有大量資料要傳輸時使用。
將 *start 設定為介於 buffer 跟零 之間的值，資料是從 buffer 起始位址開始填，return 每次要填的資料長度，如果你的資料還沒填完，第二次進入 read_proc 時 offset 值會增加 *start 的長度，直到你填完資料後再設定 *peof = 1; 就可以完成傳輸大量資料了。

第三種跟第一種一樣，只是把 offset 代換成 *start

參考文獻：

1. procfs-guide.pdf 3.1 Reading data
2. linux kernel source: ~linux/fs/proc/generic.c, ~linux/drivers/char/efirtc.c
3. Linux Modules (3) - procfs

boot code, bootloader, and Linux Kernel entry points

菠蘿麵包整理了 Android 開機流程 boot sequence
給個 boot rom, bootloader, Linux kernel, Android Init, Zygote, Dalvik,, System Server, 最後發出
ACTION_BOOT_COMPLETED 的 braodcast intent 觸發需要知道開機啟動的服務，其中從
硬體到使用者接觸到的應用程式的完整流程。

我們關注的是前面這段觀念：
硬體平台上的 boot ROM 儲存了 boot code，boot rom 本身也是在記憶體上執行，arm cpu
藉由 reset 0x0000, 0000 由 chip select 線路連結的開機媒介決定到哪一種 storage (Nor flash,
 Nand flash) 去讀取 boot loader。 將 boot loader 載入到實體記憶體後開始執行 boot loader ...

在 booting sequence documentation 則提到在 bootloader 到 linux kernel 端的開機介面
與流程：

ARM Linux kernel 對 bootloader 所需要的，就是藉由 bootloader 將 Linux kernel 從
storage 讀出載入到記憶體，設定某些暫存器，並呼叫 Linux kernel entry point，此
時還不需要啟動 MMU。

 Linux kernel 的 zImage 壓縮檔，就必須要跳到 arch/arm/boot/compressed/head.S
會使用  arch/arm/boot/compressed/misc.c (抄自 gzip 的某些函式介面) 裡面的
decompress_kernel() 其中會呼叫 arch_decomp_setup() 設定 debug FF/ST uart port,
或特殊的 Chip Select memory mapping，接著在開機印出 "Uncompressing Linux..."
字串後進行解壓縮。

ARM Linux boot sequence

另外關於 arm linux 的開機流程也有人寫了程式碼分析文：
ARM Linux boot sequence

zImage 解壓縮階段：
從跟 boot loader 串接，關閉 cpu cache, MMU, 設定 stack, kernel entry point 在實體
記憶體位置，設定 cpu 型號辨識，啟用 cpu cache, MMU, 設定 MMU page table
將 kernel zImage 解壓縮並載入到 RAM，進入 kernel start...

ARM 相關的 kernel code:
查詢 cpu 型號，啟用多核心支援，查詢(主機)板子的 machine 型號，MACHINE_DESC
macro 的定義。建立 MMU 的 page table，enable MMU，初始化 cache, write buffer。
繼續 enable MMU，設定 page table pointer (TTB)，找到 page table 起始點，切換
MMU 進入 virtual address space, 回到已經過 mmap 過的 switch data。

複製 data segment 到 RAM
清空 BSS(寫零)
跳到 start_kernel 開始執行 Linux kernel 開機程序。也就是接 Intel 文件中的 C 程式碼
起始點。 

Linux kernel entry points

讀 Intel 的 device driver debugging 可以找到幾個 Linux kernel source entry point。

開發新平台(OS Adaptation, OS bring up, customize core components)
其中一項重要的工作就是寫驅動程式，有些多媒體編解碼的最佳化，
也是在驅動程式端實作。

一些有用的 kernel 資訊如：active kernel threads, loaded kernel modules

x86 開機流程中 BIOS->OS boot loader --start_kernel()-->OS

sched_init() 是 scheduler initialization

mwait_idle() 是 OS 主要的迴圈(就像 micro controller 的 main loop)


相關連結：

Device Driver Debugging on Intel Atom processor based devices (pdf)

cross compile Android native C code

當需要建立一些指令列工具，需要自行 build code 在 Android
command line 上執行，或供應用程式透過 JNI 呼叫的函式庫時，
需要 cross compile android native C program

1. agcc, 一個幫你搞定 cross compile 所需複雜參數的 perl script，依照
Compiling for Android wiki 上的步驟，應該就可以成功

2. 如果幸運的話，你可以不用往下看，不然就繼續吧，假如 agcc
不能達要你的需求，網路上也有神人已經寫了 Makefile 再加上 1. 裡
面的其他設定設好，以及你所使用平台的 C runtime library，在
~android/bionic/libc/arch-arm/bionic 底下 copy crtbegin_dynamic.S,
crtend.S 到你的 utility source 目錄，一起 link 就可以從正確的 entry symbol
__start 執行。否則直接拿 x86 cross compile 給 arm 平台的程式時
會有類似以下的警告訊息：

warning: cannot find entry symbol _start; defaulting to 000082c8

3. add scripts to ease rebuild native C code and installation，要將 utility
包 到 system.img 時需要先移除 ~android/out/target/product/arm/system.img
再將新加的 utility 放到 ~android/out/target/product/arm/system/bin
重新 build android，因為前面已經將其他 object files build 完，所以只剩下
archive system.img 的工作。

因此再借用神人的 my_command_line utility Makefile 改成如下：


# ripped from http://forum.xda-developers.com/archive/index.php/t-623976.html
AR = arm-eabi-ar
AS = arm-eabi-as
CC = arm-eabi-gcc
CXX = arm-eabi-c++
LD = arm-eabi-ld

ANDROID_SOURCE_ROOT = /path/to/your/androidsource
NDK_KIT = $(ANDROID_SOURCE_ROOT)/ndk/
PLATF_KIT = build/platforms/android-4

ARM_INC = $(NDK_KIT)/$(PLATF_KIT)/arch-arm/usr/include
ARM_LIB = $(NDK_KIT)/$(PLATF_KIT)/arch-arm/usr/lib

PLATF_INC = $(NDK_KIT)/$(PLATF_KIT)/common/include

OUT_DIR = $(ANDROID_SOURCE_ROOT)/out/target/product/arm
OUT_SYSTEM_BIN = $(OUT_DIR)/system/bin/
ALL_SYSTEM_IMG = $(OUT_DIR)/system.img $(OUT_DIR)/obj/PACKAGING/systemimage_unopt_intermediates/system.img

PROJECT = my_command_line
SRCS = $(PROJECT).c util.c
OBJS = $(PROJECT).o util.o crtbegin_dynamic.o crtend.o
EXES = $(PROJECT)

all: $(EXES)
file $(EXES)

install: $(EXES)
cp -afv my_command_line $(OUT_SYSTEM_BIN)
cd ../; rm -fv $(ALL_SYSTEM_IMG)
@echo "Please re-run build_android.sh to rebuild system.img"

$(EXES): $(OBJS)
$(LD) \
--entry=_start \
--dynamic-linker /system/bin/linker -nostdlib \
-rpath /system/lib -rpath $(ARM_LIB) \
-L $(ARM_LIB) -lc $(OBJS) -o $(EXES)

$(OBJS): $(SRCS)
$(CC) -I $(ARM_INC) -I $(PLATF_INC) -c $(SRCS)
$(CC) -mthumb-interwork -o crtbegin_dynamic.o -c crtbegin_dynamic.S
$(CC) -mthumb-interwork -o crtend.o -c crtend.S
#crtbegin_dynamic.S and crtend.S copy from bionic/libc/arch-arm/bionic

clean:
rm -f $(OBJS) $(EXES)


另外寫程式要注意的是 ~android/bionic/libc/README 提到跟 standard C
library 差異處與特性：
- no support for locales
- no support for wide chars (i.e. multi-byte characters)
- its own smallish implementation of pthreads based on Linux futexes
- support for x86, ARM and ARM thumb CPU instruction sets and kernel interfaces

4. Thinker 發表的 Android Build System 分析一文相當值得細讀，善用
Android makefile 的 build system 可以省掉去瞭解這些編譯的細節。

5. Android Source Code 中的 NDK 也詳細介紹了使用 Android Java VM
的 JNI 介面與實作 shared library 的建議，在
~android/ndk/docs/OVERVIEW.TXT 中有說明，Google 一下也可以找到
中文翻譯資料，我就不翻了。 :P

結論是網路上神人很多，Google 搜尋跟這些神人也很熟。:P

相關連結：

Android 原生(Native) C 開發之八: Toolchain 環境搭建篇

How Android Differs from GNU/Linux (pdf)
Walkingice, 0xlab 2009/08/16, COSCUP

Compiling for Android

Building Open Source libraries with Android NDK

makefile 的變數 -D

How to compile native android code

Android Native Development Using the Android Open Source Project

從 gpio & I2C 硬體線路對應到檔案讀寫

0. 硬體電路的 schema

找到電路圖上的 gpio, i2c 線路圖上的 block 是接到 datasheet 上哪一個 slot

1. datasheet 中的 gpio chapter

針對 gpio controller 的 register 值依照 in/out, pull up/down, data 值設定

2. board initial entry point，比如 Samsung s3c6410

~linux/arch/arm/mach-s3c64xx/mach-smdk6410.c

MACHINE_START macro 定義 board information

可以看到註冊的 .init_machine 進入點 function 是 smdk6410_machine_init

Qualcomm 的 arm board initial 檔案則是在
~linux/arch/arm/mach-msm/board-msm7x27.c
定義了 QCT MSM7x2x (7225)
~linux/arch/arm/mach-msm/board-msm7x30.c
定義了 QCT MSM7x30
~linux/arch/arm/mach-msm/board-qsd8x50.c
定義了 QCT QSD8X50 (8250)

3. i2c
關於 i2c 參考 Documentation/i2c/instantiating-devices，可以看到 mach-smdk6410.c 定義兩個 i2c slot 0, 1 為 struct i2c_board_info，裡面定義這個 bus 上接的 i2c slave device(s) 名稱與 slave address 資訊，透過 S3C_EINT 對應到外部中斷 12，然後在 smdk6410_machine_init()：

i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));

註冊兩個 i2c bus，0 跟 1。接下來 i2c device 的具體化由 i2c core 完成。

kernel driver 可以在 ~linux/drivers/i2c 目錄找到，可以使用 i2c-dev，直接 sudo modprobe -a i2c-dev，就可以在 /dev/i2c-0 存取 i2c bus。

參考 ~linux/Documentation/i2c/dev-interface 可以針對 /dev/i2c-0[1] 的 device file 使用 user space driver 的 ioctl 控制 i2c 設定與傳輸。

最簡單的動作是 ioctl(file, I2C_SLAVE, addr)，就直接對 file read(), write() 就可以讀寫 i2c device 資料。

4. gpio
關於取得需要使用的 gpio 方式如下：

gpio_request(S3C64XX_GPN(5), "LCD power");
gpio_request(S3C64XX_GPF(13), "LCD power");
gpio_request(S3C64XX_GPF(15), "LCD power");

這是指取用 GPN pin 5 跟 GPF pin 13, pin 15 操作 LCD power

~linux/Documentation/gpio.txt 可以用 /sys/class/gpio/ 底下針對 gpiochip (controller) 或是 gpioXX (pin) 進行 user driver 的控制 in/out, high/low, trigger mode /sys/class/gpio/gpiochip0/ 中的 label 可以對應到 datasheet 的 controller 名稱，參考 arch/arm/mach-s3c64xx/include/mach/gpio.h 可以找到 S3C64XX_GPA, S3C64XX_GPB 等 gpio controller

S3C64XX_GPIO_A_NR (8) 定義 Bank A 有 8 根 gpio 腳位，依此類推對於 /sys/class/gpio/gpioXX/value read/write 就可以讀取 gpio 腳位high/low 或設定 high/low

相關連結：

Linux kernel source code

Samsung s3c6410 datasheet (pdf)

man 6410 datasheet (pdf)

Keil C C51 語法

1. 加上記憶體型態的變數宣告順序：

變數型態 記憶體型態 變數名稱;

變數型態指一般 C 語言的 int, char 等

記憶體型態指 code, data, bdata, xdata, pdata 等六種記憶體位置
，各型態記憶體位置，以 Silicon Labs C8051F320/1 為例：

內部記憶體：
0x00~0xFF 都可使用間接定址存取資料的 data 記憶體

data 記憶體內：
0x00 ~ 0x1F 是一般暫存器 0x20~0x2F 給 bit/bytes 直接定址 bdata
0x30~0x7F 是直接定址記憶體
0x80~0xFF 是給 sfr(special function register) 只能間接定址 Stack
Pointer 可以是在 data 記憶體內定址的 256 bytes 區塊

外部記憶體：pdata
0x0000~0x03FF 是 1K 的 pdata
0x0400~0x07FF 是 1K 的 USB FIFO

16K Flash 記憶體：xdata, code

0x0000~0x3DFF 是 16K 的 In-System Programmable 記憶體
也是 firmware update 使用區，參考 PSCTL 暫存器的 PSWE、
PSEE 位元保護寫入與讀取的動作。

0x3DFF~0x3E00 是 Security Lock Byte，理論上可以鎖定 64K
bytes 的連續記憶體

Security Lock Byte 可以指定要鎖定的 512 bytes
(page 0 = 0x0000~0x01FF)

鎖定的區塊比未鎖定區塊有較高優先權，可以讀、寫、刪鎖定與未鎖定的記憶體區塊。鎖定是防止透過 C2 interface 讀寫 flash 的燒錄器讀取韌體機密，但無法防止其他介面的讀寫，因此韌體在其他介面溝通時，如果有機密資料需要做加密傳輸。

鎖定區如果要強制讀取會透過電路先將 flash erase 才可以讀寫，可以做到保護鎖定區資料機密性的功能。在鎖定區的 loader，在進行韌體更新時，檢查是否是合法的 firmware，才進行更新，以防止燒錯 firmware，或是被 crack 修改到鎖定區內資料。

檢查是否是合法 firmware 可以用公開金鑰機制防護，在鎖定區內的 loader 存 private key，要燒錄到 flash 上的韌體存 public key。可以做到韌體加密與驗證合法韌體的功能。

0x3E00~0x3FFF 保留未使用

比如宣告

char xdata GPIO1 _at_ 0x100;

表示宣告為型態 char，在 external data memory 位置 0x100 的 GPIO1 變數

2. 宣告 register 與位元

sfr P0 = 0x80; // 宣告 P0 是 special function register，
// Port 0 位址在 0x80，8 bit constant, 位在 IDATA 型態的
// 0x80~0xFF 直接定址區
// 0x00 ~ 0x7F 位在 DATA 型態記憶體的直接定址區

sfr SCON = 0x98;
// 宣告 SCON 為 register，SCON register 值為 0x98

sbit B1 = SCON ^ 0;
//宣告B1 為 SCON sfr 的第0個位元( 1 byte = 0~7 bits)


3. 中斷函式宣告、註冊與定義

timer0_int() interrupt 1
{
// C codes
}


宣告函式名稱 timer0_int()，註冊在中斷 1，中斷 n 的向量(編號)

公式為 (中斷大小*n +3) + 中斷向量基底位址，中斷向量由 C51 compiler 計算。若一般中斷大小為 8，中斷向量基底位址為 0x4000，則宣告 timer0_int() 程式碼放在 code memory 位址 0x400B。

4. 在固定記憶體位置宣告 struct, memory mapped struct

struct MyStruct { char data;};

struct MyStruct xdata *sPtr;
// C51 依 xdata 配置視 sPtr 為指向一個 memory mapped struct

sPtr = (void xdata*) 0x8000;
// 這個 struct pointer map 到 0x8000 實體記憶體
// 類比 standard C lib 的 malloc heap memory


相關連結：

Silicon Labs C8051F320, C8051F321 Datasheet (pdf)

The C51 Primer (pdf)

SDCC small device C compiler Open Source 8051 C compiler

SDCC Open Knowledge Resource Open Source C libraries for 8051

Keil C51 第一家在 8051 平台推出 C compiler 的公司

8051 market in 2008

8051 C Compilers

http://o.keil.com/forum/docs/thread356.asp

程式設計的文藝復興

翻譯自：AppTrain: Renaissance Programming

這是一個關於採用 Ruby on Rails, PHP, MATLAB, 以及 Google
Docs 程式設計介面的故事。

文藝復興時期的程式設計師應該可以跨越平台、程式語言的限制寫
出產品所需要的程式。猶如文藝復興時期的建築師般，程式設計師
知道設計寫作程式的重點，就是在於產出程式的整齊、對稱與簡潔
。

當我們在實作 kpozsports 產品時，第一個挑戰就是原始網站是用
PHP寫的。在過去幾年來我都是在 Ruby, Rails 的程式設計開發環
境。我們團隊中的 Jim 是一位優秀的 PHP 程式設計師。我們要如
何在同一個網站中讓 PHP 跟 Ruby 共存？

1) 釐清責任區分
專案計劃中每位開發者都要達成特定的功能目標。完成這些功能性
目標的程式語言只是輔助工具。即使是一家小公司，使用多種工具
完成目標也是很常見的。比如 Rob 是 MATLAB 專家，所有運算集
中的程式碼都是使用 MATLAB 完成。架構網頁前端的程式語言則
是 PHP。這方面我們交給 Jim 完成。Ruby 在整個計劃中則是隨處
可見的，因為他的高藕合特性幾乎可以運用在任何需要系統整合的
專案中。我的主要責任是從多個來源蒐集資料，組織好資料後再傳
送到有 MATLAB 後端運算的 PHP 網站上。

2) 聚集類似的目標與工作任務(內聚)
軟體開發稱這個動作為內聚 cohesion. 本專案中的 Rake 任務是到
網頁上蒐集公開的網頁資料，所需要找的是同一款電玩遊戲的所
有相關網頁資料。剛好我最近都在研究相關的議題，這正好在工
作中派上用場。

3) 保持元件獨立
在專案中我們除了前端 PHP 及其相關的 MATLAB 模組，也架構
另一個 Rails 內部網站，兩個網站雖然互相溝通但實作上相互獨立
，我們稱為 low coupling, 如此一來我們兩邊元件開發可以同時進
行而不造成相互等待的時間浪費，也不會產生過於複雜的溝通系
統。

4) 共同設計
建構一個可用的軟體應用程式需要持續的設計。專案中所有成員
都共同參與設計的工作。我們會把重要的觀念放到線上領域知識
字典，並隨著設計過程增加到網站上。這讓我們對同樣的概念有
相同的詞彙，增加溝通效率。保有共同詞彙讓我們在開發程式的
命名上也更有共識，最後呈現給使用者的介面也會更一致。

5) 不要重造車輪
Don't Repeat Yourself, DRY 原則。The Pragmatic Programmer
裡面寫著：

在同一系統內，每個知識必須要有單一、明確、權威的表示方式。

當資料在資料庫之間傳遞時，必須由具權威代表的資料庫傳遞到備
份資料庫中。我們系統中的權威資料庫是存放在 Rails 框架構成的
網站，所有在 Rails 對資料庫做的修改都會連帶修改其他的備份資
料庫中。固定資料傳遞的方向是為了避免網站架構變得太複雜難以
維護。除了在程式碼中保持 DRY 原則外，整個系統架構上都要記
得同樣的 DRY 原則。

6) 持續的溝通
沒有位在同一辦公室的共同開發者，更是需要積極主動的溝通。在
這個專案中我們每週有兩次共同電話會議。在一星期的開始我們會
討論計劃、策略、戰術，以及任務、與遇到的問題。一星期結束時
則是每個人各自簡報的會議。如此就算有人太忙碌，或是在旅行中
，也都至少可以參與到一次的每週會議。我們私底下也是會常常溝
通，從討論複雜的程式設計議題，到補修統計學，或是共同慶祝喜
愛的橄欖球隊獲勝。

7) 開放的心胸
在 Pragmatic Thinking and Learning 中，Andy Hunt 討論到
神經生成科學 Neurogenesis。與一般坊間聽到的剛好相反，我們的
腦細胞在進入成年以後仍然不斷地產出與生長。在這個專案中我們
接觸到越多陌生的開發環境與工具，就讓我們心智成長、心靈更加
開放。

當 Rob 需要網路上的橄欖球統計資料時，我們利用 Rake 進行這項
工作，並將資料送到 Google Spreadsheet API。另一個 Rake 針對
連結到這個 Spreadsheet 的 PHP 網頁進行更新連結到新
Spreadsheet。

我們系統中已經整合許多不同系統與環境，如果要再新增其他系統
也是輕而易舉。注意我前面提到的這些工具，都是專案成員共同開
發，因此我們同時也都在不同的開發環境中一起成長精進。

在開發網站時，我也會考慮都用 Rails 或是 PHP 進行開發比較好？
結果發現將每個工具用在他最適切的使用需求上才是最好的做法。
這讓我想到文藝復興時代的藝術建築創作，一個熟練多種不同開發
環境與工具的程式設計師。就我個人來說也彷彿經歷一場文藝復興
時期的成長，除了使用的工具與開發環境外，最重要的是產出的軟
體是否符合需求？

相關文章：

C++ 之父 Bjarne Stroustrup 談軟體教育

相關連結：

Renaissance Programming

C++ 之父 Bjarne Stroustrup 談軟體教育

Bjarne Stroustrup 是當代軟體的大人物之一。身為 C++ 程式語言設計人，他的成就已經
影響了無數的軟體開發專案，包括Google 搜尋引擎、到 iphone 手機。

Bjarne Stroustrup 在貝爾實驗室有 24 年的研究員經驗，2002 年獲任德州 A&M
大學的資訊工程學系主任，這些經驗讓他對教育未來的軟體開發員有深度的見解。

在訪談中 Bjarne 也坦誠表示教育界所面對的挑戰與問題，以及相關的改進。談到的問題
包括學生觀察能力不足以深入瞭解，學校教育要如何平衡理論與現實之間的差距，他也
指出業界最常抱怨的是資訊科系學生的能力並不完全合格。

他也認為學生在學時將太多重心放在 Java 程式語言上。也許 Java 讓開發員入門學習
更為容易，但問題的癥結點是在寫程式的態度上，而非單純歸咎到程式語言上。學界
正在努力將程式語言課程設計得更完善，來讓學習軟體開發更有實際用處。

就 Bjarne 所知從 Adobe, Apple, AT&T, IBM, Intel, Microsoft, 到不知名的小公司，
幾乎每一家大大小小的軟體公司，或是有使用到軟體的公司都曾經跟他抱怨過缺乏好
的軟體開發員。

可能 C++ 程式語言至今仍是許多公司採用的重要程式語言，許多業界公司人員都會找
Bjarne 討教相關議題，主要的問題不外乎缺乏好的程式框架 framework 、基礎架構配置 infrastructure、以及大型機構普遍都缺乏對能夠駕馭複雜軟體系統的人才。

由於學校教導的重點在於電腦科學而非軟體開發，可能有學習多年程式經驗的學生仍然
會寫出充滿神奇數字( Magic number)的程式碼，造成日後他人/自己閱讀困擾。原因不外
乎程式設計被認為是低階的技術，或是認為學生自己有能力學會。

有些研究生對於寫出來的程式碼，完全沒有考慮到日後擴充、維護。學生的學習重點
在於演算法、資料結構、計算機架構、程式語言、作業系統。

Robert Dewar 則是指出公司機構會發出這些抱怨，就是因為他們找到的程式開發員無法
在公司所要求的便宜價格、穩定性、時限內產出所需的程式碼，因此制定出許多防呆
防錯的限制。但也因為這些陳規陋習讓真正有才能的高產出程式設計師無法盡情發揮，
甚至會因此被同化而墮落下去。

Bjarne Stroustrup 在他的新書 Programming - Principles and Practice using C++
(for educators)中指出，教導學生如何寫出一個可供他人接手使用的軟體專案，其中包括
錯誤處理、類別設計、檔案輸出入、畫圖與圖型介面、標準函式庫的容器與演算法。
其中也呈現了基本的物件導向程式設計、泛型程式設計。

軟體開發教育的其中一個缺失是，現今有太多現成的工具、軟體可供使用、修改，學生
們缺乏獨立工作思考、並且要習慣不是為了考試成績而學習(但出了社會還是要面對考績)
、努力認真的精神、尋找所需資料的能力、學習寫作與口頭表達思考的能力。專案導向
的工作是最適當的訓練方式，使用什麼程式語言倒是其次的問題，最好有點難度給與
學生挑戰的機會與成長空間。

給與學生重複訓練的機會相當重要，因為人總是健忘的，特別是結合學過的演算法、
資料結構、計算機架構的理論後，給與學生可以整合這些理論與實際寫出專案程式的
機會是相當重要的。這也是 Bjarne Stroustrup 熱衷的教育方向之一，他認為資訊科學是
相當完美的應用科學，不論偏廢理論或實作都無法成功(這也是現今大家面對的問題)。

Bjarne Stroustup 認為身為一名資訊科學教授，不能只偏重在一種程式語言上，本身也要
熟悉多種程式語言。

除了資訊科學的工程面以外，最終的目標在能夠寫出有品質的程式專案後，還要能追求
軟體藝術層面的提升。但這仍需要有科學的計算模型來評估工程面的實用性，以及藝術
性。

軟體教育不只是熟練程式設計的技巧，需要放更多心力在數學、科學、工程面上。訓練
學生觀察出軟體專案之美的最佳方法，就是給學生們欣賞更多趨近完美的軟體專案成果
。最好是像藝術家、建築師的展覽般，舉辦學生的成果發表會，讓學生們多觀摩何謂美
的軟體專案，這是軟體美學教育的最佳途徑。

軟體教育也是需要下苦功的，就像要成為一名稱職的水管工人、你不可能一夜之間成為
一名專業的軟體工程師，做你該做的系統分析、設計，實作並驗證你的設計，反覆的
練習直到這些動作成為你自己的一部份。

像 Java 這類滿載許多預製好的函式庫可供使用的程式語言，可以是很便利的工具，但
如果你只知道如何使用這些預設的函式庫並不能讓你學習、成長。Bjarne 認為 C/C++
的記憶體配置觀念仍然是相當重要的。

有人說軟體外包造成資訊科學學生遞減，但也許我們可以說是因為沒有足夠多的好軟體
設計師，導致這些工作外包到海外尋找更多的好工程師。

C++ 的問題之一是標準函式庫並不那麼好用，希望 C++0x 可以解決這個問題。包括
vector 初始化 {} 與 for loop 的 auto range 語法，都是要簡化軟體設計的工作。

Bjarne Stroustrup 認為軟體開發者的偉大之處，在於他的好奇心、創新、韌性、邏輯
推理、能夠溝通進行團隊合作。這應該可以適用在軟體開發以外的領域，另外一項重要
的特質是，不要忘了你的幽默感。

Bjarne Stroustrup 給所有軟體設計師的建言：
程式設計只是軟體開發的一部份，不管你的程式寫得多棒，前題都是必須要正確運作
、解決問題，並且能讓別人看得懂，請改善你的溝通技巧，學習傾聽、問正確的問題
、寫作簡明，表達清楚。正式的軟體開發工作是藉由團隊合作完成，請改善你的社交
技巧。埋首在成堆比薩跟可樂的頂尖聰明技客已經無法靠單打獨鬥面對當代軟體開發。

認真完整的學完你的第一個程式設計語言，試著用這個程式語言解決困難的問題，不要
沉迷在奇淫技巧當中，專注在技術跟科學本質上。

學習第二個程式設計語言，最好是跟第一個程式語言不完全類似的語言(interpreter, compiler)，只會一種程式語言絕對不足以面對現今多樣化的問題。每個問題都有相對
最適合的程式語言。

不要只會程式設計。軟體是解決問題的工具。將你的軟體技能運用在各種可能的領域：
中世紀歷史、汽車引擎設計、火箭科技、血壓分析、圖形影像處理、幾何計算、生物學
塑模等，任何你可能有興趣的領域。就我個人領域來看，這些都是真實可應用的領域。
當然最理想的是你已經有對某個領域抱有相當的興趣，請開始使用程式與軟體解決你所
遇到的問題吧！

相關文章：

程式設計的文藝復興

相關連結：

Bjarne Stroustrup on Educating Software Developers

shell script: eval

今天逛到瘋狂帽客的 shell script 執行結果變指令。

#!/bin/bash
## A=100
## ls -l
## free -m
eval "`grep "^## " $0 | sed 's/^## //'`"
echo "A=$A"

從執行結果來看，會顯示出 A=100，但是 A=100 原本是在 comment 符號 # 之後，為什麼會執行？原來是 grep "^##" 把 ## 開頭的程式取出，接著用 sed 置換 ## 。於是 eval 接著就會執行

A=100
ls -l
free -m

最後一列指令印出字元 A 等於變數 A 的值一百。因此輸出：

A=100

shell script 也是要花腦筋的。

Google 教你寫程式

Goole 除了搜尋、gmail 讓你收發郵件，gtalk
讓你有 ssl (採用 https 連線 gmail) 的保密聊天
通道外，現在 Google 也要教你寫程式。

http://code.google.com/edu/

其中包括

• Ajax programming
• Distributed Systems
• Web Security
• Languages

Tools 101 教你使用常見的資料庫、版本控管
系統。

CS Curriculum search幫你找尋世界上所有教
授資訊科學領域的網路教材。你可限定在演
講、作業、或課程參考教材等範圍來進行搜
尋。

並且也有設立論壇供討論該服務相關問題。