CRC-check 算法如下：
1. 令16-bits暫存器 CRC=FFFF (Hex)。
2. 第一個8-bit byte值與CRC暫存器做 Xor，將結果存入CRC暫存器內。
3. CRC暫存器右移一位 bit，然後將 0 填入至高位元。
4. 檢查右移的值如果是 0，則將新值放入CRC暫存器內，否則將新值與A001(Hex)做 Xor，
將其結果存入CRC暫存器內。
5. 重複步驟 3~4，直到 8個 bit 全部運算完成。
6. 重複步驟 2~5，取下一個 8-bit 訊息資料做運算，直到所有訊息資料運算完成，即是CRC的檢查碼。
嵌入式系統專案實務 fork 及vfork的差異
fork()和vfork()這兩個系統功能都可以複製出和呼叫者﹙parent﹚完全相同的process﹙child﹚，但呼叫vfork()後的parent process會被暫停，直到被複製出來的child process執行了exec()或exit()；而呼叫fork()後的parent process會和新產生的child process平行﹙concurrent﹚執行。
接下來我們必須約略解釋一下fork()在Linux中的實現方式，旨在讓讀者知道為什麼這個系統功能沒法直接移植到沒有MMU的CPU上；首先我們必須先介紹一下”copy-on-write”這個觀念：
一個程式在執行時會佔據記憶體空間，粗略可分為程式段、資料段、堆疊段與常數段，其中程式段與堆疊段是唯讀的，資料段與堆疊段的內容則有可能在執行時期被改變。在Linux中，當某個process呼叫fork()產生child process時，系統只會為新的process配置堆疊段，其他的記憶體區段都是共用的；實際上在child process呼叫exec()去執行另一個程式前，諸如程式段以及常數段這些內容不可以被改變的記憶體區段始終可以共用。可是資料段就不能一直共用，如果parent與child process同時去操作某個變數勢必會引起混亂。
Child process被fork出來後馬上呼叫exec()去執行其他程式是最常用的流程，以此說來，雖然每個process都必須有獨立的資料段，但馬上為child process配置資料段是很不經濟的，因為在大部分的狀況下child process並不會去對資料段作寫入的動作，在執行exec()後，之前的資料段就沒用了。
為了解決這個問題，Linux(fork)採用”copy-on-write”的技術，在child process尚未對資料段作寫入的動作之前，parent與child process共用資料段；當child process對資料段記憶體作出寫入的要求時，系統會配置一塊實體記憶體﹙一個page﹚給child process，並將原本資料段中被要求寫入之page的內容複製到這塊新的page；接著系統會更改child process的page table，使要被寫入資料的虛擬位址可以對應到上述新配置的實體記憶體位址。
此時child process與parent process的資料段大部分都還是功用的，不同的地方只是這次要被寫入的page；這種演算法的好處很多，在最節省記憶體的前提下使得parent與child process不致互相影響。要達到這種效果，CPU沒有支援MMU是做不到的，所以uClinux無法直接支援fork()這個系統功能。
uClinux無法作到安全的資料段分享機制，產生child process後複製整塊資料段也顯得有點笨拙，於是只好讓parent process停止執行，直到child process結束執行或有了自己的資料段之後才能恢復執行，前者表示child process出現例外或呼叫了_exit()，而後者則表示child process呼叫了exec()去執行其他的程式。這樣妥協出來的功能，就是原本Linux中的vfork()系統呼叫。
如果讀者對copy-on-write的原理不清楚也沒關係，讀者在使用uClinux時只需知道一般Linux在實現fork()這個系統功能時必須用到MMU的機制，而uClinux執行在沒有MMU的CPU之上，所以fork()無法直接移植到uClinux上；uClinux提供vfork()以達到多工的效果。
必須注意的是，使用vfork()產生的child process很可能會破壞parent process原本的資料段，所以程式設計師在uClinux上使用vfork()時必須格外小心；而且沒有fork()系統功能的事實使得許多原本運行在Linux上的應用程式無法完全不經修改救執行於uClinux之上。
我的心得：在早期的fork會複製整個parent的address space，造成時間的浪費，使用vfork則不會複製parent的address space。近來的fork則使用copy-on-write的技術，但是這卻需要MMU的幫忙，才能將child process的page table修改成正確的physcial address，而在嵌入式系統上，uClinux並不支援MMU，所以只能使用vfork。
接下來我們必須約略解釋一下fork()在Linux中的實現方式，旨在讓讀者知道為什麼這個系統功能沒法直接移植到沒有MMU的CPU上；首先我們必須先介紹一下”copy-on-write”這個觀念：
一個程式在執行時會佔據記憶體空間，粗略可分為程式段、資料段、堆疊段與常數段，其中程式段與堆疊段是唯讀的，資料段與堆疊段的內容則有可能在執行時期被改變。在Linux中，當某個process呼叫fork()產生child process時，系統只會為新的process配置堆疊段，其他的記憶體區段都是共用的；實際上在child process呼叫exec()去執行另一個程式前，諸如程式段以及常數段這些內容不可以被改變的記憶體區段始終可以共用。可是資料段就不能一直共用，如果parent與child process同時去操作某個變數勢必會引起混亂。
Child process被fork出來後馬上呼叫exec()去執行其他程式是最常用的流程，以此說來，雖然每個process都必須有獨立的資料段，但馬上為child process配置資料段是很不經濟的，因為在大部分的狀況下child process並不會去對資料段作寫入的動作，在執行exec()後，之前的資料段就沒用了。
為了解決這個問題，Linux(fork)採用”copy-on-write”的技術，在child process尚未對資料段作寫入的動作之前，parent與child process共用資料段；當child process對資料段記憶體作出寫入的要求時，系統會配置一塊實體記憶體﹙一個page﹚給child process，並將原本資料段中被要求寫入之page的內容複製到這塊新的page；接著系統會更改child process的page table，使要被寫入資料的虛擬位址可以對應到上述新配置的實體記憶體位址。
此時child process與parent process的資料段大部分都還是功用的，不同的地方只是這次要被寫入的page；這種演算法的好處很多，在最節省記憶體的前提下使得parent與child process不致互相影響。要達到這種效果，CPU沒有支援MMU是做不到的，所以uClinux無法直接支援fork()這個系統功能。
uClinux無法作到安全的資料段分享機制，產生child process後複製整塊資料段也顯得有點笨拙，於是只好讓parent process停止執行，直到child process結束執行或有了自己的資料段之後才能恢復執行，前者表示child process出現例外或呼叫了_exit()，而後者則表示child process呼叫了exec()去執行其他的程式。這樣妥協出來的功能，就是原本Linux中的vfork()系統呼叫。
如果讀者對copy-on-write的原理不清楚也沒關係，讀者在使用uClinux時只需知道一般Linux在實現fork()這個系統功能時必須用到MMU的機制，而uClinux執行在沒有MMU的CPU之上，所以fork()無法直接移植到uClinux上；uClinux提供vfork()以達到多工的效果。
必須注意的是，使用vfork()產生的child process很可能會破壞parent process原本的資料段，所以程式設計師在uClinux上使用vfork()時必須格外小心；而且沒有fork()系統功能的事實使得許多原本運行在Linux上的應用程式無法完全不經修改救執行於uClinux之上。
我的心得：在早期的fork會複製整個parent的address space，造成時間的浪費，使用vfork則不會複製parent的address space。近來的fork則使用copy-on-write的技術，但是這卻需要MMU的幫忙，才能將child process的page table修改成正確的physcial address，而在嵌入式系統上，uClinux並不支援MMU，所以只能使用vfork。
memcpy 跟strcpy 用法上的差別
strcpy()只能透過零結尾來判定結束，所以有以下的缺點：
1. 速度慢，因為只能以BYTE為單位執行拷貝。
2. 容易出現overlay/memory-corruption，這有兩個情況，一個是目標緩衝區太小了，另一個是來源忘了零結尾。
3. 重疊的情況時，拷貝會出錯。
memcpy()透過第三個參數來得知拷貝的長度，程式本身可以優化，也就是速度可以快些，再加上拷貝的長度由程式師指定，比較不容易出錯，但重疊的情況仍有問題，這種情形需須改成呼叫memmove()。
1. 速度慢，因為只能以BYTE為單位執行拷貝。
2. 容易出現overlay/memory-corruption，這有兩個情況，一個是目標緩衝區太小了，另一個是來源忘了零結尾。
3. 重疊的情況時，拷貝會出錯。
memcpy()透過第三個參數來得知拷貝的長度，程式本身可以優化，也就是速度可以快些，再加上拷貝的長度由程式師指定，比較不容易出錯，但重疊的情況仍有問題，這種情形需須改成呼叫memmove()。
訂閱：
文章 (Atom)