關於程式部份有一些小小建議與疑問...

发布于 2010-07-06 19:59:31 浏览：4230 订阅该版

小弟不是什麼高手..有些東西有點小小的建議..有說錯的部份煩請各位大大們糾正(請手下留情阿)...^^"小弟目前使用敝公司所新開的一顆ASIC chip核心是ARM9, 亦剛porting完FreeRTOS, 已可正常工作..由於看到RT-Thread對於許多週邊的支持, 及許多強大的特性, 所以捨棄FreeRTOS改用RT-Thread..目前在porting RT-Thread有遇到一些問題並且有一些小小的建議, 如下...

1. 程式內有許多的函式與全域變數使用extern,  從程式的封裝特性來看, 會導致許多library無法重用(re-use), 而且許多私有函式如果沒有宣告成static, 任何程式都可以用extern去調用, 這就破壞了封裝特性(這部份不曉得大大們有沒有不同的看法)...

2. 接續第一點, 在bsp及libcpu資料夾裏, 許多檔案都只有.c檔沒有.h檔, 其他程式在呼叫時都必須使用extern, 且相關define設在.c檔裡, 如果有其他程式需要用到這個define, 可能需要把define移到其他公用的.h檔, 或是自己建立一個.h檔...小弟在想是否.c檔各自加入對應的.h檔會比較好..可以放一些公用define和函式來做一個對外界面的封裝, 而不是用extern, 包含全域變數的部分是否也可用函式來傳出指標就好, 而不用extern, 達到一個完整的介面封裝...

3. 目前小弟的初步理解, 似乎與OS相關的硬體porting部分, 大都是rthw.h裡面的函式, 這部份似乎分散在各個檔案, 是否可開設一個如porting 的資料夾, 或是將與OS相關的porting部份改成只使用一個如port.c或rthw.c檔...對於所需porting的函式也改成使用mount的方式(函式指標), 這樣可以將library與porting 部分分隔開來, 不必將porting的部分寫到library中(破壞library的封裝, 且library的module name通常不會是"rt_hw_"為開頭)...

4. src資料夾內的timer.c 這個檔案..可能只是一個小小的問題...因為小弟亦有一個叫timer.c的library用來做一些timer相關的硬體設定, 目前是把自己的timer.c改名><"...小弟在想關於系統核心的檔名, 是否加些前綴會不會比較不會有檔案衝突, 因為很多平台的library都會有類似像timer.c這樣的檔名(當然最簡單的做法就是把自己平台的library改名><")...

5. startup.c裡面有一個如下的heap初始化..
rt_system_heap_init((void*)&Image$$ER_ZI$$ZI$$Limit, (void*)0x34000000);
第2個參數是一個"magic number", 想說會不會改成用define或者用一些其他方式來處理比較好(小弟也不知道用什麼方式比較好><")...因為看到這個常數有點不太了解意思(目前是把他設在SDRAM的最後一個位址)...

6. 對於"rt_hw_"這個函式的前綴名...一直覺得有點困惑, 看起來像是跟OS相關的硬體部分...但似乎並非所有這個前綴名的函式都跟OS相關, 可能只是單純的硬體部分(例如board.c裡的一些init)...想說是否可以跟OS相關的才用這些前綴名...

總結: 小弟覺得RT-Thread真的是一個很好的東西, 只是在porting一個新的平台, 似乎還沒那麼friendly, 以上是小弟的一些淺見, 在此還是感謝各位大大做出這麼好的東西^^...

5 个回答

bernard 2010-07-06

这家伙很懒，什么也没写！

谢谢你的建议，你是来自大陆对岸？都是繁体字啊，我的意见如下：

>小弟不是什麼高手..有些東西有點小小的建議..有說錯的部份煩請各位大大們糾正(請手下留情阿)...^^"小弟目前使用敝公司所新開的一顆ASIC chip核心是ARM9, 亦剛porting完FreeRTOS, 已可正常工作..由於看到RT-Thread對於許多週邊的支持, 及許多強大的特性, 所以捨棄FreeRTOS改用RT-Thread..目前在porting RT-Thread有遇到一些問題並且有一些小小的建議, 如下...
>
>1. 程式內有許多的函式與全域變數使用extern,  從程式的封裝特性來看, 會導致許多library無法重用(re-use), 而且許多私有函式如果沒有宣告成static, 任何程式都可以用extern去調用, 這就破壞了封裝特性(這部份不曉得大大們有沒有不同的看法)...

---

在编写RT-Thread Kernel的时候，希望头文件能够少一些，这样API等也就相对集中一些，包含的路径也相应的少。所以采用了类似目前这样的风格：
rtdef.h -- 和定义相关的声明。
rthw.h -- 和硬件相关的声明。
rtthread.h -- 常规的RT-Thread API声明。

而在这之外，文件与文件之间无疑会交叉的用到一些变量、函数，而又不希望这部分变量出现在头文件中（头文件往往是提供给用户做为API来使用），所以采用了目前extern变量的形式。而如果变量或函数仅局限于一个文件内部使用的，都尽量的采用static的声明方式。为了避免一些名称的冲突，所以名称上都取了rt_的前缀。

>2. 接續第一點, 在bsp及libcpu資料夾裏, 許多檔案都只有.c檔沒有.h檔, 其他程式在呼叫時都必須使用extern, 且相關define設在.c檔裡, 如果有其他程式需要用到這個define, 可能需要把define移到其他公用的.h檔, 或是自己建立一個.h檔...小弟在想是否.c檔各自加入對應的.h檔會比較好..可以放一些公用define和函式來做一個對外界面的封裝, 而不是用extern, 包含全域變數的部分是否也可用函式來傳出指標就好, 而不用extern, 達到一個完整的介面封裝...

---

是的，libcpu这部分大多是rthw.h中声明的实现。和上面相同的道理，这里本来还是希望头文件能够尽量少一些，所以就不再安排新的头文件了，或这些新的头文件仅会被当前目录中的文件做
#include "xxx"
包含。

>3. 目前小弟的初步理解, 似乎與OS相關的硬體porting部分, 大都是rthw.h裡面的函式, 這部份似乎分散在各個檔案, 是否可開設一個如porting 的資料夾, 或是將與OS相關的porting部份改成只使用一個如port.c或rthw.c檔...對於所需porting的函式也改成使用mount的方式(函式指標), 這樣可以將library與porting 部分分隔開來, 不必將porting的部分寫到library中(破壞library的封裝, 且library的module name通常不會是"rt_hw_"為開頭)...

---

使用更简化的porting方式也是一个趋势，从历史来看，应该会稍微看得出来，这个目录下的文件安排和u-boot中的很想像。但是发展到现在，RT-Thread不再仅仅局限于此，所以以后这块也尽量朝简化的方向发展。

另外，对于你说的“改成使用mount的方式”，这个还不是太明白，可能是文化的差异，能否继续描述下？难道指的是，一个系统能够包括多份移植？

>4. src資料夾內的timer.c 這個檔案..可能只是一個小小的問題...因為小弟亦有一個叫timer.c的library用來做一些timer相關的硬體設定, 目前是把自己的timer.c改名><"...小弟在想關於系統核心的檔名, 是否加些前綴會不會比較不會有檔案衝突, 因為很多平台的library都會有類似像timer.c這樣的檔名(當然最簡單的做法就是把自己平台的library改名><")...

---

是的，关于重命名的问题没有比较好的解决办法，一种可能是把它编译成静态库，或者使用RT-Thread提倡的scons building环境。

>5. startup.c裡面有一個如下的heap初始化..
>rt_system_heap_init((void*)&Image$$ER_ZI$$ZI$$Limit, (void*)0x34000000);
>第2個參數是一個"magic number", 想說會不會改成用define或者用一些其他方式來處理比較好(小弟也不知道用什麼方式比較好><")...因為看到這個常數有點不太了解意思(目前是把他設在SDRAM的最後一個位址)...

---

好的，以后关于这个heap end的问题尽量明确一些。

>6. 對於"rt_hw_"這個函式的前綴名...一直覺得有點困惑, 看起來像是跟OS相關的硬體部分...但似乎並非所有這個前綴名的函式都跟OS相關, 可能只是單純的硬體部分(例如board.c裡的一些init)...想說是否可以跟OS相關的才用這些前綴名...

---

这部分还请详细些列出，原来的考虑是，硬件相关，驱动等都采用rt_hw_的前缀。

>總結: 小弟覺得RT-Thread真的是一個很好的東西, 只是在porting一個新的平台, 似乎還沒那麼friendly, 以上是小弟的一些淺見, 在此還是感謝各位大大做出這麼好的東西^^...

---

感谢你的建议，这个系统在你们那边反响如何呢？以前jserv曾说，[http://blog.linux.org.tw/~jserv/archives/001745.html](“[RT-Thread] 就是一個精巧但完整的 Realtime microkernel”)，后来jserv大大兴趣转向0xlab、Anroid就很少联系了。

bcc6 2010-07-07

这家伙很懒，什么也没写！

非常感謝大大的回覆, 沒錯, 我是對岸的, 哈^^

第1, 2點 大概了解大大的意思了..

第3點  小弟可能說的不是很清楚, mount(掛載)指的是用函式指標, 用interrupt.c舉個例子:
首先將原始的interrupt.c分成幾個部份...

[通用library的部份 - interrupt_hw.c] 
  void interrupt_hardware_init(void) {
     /* 中斷硬體初始化, 不含OS相關程式*/
     ...
  }

[RT-Thread的部份 - interrupt_os.c]
void rt_hw_interrupt_init(void) {
  /* 中斷硬體初始化 */
  os_hw_port->intr_init();
  /* init exceptions table */
  ...
  /* init interrupt nest, and context in thread sp */
  ...
}

[Porting的部份 - port.c]
 struct OS_HW_PORT {
    (void)(*intr_hw_init)(void);
    (void)(*timer_hw_init)(void);
    ...
 } * os_hw_port;
/* 掛載(mount)中斷硬體初始化函式 */
os_hw_port->intr_hw_init = interrupt_hardware_init;

以上是小弟的一個想法, 不一定是最適合的作法, 目的是爲了將OS部份和通用硬體library分隔開來, 交會點則在port.c裡....這樣可以不必將OS所使用的全域變數加到通用硬體library...也不用將原本的函式名改為rt_hw_interrupt_init...對其他平台的移植, 也只是去修改port.c, 掛載對應的函式...

第4點 目前還不明白scons building是什麼樣的東西, 在什麼環境下跑, 這部份會花時間去研究^^"...

第5點 了解

第6點  小弟不是很明白"rt_hw_"這個前綴名, 是只跟"kernel相關"的硬體部分才會加這個前綴名, 或是只要是硬體部分都會加這個前綴名...

其實RTT小弟之前就有看過, 只是看到版本是0.X.0, 怕OS不穩定還不敢用, 所以之前是用FreeRTOS(Linux太大就不考慮了),後來是公司主管看到RTT有很多不錯的功能, 才會想導入RTT來試試...Google了一下, 台灣這邊似乎還沒很多人用RTT, 我想應該是因為跟其他的OS比起來, RTT還算比較新的OS吧...