Please refer to the following articles:
XML Schema 從看不懂到慢慢懂 - part 1
XML Schema 從看不懂到慢慢懂 - Part 2
XML Schema 從看不懂到慢慢懂 - Part 3
XML Schema 從看不懂到慢慢懂 - part 4
XML Schema 從看不懂到慢慢懂 - part 5
2008年3月12日 星期三
Ref: XML Schema
2008年3月11日 星期二
Some C and OS related tests
(1) What might be run-time problem of the following code?
How should we modify it?
int foo(int *pi) {
*pi = 1;
return *pi;
}
ps: anybody knows the answer??
(2) Please write a function that returns the maximum number of 3 numbers.
Ans: Take "integer" for example
=>
int getMaxNumFromThree(int a, int b, int c) {
int tmp;
tmp = (a > b) ? a : b;
tmp = (tmp > c) ? tmp : c;
return tmp;
}
(3) Please re-write the following code.
===>
typedef ____fp_______ ;
fp *pfunc[3];
Ans:
typedef void (*fp) (char *test);
fp *pfp[3];
(4) recursive -- what's the output of the following code?
void e(int num) {
if (num > 0) {
e(num - 1);
printf("%d ", num);
e(num - 1);
}
return;
}
Ans: e(3) => 1 2 1 3 1 2 1
(5) pointer -- what's the output of the above code?
int ref[] = {8, 4, 0, 2};
int *ptr;
int index = 0;
for (index = 0; index < 4; index++; ptr++) {
printf("%d %d\n", ref[index], *ptr);
}
Ans:
8 8
4 4
0 0
2 2
(6) In OS scheduling, what is "priority inversion"?
and in what situation it may happen?
Ans:
這個情況會發生在 當 low priority task 佔用了 high priority task 的資源時...
high priority task 此時必須等到 low priority task 釋放該資源才可以繼續做事...
在 RTOS 的環境中若是 interrupt 沒處理好就有可能發生這種事情...
(7) what's the difference between process and thread?
process 是獨立的執行單位，擁有自己的位址空間還有狀態資訊，
process 與 process 之間的溝通透過某些 IPC 機制，ex: socket, shared memory 等
thread 是活在 process 內的執行程式，所有的 thread 可享有 process 內部的資源，
如 memory space..而 process 的 threads 之間可直接溝通，因為他們享有同樣的
process 內的變數...保護共享的方法有 semaphore or mutex 等..
(8) The comparisons between different RTOSes, such as
WinCE vs Windows Mobile 5/6
MicroC
NuCleus
Linux
Ref:What an embedded system developer should know?
Preface
| Reference |
想成為嵌入式程序員應知道的0x10個基本問題 
C語言測試是招聘嵌入式系統程序員過程中必須而且有效的方法。這些年，我既參加也組織了許多這種測試，在這過程中我意識到這些測試能為面試者和被面試者提供許多有用信息，此外，撇開面試的壓力不談，這種測試也是相當有趣的。
從被面試者的角度來講，你能瞭解許多關於出題者或監考者的情況。這個測試只是出題者為顯示其對ANSI標準細節的知識而不是技術技巧而設計嗎？這是個愚蠢的問題嗎？如要你答出某個字符的ASCII值。這些問題著重考察你的系統調用和內存分配策略方面的能力嗎？這標誌著出題者也許花時間在微機上而不是在嵌入式系統上。如果上述任何問題的答案是"是"的話，那麼我知道我得認真考慮我是否應該去做這份工作。
從面試者的角度來講，一個測試也許能從多方面揭示應試者的素質：最基本的，你能瞭解應試者C語言的水平。不管怎麼樣，看一下這人如何回答他不會的問題也是滿有趣。應試者是以好的直覺做出明智的選擇，還是只是瞎蒙呢？當應試者在某個問題上卡住時是找藉口呢，還是表現出對問題的真正的好奇心，把這看成學習的機會呢？我發現這些信息與他們的測試成績一樣有用。
有了這些想法，我決定出一些真正針對嵌入式系統的考題，希望這些令人頭痛的考題能給正在找工作的人一點幫助。這些問題都是我這些年實際碰到的。其中有些題很難，但它們應該都能給你一點啟迪。
這個測試適於不同水平的應試者，大多數初級水平的應試者的成績會很差，經驗豐富的程序員應該有很好的成績。為了讓你能自己決定某些問題的偏好，每個問題沒有分配分數，如果選擇這些考題為你所用，請自行按你的意思分配分數。
預處理器（Preprocessor）
1 . 用預處理指令#define 聲明一個常數，用以表明1年中有多少秒（忽略閏年問題）
#define SECONDS_PER_YEAR (60 * 60 * 24 * 365)UL
我在這想看到幾件事情：
1) #define 語法的基本知識（例如：不能以分號結束，括號的使用，等等）
2)懂得預處理器將為你計算常數表達式的值，因此，直接寫出你是如何計算一年中有多少秒而不是計算出實際的值，是更清晰而沒有代價的。
3) 意識到這個表達式將使一個16位機的整型數溢出-因此要用到長整型符號L,告訴編譯器這個常數是的長整型數。
4) 如果你在你的表達式中用到UL（表示無符號長整型），那麼你有了一個好的起點。記住，第一印象很重要。
2 . 寫一個"標準"宏MIN ，這個宏輸入兩個參數並返回較小的一個。
#define MIN(A,B) （（A） <= (B) ? (A) : (B))
這個測試是為下面的目的而設的：
1) 標識#define在宏中應用的基本知識。這是很重要的。因為在 嵌入(inline)操作符 變為標準C的一部分之前，宏是方便產生嵌入代碼的唯一方法，對於嵌入式系統來說，為了能達到要求的性能，嵌入代碼經常是必須的方法。
2)三重條件操作符的知識。這個操作符存在C語言中的原因是它使得編譯器能產生比if-then-else更優化的代碼，瞭解這個用法是很重要的。
3) 懂得在宏中小心地把參數用括號括起來
4) 我也用這個問題開始討論宏的副作用，例如：當你寫下面的代碼時會發生什麼事？
least = MIN(*p++, b);
3. 預處理器標識#error的目的是什麼？
如果你不知道答案，請看參考文獻1。這問題對區分一個正常的夥計和一個書呆子是很有用的。只有書呆子才會讀C語言課本的附錄去找出像這種問題的答案。當然如果你不是在找一個書呆子，那麼應試者最好希望自己不要知道答案。
!!NOTES: Mark
#error: Error directives produce compiler-time error messages.
死循環（Infinite loops）
4. 嵌入式系統中經常要用到無限循環，你怎麼樣用C編寫死循環呢？
這個問題用幾個解決方案。我首選的方案是：
while(1)
{
}
一些程序員更喜歡如下方案：
for(;;)
{
}
這個實現方式讓我為難，因為這個語法沒有確切表達到底怎麼回事。如果一個應試者給出這個作為方案，我將用這個作為一個機會去探究他們這樣做的基本原理。如果他們的基本答案是："我被教著這樣做，但從沒有想到過為什麼。"這會給我留下一個壞印象。
第三個方案是用 goto
Loop:
...
goto Loop;
應試者如給出上面的方案，這說明或者他是一個彙編語言程序員（這也許是好事）或者他是一個想進入新領域的BASIC/FORTRAN程序員。
數據聲明（Data declarations）
5. 用變量a給出下面的定義
a) 一個整型數（An integer）
b)一個指向整型數的指針（ A pointer to an integer）
c)一個指向指針的的指針，它指向的指針是指向一個整型數（ A pointer to a pointer to an intege）r
d)一個有10個整型數的數組（ An array of 10 integers）
e) 一個有10個指針的數組，該指針是指向一個整型數的。（An array of 10 pointers to integers）
f) 一個指向有10個整型數數組的指針（ A pointer to an array of 10 integers）
g) 一個指向函數的指針，該函數有一個整型參數並返回一個整型數（A pointer to a function that takes an integer as an argument and returns an integer）
h) 一個有10個指針的數組，該指針指向一個函數，該函數有一個整型參數並返回一個整型數（ An array of ten pointers to functions that take an integer argument and return an integer ）
答案是：
a) int a; // An integer
b) int *a; // A pointer to an integer
c) int **a; // A pointer to a pointer to an integer
d) int a[10]; // An array of 10 integers
e) int *a[10]; // An array of 10 pointers to integers
f) int (*a)[10]; // A pointer to an array of 10 integers
g) int (*a)(int); // A pointer to a function a that takes an integer argument and returns an integer
h) int (*a[10])(int); // An array of 10 pointers to functions that take an integer argument and return an integer
人們經常聲稱這裡有幾個問題是那種要翻一下書才能回答的問題，我同意這種說法。當我寫這篇文章時，為了確定語法的正確性，我的確查了一下書。但是當我被面試的時候，我期望被問到這個問題（或者相近的問題）。因為在被面試的這段時間裡，我確定我知道這個問題的答案。應試者如果不知道所有的答案（或至少大部分答案），那麼也就沒有為這次面試做準備，如果該面試者沒有為這次面試做準備，那麼他又能為什麼出準備呢？
Static
6. 關鍵字static的作用是什麼？
這個簡單的問題很少有人能回答完全。在C語言中，關鍵字static有三個明顯的作用：
1)在函數體，一個被聲明為靜態的變量在這一函數被調用過程中維持其值不變。
2) 在模塊內（但在函數體外），一個被聲明為靜態的變量可以被模塊內所用函數訪問，但不能被模塊外其它函數訪問。它是一個本地的全局變量。
3) 在模塊內，一個被聲明為靜態的函數只可被這一模塊內的其它函數調用。那就是，這個函數被限制在聲明它的模塊的本地範圍內使用。
大多數應試者能正確回答第一部分，一部分能正確回答第二部分，同是很少的人能懂得第三部分。這是一個應試者的嚴重的缺點，因為他顯然不懂得本地化數據和代碼範圍的好處和重要性。
Const
7．關鍵字const有什麼含意？
我只要一聽到被面試者說："const意味著常數"，我就知道我正在和一個業餘者打交道。去年Dan Saks已經在他的文章裡完全概括了const的所有用法，因此ESP(譯者：Embedded Systems Programming)的每一位讀者應該非常熟悉const能做什麼和不能做什麼.如果你從沒有讀到那篇文章，只要能說出const意味著"只讀"就可以了。儘管這個答案不是完全的答案，但我接受它作為一個正確的答案。（如果你想知道更詳細的答案，仔細讀一下Saks的文章吧。）
如果應試者能正確回答這個問題，我將問他一個附加的問題：
下面的聲明都是什麼意思？
const int a;
int const a;
const int *a;
int * const a;
int const * a const;
/******/
前兩個的作用是一樣，a是一個常整型數。第三個意味著a是一個指向常整型數的指針（也就是，整型數是不可修改的，但指針可以）。第四個意思a是一個指向整型數的常指針（也就是說，指針指向的整型數是可以修改的，但指針是不可修改的）。最後一個意味著a是一個指向常整型數的常指針（也就是說，指針指向的整型數是不可修改的，同時指針也是不可修改的）。如果應試者能正確回答這些問題，那麼他就給我留下了一個好印象。順帶提一句，也許你可能會問，即使不用關鍵字 const，也還是能很容易寫出功能正確的程序，那麼我為什麼還要如此看重關鍵字const呢？我也如下的幾下理由：
1) 關鍵字const的作用是為給讀你代碼的人傳達非常有用的信息，實際上，聲明一個參數為常量是為了告訴了用戶這個參數的應用目的。如果你曾花很多時間清理其它人留下的垃圾，你就會很快學會感謝這點多餘的信息。（當然，懂得用const的程序員很少會留下的垃圾讓別人來清理的。）
2) 通過給優化器一些附加的信息，使用關鍵字const也許能產生更緊湊的代碼。
3) 合理地使用關鍵字const可以使編譯器很自然地保護那些不希望被改變的參數，防止其被無意的代碼修改。簡而言之，這樣可以減少bug的出現。
Volatile
8. 關鍵字volatile有什麼含意?並給出三個不同的例子。
一個定義為volatile的變量是說這變量可能會被意想不到地改變，這樣，編譯器就不會去假設這個變量的值了。精確地說就是，優化器在用到這個變量時必須每次都小心地重新讀取這個變量的值，而不是使用保存在寄存器裡的備份。下面是volatile變量的幾個例子：
1) 並行設備的硬件寄存器（如：狀態寄存器）
2) 一個中斷服務子程序中會訪問到的非自動變量(Non-automatic variables)
3) 多線程應用中被幾個任務共享的變量
回答不出這個問題的人是不會被僱傭的。我認為這是區分C程序員和嵌入式系統程序員的最基本的問題。搞嵌入式的傢伙們經常同硬件、中斷、RTOS等等打交道，所有這些都要求用到volatile變量。不懂得volatile的內容將會帶來災難。
假設被面試者正確地回答了這是問題（嗯，懷疑是否會是這樣），我將稍微深究一下，看一下這傢伙是不是直正懂得volatile完全的重要性。
1)一個參數既可以是const還可以是volatile嗎？解釋為什麼。
2); 一個指針可以是volatile 嗎？解釋為什麼。
3); 下面的函數有什麼錯誤：
int square(volatile int *ptr)
{
return *ptr * *ptr;
}
下面是答案：
1)是的。一個例子是只讀的狀態寄存器。它是volatile因為它可能被意想不到地改變。它是const因為程序不應該試圖去修改它。
2); 是的。儘管這並不很常見。一個例子是當一個中服務子程序修該一個指向一個buffer的指針時。
3) 這段代碼有點變態。這段代碼的目的是用來返指針*ptr指向值的平方，但是，由於*ptr指向一個volatile型參數，編譯器將產生類似下面的代碼：
int square(volatile int *ptr)
{
int a,b;
a = *ptr;
b = *ptr;
return a * b;
}
由於*ptr的值可能被意想不到地該變，因此a和b可能是不同的。結果，這段代碼可能返不是你所期望的平方值！正確的代碼如下：
long square(volatile int *ptr)
{
int a;
a = *ptr;
return a * a;
}
!!NOTES: Mark
More explanation about volatile:
由於訪問寄存器 (Mark: "register") 的速度要快過RAM，所以編譯器一般都會作減少存取外部RAM的優化。比如：
// ps: the following line should be volatile static int i = 0;
static int i=0;
int main(void)
{
...
while (1)
{
if (i)
dosomething();
}
}
/* Interrupt service routine. */
void ISR_2(void)
{
i=1;
}
程序的本意是希望ISR_2中斷產生時，在main當中調用dosomething函數，但是，由於編譯器判斷在main函數裡面沒有修改過 i，
因此可能只執行一次對從i到某寄存器的讀操作，然後每次 if 判斷都只使用這個寄存器裡面的「i副本」，
導致dosomething永遠也不會被調用。
如果將將變量加上volatile修飾，則編譯器保證對此變量的讀寫操作都不會被優化（肯定執行）。此例中 i 也應該如此說明。
一般說來，volatile用在如下的幾個地方：
1、中斷服務程序中修改的供其它程序檢測的變量需要加volatile；
2、多任務環境下各任務間共享的標誌應該加volatile；
3、存儲器映射的硬件寄存器通常也要加volatile說明，因為每次對它的讀寫都可能有不同意義；
PS: 因為volatile抑制了優化，因而應儘量減少對它的引用操作，最好只對它進行簡單的讀寫賦值
位操作（Bit manipulation）
9. 嵌入式系統總是要用戶對變量或寄存器進行位操作。給定一個整型變量a，寫兩段代碼，第一個設置a的bit 3，第二個清除a 的bit 3。在以上兩個操作中，要保持其它位不變。
對這個問題有三種基本的反應
1)不知道如何下手。該被面者從沒做過任何嵌入式系統的工作。
2) 用bit fields。Bit fields是被扔到C語言死角的東西，它保證你的代碼在不同編譯器之間是不可移植的，同時也保證了的你的代碼是不可重用的。我最近不幸看到 Infineon為其較複雜的通信芯片寫的驅動程序，它用到了bit fields因此完全對我無用，因為我的編譯器用其它的方式來實現bit fields的。從道德講：永遠不要讓一個非嵌入式的傢伙粘實際硬件的邊。
!!NOTES: Mark: Bit fields introduction
1) Examplestruct foo {
int flag : 1;
int counter : 15;
};2) Disadvantagea) the ordering of bits in memory varies from compiler to compilerb) many popular compilers generate inefficient code for reading and writing bit membersc) there are potentially severe thread safety issues relating to bit fields(especially on multiprocessor systems) due to the fact that most machines cannot manipulate arbitrary sets of bits in memory,but must instead load and store whole words. e.g the following would not be thread-safe, in spite of the use of a mutex:ex:----struct foo {int flag : 1;int counter : 15;};struct foo my_foo; ...
pthread_mutex_lock(&my_mutex);my_foo.flag = !my_foo.flag;pthread_mutex_unlock(&my_mutex);my_foo.counter++;if (my_foo.counter >= 92)cout << "I pity da foo.\n";----Explanation:as on most machines it is impossible at the hardware level to load and storeflagandcounterseparately.(In order for this to be thread safe, you would need to lock and unlock the mutex around all accesses to bothflagandcounter,even ifcounterdoesn't itself need to be thread-safe.)
3) 用 #defines 和 bit masks 操作。這是一個有極高可移植性的方法，是應該被用到的方法。最佳的解決方案如下：
#define BIT3 (0x1 << 3)
static int a;
void set_bit3(void)
{
a |= BIT3;
}
void clear_bit3(void)
{
a &= ~BIT3;
}
一些人喜歡為設置和清除值而定義一個掩碼同時定義一些說明常數，這也是可以接受的。我希望看到幾個要點：說明常數、|=和&=~操作。
訪問固定的內存位置（Accessing fixed memory locations）
10. 嵌入式系統經常具有要求程序員去訪問某特定的內存位置的特點。在某工程中，要求設置一絕對地址為0x67a9的整型變量的值為0xaa66。編譯器是一個純粹的ANSI編譯器。寫代碼去完成這一任務。
這一問題測試你是否知道為了訪問一絕對地址把一個整型數強制轉換（typecast）為一指針是合法的。這一問題的實現方式隨著個人風格不同而不同。典型的類似代碼如下：
int *ptr;
ptr = (int *)0x67a9;
*ptr = 0xaa55;
A more obscure approach is:
一個較晦澀的方法是：
*(int * const)(0x67a9) = 0xaa55;
即使你的品味更接近第二種方案，但我建議你在面試時使用第一種方案。
中斷（Interrupts）
11. 中斷是嵌入式系統中重要的組成部分，這導致了很多編譯開發商提供一種擴展—讓標準C支持中斷。具代表事實是，產生了一個新的關鍵字 __interrupt。下面的代碼就使用了__interrupt關鍵字去定義了一個中斷服務子程序(ISR)，請評論一下這段代碼的。
__interrupt double compute_area (double radius)
{
double area = PI * radius * radius;
printf("nArea = %f", area);
return area;
}
這個函數有太多的錯誤了，以至讓人不知從何說起了：
1)ISR 不能返回一個值。如果你不懂這個，那麼你不會被僱用的。
2) ISR 不能傳遞參數。如果你沒有看到這一點，你被僱用的機會等同第一項。
3) 在許多的處理器/編譯器中，浮點一般都是不可重入的。有些處理器/編譯器需要讓額處的寄存器入棧，有些處理器/編譯器就是不允許在ISR中做浮點運算。此外，ISR應該是短而有效率的，在ISR 中做浮點運算是不明智的。
4) 與第三點一脈相承，printf()經常有重入和性能上的問題。如果你丟掉了第三和第四點，我不會太為難你的。不用說，如果你能得到後兩點，那麼你的被僱用前景越來越光明了。
代碼例子（Code examples）
12 . 下面的代碼輸出是什麼，為什麼？
void foo(void)
{
unsigned int a = 6;
int b = -20;
(a+b > 6) ? puts("> 6") : puts("<= 6");
}
這個問題測試你是否懂得C語言中的整數自動轉換原則，我發現有些開發者懂得極少這些東西。不管如何，這無符號整型問題的答案是輸出是 ">6"。原因是當表達式中存在有符號類型和無符號類型時所有的操作數都自動轉換為無符號類型。因此-20變成了一個非常大的正整數，所以該表達式計算出的結果大於6。這一點對於應當頻繁用到無符號數據類型的嵌入式系統來說是豐常重要的。如果你答錯了這個問題，你也就到了得不到這份工作的邊緣。
13. 評價下面的代碼片斷：
unsigned int zero = 0;
unsigned int compzero = 0xFFFF;
/*1's complement of zero */
對於一個int型不是16位的處理器為說，上面的代碼是不正確的。應編寫如下：
unsigned int compzero = ~0;
這一問題真正能揭露出應試者是否懂得處理器字長的重要性。在我的經驗裡，好的嵌入式程序員非常準確地明白硬件的細節和它的侷限，然而PC機程序往往把硬件作為一個無法避免的煩惱。
到了這個階段，應試者或者完全垂頭喪氣了或者信心滿滿志在必得。如果顯然應試者不是很好，那麼這個測試就在這裡結束了。但如果顯然應試者做得不錯，那麼我就扔出下面的追加問題，這些問題是比較難的，我想僅僅非常優秀的應試者能做得不錯。提出這些問題，我希望更多看到應試者應付問題的方法，而不是答案。不管如何，你就當是這個娛樂吧...
動態內存分配（Dynamic memory allocation）
14. 儘管不像非嵌入式計算機那麼常見，嵌入式系統還是有從堆（heap）中動態分配內存的過程的。那麼嵌入式系統中，動態分配內存可能發生的問題是什麼？
這裡，我期望應試者能提到內存碎片，碎片收集的問題，變量的持行時間等等。這個主題已經在ESP雜誌中被廣泛地討論過了（主要是 P.J. Plauger, 他的解釋遠遠超過我這裡能提到的任何解釋），所有回過頭看一下這些雜誌吧！讓應試者進入一種虛假的安全感覺後，我拿出這麼一個小節目：
下面的代碼片段的輸出是什麼，為什麼？
char *ptr;
if ((ptr = (char *)malloc(0)) == NULL)
puts("Got a null pointer");
else
puts("Got a valid pointer");
!!NOTES: Mark
Whether "ptr == NULL" should be implementation-defined.
I got "non-NULL" pointer when testing with VC6.
這是一個有趣的問題。最近在我的一個同事不經意把0值傳給了函數malloc，得到了一個合法的指針之後，我才想到這個問題。這就是上面的代碼，該代碼的輸出是"Got a valid pointer"。我用這個來開始討論這樣的一問題，看看被面試者是否想到庫例程這樣做是正確。得到正確的答案固然重要，但解決問題的方法和你做決定的基本原理更重要些。
Typedef
15 Typedef 在C語言中頻繁用以聲明一個已經存在的數據類型的同義字。也可以用預處理器做類似的事。例如，思考一下下面的例子：
#define dPS struct s *
typedef struct s * tPS;
以上兩種情況的意圖都是要定義dPS 和 tPS 作為一個指向結構s指針。哪種方法更好呢？（如果有的話）為什麼？
這是一個非常微妙的問題，任何人答對這個問題（正當的原因）是應當被恭喜的。答案是：typedef更好。思考下面的例子：
dPS p1,p2;
tPS p3,p4;
第一個擴展為
struct s * p1, p2;
.
上面的代碼定義p1為一個指向結構的指，p2為一個實際的結構，這也許不是你想要的。第二個例子正確地定義了p3 和p4 兩個指針。
晦澀的語法
16 . C語言同意一些令人震驚的結構,下面的結構是合法的嗎，如果是它做些什麼？
int a = 5, b = 7, c;
c = a+++b;
這個問題將做為這個測驗的一個愉快的結尾。不管你相不相信，上面的例子是完全合乎語法的。問題是編譯器如何處理它？水平不高的編譯作者實際上會爭論這個問題，根據最處理原則，編譯器應當能處理儘可能所有合法的用法。因此，上面的代碼被處理成：
c = a++ + b;
因此, 這段代碼持行後a = 6, b = 7, c = 12。
如果你知道答案，或猜出正確答案，做得好。如果你不知道答案，我也不把這個當作問題。我發現這個問題的最大好處是這是一個關於代碼編寫風格，代碼的可讀性，代碼的可修改性的好的話題。
好了，夥計們，你現在已經做完所有的測試了。這就是我出的C語言測試題，我懷著愉快的心情寫完它，希望你以同樣的心情讀完它。如果是認為這是一個好的測試，那麼儘量都用到你的找工作的過程中去吧。天知道也許過個一兩年，我就不做現在的工作，也需要找一個。
作者介紹:
Nigel Jones 是一個顧問，現在住在Maryland，當他不在水下時，你能在多個範圍的嵌入項目中找到他。 他很高興能收到讀者的來信，他的email地址是: NAJones@compuserve.com
參考文獻
1) Jones, Nigel, "In Praise of the #error directive," Embedded Systems Programming, September 1999, p. 114.
2) Jones, Nigel, " Efficient C Code for Eight-bit MCUs ," Embedded Systems Programming, November 1998, p. 66.
靜態鏈接網址|評論 (0)
如何優化C語言代碼(程序員必讀)
AlexanderWu 發表於2006 2月, 11 12:37 [C資料庫]
1、選擇合適的算法和數據結構
應該熟悉算法語言，知道各種算法的優缺點，具體資料請參見相應的參考資料，有
很多計算機書籍上都有介紹。將比較慢的順序查找法用較快的二分查找或亂序查找
法代替，插入排序或冒泡排序法用快速排序、合併排序或根排序代替，都可以大大
提高程序執行的效率。.選擇一種合適的數據結構也很重要，比如你在一堆隨機存
放的數中使用了大量的插入和刪除指令，那使用鏈表要快得多。
數組與指針語句具有十分密碼的關係，一般來說，指針比較靈活簡潔，而數組則比
較直觀，容易理解。對於大部分的編譯器，使用指針比使用數組生成的代碼更短，
執行效率更高。但是在Keil中則相反，使用數組比使用的指針生成的代碼更短。。
3、使用儘量小的數據類型
能夠使用字符型(char)定義的變量，就不要使用整型(int)變量來定義；能夠使用
整型變量定義的變量就不要用長整型(long int)，能不使用浮點型(float)變量就
不要使用浮點型變量。當然，在定義變量後不要超過變量的作用範圍，如果超過變
量的範圍賦值，C編譯器並不報錯，但程序運行結果卻錯了，而且這樣的錯誤很難
發現。
在ICCAVR中，可以在Options中設定使用printf參數，儘量使用基本型參數(%c、
%d、%x、%X、%u和%s格式說明符)，少用長整型參數(%ld、%lu、%lx和%lX格式說明
符)，至於浮點型的參數(%f)則儘量不要使用，其它C編譯器也一樣。在其它條件不
變的情況下，使用%f參數，會使生成的代碼的數量增加很多，執行速度降低。
4、使用自加、自減指令
通常使用自加、自減指令和復合賦值表達式(如a-=1及a+=1等)都能夠生成高質量的
程序代碼，編譯器通常都能夠生成inc和dec之類的指令，而使用a=a+1或a=a-1之類
的指令，有很多C編譯器都會生成二到三個字節的指令。在AVR單片適用的ICCAVR、
GCCAVR、IAR等C編譯器以上幾種書寫方式生成的代碼是一樣的，也能夠生成高質量
的inc和dec之類的的代碼。
5、減少運算的強度
可以使用運算量小但功能相同的表達式替換原來複雜的的表達式。如下：
(1)、求余運算。
a=a%8;
可以改為：
a=a&7;
說明：位操作只需一個指令週期即可完成，而大部分的C編譯器的「%」運算均是調
用子程序來完成，代碼長、執行速度慢。通常，只要求是求2n方的餘數，均可使用
位操作的方法來代替。
(2)、平方運算
a=pow(a,2.0);
可以改為：
a=a*a;
說明：在有內置硬件乘法器的單片機中(如51系列)，乘法運算比求平方運算快得多
，因為浮點數的求平方是通過調用子程序來實現的，在自帶硬件乘法器的AVR單片
機中，如ATMega163中，乘法運算只需2個時鐘週期就可以完成。既使是在沒有內置
硬件乘法器的AVR單片機中，乘法運算的子程序比平方運算的子程序代碼短，執行
速度快。
如果是求3次方，如：
a=pow(a,3.0);
更改為：
a=a*a*a；
則效率的改善更明顯。
(3)、用移位實現乘除法運算
a=a*4;
b=b/4;
可以改為：
a=a<<2;
b=b>>2;
說明：通常如果需要乘以或除以2n，都可以用移位的方法代替。在ICCAVR中，如果
乘以2n，都可以生成左移的代碼，而乘以其它的整數或除以任何數，均調用乘除法
子程序。用移位的方法得到代碼比調用乘除法子程序生成的代碼效率高。實際上，
只要是乘以或除以一個整數，均可以用移位的方法得到結果，如：
a=a*9
可以改為：
a=(a<<3)+a
6、循環
(1)、循環語
對於一些不需要循環變量參加運算的任務可以把它們放到循環外面，這裡的任務包
括表達式、函數的調用、指針運算、數組訪問等，應該將沒有必要執行多次的操作
全部集合在一起，放到一個init的初始化程序中進行。
(2)、延時函數：
通常使用的延時函數均採用自加的形式：
void delay (void)
{
unsigned int i;
for (i=0;i<1000;i++)
;
}
將其改為自減延時函數：
void delay (void)
{
unsigned int i;
for (i=1000;i>0;i--)
;
}
兩個函數的延時效果相似，但幾乎所有的C編譯對後一種函數生成的代碼均比前一
種代碼少1~3個字節，因為幾乎所有的MCU均有為0轉移的指令，採用後一種方式能
夠生成這類指令。
在使用while循環時也一樣，使用自減指令控制循環會比使用自加指令控制循環生
成的代碼更少1~3個字母。
但是在循環中有通過循環變量「i」讀寫數組的指令時，使用預減循環時有可能使
數組超界，要引起注意。
(3)while循環和do…while循環
用while循環時有以下兩種循環形式：
unsigned int i;
i=0;
while (i<1000)
{
i++;
//用戶程序
}
或：
unsigned int i;
i=1000;
do
i--;
//用戶程序
while (i>0);
在這兩種循環中，使用do…while循環編譯後生成的代碼的長度短於while循環。
7、查表
在程序中一般不進行非常複雜的運算，如浮點數的乘除及開方等，以及一些複雜的
數學模型的插補運算，對這些即消耗時間又消費資源的運算，應儘量使用查表的方
式，並且將數據表置於程序存儲區。如果直接生成所需的表比較困難，也儘量在啟
了，減少了程序執行過程中重複計算的工作量。
8、其它
比如使用在線彙編及將字符串和一些常量保存在程序存儲器中，均有利於優化
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=632175
2008年2月22日 星期五
LCT, ALC, FLUTE info
Preface
| Reference |
|
LCT header format -- ref 5.1 of RFC3451
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C | r |S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*(C+1) bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32*O+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time (SCT, if T = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expected Residual Time (ERT, if R = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Default LCT header format!!NOTES:
1) the total length of LCT header is (HDR_LEN x 4) bytes
2) if the total consumed number of bytes before "Header Extensions" is
less than (HDR_LEN x 4) bytes, it means that "Header Extensions" is/are included.
3) If "Header Extensions" is included, the format is determined by
"Header Extension Type", which is the first byte of "Header Extensions",
ex: EXT_FDT (HET=192), EXT_FTI(HET=64)
ALC header format -- ref 4.1 of RFC3450
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Default LCT header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Overall ALC packet format!!NOTES:
1) Default LCT header only contains those fields before
"Header Extensions" part
2) FEC Payload ID -- ref. section 3 of RFC 3452
Identifies the encoding symbol(s) in the payload of
the packet. The types and lengths of the fields in
the FEC Payload ID, i.e., the format of the FEC
Payload ID, are determined by the FEC Encoding ID.
The full specification of each field MUST be uniquely
determined by the FEC Encoding ID for Fully-Specified
FEC schemes, and MUST be uniquely determined by
the combination of the FEC Encoding ID and the
FEC Instance ID for Under-Specified FEC schemes.
FLUTE-related
Overall FDT Packet -- ref 3.4 of RFC3926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default LCT header (with TOI = 0) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) for FDT Instance |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Overall FDT Packet
EXT_FDT format -- FDT Instance Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 192 | V | FDT Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
General EXT_FTI format -- ref 5.1.1. of RFC3926 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 64 | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Transfer Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Instance ID | FEC Enc. ID Specific Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!!NOTES:1) "FEC Enc. ID" should be equivalent with "CodePoint"
of LCT header.
2) Refer "FEC Enc. ID Specific Format" in
5.1.2 of RFC3926
FEC Encoding IDs, 0, 128, 130 -- ref 5.1.2.1 of RFC3926 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
General EXT_FTI format | Encoding Symbol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!!NOTES:1) FEC Encoding ID 0 is 'Compact No-Code FEC'(Fully-Specified)2) FEC Encoding ID 128 is 'Small Block, Large Block and
Expandable FEC' (Under-Specified)3) FEC Encoding ID 130 is 'Compact FEC' (Fully-Specified)
FEC Encoding ID 129 -- ref 5.1.2.2 of RFC3926 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
General EXT_FTI format | Encoding Symbol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Source Block Length | Max. Num. of Encoding Symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+!!NOTES:1) FEC Encoding ID 129 is 'Small Block Systematic FEC'
(Under-Specified)
FEC Payload ID for FEC Encoding IDs 0 and 130
-- ref 2.1 of RFC3695 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!!NOTES:1) "Source Block Number" and "Encoding Symbol ID" should
be used together to identify the current Encoding
Symbols in a certain TOI.
Psuedo code: TOI_frag_ID = (Source_Block_Number << 16) | Encoding_Symbol_ID;FEC Payload ID for FEC Encoding ID 128 -- ref 5.1 of RFC3452
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Payload ID for FEC Encoding ID 129 -- ref 5.2 of RFC3452 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2008年2月21日 星期四
UDP, RTP, RTCP
[UDP]
| Reference |
|
| MAC header | IP header | UDP header | Data ::: |
UDP header:
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Source Port | Destination Port | ||||||||||||||||||||||||||||||
| Length | Checksum | ||||||||||||||||||||||||||||||
| Data ::: | |||||||||||||||||||||||||||||||
!!NOTES:
1) The checksum algorithm is the same as that of IP header.
2) Length = (UDP_header_length + UDP_payload_length)
[RTP header]
| Reference |
|
| MAC header | IP header | UDP header | RTP message |
RTP header, version 2:
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Ver | P | X | CC | M | PT | Sequence Number | |||||||||||||||||||||||||
| Timestamp | |||||||||||||||||||||||||||||||
| SSRC | |||||||||||||||||||||||||||||||
| CSRC [0..15] ::: | |||||||||||||||||||||||||||||||
!!NOTES:
1)
V(Version):
The current version of RTP is 2.
P(Padding):
is used to indicate that the payload has been padded out past
its natural length.
M:
is used to mark events of interest within a media stream;
its precise meaning is defined by the RTP profile and
media type in use.
PT(payload type):
identifies the media transported by an RTP packet
Sequence Number:
identify packets, and to provide an indication to the receiver
if packets are being lost or delivered out of order.
Timestamp:
denotes the sampling instant for the first octet of
media data in the packet and it is used to schedule
playout of the media data.
Synchronization Source (SSRC):
identifies participants within an RTP session.
Contributing Source(CSRC):
identifies participants who have contributed to
an RTP packet but were not responsible for its
timing and synchronization.
2) if P is set to 1, the last byte of the RTP payload shows the
number of padding bytes following RTP payload.
3) Timestamp wrap-around should be handled by all applications. A better design is to calculate timestamp using 32-bit modulo arithmetic. A 64-bit arithmetic is not recommended due to inefficiency.
4) Sequence number may be wrapped around, too. Using 32-bit arithmetic as extended_sequence_number is recommended.
[RTCP header]
| Reference |
|
| MAC header | IP header | UDP header | RTCP header | Data ::: |
RTCP header:
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Version | P | Count | Type | Length | |||||||||||||||||||||||||||
| Data ::: | |||||||||||||||||||||||||||||||
!!NOTES:
1) If Type == 200, it means RTCP conveys Sender Report, which is used for a/v synchronization.
The format of Sender Report is
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|Count | Type (200) | Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reporter SSRC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp (high)
| NTP timestamp (low)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's packet count
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's octet count
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver report block(s)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
psuedo code:
int64 ntp_high = ntohl(*((unsigned int*)(pRTCPBuffer+8)) );
int64 ntp_low = ntohl(*((unsigned int*)(pRTCPBuffer+12)) );
int64 timestamp = ntohl(*((unsigned int*)(pRTCPBuffer+16)) );
int64 rtcp_ntp_in_microsecond_base = ntp_high*1000000 + ((ntp_low*1000000) >> 32);
int64 rtcp_timestamp_base = timestamp;
absolute_PTSinMicroSec =
rtcp_ntp_in_microsecond_base +
(RTP_timeStamp - rtcp_timestamp_base)*1000000 / clock_rate;
IPv6 header introduction
[IPv6]
| Reference |
|
| MAC header | IPv6 header | Data ::: |
IPv6 header:
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Version | Traffic Class | Flow Label | |||||||||||||||||||||||||||||
| Payload Length | Next Header | Hop Limit | |||||||||||||||||||||||||||||
| Source address ::: | |||||||||||||||||||||||||||||||
| Destination address ::: | |||||||||||||||||||||||||||||||
| Data ::: | |||||||||||||||||||||||||||||||
Extension Headers
| Reference |
|
!!NOTES:
1) The value of "Next header" field is 0x2C when it comes to IPv6 Fragment Extension Header.
2) The method of assembling IPv6 fragmented is the same as that of IPv4.
2008年2月20日 星期三
IPv4 header introduction
[IPv4]
| Reference |
| MAC header | IP header | Data ::: |
IP header:
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Version | IHL | TOS | Total length | ||||||||||||||||||||||||||||
| Identification | Flags | Fragment offset | |||||||||||||||||||||||||||||
| TTL | Protocol | Header checksum | |||||||||||||||||||||||||||||
| Source IP address | |||||||||||||||||||||||||||||||
| Destination IP address | |||||||||||||||||||||||||||||||
| Options and padding ::: | |||||||||||||||||||||||||||||||
!!NOTES:
1) Real_Fragment_Offset = Fragment_Offset x 8
2) Identification and MF_in_Flags, and Fragment_Offset are used to assemble fragmented IP packets.
3) checksum in C code (ps: checksum field has to be set to 0 first)
typedef unsigned short u16;
typedef unsigned char u8;
typedef unsigned long u32;//!!NOTES:
// before ip checksum is calculated,
// the IP_Header::Checksum should be 0
u16 ip_sum_calc(u16 len_ip_header, u8 buff[])
{
u16 word16;
u32 sum=0;
u16 i;// make 16 bit words out of every two adjacent 8 bit words in the packet
// and add them up
for (i=0;i<len_ip_header;i=i+2){
word16 =((buff[i]<<8)&0xFF00)+(buff[i+1]&0xFF);
sum = sum + (u32) word16;
}// take only 16 bits out of the 32 bit sum and add up the carries
while (sum>>16)
sum = (sum & 0xFFFF)+(sum >> 16);// one's complement the result
sum = ~sum;return ((u16) sum);
}
訂閱：
文章 (Atom)