版主提一個讓大家集思廣義的題目,大家一起來努力 如果寫控制程式像寫delphi這樣,也就是說有oop的關念,程式就容易下手 思考方向: 舉一個8051的範例 如果你要寫一個rs-232全多工通訊程式,不管是組合語言或C語言,都要廢一番工夫 設想若是程式能這樣寫是否容易多了 [CODE] CLOCK EQU 11.0592MHz BAUD_RATE EQU 9600 //這裡就是要集思廣義的程式思考區 //可以寫一個個巨集 //可以......... //應用程式區 //要讀資料就下一個"READ_COM_DATA" //要寫資料就下一個"WRITE_COM_DATA" 來吧大家共同來努力 MYMJ誠誌的邀請

要做到oop應該是蠻困難的啦!! 光是搞個結構變數都一堆麻煩.... 我曾經努力過... 後來我折衷的做法是把每個不同零件都做成獨立的.lib 例如我需要EEPROM 我就把EE24C04.lib or EE93C66.lib 拉進來 要ADC就把ADC拉進來...... 然後為了節省CODE SIZE 再用很多的#if .... 把不同頻率所算出來的sfr填入資料 例如: #define MHZ 12; //編譯器就會依照12M的程式段去編譯 如果填入32 則依32MHZ去編譯 包括RS232也是如此 諸如此類的做法 讓我所有的程式都可共用 ,每個案子只需針對UI.C去做編寫 其餘都用INCLUDE 就可以了 這是我的心得 或許你有更好的方法 也歡迎提出來分享喔 ~ 勿在浮沙上面築高塔 ~

------
~ 勿在浮沙上面築高塔 ~

當然如您所說建立一個個程式庫也是很棒的方法 其實我的目的是希望大家一起共同努力建立一個個共享的巨集,或程式庫 這樣只要花較少時間就可以完成專案 您說是否可行

這個點子有實行上的困難，因為單晶片的電路是高度客製化的，跟硬體有關的程式 必須針對電路特性撰寫，加上單晶片種類很多，彼此指令不見得相容。 在下認為單晶片程式難入手的原因在於硬體(數位邏輯、電子學)的根基不夠，假如硬體已經有不錯的基礎，加上一點程式的經驗，單晶片的程式很容易下手。此外要是你 懂得利用一些儀器來除錯(ex.示波器)，單晶片的程式寫起來更是輕鬆愉快。 而且在下不覺得單晶片程式需要引入OOP，因為單晶片的程式規模比起一般應用程式 規模要小很多，而且常用的語言是ASM C，所以基本的模組化就很夠用了，像是daniel__lee兄的作法就很好。

其實，OO在我個人用了十多年的經驗。它只適合一些很多人共同開發的大案子。 而且。它不把CPU跟記憶體耗用當考量。 如果你了解OO的話。你就會發現在呼叫一個CLASS下的FUNCTION時它會怎麼呼叫。 而當你所呼叫的是一個經過多重繼承的FUNCTION時。你會發現它的組合語言上 會是很多層的CALL存在。 在PC這種機器上。它當然沒問題。 可是到了單晶上呢？ 1.記憶體會不會死在那一點？未知。 2.我的堆疊會不會OVER？未知。 3.我的時序會不會準時？很難。 等等等的問題。 尤其是在使用 51 這種”小”東西時。這種風險更是無法估算。 我個人用C寫單晶的程式。也只在這顆單晶是 32BIT的ARM或MIPS時。 我才會用C來開發。 其它的像 CYPRESS的USB，51.....這些東東。我還是會很老實的用ASM慢慢做。 我也不會打算把我ARM的開發環境由C變成C 因為我知道那樣並不會得到多大的方便性。 反而會產生更大的困擾。 就這樣。個人意見。^_^ http://www.mcu51.com/list.asp?id=1588 想想別人怎麼學，我們有這麼用心嗎？ 憂心啊~~~~~~

也不一定都要用全物件導向來開發,也許可以有一點點的OO概念,而不會造成系統任何多餘的負擔,進而增加整個程式的結構,可讀性 例如:我是把一個.C的檔案當成是一個物件,而物件中的private變數我是用static來宣告,這樣不就有一點點OO的概念?而且也不會增加CPU負擔