Normandy 博客

@Nick
見笑了，英語不咋地，多謝兄臺提醒 :)

Keep going on with your dream

@wocow3
各線程清理資源并結(jié)束自己的時(shí)候， 用 WaitForSingleObject() 可保證線程有序的清理資源并退出。

很多情況可引發(fā)競爭: 如線程1 欲結(jié)束自己, 但僅清理了一半資源，這時(shí)發(fā)生 context switch, CPU 切換到線程 2, 而線程2 也要清理資源并結(jié)束自己，如果清理資源的動(dòng)作必須保證有序，就會(huì)引發(fā)競爭。

@wocow3, 唐新發(fā)

這里不會(huì)引發(fā)等待， 因?yàn)?WaitForSingleObject 的第二個(gè)參數(shù)是 0。 另外， 用全局變量作退出標(biāo)志有一個(gè)致命缺點(diǎn)，當(dāng)兩個(gè)已上的線程并發(fā)讀寫全局變量的時(shí)候, 就會(huì)引發(fā)競爭，而用 WaitForSingleObject 則是安全的。

@陳梓瀚(vczh)

Good catch, thanks.

Updated the title with "Keep go on with your dream"

@金中偉
其實(shí)沒有這么復(fù)雜，我是通過 Makefile 編譯的， 沒有用 IDE。你打開 Visual Studio 2005 Command Prompt 或 Visual Studio 2008 Command Prompt ，然后進(jìn)到源碼目錄下 敲一個(gè) nmake 命令， 所有的都會(huì)為你自動(dòng)生成。細(xì)節(jié)可查看源碼目錄下的 Makefile 文件。

@achilles
將一些過程放在遠(yuǎn)程是分布式程序的要求，如客戶機(jī)/服務(wù)器模式。相比常規(guī)的網(wǎng)絡(luò)通信程序而言，在用 RPC 時(shí)我們只需要關(guān)心程序本身的邏輯，就像建本地程序一樣，因?yàn)?RPC 已經(jīng)幫你做了網(wǎng)絡(luò)通信的工作!

如果你還是不能理解， 請下載我上面的遠(yuǎn)程過程調(diào)用示例，將客戶程序和服務(wù)程序放在兩個(gè)不同的機(jī)器上運(yùn)行看看。

如果你想了解更多的細(xì)節(jié)，請看一下 <<Linux 網(wǎng)絡(luò)編程>> 第十二章，上面的內(nèi)容更精彩!

@achilles
優(yōu)點(diǎn)是可直接訪問遠(yuǎn)程過程，避免煩瑣的打包和解包過程，且不依賴于某種特定的協(xié)議

@毛
實(shí)際上板子加電啟動(dòng)時(shí)，SRAM 從 0x40000000 開始的 4096 字節(jié)區(qū)域被映射成 從 0x00000000 開始的 4096 字節(jié)區(qū)域, 手冊上有說明

@AlexEric
看情況吧，只恐時(shí)間精力不夠用。參與開源著重解決實(shí)際問題，分析 Kernel 源碼則強(qiáng)調(diào)理解底層，我更喜歡看些底層的東西。

AlexEric 兄若有心得，一定要拿出來分享啊!

@AlexEric
兄弟對 TCP/IP 也有興趣啊，我打算通讀 Linux 下的協(xié)議棧源碼，有機(jī)會(huì)多切磋啊 :-)

@嚴(yán)植
上面例子是基于查詢而非 DMA ，不過應(yīng)該不難。我想可能是以下的問題:
(1) 超級終端收發(fā)數(shù)據(jù)有問題(看看設(shè)置，如波特率等是否正確)
(2) 板子串口有問題(我的經(jīng)常是這樣， 多插幾次試試)
(3) UART 設(shè)成 DMA 中斷方式有誤 (請仔細(xì)查看手冊, 確認(rèn)相關(guān)的控制寄存器是否設(shè)置正確)

可用 Emacs

NTEmacs 很好用， 你可以試試

@xi_liang
Nand Flash 只是存儲器，其前 4k 被映射到 SRAM (就是 NOR FLASH) 里，所以小于 4k 的程序運(yùn)行是沒有問題的, 大于 4k 的程序則不行。在執(zhí)行 ldr pc, =main 之前 bl copy_block_to_sdram 把 Nand Flash 里的代碼搬到 SDRAM 里從 0x30000000 處開始的區(qū)域了。而 ldr pc, =main 實(shí)際上執(zhí)行的是:

ldr pc, 0x30000000 + main_addr

這實(shí)際上是跳到 SDRAM 里的 main 處并執(zhí)行 main 調(diào)用

@宗華
編譯 busybox 1.9.2 需要 arm linux 3.3.2 的編譯器, 用 3.3.4 的編譯器會(huì)有問題, 你需要安裝 3.3.2 版本來制作根文件系統(tǒng)

@sinper
呵呵， 多謝指正!

@guest
看了, 內(nèi)核配置應(yīng)該沒有問題, 可能是根文件系統(tǒng)的問題, 你用 busybox 制作的根文件系統(tǒng)有多大? 你先用 skyeye testsuite 里的根文件系統(tǒng)試試， 看能否啟動(dòng)?

@guest
可能是 "Initial RAM disk (initrd) support" 沒有選中，所以根文件系統(tǒng)沒能成功加載。檢查一下你的內(nèi)核配置，看看在我這篇博客里用黃色加亮的部分是否被正確配置。或者把你的內(nèi)核配置文件 .config 發(fā)我看看(jbin8164@gmail.com)。

@guest
從上面看不出哪出錯(cuò)了，你的用 skyeye 和 linux 內(nèi)核版本是多少? 內(nèi)核如何配置的?

@silence
我的成功了。可能網(wǎng)卡驅(qū)動(dòng)沒有加載，請用如下命令確認(rèn)一下: dmesg | grep -i 'eth'
看看有沒有 eth0 或 cs8900 之類的字消息，有的話，請重新在 skyeye 上運(yùn)行 arm-linux。如果沒有，那就考慮一下如何加載 cs8900 這個(gè)網(wǎng)卡驅(qū)動(dòng)。

@補(bǔ)考少年
模擬正是為了實(shí)踐，這樣修改了內(nèi)核可以在 skyeye 上跑跑， 省得老燒板子了

@FAN
從錯(cuò)誤信息上也看不出什么問題, 我猜測可能是如下兩個(gè)原因:
(1) 你的 arm-linux-gcc 3.4.1 有問題
或者
(2) 編譯時(shí)你用的 arm-linux-gcc 是 3.3.2, 但鏈接時(shí)用的卻是 arm-linux-gcc 3.4.1 的庫(libgcc.a)

@niube's son
呵呵， 一定! 很高興能對大家有點(diǎn)幫助。大家也可把自己用 Ubuntu 時(shí)遇到的困難寫出來，一起解決嘛 :-)

@wz
你說的有道理，只有 subs 才能影響 CPSR 的 N 標(biāo)志位, 看來確實(shí)是我大意了。謝謝指正，以后多交流啊!

@FAN
我沒有試過 #define TXD0_READY 0x4 查了一下手冊，上面這樣描述, 對于 UTRSTA0[2]:

Set to 1 automatically when the transmit buffer register has
no valid data to transmit and the transmit shift register is
empty.
0 = Not empty
1 = Transmitter (transmit buffer & shifter register) empty

我覺得可以，你可以試試，別忘了把結(jié)果告訴我啊 :-)

@FAN
你好，已將代碼發(fā)到你郵箱，有問題及時(shí)討論。

@含著淚的微笑
1. RXD0 和 TXD0 你并看不到，能連線的只有串口。
2. 電阻上拉，我的理解是拉高電壓，使電路更穩(wěn)定。
3. 仔細(xì)閱讀板子附帶的手冊吧，把這個(gè)例子在你的板子上先跑起來

@含著淚的微笑
0x05 代表查詢模式，實(shí)現(xiàn)起來最簡單。

@含著淚的微笑
歸納了你的問題，做答如下:
1. 不一定非得用超級終端, 你也可以自己寫程序。將 PC 的串口和 ARM 開發(fā)板的串口相連后，只要你的程序向 PC 串口發(fā)數(shù)據(jù)， ARM 就能通過連線獲得數(shù)據(jù)。
2. 至于如何標(biāo)識一個(gè)字串結(jié)束， 這是一個(gè)協(xié)議問題，可指定一個(gè)數(shù)，比如 0x55AA，當(dāng)收到的兩個(gè)連續(xù)字符是0x55AA時(shí)，則停止接收。
3. 可先將數(shù)據(jù)存到 SDRAM 緩沖區(qū)，再寫到 Nand Flash。至于如何寫 Nand Flash, 可參考 vivi 的源代碼，里面有一個(gè)向 Nand Flash 寫數(shù)據(jù)的方法。

@含著淚的微笑
這兩個(gè)函數(shù)是如下使用的:
getc() 會(huì)從 UART0 讀取一個(gè)符, 它不管你向 UART0 輸入了什么， 只要有數(shù)據(jù)就讀取, 沒有數(shù)據(jù)就等待。

putc() 會(huì)向 UART0 輸出一個(gè)字符, 上位機(jī)的軟件(如超級終端) 可以顯示它輸出的是什么

我想你的問題是這樣的:
上位機(jī)向 ARM 板子上的 UART0 發(fā)送了一個(gè)串: "hello,2008", ARM 該如何獲取到這個(gè)串, 是這樣吧?
可以這樣解決:

char *buf = (char *)0x30010000;
char *p = buf;
char c = getc();
while (c != 0x0d) {
*p++ = c;
c = getc();
}
*p = '\0';

0x0d 指回車, 意思是當(dāng)接收到回車時(shí)，停止讀取操作。這時(shí) "hello,2008" 已經(jīng)存入緩沖區(qū) buf 里， 你可以再對這個(gè) buf 進(jìn)行操作了。

@FAN
呵呵，談不上指教，只是早點(diǎn)入門而已， 以后有問題多切磋、交流, 這樣大家都能提高的快些!

@wz

呵呵，這個(gè)程序在 FS2410 能跑的。不知有何問題? 還請不吝賜教啊!

@葫蘆瓜
有兩種思路:
(1) 如果你編譯后生成三個(gè)二進(jìn)制程序, 可通過sjf2410 分三次將三個(gè)文件燒入 Nand Flash的不同位置, 具體請看 sjf2410.exe 的用法。
(2) 如果你編譯后只生成一個(gè)二進(jìn)制文件， 即把 boot 、main 、apply 三個(gè)目標(biāo)文件連接成一個(gè)文件，可通過sjf2410 一次燒寫即可。要點(diǎn)是在連接時(shí)指定連接腳本。 連接腳本如下:

SECTIONS {
first 0x00000000 : { boot.o}
second 0x00000000 : AT(4096) { main.o }
third 0x00000000 : AT(8192) { apply.o }
}

然后在連接程序中這樣調(diào)用連接腳本:
arm-linux-ld -Tnand.lds boot.o main.o apply.o -o prog_tmp.o
arm-linux-objcopy -O binary -S prog_tmp.o prog

@niube' son

代碼在我的板子上是沒有問題的, 不知樓上的兄弟是否成功編譯代碼?
另外有幾點(diǎn)說明:
(1) 代碼是直接運(yùn)行在裸板上的， 而非運(yùn)行在 arm-linux 上
(2) 我是借助 FS2410 自帶的sjf2410.exe 燒寫到 Nand Flash 的, 很可能樓上的兄弟沒有燒寫成功

如果能提供更詳細(xì)的信息就好了， 這樣就可以看看到底是哪個(gè)環(huán)節(jié)出錯(cuò)了!

@ggyy

呵呵，問題已經(jīng)解決，一個(gè)低級的錯(cuò)誤，原因如下:
508 + 0x8 即 516， 大于 512, 前面我提到把 Nand flash 的前 512 字節(jié)復(fù)制到 0x33ff0000 處用以設(shè)置高端中斷向量表，這樣當(dāng)發(fā)生 IRQ 中斷時(shí)，程序會(huì)去 0x33ff0000 + 508 + 0x8 處把 0x30004208 裝進(jìn) pc 并進(jìn)行跳轉(zhuǎn)來響應(yīng)中斷，但不幸的是我只復(fù)制了512字節(jié)，所以 IRQ 中斷是不能響應(yīng)的。總結(jié)一下，對比上面提到的兩種設(shè)置中斷跳轉(zhuǎn)指令的方式：

(1)
b reset
NOP
NOP
NOP
NOP
NOP
ldr pc,=handle_irq
NOP

(2)
b reset
NOP
NOP
NOP
NOP
NOP
ldr pc, handle_irq_addr
NOP
handle_irq_addr:
.long handle_irq

第二種方式的好處是顯而易見的，只需要偏移 0x8 就能取到目的地址了;對第一種方式，ARM 要去通過一個(gè)偏移來取到目的地址，具體數(shù)值要看編譯如何設(shè)置了。

@qqwe
可以這樣精簡一下:

putc(ch);
if (ch == 0x0d) putc(0x0a);

0x0d 代表回車
0x0a 代表換行
它們的順序應(yīng)該是先回車再換行

@ngn999
呵呵， 在 Windows 用Emacs也不錯(cuò)， 有個(gè) NtEmacs 就是跑在 windows下的， 在這里可下載到最新的: http://ntemacs.sourceforge.net/