測試DLL函式庫功能

這是Bee最常用的。拿來測試DLL內的功能並看單一結果。
在Win32Forth下直接寫以下程式，去連接OpenCV的DLL並呼叫函式

WinLibrary cv110.dll
WinLibrary cxcore110.dll
WinLibrary highgui110.dll

1 z" Win32Forth Call CV DLL " call cvNamedWindow

結果就有一個視窗出現，標題字串就是由Win32Forth傳的。

但有一些規則還是要注意(其實是Bee太久沒用，寫給自己做記錄）：

1. 參數要查出真值，因為無法使用C的#include。
2. 參數要倒序先放，這是Win32Forth的習慣。
3. 字串使用 z"，因為Forth的字串和C的格式不同。

近二個月電腦語言排名變動大

繼上個月排名第一的換了，這個月排名十也換了。

不過排名十附近的"三軍"本來就不是那麼穩定。

比較令Bee在意的是Basic，已經確定離開二軍靠到三軍去了。

一但和三軍在一起，和許多具不同特性的語言"拼"，很難再佔有絕對優勢的。

不過VB和C#確定是要正面交鋒了。這下VB可能更是不被看好，因為雖是同父母，喜好程度大不同。

不過排名三十最近變動也大，不知是什麼狀況。

看著看著才發現，怎麼都是C在抬頭。C、C++、C#、Objective-C，都有C。

重做uCOS-II Win32 port的心得

發現竟然又懂得更多。

因為移植了幾個程式，跑起來還是有點小問題，一一修正後，可以修正到我想要的結果。
但不同的不台，要加入不同的驅動方法。

像取用亂數這件事rand()。
在uCOS-II中，被視為共用資源，所以要保護起來。

但在Win32中有無保護都沒有影響。
現在才發現原來Win32已保護過了，所以一點影響也沒有。

但好玩的是每一個Task都有一樣序列的亂數。
那是因為在Win32，每一個Thread皆有自己的區域變數，rand()就是其一。

後來各task使用自己的srand()，利用windows的時間計數器為種子。
結果10個task只有分成二群，大概是使用雙核心的結果。

那在各task創造時加入不同的延時，果真創造出10個使用不同亂數序列的Task。
二年前還不了解的狀況，如今一下子就解開了。

試驗程式：
有十個Task，各自擁有唯一數字0~9，隨機找位置填入。
也就是擁有"0"的一直找地方填。其他Task也相同。

這是原始的程式結果，為MSDOS程式。

Win32模擬成功後的樣子。
發現所有Task皆使用一樣的亂數序列的狀況

這是加了使用系統時間做為亂數種子的結果，只有分成二群。

修改過最後結果。

讀書：精通Windows API

看這本書是因為Bee要學Windows程式，實際的說法是，利用Windows作業系統。
因為Bee是C語言使用者，還是喜歡Console系統，但還是需要使用Windows資源才找此書。

主要是要解決uCOS-II win32 port資源利用問題。
不過Windows API查是查得到，但有許多部分沒有說明系統模型及使用方式。
還是找書還比較好，有系統環境說明。另外還有開發環境的說明。

其他像視窗程式，我是覺得還是放個console做為除錯也沒差。反正有方法關掉，使用Editbin去編譯exe檔的屬性的行了。
另外像是cuda也只能使用main()做為進入點，所以還是不用去轉換進入點的形式。

接下來應該就是配合uCOS-II一起玩了。

讀書：程式設計師的自我修養─連接、載入、程式庫

這本書，光是標題，許多人連看也不會看。基本上這些工作都是作業系統做完了。

但寫程式，每天都在用，卻沒有什麼人想了解。

可是在嵌入式系統，這是基本功，基本到被人忽略。
所以Bee可以了解到這本書名為何要取名為程式設計師的自我修養。

書上的系統是以PC作業系統為平台。不過我本來沒有多大興趣，結果一看就停不下來。

Bee沒有想到有書如此詳細解析Loader,library,DLL的格式，還可以修改。
其中在Linux的資料特別詳細，也難怪嵌入式系統使用PC幾乎只用Linux。
因為Windows上什麼也不公開。而嵌入式的環境又是如此特別，使用Windows安裝常常有一堆問題。

加上近來Bee被人問MPI相關，可是Bee完全沒有接觸過MPI。
在看過DLL相關的段落時，Bee就了解MPI是如何實現了。
其實MPI的實現，可以說是將DLL及相關資料送到遠端電腦去執行。不過還要查證一下。
也就是有實現DLL的作業系統，MPI就可以很容易實現了。之前還在想是有多難的技術呢！

作業系統中有許多很細微的動作，而嵌入式系統工程師要從MCU進步到使用PC這些動作還是要有所理解。
這本書補償了這個空隙。

讀書：早上3小時，完成一天工作

這是買其他書本順便買的。和許多勵志書一樣。
不過Bee很懶，常常只有一小段時間有點用。

現在則是因為一句有用的話，讓Bee很受用。其實Bee還沒看完書，但取得有用的話已經夠用了。
這句話就是

"永遠要想備用計劃"。

Bee發現這句話有三個義意。
1.不要放棄原本目標。
2.即使不成功，也會有所進度。
3.若是意外失敗，也會停止情緒化，馬上收集狀態，想下一個動作。

有多太次，心想的計劃失敗了，到最後什麼也沒有。這一直是Bee心中最大的魔障。
不管看了多少勵志書，仍是無效。結果一句話，一個簡單的意念，就可以解決了。

每個人勵志方式不同，還是要好好了解自己，才能不斷進步。

uCOS-II win32-port官方版本解析

根據之前追蹤的經驗，重點在於如何利用Windows的Thread。

看過之後，發現果然是官方版本，在管理CtxSW更符合CPU運作，只不過更符合單核心的context switch。難怪可以避免多核心衝突。

使用的Hook比較少，大部分在OSStartHighRdy()內做，這個也是不錯的點，也是只有呼叫一次，同在cpu_c.c內。

它一樣使用三種thread：
context switch一個，動作就是排程管理。
timer中斷。
一般工作。

有一點和Bee想的一樣，要將win32的thread handle於在stack上才好管理。這點有做到，所以不會引發其他問題。
唯一不同的是一般工作的thread一不小心退回到win32 thread下，有做task delect動作，有做好的收尾。
MCU的話，會抓stack底部資料產生return，就不知到那裏去了。要是stack有放一些可以產生中斷的特定資料才可以防好。

對於Bee來說，欠缺的功能就是外部中斷支援，以及PC console界面管理了。
PC console界面，可以參考以前的PC.c進行移植。
外部中斷就要仿照Timer做了。

如何讀書2：多看幾次

學會速讀後，所會面臨的問題是，快速掃瞄後，到底有沒有吸收到?

其實這個問題後來才發現根本不同擔心。因為在開始理解掃瞄到的資訊後，就會"自然感覺到"是不是要再看一遍。
這裡的"自然感覺到"就是在掃瞄完後產生的，關於這點，就是和之前讀書是不一樣的。

因為以聲音為了解依據的時候，會自然以為意念的傳達是依聲音為準。
轉到速讀後，才發現並不是，也不完全是影像，可以說是一種多次元的意念。

以前在聲音為理解的時代，讀書資訊是以一維的方式進行輸入。
在速讀的狀況下，讀書資訊是以二維的方式進行輸入。

但因為速讀有一招"倒向看"就是一種段落掃瞄方式，進行輸入，完全不照順序性。
所以在腦中要以超維度的方式才可以解析二維輸入的速讀資訊。

解析後的資料比較像全書被分解成一堆以2D圖片索引的心得資料。
說是"心得"也不為過，因為大部分較為無義意的句子皆不存在了。

而有資料無法連貫的地方，就是沒看懂的地方。
當心思回想書的內容，很快就可以知道那裏沒有連貫，自然就會回去再看一次。

不過只讀一次，只能認知其表面含義。
反正速讀一本書的時間不長，基於表面含義再去看一次，就可以再看到更深的意境。

有時是書的問題，就算多看幾次也是不清楚。
這時的多看幾次就會變成是多看幾本不同人寫的相同主題的書。
不同的人表達不同，就可以找到和自己背景相符合的表達，這樣就可以看懂了。