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是用記憶體模擬，要模擬到像機器，仍有好一段路。