星期六, 10月 28, 2006

Change to realchecko.blogspot.com

越來越不穩了。
因為這個blogger每次發佈都要reflash 整個blog,所以文章多的blog在發佈時就會越來越慢,而且常常會update失敗。

這個blog用到現在,文章好像也有1600多篇(篇數雖然多,但是長度都很段短,有一段時間還當作memo用...),所以update 失敗的次數就越來月多了..

沒辦法,只好遷移到blog-beta去,但是blog-beta還真的是beta,轉移還有些問題,所以就新開一個好了... 就是上次try blog-beta時register的 blog : http://realchecko.blogspot.com

以後都會po到那了。

有空的時候也會拿那邊的data update這裡一下。

Change HD for X32

換上命運多舛的80G HD。
換得時候看了一下 兩顆hd的spec。
原來用的是Toshiba, 1A。
新的是 是seagate 0.45A。
所以,換上去電池會撐得比較久嗎?

還有,速度會便得比較慢嗎? -- 好像有比較曼的樣子。

順便試試上次做的X32 回復光碟,果然很方便,都不用到bios設定了。
一路裝完。大約要2 hours。

星期四, 10月 26, 2006

CE : MISC Work Record : Tiny Kernel Mode ,, Test Program

在build log 中會出現:

CE_MODULES=coredll nk shell relfsd loaddbg shellcelog fsdmgr filesys toolhelp rt_tests
COREDLL_COMPONENTS=coremain lmem showerr thunks corecrt corestrw snotify coregwestub coreimmstub coresiow serdev locmini multiui full_crt crypthash rsa32
NK_COMPONENTS= nkcompr nkmapfile
FILESYS_COMPONENTS=fsheap fsmain fsreg fsysram msgqueue
可以看出NK.EXE, COREDLL.DLL, 各由哪一些 lib 組合而成,但是不知道決定dependency 的地方在哪裡。

New Platform : build 出來的platform在OS design View中會自動依照Platform-Setting - Build Option 的項目加入需要的item,所以刪除該item時,會出現一個dialog,說明同時要將 ENABLE_XXX 的item 關閉。

但是雖然OS Design View 中有該item,實際看workspace.pbxml 卻還是只有基本的item (就是有選的item),也就是說... 實際的和OS Design View 不符。

將 platform-Setting-build option 中的item 都不勾選,TinyKernel 就只有標準的nk, coredll 兩個。


  1. uncheck all "Platform - Settings - Build Options" except "FullKernelMode".
  2. uncheck "Clean befor build" and "make run-time image after build".
  3. build and sysgen
  4. modify platform.bib
    1. comment out FlashDrv.dll
    2. comment sdmmc ...
    3. comment pnashell.bib
  5. modify *.reg <- seems not need to do this


TinyKernel Test Program的位置在
PUBLIC\COMMON\OAK\tktest

在common.bib中有描述,當指定使用MODULE_TKTEST時,會將tktest.exe copy到 image中,rename成filesys.exe。

這是因為 CE 的 kernel : 寫死了 起動後 run ...
  • schedule.c : SchedInit( ) : CreateThread( ... SystemStartupFunc ...)
  • schedule.c : SystemStartupFunc : CreateKerelThread( ... RunApps ... )
  • kmisc.c : RunApps( ) : CreateProcess( ..filesys.exe... )
所以...第一個啟動的是filesys.exe (?)。
跟Linux一樣,kerel boot後,指定root filesystem, kernel 用內建node id找到後,找到裡面的init.. load, run。
所以makeimg完,用viewbin -top nk.bin 看 MODULE 只有看到filesys.exe,沒看到tktest.exe。
dir 出來看,tktest.exe 和 filesys.exe 的size一樣大。

download and Run ...
In TKTest
Page size=4096, 13426 total pages, 13402 free pages. 13401 MinFree pages (102400 MaxUsed bytes)
Event created successfully, About to set event
Look, a message from a thread
In thread, loop cnt = 0
In thread, loop cnt = 1
In thread, loop cnt = 2
In thread, loop cnt = 3
...
.成功。

很愚蠢的是 沒有單純build tktest.exe 的方法,tktest\source 中指定target是sharelib,所以build 出來會是 tktest.lib (!!)。
好像是到該folder build -c 後 sysgen ,修改platform.bib後再makeimg就可以..

這樣啟動的kernel,因為filesystem 沒有啟動,所以registry 都沒有用。

the 1st Process launched by nk.exe

SchedInit( ) OpenExecutable ("nk.exe").. in nk.exe..

Kernel 的sheduler好像是在 NK\KERNEL\scheduler.c 中的 SystemStartupFunc ( )

  1. 在pROM 結構中找到sharedll 區域的位置
  2. Alloc Memory
  3. Load coredll.dll
  4. 在load 到memory 的coredll.dll 中找到需要的一些function pointer ( 用 function index的方法 )。
  5. Create Kernel need synchronize object - event, critical section..
  6. CreateThread : PowerHandlerGuardThrd,
  7. Load shimeng.dll
  8. CreateThread : CleanDirtyPagesThread
  9. CreateThread : RunApp
  10. Endless While - Wait Alarm (Time limit - oneday), give CleanDirtyPages a chance to run.
RunApp 在 kmisc.c
  1. CreateProcess : filesys.exe <-- this is the very 1st process Lives after nk.exe

New Platform - why I have somthing I don't want ?

New Platform

問題:每次New Platform 一個新的platform ,結果出來的OSDesign View Item 好像都不一樣。

回答:

這是因為 Platform Builder很自動(多事?)的幫你加入一些item 的關係(即使你選了"custom"也一樣)。

在platform builder中使用New Platform Create一個platform 時,第一個動作: "BSP"。
在選定BSP後,Platform builder會參考該BSP下的bat檔 (platform\<your_platform>\<your_platform>.bat),執行他,所以該BAT檔中所有設定的環境變數,都會在接下來的操作中繼承。

舉例來說:在 <your_platform>.bat中設定了SYSGEN_BINFS=1,則接下來Platform Builder就會自動在New Platform 中加入 Binary File System 這一個component (將游標移掉Catalog item 上, platform builder會顯示出該item 對應的SYSGEN_VAR)。即使你在接下來的各item 選擇中都沒有加入該item (Custom ),最後那一個item 還是會被 加入。

New Platform 完成後,在Workspace的OSD View中就可以看到被自動加入的item,如果去delete他,會有warning dialog出現,請你刪除掉 " SYSGEN_XX" 環境變數。

反過來說,當自己create一個platform時,可以藉由定義SYSGEN_XXX的方式來強制使用該BSP的設計加入需要的item。

另外Platform Setting 中build option 也會影響到被加入的item,可以在New Platform 的最後一步 "modify building options without leaving the dialog" 按下這個link,將不要的build option 拿掉,這樣最後Create出來的platform 才會包含你需要的item (不會被自動加入其他的item )。

CE 的Build Phase

一般的software , os run time image的 build 動作,不外乎是..

  1. config, generate heder and defines
  2. compile
  3. link
  4. relocate resource and exe files
  5. combine all to rom image
但是CE platform build卻看不出這幾個動作..

首先,這一篇(要用IE 或IE Tab來看,因為裡面的圖用了IE特殊的script )有說明build phase. 出乎意外的是:
  1. Compile
  2. Sysgen
  3. Release Copy
  4. Make run-time image
Compile在sysgen之前。

文章的圖對於各build tool 之間的關係說得很仔細:

所以blddemo.bat 是最大的batch program,做了所有的事。依據呼叫cebuild.bat, buildrel.bat 和makeimg.exe。

cebuild.bat 作 上面.. 1.Compile 和 2.sysgen 的動作。

所以sysgen 並沒有compile 囉?


blddemo.bat 可以有以下使用法:
blddemo [clean | noclean] [rel | norel] [-q | -qbsp] [Cebuild.bat parameters]
clean, noclean - clean 的目標是指%_PROJECTROOT%\Cesysgen 和 %_PLATFORMROOT%\Cesysgen。
當有修改 %_WINCEROOT%\Public\CEBASE\OAK\Misc\Cesysgen.bat 時,才需要clean。
含有environment variable 中,以SYSGEN 和BSP 開頭的變數有變更時,也需要clean。

rel, norel - norel 大概是指要不要自動將 compile完的file copy 到release folder,及之後的動作(makeimg)。

-q - 這是pass給cebuild.bat 的參數, -qbsp 是告訴cebuild 只要build plaform folder以下的source。 -q 是說 ? 有點conflict.. 好像說,所有source 和sysgen 變數都沒有改變。

cebuild.bat parameters - 是任何呼叫cebuild.bat 時傳遞的參數。


在command line 使用blddemo.bat 來build image的話,可以先設定好環境變數:
set BLDDEMO_MI_LOG=1
這樣blddemo.bat會在目前目錄下產生
  • Makeimg.out : makeimg.bat 的log
  • SysgenSettings.out : sysgen 在做完dependency check 後的setting.

Cebuild.bat
  1. 在%_WINCEROOT%\Public\ 中,所有env var : _DEPTREES 中所包含的 folder name,一一的到該目錄下執行 build.exe 來compile source code。
  2. 對每一個_DEPTREES 中包含的item XXX,執行 Sysgen.bat -p XXX 。
    Sysgen.bat 將會 還會依照cesysgen.bat 產生的module 需求,buid module。
    Sysgen.bat 還會build %PROJECTROOT%\Oak\Misc 下的module。
  3. 到%_PLATFORMROOT%\%_TGTPLAT% 作build.exe,compile hardware platform的module
猜測Build 作compile, sysgen 才作link。
為此,使用Cebuild.bat時,可以加上 " -q " 叫cebuild.bat不要呼叫build.exe將source code重新compile,直接叫sysgen 重新link就好。

Sysgen.bat

真的是作link的動作...

sysgen.bat 將Cesysgen.bat中指定的所有module,用nmake.exe將各個lib link起來。
  1. sysgen.bat 到%_PROJECTROOT%\Oak\Misc中參考Cesysgen.bat,設定好適當的envvar。
  2. 參考 %_WINCEROOT%\Public\Common\Cesysgen 下的makefile,如果有-p option時,則follow -p option 指定的 Project ,參考 %_WINCEROOT%\PBWorkspaces\<Project Name%gt;\Cestsgen 下的makefile。參考這些makefile,作以下..
    1. Create Target system directory
    2. 將Cesysgen.bat中指定的 .lib link 起來
    3. Call Res2res.exe, 將所有resource file 合併起來
    4. call Cefilter.exe 處理 CE header file 和其他source file,
      CE header file 中有些comment 被用來作condition statement : @CESYSGEN。
      利用這些condition statement,可以讓Cefilter變更處理的動作。
    5. Cefilter.exe處理%_COMMONPUBROOT%以下四個folder中的file,並且output到 %PROJECTROOT%\Cesysgen\的對應位置:
      1. \Sdk\Inc\*.* ==>\Sdk\Inc
      2. \Oak\Inc\*.* ==>\Oak\Inc
      3. \Ddk\Inc\*.* ==>\Ddk\Inc
      4. \Oak\Files\Common\*.* ==> \Oak\Files
    6. Copy modules 到target directory
  3. Sysgen.bat會將Error輸出log到%_WINCEROOT%\Build.log中
stsgen   [-c] [-p Tree] [NmakeTarget] [NmakeTarget] ...
-c : Run Nmake.exe時, 加上clean 參數
-p Tree : 對 Tree 作sysgen,當沒有指定時,對common project 作 (?)
NmakeTarget : 指定build Target module就好,當沒有指定時,sysgen 對所有Cesysgen.bat中列出的module作sysgen。
 sysgen -p wceshell
這個動作指示sysgen build/link wceshell module,並且copy 到 target folder

Cesysgen.bat
?

簡單的說:
  • build.exe 是compile,但是build.exe產生的是lib (也是就ar 起來的一堆obj)
  • sysgen 是link,依照cesysgen.bat 的內容將各 lib link成target : exe, dll
  • resource arrangement - 略
  • makeimge : 依照binary image script (*.bib) 將各exe, dll , res,... 合併成一個image。
以上整個動作可以由blddemo.bat完成。

星期三, 10月 25, 2006

CE : Register an INT handler - Thread

Interrupt Handling Process..
用Thread來作

  1. Create an Event
  2. Associate this Event to specific INT
  3. while loop - WaitForSingleObject

讓event 和INT關聯起來的方法: IOCTL_HAL_REQUEST_SYSINTR
argument:
  • lpInBuf : 要"觀照"的 IRQ - 例如...EXT_INT0
  • lpOutBuf : 取得的ID
之後再用 InterruptInitialize ( ) 把剛拿到的ID和Event關聯在一起(跟kernel 註冊)。

但是不知道 .. INT ... sispatch .. int handler .. event .. waitObject thread.. 這個flow 的code再哪裡。

CE : MISC Work Record : Tiny Kernel Mode ,, Test Program

在build log 中會出現:

CE_MODULES=coredll nk shell relfsd loaddbg shellcelog fsdmgr filesys toolhelp rt_tests
COREDLL_COMPONENTS=coremain lmem showerr thunks corecrt corestrw snotify coregwestub coreimmstub coresiow serdev locmini multiui full_crt crypthash rsa32
NK_COMPONENTS= nkcompr nkmapfile
FILESYS_COMPONENTS=fsheap fsmain fsreg fsysram msgqueue
可以看出NK.EXE, COREDLL.DLL, 各由哪一些 lib 組合而成,但是不知道決定dependency 的地方在哪裡。

New Platform : build 出來的platform在OS design View中會自動依照Platform-Setting - Build Option 的項目加入需要的item,所以刪除該item時,會出現一個dialog,說明同時要將 ENABLE_XXX 的item 關閉。

但是雖然OS Design View 中有該item,實際看workspace.pbxml 卻還是只有基本的item (就是有選的item),也就是說... 實際的和OS Design View 不符。

將 platform-Setting-build option 中的item 都不勾選,TinyKernel 就只有標準的nk, coredll 兩個。


  1. uncheck all "Platform - Settings - Build Options" except "FullKernelMode".
  2. uncheck "Clean befor build" and "make run-time image after build".
  3. build and sysgen
  4. modify platform.bib
    1. comment out FlashDrv.dll
    2. comment sdmmc ...
    3. comment pnashell.bib
  5. modify *.reg <- seems not need to do this


TinyKernel Test Program的位置在
PUBLIC\COMMON\OAK\tktest

在common.bib中有描述,當指定使用MODULE_TKTEST時,會將tktest.exe copy到 image中,rename成filesys.exe。

這是因為 CE 的 kernel : 寫死了 起動後 run ...
  • schedule.c : SchedInit( ) : CreateThread( ... SystemStartupFunc ...)
  • schedule.c : SystemStartupFunc : CreateKerelThread( ... RunApps ... )
  • kmisc.c : RunApps( ) : CreateProcess( ..filesys.exe... )
所以...第一個啟動的是filesys.exe (?)。
跟Linux一樣,kerel boot後,指定root filesystem, kernel 用內建node id找到後,找到裡面的init.. load, run。
所以makeimg完,用viewbin -top nk.bin 看 MODULE 只有看到filesys.exe,沒看到tktest.exe。
dir 出來看,tktest.exe 和 filesys.exe 的size一樣大。

download and Run ...
In TKTest
Page size=4096, 13426 total pages, 13402 free pages. 13401 MinFree pages (102400 MaxUsed bytes)
Event created successfully, About to set event
Look, a message from a thread
In thread, loop cnt = 0
In thread, loop cnt = 1
In thread, loop cnt = 2
In thread, loop cnt = 3
...
.成功。

很愚蠢的是 沒有單純build tktest.exe 的方法,tktest\source 中指定target是sharelib,所以build 出來會是 tktest.lib (!!)。
好像是到該folder build -c 後 sysgen ,修改platform.bib後再makeimg就可以..

這樣啟動的kernel,因為filesystem 沒有啟動,所以registry 都沒有用。

星期日, 10月 22, 2006

CE book Notes : Process and IPC objects

以下是"Building Powerful Platform with Windows CE"的筆記..



和大部分的Realtime OS一樣...

Program ,Process,Thread

在Storage中,還沒活化(也就是說,還沒有依照program header alloc memory, 給他用,還沒將run-time 環境設好的狀態)。叫Program。
Program活化後,就叫Process,Process有自己的memory space,OS 用virtual memory的方式為每個process提供自己的memory space,並且保護不讓彼此影響,也不會影響到OS。
Thread是OS scheduler的排程單位,每個Process都是自己的"Pimary Thread",當然,可以create 多個Thread,方便設計,同一個Process的Thread都和share同一個memory space,所以可以互相access彼此宣告的變數。

Thread可以run在kernel mode或是user mode,這是由CE kernel決定的,一般ISR thread會run在kernel mode,其他就run在user mode,kernel mode的thread可以access所有kernel resource,所以也可以crash kernel。

在kernel mode執行的thread 效能會比較好一點,因為減少了access right check的時間。所以如果你很勇敢的話,可以啟動"full kernel mode"選項,讓所有的process (thread) 都run在kernel mode。


Process是用CreateProcess( )來啟動,argument是Process的對應program name,可以在argument中直接指定program所在的path,不然kernel會依照 "WINDOWS", "\","PPSHELL","."。OEM 可以在registry : HKEY_LOCAL_MACHINE\Loader\SystemPath 中寫入search path string。

Thread用CreateThread( )來啟動,argument是thread的function address (pointer),還有一個argument是用來傳遞給這個thread的working space,通常是一個structure。Thread可以啟動在suspend mode,然後用ResumeThread 恢富工作。


Schedler

CE的schedule是preemptive,priority, time-slice base。預設的tread quantum是100ms,OEM可以在kernel 啟動時設定自己要的thread quantum。

每個thread可以有0-255 的priority,0是最高的priority。當有很多thread是相同的priority時,scheduler採用round robin的方式。


Synchronization

和其他RTOS一樣,CE也有Mutex,Semaphore,Events,Critical Section用於IPC的object。每個object在使用前都要用create來取得一個handle作溝通用。thread可以用WaitForSingleObject 或是WaitForMultipleObject 來wait(取得)單一或多個IPC object。
所以syhchronization object的用法通常是宣告一個global variable 的object handle,在還沒使用前create他,然後各thread用這個global variable來操作。

Mutex 就是簡單的互斥物件,CE為了防止programmera acqure到一個mutex後還沒release就又acquire他,設計成"acquire一個已經擁有的mutex時,會馬上return,不會被block..。

Semaphore 可以看作是counting mutex,在create semaphore時可以決定他的available number是多少(32 bit int)。

Events是用來"通知"的object,一個thread可以signle 一個event,讓wait 這個event的thread知道該事件已經發生。CE的設計是:當有多個thread都在wait同一個event,只有第一個wait這個event的thread會return。

Critical Section 用EnterCriticalSection和LeaveCriticalSection來形成一個不會被swap out 的code section。(但是不清楚ISR會不會也被disable)。


Communication between Process


剛剛講的都是Thread之間的IPC,因為同一個process的thread都在同一個memory space,所以可以用共用變數來傳遞IPC object handle。但是在Process間就不能這樣用了,因為Process間有OS的virtual memory 隔開,不互相存取對方的變數。所以Process間的IPC就要用其他的方法。

CE利用Windows Message作為Process間同步的機制,一樣,要使用前,必須要用RegisterWindowsMessage向kernel 索取一個沒有人用的message id,然後用這個message來傳遞資料給其他Process (那其他Process怎麼會知道他要對哪一個Message ID反應?)。

傳遞message時,可以同時包含兩個參數: lParam, wParam。都是DWORD,這也就代表只能傳遞 8 bytes的資料,如果要傳更大的資料,就要先用structure包裝好,然後將structure pointer放在lParam中,但是因為Process間的virtual memory mapping是不同的,所以光傳address過去,對方也取不到你的memory 資料。為此,要使用WM_COPYDATA這一個message來傳遞參數才行,這個message的lParam是COPYDATASTRUCT型別,包含一個pointer和一個size,kernel會負責將size的資料copy到對方的空間。這樣的需求(kernel幫忙處理),就要用SendMessage這一個function來傳遞WM_COPYDATA,讓kernel在將message交到reciver process前,先將data copy好。

身份證字號?

購物網站PayEasy 的login帳號竟然是身份證字號,光是註冊資料要求身份證字號的 就已經很誇張了。
竟然還有直接用身份證字號作login name的!

大概PayEasy的客戶群的關係,使用身份證字號對PayEasy的客戶群來說,反而是比較方便的方法(不用記login name,,)。

反過來想,會考慮到將身份證資料提供給網站所存在的危險性,這樣的人,可能也不會被PayEasy的商品吸引,所以PayEasy也沒必要為這些人考慮,去設計其他比較安全放心的註冊方式。

星期五, 10月 20, 2006

可以直接作還原光碟了 - X32

這裡 (lenovo China) 看到的, X32不用再到hpa - F3-F11, 下command FWBACUP XXXX 才能做出HPA的備份光碟了。

現在 在Windows 中就內建 "建立恢復光碟",所以可以直接燒錄DVD/CD囉!
(這是X32才有的喔,X31, X30 都沒有 ... 難道是因為X32 才會常常用到"恢復光碟" ? )

等我寄回送修的HD拿到後再來試試... (希望銀箭線上會寄一個良品回來給我..)。

CE : QFE on "PRIVATE" source code.

CE 5.0 Product Update Rollup 2005 中有...
041028_KB887702 - This is an update to the private source code files that will allow to rebuild the kernel for debugging purposes.

The file(s) with the new public source code changes for this component can be found in the directory %_WINCEROOT%\:

private\winceos\coreos\core\acl\accchk.c
private\winceos\coreos\inc\gweapiset1.hpp
private\winceos\coreos\inc\kmodeentries.hpp
這個大概就是news groupe 中提到的吧,
這個QFE是在"年度" update中。

星期四, 10月 19, 2006

some feeling about .. C & L

搞了一陣子,終於有點了解CE的結構和code directory 安排方式。

感想:....

即使原來是很好的結構(其實我並不覺得architecture有比較好),
但是為了要做到"某些 source code要隱藏","某些source code 讓客戶修改",
所以還要特別將明明就是同一個模組的code拆開成兩個lib, obj,
然後明明是同一個module的code,還不能放在一起,要放在很遠的地方,
這樣,
導致module, source dependency 一團混亂,makefile 和 config 也一團亂,
所以沒辦法真的 在build的時候follow source, header dependancy...
所以還特地設計build tool,能夠盡量正確的follow到dependency...
但是,
結果還是一團混亂,build的process非常不清楚。
導致 user無法確定自己的修改到底有沒有 compile, link進去 (所以,為求保險,都enable "clean before build")導致build時間超長...
這樣就好像最近很有名的"有名大站"一樣,工程師 花時間在"內嵌一個讓人無法block掉的廣告"的技術上,而不是在增加服務品質(嗯,和資料保全上),所以 就算 他真的是一個很好的服務商,也被這些東西稿得一團亂。
所以我覺得wince 6.0 將原來kernel + oal 合在一個exe的設計,拆成kernel 和oal 兩個exe,然後用"插銷"讓兩個exe除傳送需要的"function table"給對方,這樣的設計,其實是為了 方便將kernel.exe的source code整個隱藏起來,不會像 5.0 一樣,因為oal 要讓custom設計而導致kernel 的大部分module都要release出來。

嗯,為甚麼要花這麼多時間在"隱藏"上?把原來很好的架構 攪得五馬分屍,
(CE的設計者看到他的設計被搞成這樣應該傷心吧..)

這樣有點了解到open source 為甚麼進步得比較快,為甚麼source code的品質比較好.....
因為programmer不用花時間這些無聊的事情上呀,完全依照功能需求來寫code,
不必為了這些狗屁到灶的事情傷腦筋....





很明顯的,這一篇是"純抱怨"....... :P

捉迷藏 : nk.exe nk.lib kern.exe..

build and sysgen BSP .. 將log copy 下來用ultra editor 打開 -- 目的是要find "nk.exe",發現..
makeimg 時有:
Copying C:\WINCE500\PBWorkspaces\CoreOS2440\RelDir\smdk2440a_ARMV4I_Release\kern.exe to
C:\WINCE500\PBWorkspaces\CoreOS2440\RelDir\smdk2440a_ARMV4I_Release\nk.exe for debugger
所以實際上nk.exe就是kern.exe (?)。
難怪找不到kern.exe..因為被rename掉。

nk.exe 的build sources file 在 platform\<your platform>\Src\Kernel\Kern\sources

但是指定要link oal.lib 和 nk.lib

oal.lib 就在同目錄的oal folder。

newsgroupe ( http://groups.google.com.tw/group/microsoft.public.windowsce.platbuilder/
browse_thread/thread/4eb1eee943701dc1/68f759ac9fc8049d?lnk=st&amp;amp;amp;amp;q=
nk.lib+nkmain.lib&rnum=1&hl=zh-TW#68f759ac9fc8049d )說:
nk.lib= nkmain.lib + nkcomp.lib+nomapfile.lib 
有些private folder的source code到最近才release,所以要install QFE ( http://www.microsoft.com/downloads/results.aspx?productId=&amp;amp;amp;amp;CategoryID=
&freetext=ce+update&DisplayLang=en&DisplayEnglishAlso=&sortCriteria=date&startDate=
&amp;amp;amp;amp;period=0&type=&nr=20 )

網路上只有這一篇成功build出nk.lib,其他都是說明由於MS release source 不全,所以沒辦法build nk.lib。

一陣惡搞之後,的確已經build出modified kernel image ( 從debug message 可以看到.. ),但是已經忘了是怎麼弄出來的 (因為build 一次最少要40 min,最多要 2 hours )。

大概紀錄一下:
  • private 內的source 大部分是 *.lib,最後會放在 PUBLIC\COMMON\OAK\LIB中,讓其他project link.
  • nk.exe from kern.exe, kern.exe 的 sources (makefile 描述檔)在platform\smdk2440\src\kern

從頭開始:
  1. restore WINCE500
  2. disable multixip, active configuration = release, build and sysgen current BSP
    Error : don't know how to make fal.lib.
  3. 改 Build and sysgen .
成功!也就是..
  1. 先到 private\src\ ... nk 下 作" build -c"
  2. 到public\common\oask\...\lib 去看 nkmain.lib 的time tag對不對
  3. build and sysgen ....then wait.
但是在log中還是看不到哪裡build 出nk.lib...所以沒辦法只build nk.lib.

但是我是要build device.exe ... @_@.

星期二, 10月 17, 2006

X32 arrived

X32 收到 (其實是昨天收到的),就是pchome的29900 (雖然抱怨這麼多,還是繼續光顧)。
就和大多數人一樣(真的很多人喔),當初也煩惱是要X60還是X32,而TPUSER論壇在當時也很巧的un-available一下,所以只好靠著少少的資訊,最後還是選了X32 (因為沒$$)。

結果,X32的缺點還蠻多的呢:
  • pcmcia card 的上緣會斷
  • Fn- F5 會失效
  • LCD 顏色不準
  • 鍵盤不夠好
  • 一下子就很熱
  • ...

但是用起來還是不錯,比R40e, 570 都好。 現在就希望他能好好服役一陣子,不要太快壞 (雖然這台有3年保固,要去換還是很麻煩的)。

拿到機器,IBM 的啟動完成後,第一步...竟然是 download windows update... 十多項..
天哪!8月生產的機器,10月就要上十多項的update !!

然後..download firefox. 酷音...

yeh ! 使用Benq的外接DVD可以開機。

開始測試battery life - 開啟wifi, lcd 亮度1格,一般web browsing... msn..
... 9:18 開始。 5:43 left.
... 10:32 2:43 left 76%.
... 10:55 2:13 left 65%.

Jserv 的 orz microkernel . part I

收到Jserv 的Orz microkernel 了..Lucky :)

因為現在用的pc等級實在太低,光是run 起PlatformBuilder 就loading 過重,所以沒辦法再run qemu 和install build environment,只好先看一下code...



果然是簡潔有力,雖然全部都是用assembly 寫的,但是一點也不影響可讀性 (這就是長年在open source 社群中Coding的習慣?)。

source code的安排也很清楚,依照功能與階層相依性安排folder。

連bootloader, shell, sample appliction 都有 (這真的 都是在端午節下午完成的 ?)

具體而微的OS,沒有多餘的code,因為microkernel 的架構,讓interface切得很清楚。

從這個開始學OS真是再好不過了。


kernel : 整個kernel 在main.asm 中安排得很好:
  • 先是16 bit code, load GDT, IDT, 進入protect mode.
  • 32 bit mode, configure and enable timer.
  • create system service proram - 這些service 都是application喔,不是直接link到kernel image,而是build好,成execution image 後放入kernel 的data block。所以跟一般user application 的地位是相同的。
  • 進入scheduler,完成。
kernel 中,Create Task 時要AllocPage 要求一塊記憶體,這個MM模組就不屬於 service module,而是和kernel link在一起。

kernel 中,Task 模組提供 Create, Kill 和Scheduler 的function.

以上兩部份是 microkernel 的 process 和 memory management,剩下一個microkernel 要有的功能就是 IPC: 這部份 orz microkernel 用message來作,message用 x86 的軟體中斷來提供,從0x30 開始,這部份的INT handler 在kernel boot時,load IDT時就將INT handler都設定好了。

Message Service 有
  • Get Message
  • Send Message
  • Process Message
  • Remove Message
  • Answer Message
Message中的reveiver Task 決定是由kernel (ID=0)還是 service module 來接收這個message。


所以這個kernel 真的是 pure microkernel 呢。



雖然很小,但是包含的東西有好多好多:execution file format, loader, file system(?), shell...先寫到這邊,接著再來看 keyboard interrupt 到 keyboard service module 的path ....

CE : build debug IMAGE

將eboot (整個bootloader) 從 Src/dirs 中刪掉後,已經可以build出debug 的image 了。
但是:
SIZE....
  • Release : 16M
  • Debug : 33M
放不進 Flash 里 @_@

只好啟動XIP了... (但是XIP /None XIP 省的是 exeution RAM space,不是Flash size 吧..)。

應該是放不進RAM才對,因為用的是signle block, 整個image都要load到ram中來run的方式。

XIP build Fail - size exceed the entry address.

只好刪除driver了.. 留下LCD, Backlight 和 power button. 改回 single bin block。

一樣,33,920,403 bytes.

刪除 .net 試試 - 從IDE的Workspace中 remove - IDE整個當掉,workspace中的catalog window 不見 :P

星期一, 10月 16, 2006

要自己寄回去.....真倒楣...下次不要買這家..

真的是超級麻煩...
請您將問題商品妥善包裝後,郵局掛號寄回廠商處作更換。請記得一定要註明您的姓名、訂單號碼、電話、地址及故障原因,感謝您的協助。廠商會再退回郵資給您,請您放心。

廠商資料如下─
廠商名稱:銀箭資訊股份有限公司
這次買的HD拿到壞品,竟然要自己掛號寄回...郵資是小事,上班時間要怎麼去郵局呀?

所以下次買pc home的東西要小心,這一家"銀箭資訊" (注意 注音要選字喔)的,是要自己寄回的。跟其他 會叫快遞來收的不一樣。...上次那個hd box不到1000,也是快遞來收的呀,這次這個2600竟然還要自己寄。..真是!

CE : about Shared Source Code ("PRIVATE" folder)

關於source code,誤會了CE,因為CE 也幾乎提供的所有的source code (只是build 的動作太不清楚)。

CE將Code分為兩部份 - Public and Private,Private的部份是需要另外的 license。Public 的地方可以任意修改。

Private 的部份又稱作"Shared Source Code" (因為要簽署Shared Source Code Agreement),放在"PRIVATE" folder李。

安裝時,安裝了所有source的人,private (shared) source code可以當作是public的部份一般,可以用IDE在code中設break point,觀察call stack,也就是說,可以作source debugging。
-- 參考 這裡 http://msdn.microsoft.com/library/default.asp?url=
/library/en-us/wceosdev5/html/wce50condebuggingsharedsourcecode.asp

MS允許你利用shared source了解和修改CE kernel,但是不允許你使用修改過的shared source 出貨。
所以在你修改shared source之前,要先將所有shared source 和library備份起來。
(? lib ? 所以並不是所有source都有release..)。
被分的方法是用 command line tool : CeBackup Tool.
-- 參考 這 http://msdn.microsoft.com/library/default.asp?url=
/library/en-us/wceosdev5/html/wce50concreatingabackupofthesourcecodefiles.asp

備份source code:
  1. 就是單純的把你要修改的code的folder整個copy到另外的folder中 (以後copy回來覆蓋就OK)。
備份 *.lib
  1. "Open Release Directory" 出現command console。
  2. 輸入
    cebackup backup
    將會backup public, private ... WINROOT下所有的*.lib。
Restor 呢?
  1. Source Code部份就是把folder copy回來就OK。
  2. *.lib部份,一樣,"open release directory"在console中輸入
    cebackup restore
  3. 確認IDE中"Copy Files to Release Directory After Build" 和 "Make Run-time Image" 都要check。
  4. "Build and Sysgen"
如果沒有備份到source code,可以..
  1. To differentiate between modified and original files, use Windows File Explorer to sort by date. Modified files have a more recent date than original files.

  2. Run the Windows CE Setup Wizard.
  3. From the Program Maintenance dialog box, choose Repair.

    This action reinstalls the files you deleted.

  4. From the Build OS menu, verify that Copy Files to Release Directory After Build and Make Run-Time Image After Build are selected.
  5. From the Build OS menu, choose Build and Sysgen.

    This action rebuilds your run-time image with the original files. Your run-time image will no longer contain your modified files.


--參考 這裡 http://msdn.microsoft.com/library/default.asp?url=
/library/en-us/wcepbguide5/html/wce50conCeBackupTool.asp
--參考 這裡 http://msdn.microsoft.com/library/default.asp?url=
/library/en-us/wceosdev5/html/wce50conrestoringtheoriginalbinaryfiles.asp


有列出一些command argument,可以備份某個folder,如果整個 WINROOT的 *.lib都要備份,會用掉20G (??) ,,, 所以要作之前最好先看一下這一份reference。


最重要的部份 : 用修改過的Shared Source Code build你的Image :
http://msdn.microsoft.com/library/default.asp?url=
/library/en-us/wceosdev5/html/wce50conbuildingaplatformusingmodifiedsharedsourcecode.asp

重點好像是 只能build "debug" version,所以Active Configuration 要設debug,否則build不出來。(大概又是沒有release 的library 用debug build的關係...)

還有說明不是所有的Private folder都可以build,在 這裡 可以一層一層的去check 哪一個folder 可以build。
( http://msdn.microsoft.com/library/default.asp?url=
/library/en-us/wcepbguide5/html/wce50conSharedSourceCodeDirectories.asp )

Build的步驟:
  • Open Workspace,Build OS - Set Active Configuration - 選 debug,這樣才會去build share 的source code。
  • 確認"Build OS" 中的 "Copy Files to Release Directory After Build" 和 "Make Run-Time Image After Build" 都有選。
  • 選 "Build OS - Sysgen",開始build image,這是未修改前的base line。可以用來backup用。
  • 備份:
    將整個"Private" folder copy下來備份。
    用CeBackup 備份所有library。
  • 可以修改private 下的code了。


build shared source code一定不會很順利,看 這篇 : build shared source 時當機怎麼辦 ?
http://support.microsoft.com/kb/887702

星期日, 10月 15, 2006

Scatchbox : 讓cross-compile的動作變成native.

一樣,從hemi上看到jserv摘的,所以到原網站看一下,真是不錯的東西,TS看到應該會很高興吧。
一般作embedded system的人要作:
  • install cross -tools
  • cross compile library
  • cross compile application
tool install 還好,因為target不多,而且大部分都有人已經做好package 了,apt-get或是tar一下,follow 一般application 安裝步驟就可以做得很好。

library 也差不多,常用的library 也都可以職些安裝,有些甚至在安裝cross tool 時,就會一併把library都build好。

所以,作embedded system 花最多時間的就是在 cross compile自己需要的application上。

一般都是這樣:
  • 找自己要的applicaion,download source
  • run config 產生make file
  • 修改makefile ,讓他改用cross compile和target的environment
  • test build -- 如果不成功,修改makefile,直到build ok為止
  • 拿到 target system上run,看看跟library link得怎麼樣,需要的/etc 設定當是否OK
其中改makefile那一段真是花時間呀。常常都會希望能像native build一樣,run "make config" 就ㄎ可以自動將makefile中各項參數config好。

Scratchbox 這個專案就是這個用途,他是用chroot的方式,模擬出一個target system的環境,所以在裡面 autoconfig的detect function都可以正確使用,detect出target system的參數i。

Scratchbox中build target 的application,就像native build一樣簡單了。

新的microkernel approach 和benchmark 文章

在hemi看到jserv摘這一篇,所以看看。還真是不錯。說得非常仔細。
( http://os.inf.tu-dresden.de/pubs/sosp97/) The Performance of µ-Kernel-Based Systems
先是說明一下micro kernel的歷史.
第一代的u-kernel :Chorus, Mach。
第二代的 : L-4, QNX。

古老 u-kernel為人詬病之處就是效能,但是第二代的u-kenrl已經很不錯了。

所謂的 "pure" u-kernel 就是說,kernel 只提供
  • address space
  • threads
  • IPC
其他部份都交由user space的sevice application提供。

這篇文章將Linux porting到L4 上,並且調整一些server,看看實做一些到L4內,和增加一些是當的user space server 對於效能有甚麼影響。

這個porting,讓Linux Kernel 算是L4 的一個User Process (簡單的說,是一個Pager - 記憶體管理程式)。原Linux上的user program也算是L 4的user process。

這個porting 目的要保持所有ABI一致,同時說明,由於Linux source code的高度模組化,所以可以把porting到L4的動作當作是porting到另一個hardware architecture,所以只需要更動hardware dependent part (就是source code中的arch folder..)。

文章說明的東西很多:
  • L4
  • Linux
  • Linux on L 4
  • Linux on L4 的各項實做:kernel service, interrupt, user process, System call, Signaling, Scheduling, Tagged TLB, Dual Space Mistake (?),
解說了這麼多,最後說明完成的Linux on L4 完全維持binary compatibility。

接下來作調整和benchmark..
  • 先作基本的benchmark
  • 把Linux 中的pipe和RPC改為L4 中的IPC作法
  • 將Virtual Memory Operation 由Linux Server中分離出來,成為一個獨立的user space server。
最後... 這樣的micro kernel 是否可用呢....

拿來作backup的Eponym 要停止免費服務了

今天收到這封信:
Starting November 1st Eponym will start providing a free 30 day trial blog and will be discontinuing our free blog package. For those of you who are using our free blog package, you will be automatically moved to the free 30 day trial package on November 1st. At the end of the 30 day trial (November 30th), your blog will need to be upgraded for your blog to remain active.

If you wish to keep your blog active, please go to https://secure.eponym.com/upgrade/ to upgrade.

It was a hard decision for us to stop offering the free blog package, however there were two major factors that influenced us. First, we did not like having to put advertisements on people's blogs. We know that our users would put up with the ads to have a free blog, but we don't want you to have to “put up” with anything, especially an invasive and annoying ad on your blog that you can't control. Second, the advertising revenue from the free blogs that we did receive was not nearly enough to cover the costs of providing the free blogs. Looking at these two reasons, we knew that we had to make a change to keep Eponym going strong.

We apologize for the inconvenience that this causes for some of you, but we feel that it is absolutely necessary for us to continue to provide the best blogging service, software, and community on the Internet.

Thank you for using Eponym!
也就是說,拿來作backup的bloghost : Eponym 要收費了。

大概也猜得到,因為用沒多久就開始限制流量,然後又這個的,又那個的。
現在終於...宣佈停止免費的服務,所以。那個blog就要被刪掉囉。

這也是很奇怪的事,另一個blog backup的的方式 MSN Live Space (因為Eponym 和 MSN Live Space都支援 mail to blog),兩個site的文章是一模一樣,但是在Eponym的流量就大得多(很多)`知道是甚麼原因。
(難怪有這麼多人死命的就是要待在無名)

剛發現 這個: http://checko.beeplog.com/ 也支援mail to blog,那就轉換到這吧。

星期六, 10月 14, 2006

又拿到壞品 : pchome Seagate 80GB 2.5吋 NB硬碟

為了ThinkPad R40e買的,80G。2666。

結果一裝上只有detect到34.14G (奇怪的數字)。不管,用HPA 開始retore... 兩次..都沒成功。
改用spfdisk來看,partition根本沒切出來。spfdisk也只有顯示 34.14G。

放棄,用usb外接何來接..XP直接出現"無法辨識的USB裝置"。

這個HD大概是掛了吧,因為R40e用80G用得很OK呀。
usb 外接盒接過120G的也OK。
所以應該是這個HD的問題吧。

這是第二次在pc home買到不良品了。

害我浪費一下午。

星期四, 10月 12, 2006

CE : Memory, Storage... XIP, Process ...

這一篇: System Memory Management in Windows CE.NET
( http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/dncenet/html/systemmemorymgmtwince.asp)
的筆記

這一篇說明CE的Memory, Filesystem 觀念,所有第一次作CE的人都應該要看這個。
然後配合 CE的HELP : ms-help://MS.WindowsCE.500/wcecoreos5/html/wce50conMemoryArchitecture.htm

... 我是指..有作過Embedded Linux的人.....


可以作成" Relocatable" 和 "XIP" (execution in place, none-relocatable)。

relocatable :

OS loader自行選定要將code load到哪裡。
好處 : RAM由OS管理,比較有效率。也不用麻煩決定memory layout。
缺點 : load program 時需要花比較多時間。

XIP:

code只能在build時指定的位址執行,所以需要在SRAM 方式的memory interface device中。
好處 : ?可以直接在NORFLASH中執行,省DRAM。
缺點 : ?

要決定使用哪一種,要了解CE工具中安排binary file的ROMIMAGE.EXE和 *.bib 的內容格式。

利用 壓縮與指定執行時期位址的方式,可以分別將OS中各component指定為relocatable或XIP。

要放到flash中的資料可以是少用到的module,並且可以利用壓縮來檢少需要的空間。
設定為壓縮,也就等於是指定這部份的code會在RAM中執行。

*.BIB

BIB檔由三個部份組成:MEMORY, MODULES, FILES.

MEMORY

通常在CONFIG.BIB中,每個bspc會有自己的config.bib。
NK  80001000 01FFF000 RAMMAGE
RAM 82000000 01DB0000 RAM
其中RAMIMAGE這個region是要romimage.exe將所有executables, modules, data 檔和compress section 放在這裡,而且給定virtual address 018000.1000 - 0x81FF.FFF的區域。這塊區域可以是在RAM或NORFLASH中。
RAM這個region是給CE Kernel用的,所有file system, object store, heaps, stacks, memory mapped file, writable data sections 都放在這個區域中,同時給定virtual address 0x8200.0000 - 0x83DB.0000的區域。

MODULES

這個section指定所有要放入各區域的file 名稱,同時指定他的attrib。

FILES

這部份的內容和MODULES類似,但是這個section的內容一定會被壓縮。
MODILES中指定的DLL檔,執行時會被load到Slot 1,這部份的資料則會被load到每一個slot中,所以會浪費virtual space 。



CE OS啟動時,create一個4G的virtual memory space,然後切割為33個slot,每個slot 32M。

CE使用 paged virtual memory management, 每個page 4K。

每個process 只能用到(看到) 32M 的位址空間。Process, DLL,heaps, stacks, ..都在這32M的區域中。

CE : Device Driver - DLL and GetProcAddr

msdn的文章(CE5.0 開發測試驅動程式)的筆記

CE的drvice driver只是DLL檔,Process將DLL load到memory中,就可以使用DLL中公開的API。

一般使用 LoadLibrary( ) 或 LoadDriver( ) 來load DLL,不同的是 LoadDriver( )除了將DLL load到memory外,同時還會確認DLL沒有被pageout。

將DLL Load進來後,使用 GetProcAddress( ) 來詢問需要的function存不存在,如果在,就會return 該function的address,如果不在,就return NULL。

有關 GetProcAddress : ( http://msdn2.microsoft.com/zh-tw/library/64tkc9y5(d=printer).aspx )以下就是load MyDLL進來,然後取得DLL中DLLFunc1( )這個function address的code..
HINSTANCE hDLL = LoadLibrary("MyDLL");

typedef UINT (CALLBACK *LPFNDLLFUNC1)(DWORD, UINT);
LPFNDLLFUNC1 lpfnDllFunc1 = (LPFNDLLFUNC1)GetProcAddress(hDLL,"DLLFunc1");

..
GetProcAddress( )中的第二個argument是function name,這是在module的.DEF檔中列出得的名字,如果該module export很多function,他會在DEF檔中同時列出ordinal (Index),這時可以用Index來取出address,省略掉FunctionName字串比較時花費的時間。

在 這一篇 Using exported DLL functions(http://blogs.msdn.com/peterrosser/archive/2006/02/22/ExportedDllFunctions.aspx ) 有說明用ordinal 取出function entry address的方法。

星期三, 10月 11, 2006

Windows CE Virtual Memory Layout for Debugging

這一篇(Sue Loh's blog ) 的同名筆記:

CE只有32個process,每個process只有32MB的virtual address。
這是因為CE的設計是使用整個virtual memory address space,即使該process並不在執行中,他依然佔有該部份的virtual memory space。

CE將低位址區分成32MB大小的slot:
  • 32M的hex 是 0x02000000
  • Slot 0 = 0x00000000 - 0x01FFFFFF
  • Slot 1 = 0x02000000 - 0x03FFFFFF
  • 最後一個process的最後一個address是0x41FFFFFF
  • 0x42000000 - 0x7FFFFFFF 是"share area",給VirtualAllocs 和 memory-mapped files 使用。所以這一段不會有symbol。
  • 0x80000000以上是"kernel stuff",kernel 佔用,並且在此處執行,同時kernel load的dll(如"Installable Interrupt Routine)也使用此區域。
Slot 0 比較特殊,他的內容就是"目前正在執行的process"。目前正在執行的process除了擁有他自己的slot外,還會被mapping到slot0來。

也就是說,如果你打開一個process,檢查其中一個variable或function的address是0x00012345,而這個process 原來佔有的slot 是0x12000000 - 0x13FFFFFF,那麼在0x12012345也可以找到和0x00012345一樣的資料。

Slot 1 也很特殊,"MODULES" section內的DLL都會load到這一個slot,但是只有DLL的code部份。
如果有兩個process load相同的DLL,他們都會使用到相同的Slot 1 code,但是DLL中的global data還是會放在caller process自己的memory space中(slot 0)。

DLL 可能被load到任何地方(slot0, slot1 和kernel space)。但是Slot1 只會load ROM DLL code。

有關slot0 的load方式,EXE檔會被load到bottom (0x00000000)的地方,DLL被load到top的地方(0x01FFFFFF)中間部份則是給HEAP和STACK用。

以下,可以由address大概分出他的類型:
  • 0x00012345 : 在Slot 0,並且在bottom,所以是在EXE中
  • 0x0056789A : 雖然在Slot 0,但是距離0x00000000和0x01FFFFFF都很遠,應該不會有這麼大的EXE檔,所以大概是EXE或HEAP。
  • 0x03123456 : 在Slot 1,所以是一個DLL,實際的offset是0x02123456
  • 0x3456789A : 在以0x34000000開始的slot中,offset是0x00456789A,和第二點一樣,距離bottom, top都太遠,所以應該是heap或stack。
  • 0x019ABCDE : 離top (0x01FFFFFF)很近,所以可能是DLL。
  • 0x6789ABCD : 不在32 slot中,也不數於kernel ,所以應該是在中間"share memory"處。

原文寫的比較好,很神奇。

星期四, 10月 05, 2006

Help Dillo Survive

看到這個 : Campaign to help Dillo survive

Dillo - 是一個很小的browser ,大概只有350k 大小,由於他的硬體需求很低,所以可以在一些老舊的電腦,或是embedded system中執行。

Dillo 已經支援:
  • 文字與圖形 rendering (PNG, JPEG, GIG)
  • SSL
  • Plugin
  • cookies
  • more..
Dillo 即將要支援:
  • i18n, l10n
  • CSS (目前以完成70%)
  • javascript
Dillo原以GTK+作為圖形引擎,但是在GTK+ v2後,因為不符合Dillo Small, efficenet的需求,所以改用FLTK2。

現在,porting到FLTK2的工作幾乎完成了,Dillo的Author : Jorge Arellano Cid 決定,沒有人來幫忙這個案子前,不會release這一版的source。
這個計畫大約需要2個full time的programmer,因為browser的規格變更實在太快了,如果這個browser改版的速度跟不上browser的需求變更,會馬上變得一文不值,所以Jorge Arellano Cid希望有人能幫忙這個Project (man and money)。



目前open source,符合embedded system的browser還真的很少。希望這個project能活下去。

星期二, 10月 03, 2006

SLEEP Mode in Datasheet

從Samsung網站download的datasheet:

Datasheet p 7-18

Signaling EINT[15:0] for Wakeup
  1. EINTn pin上的level 正確或是有edge 產生(依照INT設定)。
  2. 該EINTn pin被configur成EINT。
  3. nBATT_FLT 是High。
一旦wakeup後,該EINTn就不再作Wakeup使用,而作為一般的INT。

進入SLEEP Mode後,Databus (D[31:0]/D[15:0]),可以設定為Hi-z或是Output-Low模式。
  • 將Databus的pull-up開啟,同時將databus pin為Hi-z (databus的特殊模式)。
  • 將Databus的pull-up關閉,同時將databus pin為low (logic low state)。
但是若是databus上有另一個bus holder ic,例如74LVCH162245,則可以將pull-up 功能關閉(不管設定成Hi-z或是Low)。

接下來這一段有點奇怪.. p 7-19
Output Port State and SLEEP Mode
poweroff 時(就是Sleep ?),output port必須要給定一個位準,以降低電源消耗。
如果該port pin沒有負載,建議設為High。
當設為Low時,內部的寄生電阻會消耗電流。

如果可以選擇,建議將port設為High,降低功耗。
Battery Fault Signal (nBATT_FLT)

有兩個功能:通知applicaton battery is Low,保護system在low power時不會開機,延長battery life。
  • 平常時,將MISCCR的BATT_FUNC設為10b,可以在nBATT_FLT是Low時,產生 interrupt。
  • 在Sleep mode,將MISCCR的BATT_FUNC設為11b後,在nBATT_FLT的level是Low時,可以禁止所有EINT pin產生wakeup interrupt。
ADC Power

ADCCON 中有一個power-down bit,可以讓ADC進入power-down mode。

星期一, 10月 02, 2006

CE : inside build process - msdn

從Platform下的一個folder (platform)來看..

Platform下的file : dirs ,其中列出build時要深入的folder。
dirs 只有說明要build的有哪些目錄。

folder中的 sources 這個檔案則說明了該folder在build時的各項資料(有點像Linux的 config )。

有sources 這個file的folder就會有makefile這一個檔案,代表這個folder要實際作build動作。

幾乎所有的makefile都只有一行:
!INCLUDE $(_MAKEEVNROOT)\makefile.def
其中 _MAKEENVROOT 這個環境變數,可以在open release enviroment 中用
SET _MAKEENVROOT
來看,應該會是
_MAKEENVROOT=C:\WINCE500\public\common\oak\misc
所以這個"system-wide makefile是
_MAKEENVROOT=C:\WINCE500\public\common\oak\misc\makefile.def
在makefile中使用環境變數的方式和在command shell中不一樣。
makefile中用 $( )將環境變數刮起來,command shell中用 % % 刮起來。

build process依照幾乎統一的makefile,同時follow dirs, sources這兩個file的內容來 build。
在dirs, sources中可以定義macro,改變make的行為。macro的定義方式是:
Macroname= value
和Linux的Makefile一樣,Marconame和"="之間不可以有space。
一樣,用"\"代表聯到下一行。
Macroname 不分大小寫。

Build.exe和Nmake.exe都會將macro展開。

sources 這個檔案中,有一些常用的Macroname:
  • TARGETNAME=
    最後build出來的targetname (不含extension)
  • TARGETTPE=
    build出來的target的extensionname,PROGRAM的話就是 .exe,DYNLINK 就是 .dll。
  • TARGETLIBS=
    列出要link的library
  • SOURCES=
    要compile -in的source file有哪些,不包含header。
  • EXEENTRY=
    exe 檔的進入點,"WinMain" sets the entry point for a Windows application
  • INCLUDES=
    用到的header file
  • SOURCELIBS=
    這一個說明很奇怪,指定要link的library,這個和TARGETLIBS有什麼不一樣?
sources 決定build options。
makefile都是同一個。
dirs 決定builder recursive的path。

some messages - on/off log

BtnLED_ON(FALSE);!Data Abort: Thread=8fb42db0 Proc=8c3b7d20 'device.exe'
AKY=00000005 PC=03f92414(coredll.dll+0x00022414) RA=066d4038(device.exe+0x006c4038) BVA=066d4059 FSR=00000003
是在on/off 5142次後發生。
每次on 10sec, off 10 sec。所以一次需要20sec。
 5142 *20/60 /60  /24 = 1天 hr 
不確定是....

需要的東西:
  • 25 pin socket (mal) x 2
  • 鱷魚夾(R+B 4 組)
  • 電線

星期日, 10月 01, 2006

測試- 相片角落- 外連

新的照片網站,跟flickr一樣,但是是用flash (跟flickr剛開始時一樣)。
每個月有20M上傳流量。
可以外聯?



好像可以喔。

台灣的服務就是這樣,災難..
完全沒辦法信賴..

網誌存檔