簡單多工2版

用在PIC18、PIC33時發現一些問題，做了修改，同時加入windows平台下的模擬程式。

主程式：
#define TASK_NUM    4
extern void SimInit(void);
extern void Task1(void);
extern void Task2(void);
extern void OS_ENTER_CRITICAL(void);
extern void OS_EXIT_CRITICAL(void);

#define INIT_DEVICE()        SimInit()
#define DIS_INTR()            OS_ENTER_CRITICAL()
#define ENA_INTR()            OS_EXIT_CRITICAL()
// O.S function declaim
void Dummy(void);
unsigned char FuncID;
unsigned int Task_Delay_Count[TASK_NUM];
unsigned int Task_Skip_Count[TASK_NUM];
void (*TaskFunc[TASK_NUM])(void);
void (*TaskResumeFunc[TASK_NUM])(void);

// O.S functions
void InitSystem(void)
{
    unsigned char i;

    FuncID = 0;
    for ( i= 0; i< TASK_NUM ; i++)
    {
        Task_Delay_Count[i] = Task_Skip_Count[i] = 0;
        TaskFunc[i] = TaskResumeFunc[i] = Dummy;
    }
    TaskFunc[1] = Task1;
    TaskFunc[2] = Task2;
}

void Dummy(void)
{
    return;
}

void Task_Set_Next(void (*p_func)(void))
{
    TaskFunc[FuncID]=p_func;
}

void Task_Set_Other_Task(unsigned char id, void (*p_func)(void))
{
    DIS_INTR();
    TaskFunc[id]=p_func;
    ENA_INTR();
}

void Task_Delay_Ms_Next(unsigned int n, void (*p_func)(void))
{
    if (! n ) n = 1;
    TaskResumeFunc[FuncID]=p_func;
    TaskFunc[FuncID] = Dummy; // to sleep
    DIS_INTR();
    Task_Delay_Count[FuncID] = n;
    ENA_INTR();
}

static void Dummy_Skip(void)
{
    if ( Task_Skip_Count[FuncID] )
    {
        Task_Skip_Count[FuncID]--;
        if (! Task_Skip_Count[FuncID]) TaskFunc[FuncID]=TaskResumeFunc[FuncID];
    }
}

void Task_Set_Skip_Next(unsigned int n, void (*p_func)(void))
{
    if (! n ) n = 1;
    TaskResumeFunc[FuncID]=p_func;
    TaskFunc[FuncID] = Dummy_Skip; // to sleep
    Task_Skip_Count[FuncID] = n;
}

// O.S functions end

// main loop
void main(void)
{
    INIT_DEVICE();
    InitSystem();
    while (1)
    {
        register void (*Current_Func)(void);
        DIS_INTR();
        Current_Func = TaskFunc[FuncID]; // may break with interrupt
        ENA_INTR();
        // Trace System Code maybe add here
        Current_Func();
        if( ++FuncID >= TASK_NUM ) FuncID = 0;
    }
}

void TimeTick(void)  // This is timer interrupt
{
    unsigned char i;

    for ( i=0; i< TASK_NUM; i++)
    {
        if ( Task_Delay_Count[i] )
        {
            Task_Delay_Count[i]--;
            if (! Task_Delay_Count[i]) TaskFunc[i]=TaskResumeFunc[i]; // wake up function
        }
    }
}


給其他C檔案用的引入檔mt.h
extern void Task_Set_Next(void (*p_func)(void));
extern void Task_Set_Other_Task(unsigned char id, void (*p_func)(void));
extern void Task_Delay_Ms_Next(unsigned int n, void (*p_func)(void));
extern void Task_Set_Skip_Next(unsigned int n, void (*p_func)(void));


Windows下模擬用程式
#include <windows.h>
#include <winbase.h>

extern void TimeTick(void);

HANDLE              OSSemaphore;
DWORD WINAPI OSTickW32 ( LPVOID lpParameter );
HANDLE              OSTick32Handle;

void SimInit(void)
{
    DWORD  dwID;
   
    OSSemaphore = CreateSemaphore( NULL, 1, 1, NULL );
    OSTick32Handle = CreateThread( NULL, 0, OSTickW32, 0, 0, &dwID );
    SetPriorityClass(OSTick32Handle,THREAD_PRIORITY_HIGHEST);
    SetThreadPriority(OSTick32Handle,THREAD_PRIORITY_HIGHEST);
}

DWORD WINAPI OSTickW32( LPVOID lpParameter )
{
    while(1)
    {
        TimeTick();
        Sleep(1);
    }
    return 0;
}

void OS_SLEEP(unsigned int count)
{
    Sleep(count);
}

void OS_INIT_CRITICAL(void)
{
    return;
}

void OS_ENTER_CRITICAL(void)
{
    WaitForSingleObject( OSSemaphore, INFINITE );
}

void OS_EXIT_CRITICAL(void)
{
    ReleaseSemaphore( OSSemaphore, 1, NULL );
}


測試用程式
#include <stdio.h>
#include "mt.h"
void Task1(void)
{
    printf("G");
    Task_Delay_Ms_Next(100,Task1);
}

void Task2(void)
{
    printf("z");
    Task_Delay_Ms_Next(33,Task2);
}


測試畫面

要記得請使用多核心下去跑，因為本來就不是給Windows用的，所以會用掉一個核心。

Flash Forth的運行原理

因為使用到PIC，於是看看有無Forth可用，於是找到Flash Forth。
另一個目標是找Cortex M3上的Forth，結果找到一個分散式的Forth，PC端是用TCL寫的，TCL很不熟，就先放著。

比較令我感興趣的是PIC18上的Flash Forth。
雖然丁陳老師的eForth有做在PIC17上。但無法做新加程式，因為無法將程式寫回Flash。
但Flash Forth在PIC18上可以將程式寫回Flash。
因為MCU上我比較少做這個動作，所以沒有想到其實可以寫回Flash，就可以Run完整的Forth。
看了一下，就把回寫的地方改為燒回Flash的函式。
雖然寫回Flash是很慢，但人的反應也不快，所以不會感覺到。
只要Run的夠快就好了。

有去比對其他Forth，MSP430上的CamelForth也有這樣的能力。
不過作者有發現一個問題，就是CREATE> 指令受到影響。
而改以另一個指令去取代。

還是比較希望有Flash Forth在Cortex M3上面。目前還沒有看到。
Bee是知道FIG Taiwan的Holi有ARM7 Forth。不過他的堆疊成長方向和Cortex M3相反，要移反而麻煩。
只能說是Holi選錯了方向，因為ARM7確實二個方向都可以。
不過Cortex M3因為要精簡，就變成單向。而且組合語言指令有16 bit及32 bit混合，不像ARM7固定在32 bit上。
這些改變都要去動Forth核心動作。重寫可能還比改寫快。

五週五顆MCU

新工作上先做一些支援性任務，結果上班五週，就遇到五顆MCU。
分別是PIC18、PIC33、STM32F103、STM32F207以及待寫的STM32F100。
後三個是ARM Cortex M3，理論上會比較好適應，不幸的是這三個是分開的在二個任務上。

現代MCU和以前的不同，I/O型態多，不好設定，花最多時間在讀規格及設定成需要的I/O。
以前是很喜歡去看不同的MCU及CPU資料，不過這五週還真的有點吃不消。
不過可以看到一個趨勢，Cortex M3真的很便宜，PIC完全不是對手。
所以新設計會採用ARM是無法避免的。
本來還想說不是還有Cortex M0，問題是M3不到1美元。那還用M0做什麼?

其實還有遇到第六個MCU，因為是全組合語言寫的，且是已停產的日系MCU。就說要適應要一個月。
所以就沒再去碰了。

在這裡可以見到使用C語言是必然的。
現在MCU便宜到不行，用組合語言會被特定MCU綁住，就無法升級。
程式也是一種資產，但沒有製造成本。
全組合語言的程式很難移植，最後只好用新產品去頂掉，程式就只好用C重寫一次。
變成不做也不行的事了。

另外還有一些PC上做出來的人工智慧的程式要移進MCU中。
在沒有作業系統的幫助下，在PC上開發程式的人吃了不少苦頭。
所以我又架了RTOS做為準備工作。
這次選了FreeRTOS。有去追一下核心，設計方式和uCOS-II並不同。
不過國內沒有什麼人在用FreeRTOS，所以也没有什麼中文資料。

充實的五週，不過還沒有結束。只能一件一件事解開來。

VS2010追蹤MCU的C程式

換公司後都是用未曾用過的MCU。
這時追程式能力很重要。

除了前公司用過Source Insight外。
Bee更喜歡用Visual Studio 2010。
追MCU程式碼只要用到Express版本就剛好，是免費的。

因為不只能靜態追碼，還可以做以下動作：
1. 使用X86的除錯器，可以做到動態追碼，就是模擬執行。
2. 在執行中，可以修改程式碼。

不過要使用，有二個問題要解決。
1. 組合語言對應程式碼。
   大部分是設定MCU，對X86沒有用。
   只是去補欠缺的函式。
2. 標頭檔不同
   函式庫位置。以及二個編譯器之間的不同。

都搞定後，就可以在VS2010上面編出exe檔。
這是在X86下可以執行的。

用Debuger去追，只要遇IO就會產生記憶體存取錯誤。
沒關係，直接修改。導向一個記憶體區。
然後就繼續執行。

都改好了，就可以發現while跑完了一圈。    
去修改假IO用的記憶體區，就可以進入程式內部再追下去。

這是Bee面對大型Firmware程式用的方法。

十年，終究還是離開

一家公司待了十年。要離開還是有一點點不捨。
但，為了走更好的路，只能選擇離開。

朝下一個目標前進！

x64下安裝OpenCV2.3+CUDA

災難！
一定有人問，Bee為何裝完馬上升級。
因為，Bee要的功能是壞的啊！查了一下，發現OpenCV2.2滿是Bug。
Bee想主因是一口氣加入太多東西，GPU和X64一次加入的結果。
然後在一連串找尋中，Bee發現了OpenCV2.3可以解決問題，然後一看，11小時前更新，還是熱的啊！

OpenCV2.3需要CUDA4.0及VS2010，天啊！一切要重裝。

好! 就重裝。那就先移除CUDA3.2及VS2008。
接下來安裝顯示卡Driver，然後重開機。
再來是裝VS2010、SP1及Nsight2.0。
然後是CUDA SDK4.0，接下來就有問題了。

竟然無法編譯！少了cutil64D.lib。查了一下，好像要自己編出來。Bee邊查邊找就半小時過去了。
去\NVIDIA GPU Computing SDK 4.0\CUDALibraries下打開CUDALibrariesSDK_vs2010.sln編一次。
總算得到cutil64D.lib，然後移去要用的地方。
再來又少了shrUtils64D.lib，而且缺檔案stopwatch.cpp及stopwatch_win.cpp。
這二個檔在\NVIDIA GPU Computing SDK 4.0\C\common\src。
先從專案中移除錯的連接，再加入正確的。
總算可以用了。
最後把x64、W32、Debug及Release全部各編一次，放好備用。

可以裝OpenCV2.3了。
使用OpenCV-2.3.0-win-superpack.exe解開來。
用CMake重做一次，這次就沒有問題了。

沒想到這次是CUDA比較難裝。
不過x64模式OpenCV+CUDA總算全部搞定。

OpenCV2.2+CUDA x64模式編譯成功

使用OpenCV2.2版，用CUDA 3.2版。

因為改用CMake所以很不習慣。

裝了半天，才發現需要NPP函式庫。
NPP函式庫也要用64位元。

用VS2010編也不行，還退回去VS2008。

總算把hog_gpu給編出來了。


再來，要經由CMake重做。變得太快，不知要弄多久。

程式雙跨X86及MCU

主要是要讓MCU程式可以在Windows環境下可以編譯，或是簡單執行。
因為Bee成功將68K的程式移轉到Windows下成功。
這才了解在Windows下除錯是多麼幸福的事。
尤其在有作業系統的環境中，一般Debuger無法作用的環境中寫了數年的程式。
可以單步中斷、追蹤，是很幸福的。

在Visual Studio下，在執行時仍可以修改程式碼，立刻修改錯誤，這是不可能在MCU中可以做到的。
另外可以看呼叫來源，可以知道是如何進入函式，可以省去追各路分支。
MCU可以用Visual Studio去寫及模擬，我就不可能回到過去那種人工看Code的日子。

可以操作的等級差太多了。
以前面對10MB的原始碼，根本不知如何追起。
現在就覺得10MB不是那樣可怕，很輕鬆就可以設定及追蹤。

以下為需要修改的。
1.I/O
  使用巨集，函式外型。
  因為在沒有實體硬體時，需要另一組軟體函式來模擬。
  要是做成記憶體存取，就會變成無法模擬。
 
2.組合語言
  跳過
  以C重寫
  組合語言轉C
 
3.MCU內部設定
  幾乎都是跳過
 
4.中斷
  使用Windows Thread，另外開獨立高權限Thread來模擬中斷。
 
5.RTOS系統呼叫
  找出對應的地方，套入Windows系統呼叫。
 
但仍有一些操作上和實體不同
1.堆疊
  不會用配置記憶體做為堆疊，Windows有自己的。

2.當機的回復
  這個不是硬體當掉，而是將堆疊設置錯誤產生的。
  MCU有時會重啟RTOS，然後因全域變數留有工作，會連下去做。
  但Windows可不會。
 
  老實說，發現這個動作Bee很驚訝，這個明顯是程式設計錯誤。
  也終於了解公司的怪O.S.為何不能移到正常的作業上執行的原因。
  程式根本會死當，再利用怪怪的作業系統回復其工作，正常作業系統那裏有這招的。

NAS+Smart Phone應用方法評估

最近Bee在評估Smart Phone並利用它和家中的動物機架互連的方法。
先實驗在動物機上架FTP Server。這個不難，只是要去設防火牆這裏不熟。
至於要架那些Server，想說先參照NAS上的功能。
因為Bee認為NAS上的功能，在動物機上應該都可以架設。
目前是用另一台筆電試連，未來買進Smart Phone，就可以直接使用。

這樣的組合，就可以用手機去遙控動物機，或是監看。
但下載的節目，還是要有可以播放的地方，用手機看實在是太小了。
剛好最近平板電腦開始流行，最新的已經進展到雙核心，可以順暢播放影片。
看來新的應用組合已經到位，且價格也可以接受了。

看來新的組合運行狀況是這樣的：
1.架設家用Server，可以是NAS或是動物機，主要是節目下載。
2.利用Smart Phone可以新增下載節目，或是監看下載狀況。
3.回家看節目，或是下載到平板電腦帶出門看。
  平板電腦等於是行動播放器。

不過看來不只可以做這些事。
家用Server可以是數位家電的控制中心，這個概念Intel已經推很久了。只是一直流行不起來。
所以未來家用Server可以連接家電並做控制，只要使用手機就可以開啟或是監控。

所以生活就會變成這樣：
上班時，可以利用手機指定好下載的節目。
然後下班時，用手機遙控家中冷氣開始運轉。
再打電話訂便當，下班開車去拿便當回家。
一回家就有冷氣吹，就可以直接吃飯看節目了。
看不完的節目就轉存到平板電腦去。隔天出差坐高鐵時還可以繼續看。

Smart Phone只是開端，再來就是家用server及數位家電了。

可惜Bee沒錢，一切仍在紙上作業。

Lua排名急升

在這個月Lua成長到歷史新高，突破1%的佔有率，而且是"急升"。
一切都要感謝Apple。因為Lua已是iPhone上開發的語言。
另一個受惠於Apple的是Objective-C，可見Apple媚力很大。

以Bee猜想，Apple選用Lua是有原因的，其中之一是因為有coroutine。
因為iOS好像是單工(這個是聽來的)，所以需要使用者管理多工問題。
而Lua的Coroutine可以在單工下解決多工問題，讓管理變簡單。

再來，可以預測Lua會進前十名。

虛擬機器啟動了

最近將I/O模擬做好了。
可以看到機器的輸出，再將輸出資料組合回去變成物理量。
可以大概看到機器動作起來。
先用開檔的方式，一個字一個字餵給RS232的取代函式，可以看到機器啟動去工作了。

公司的RTOS很怪，有一些不太好的行為，才會導致近十年來無法搬去PC上模擬。
有包含忙碌等待這種8051才看得到的delay方法。以及奇怪的多工系統。
現在於Windows上可以用multi-threads去模擬及觀察。
剛好最近有比較大的修改，就可以用這個虛擬機器去看一下動態行為。
一個以全域變數為主的管理系統，沒有這個虛擬機器去觀察的話，花在解析的時間會很可觀。

Win7-64下虛擬電腦的使用

64位元作業系統下，軟體的不相容是一大問題。
而做為嵌入式工程師，就是有一些舊軟體要用。
許多工具都無法在Win7-64下執行是一個頭痛問題。

經過數個月和Win7-64的奮戰，總算告一段落。整理結果如下：

1.執行到16位元程式不相容。建議找軟體公司。

  唉，我就是軟體開發人員。還真的要找Source Code重編?
  我還真的做，為了將S19檔案轉成燒錄檔(bin),找了不少程式，總算是找到了，不過人家好心已編好執行檔。
  然後，命令格式不同，還是要改。重編譯，No，先改批次檔，重編是最後手段。
 
  ->此路不要走，真的沒有產能。

 
2.使用DosBox

  部分程式轉由DosBox來執行，不過要設定好連接的目錄夾，還有點費工。
 
  ->缺點，因為要載入轉入等等動作，執行起來比較慢。
    不過純DOS程式支援度不錯。Windows3.1也可以跑。

 
3.使用VirtualBox

  真是救星啊！早點知道就不用這樣辛苦了。
 
  第一個就是安裝WinXP。
  果然什麼問題也沒有，熟悉的環境。
  只有一個小小問題，安裝3D顯示卡Driver要進安全模式下安裝。
  雖然模擬出來的電腦效率有限，但比公司配給我的電腦還快。
  不過對硬碟取存較慢，沒關係，共享資料夾是RAMDisk，這下就不慢了。
 
  再來安裝了OS X 10.6
  這個是插花試玩的。不是完整支援。
 
  安裝Win98
  有一些網卡模擬要用的，也不是完整支援。不過可以改MAC,這點比VMware來得好。
  和外部是用網路芳鄰來通。所以也是可以作業。
  DOS就沒有裝了，因為和主端電腦不通，用DosBox還比較方便。
 
  安裝Win7-64
  一定會有人問，裝這個做什麼?
  就是用來試爆，哦！不是，試裝才對。
  因為新電腦安裝又移除許多試用軟體，沒二個月就不太對勁了。
  所以決定產生分身來試用，反正不好用，就用"快照回復"。就不會留下任何痕跡。
 
  安裝Ubuntu
  也是很好裝，只是環境不熟。
  不過，終於可以正式玩Linux了。
  只是每次都要mount來連得出來，還要再熟一段時間才行。
 
  安裝WinXP(二號試爆用)
  其實是在玩網路連線，現在一台電腦可以同時開三、四個WinXP。
  所以可以試玩網路連線。將來可以試一些網路連線程式，做分散式程式設計試驗用。
  這個不用重安裝，只要將原先的WinXP滙出，再滙入就行了。
      
為了搞這些虛擬電腦。原先的筆電做了一些調整。
記憶體升到8G，硬碟升到750G。
只差顯示卡，和我二年前買的桌機差不多同等級配備了。

現在的電腦真是不值錢。
(作業系統和電腦一樣貴，這是什麼世界?)

筆電記憶體擴充到8GB

最近因公司有需求，開始使用VirtualBox做其他作業系統的安裝及試用。

原先4GB的記憶體似乎不夠用，趁現在記憶體價格低，敗了二條4GB回來。

這下可以同時開二個以上的VirtualBox來用了。

XP是用來執行舊軟體。
                                               
OS X是公司要試的，這個真的很難裝，試了好多版本。

Ubuntu是試裝來玩。


然後看看資源監視器，這個以前沒有注意到應用程式。

原先就用了快2GB！可是Bee明明記得每次開機只用1.3GB。

記憶體只是從4BG加到8GB，怎麼又多用了700MB。


又是M$在做怪。

難怪Win7宣稱不用太多記憶體，因為它一直保留一半的實體記憶體給使用者看。

其實能有效的使用要到4GB以上，那1GB能用都是被騙的。苦的是硬碟。

所以有人一直說Win7容易讓硬碟掛掉。其實是記憶體不足，使用硬碟做為記憶體使用的結果。

顯示卡太重改裝

現在的獨立顯卡再加專用散熱片，整個很重。

放在直立機箱內，過一段時間就會當機。

只要卡片拔起重插就會好了。

可是真的不好拔，每次都花了不少時間。

有這種狀況的應該也有不少人，不過好像沒有多少人說，有人連顯示卡都燒壞。

網路上找到的方法是用竹筷去支撐。也有在賣顯示卡支撐架。

不幸的是Bee的顯示卡沒有地方可以用支撐架。

所以只好用一塊保麗龍去支撐。不過幾個星期後一樣會當機。

原因是保麗龍被壓縮了。

過年又當機，重新改造，這次用鐵絲去吊。

另外找了原子筆內的彈簧做張力支撐，這樣就不會太硬了。

verilog中讀取BMP檔

在verilog中要使用影像處理，模擬時需要一張圖檔做為驗證用。

大部分verilog都是讀取文字檔，所以圖檔要轉成文字檔。

但圖檔會修改，用以測試運行狀況。直接修改圖檔是最直接，一但轉成文字又失去感覺。

所以利用verilog 2001的檔案功能，就可以做到直接讀取BMP檔。

這樣修改圖檔進行測試會方便許多。

程式如下：
module test;
  integer fileId, i, cc;
  reg [7:0]  bmp_data [0:2000000];
  integer bmp_width, bmp_hight, data_start_index, bmp_size;

  initial begin
    fileId = $fopen("gray.bmp","rb");
    cc = $fread(bmp_data, fileId);
    bmp_width = {bmp_data[21],bmp_data[20],bmp_data[19],bmp_data[18]};
    bmp_hight = {bmp_data[25],bmp_data[24],bmp_data[23],bmp_data[22]};
    data_start_index = {bmp_data[13],bmp_data[12],bmp_data[11],bmp_data[10]};
    bmp_size  = {bmp_data[5],bmp_data[4],bmp_data[3],bmp_data[2]};
    for(i = data_start_index; i < bmp_size; i = i + 1) begin
      $display("%h",bmp_data[i]);
    end
    $fclose(fileId);
  end
endmodule

這個程式並沒有將整個BMP檔解開，只是取得資料。

至於資料格式就看個人應用。

因為應用上一般只會針對一種資料格式。

所以就要自己想辦法去排了。

使用Virtual Box安裝Win32Forth

64位元作業系統還是有不方便的地方。

所以使用VM再去裝WinXP是一個取代的方法。

Bee是安裝Virtual Box，裏面再安裝WinXP。

終於又看到熟悉的Windows，真是感動。

然後在裏面安裝Win32Forth總算可以動了。

不過記憶體用很凶。原本就用1.5G，開VM再用1G。

沒有辦法，現在4G快要用光了。

虛擬機器模擬I/O方法2：列表

Bee在上次做好RTOS於Windows下的移植，就一直在苦惱IO模擬問題。

結果案子一趕，實在沒時間思考，心想先印出工作狀況。看到樣子再打算。

得到的圖很滿意。

於是逆向思考，何不修改這個輸出，將原先讀改為寫，倒寫回去。

這樣只要改表格，不用一個一個去Key。

要是照先前想的，模擬的時間一長，會Key到死。


另外也可以看到一些固定的週期動作，以及裝置名。

也可以將輸出的結果撈出來，就可以知道各裝置的動作。

這樣要寫IO模擬的程式，也有輸出可以參考比對。

在Win7-64下，沒有Win32Forth可以玩了

最近有一位Forth同好連絡上Bee，要Bee教Forth程式。

不過Bee換了Win7-64之後就沒有玩過Forth了。

那有人要，就翻出以前的檔案來安裝吧！

結果Run之前的安裝程式，裝到一半就被McAfee防毒軟體給砍了。

心想被砍的是Win32Forth 6.12版。那就再去抓新的版本回來。

不過Win32Forth也沒有再出新的版本。

載了數版都被砍。無奈，回去安裝最原始的版本4.2版，結果沒有被防毒軟體砍，但仍不行。

原因是執行檔版本太舊64位元下無法支援。


唉！和Forth真的斷了。

產品三個月做出來?光是移植ARM就不夠用

公司用的68K遲早會沒有Source。

去建造在Windows上的模擬器，也是要保障可以移到ARM的預備步驟。

只是不給老闆知道則已。給他知道了就要三個月內把機器做出來。

光是移植就要花這麼久了，那電子和機構都沒有算在內。

軟體每次都包辦最後一棒，被趕的也是軟體。

所以，這次的軟體模擬器也許算是軟體移植的先行動作。

不過三個月期限，一看到就完全不知要如何達成。

老闆您打的算盤也太精了，就直接讓人覺得放棄比較快。

反正我光移ARM就用您三個月，看您可以從那裏調人來支援。

看到Tegra2推展影片感想

整個影片只有一個地方是比較讓Bee有感覺的。

那就是ARM處理器對x86處理器數目比。

現在ARM處理器年產量是10倍於x86處理器。

Bee以為只是數倍，顯然太久沒去注意了。

其實從Object-C快速崛起時，應該就有十倍差。

難怪nVidia要轉戰ARM。

以目前ARM的產量再走下去，真正隨手可以撿到的處理器，遲早會是ARM，而不是x86。

那Bee還是要加緊腳步移到ARM才是。

虛擬機器模擬I/O方法

想了一段時間，沒想到是個簡單的方法。
還虧Bee是電子出身的，竟然要想這麼久。
就回歸到原始的信號就行了。

只有幾個項目：時間、位址、資料。
當自己寫下要如何傳的瞬間，就想到示波器(邏輯分析儀比較正確)。
真是笨啊！不就和寫verilog相去不遠。才幾年就忘了那個感覺了嗎？

可以先做檔案將時間表格記錄，再根據時間載入模擬的I/O記憶體。
這樣可以完成初步版本。
其實可以用邏輯分析儀將Bus抓一次，檔案就算完成了。
不過身在軟體部，要借恐不易，還是自己慢慢寫。

進階版本，具有物理模擬系統也不難。因為最後要輸出的還是基本信號。

在軟體實現上。用檔案也是Open File，用Pipe也是用Open File。
所以用檔案讀入，或者用另一個程式寫入，都是用Open File指令，完全不用改。
先去完成用檔案的方式就行了。

註：寫完才想到，直接和電子部去要verilog模擬檔就行了。唉！反應變慢了。

多核心時代真的到了

近二個月收到一些訊息。
有DSP開始推展多核心，有在賣八核心的DSP。
也看到了Forth也出了144核心的chip。
而Bee自己在玩OpenMP及CUDA。
ARM也出了不少雙核，只是Bee沒有接觸到。
這些都是多核心的處理器。且隨手可得。那接下來呢？
當然就看軟體如何去應用了。

不過工程上遇到的第一個問題會是如何去設定編譯器(Compiler)。
這個一直是一般工程師很少去注意的問題。大部分都是安裝好就不會去動了。
如果您像Bee一樣是嵌入式系統工程師，那就必須去面對Compiler相關的問題。

主要的問題是，主流的語言都是由單核心發展起來的。
所以要控制多核心時，就要調整Compiler的設定。可以由語言內或語言外的設定去調整。
但是Bee常常看到網路上有一堆人在問，為何設定不起來。
沒辦法，大部分人在學compiler都是一知半解。更何況是半路出家的工程師。
有許多在使用嵌入式系統的工程師都不是學軟體的。
Bee感覺到從機械來的人也不少，可能是因為從事和機器人相關的，所以才會如此感覺。

好了回歸主題，多核心時代到來。要做的準備工作就是：記得準備好使用工具，把Compiler學好點！

64位元作業系統推廣關鍵：3TB硬碟

Bee最近換筆電，使用Win7-64。對於慣用XP的人來說，真是一場災難。

連平常用於嵌入式系統的開發工具都無法順利使用。原來Win7-64不支援16位元DOS模擬。
所以Bee實在不知這個64位元作業系統的需求在那裏。

比較大的記憶體?又沒有在玩影像編輯，所以很少破3GB的記憶體使用。
剩下還有什麼非換不可。實在想不出來。

最近發現一篇在談3TB的硬碟要如何安裝。這才發現硬碟才是真正驅動使用者去換的關鍵。
為何?因為要64位元CPU才能安裝3TB的硬碟。
原因有興趣的人自己連過去看。
揭曉3TB秘辛，全程追輯，帶領你成功安裝作業系統!

為何是關鍵?主要還是網路的流行，在使用網路會用到硬碟，卻用不到記憶體。

要不然就要一顆顆硬碟買下去。但硬碟價格只會低，遲早會撞到價格問題。到時才會一口氣換。
那下一波的換機潮，就看3TB硬碟的價格了。

再次移植uCOS-II Win32 porting

這次目標是公司的嵌入式作業系統。
它是很奇怪的系統。主要會長成這個樣子是歷史因素。
全程式原始檔大小約20MB。除去工作展示用的資料，原始程式碼也有10MB以上。
發展維護時間可以查到的有15年，但Bee認為超過20年。
因為使用的技術都是20年前的。
從原先的沒有作業系統的核心程式，採用狀態機控制系統。
到移植現代作業系統，程式都存在。
形成半狀態機半作業系統程式混合型。程式碼還夾雜從前狀態機於DOS上模擬的痕跡。
但後面無人再發動於DOS下模擬的程式，所以程式是壞的。
而編譯器用的是公司已經消失的68K compiler。
故只要離開公司，程式碼是無法編譯的。
原系統在組合語言的成份好像還很大。但後期有被大量用C改寫。除了作業系統核心外。

Bee接下程式已超過4年，仍無法弄清楚程式的運作。
主因是沒有軟體除錯器。因為作業系統會干擾Debugger運行。
但在這次的移植工作中，開始打開一扇門。利用Windows來看整套程式的運行。

在此還是感謝直屬主管願意讓我花一個月的時間去做這件工作。
因為在投資者的角度來看這種沒有產出產品的工作是沒有價值的。
其實這件事Bee已偷偷做了數個月的程式碼整理工作。
除去了程式碼約200個compiler warning。
實際在移植時又發現了200多個Warning，也是一一想辦法去除。

Warning以這幾類居多
1.型別不合
  compiler有部分會提示。部分的意思是，在放入Windows後，數目又大了三倍。
2.未用到的區域變數
  歷任維護者除錯用的。因為compiler完全不理會，所以此垃圾數量龐大。
3.沒有初始值就使用
  因為初始值會佔用ROM，故90%以上的變數都是這樣寫。
4.有路徑沒有回傳值
  就是使用switch case完全沒有default項。
  還有函式應有回傳值，在眾多的if-else之中就一個有return但沒有值。
  最常發生在走全為else的路徑，就直接走到函式最後一行。
  Compiler沒提示，所以無人發現。
這些Warning花了數個月。

建造Windows下的Project也是一件辛苦的工作。
約有150個C檔案以及150個H檔案。
C檔案有不同結構模式，所以有數個main()。
這次針對的是有130個C檔案的狀況。因為有許多同名函式，光是main()就有數個。
所以建造project的檔案不能錯，不能多，更不能少。
這一個月中，為了建立成exe檔就花了二週多。Warning多到不知何時才能完成。

建好exe檔，才是第一關，再來是執行時的不合法存取，被Windows踢出來。
有CPU的設定，Flash ROM的存取，FPGA I/O存取，這些都是。
就使用條件巨集切換，不是跳過就是導向另一個自己寫的I/O函式。
因為Bee先將FPGA I/O先用一塊記憶體先模擬。至少可以讓Debugger可以動。

main()終於可以跑完，第一關結束。OS模擬，才開始。
這是要參考uCOS，Windows以及嵌入式作業系統各作業函式的功能進行比對。
才能決定如何將這三者做融合。
終於這個星期做出來了。
現在同一套檔案可以直接編譯成Windows及目標系統的目的檔。
不過目前仍因為I/O是用記憶體模擬，要模擬到像機器，仍有好一段路。