面向對象的單片機程序開發平臺
(2011/10/19 9:24:00)
在應用C++Builder和VB寫PC軟件時想到
如果有那么的一個平臺（軟件），他的模式和C++Builder、VB差不多
要單片機實現那個功能，就調用相應的控件，更改控件的屬性就對功能的初始化和操作。
以前用ARM＋Linux構建過，在PC里做了一個平臺，在平臺了里可視化地設計介面和功能，然后以任務的方式下載到ARMLinux里，運行、更改這個任務。這樣，靈活，簡便地在同一平臺快速地開發不同的功能。
歡迎討論
網友評論：所以我現在喜歡用freescale的CPU
網友評論：太好了，作好以后俺菜鳥做個PLC玩玩
網友評論：新華龍的C8051F自帶一個軟件，好象叫個config2什么的了。可以選擇每個型號，然后在調試軟件里選擇配置芯片里自帶資源配置，比如引腳初始化、串口波特率什么的。每當選擇完畢，它就會根據你的配置生成一段代碼。然后你可以COPY到程序中，這個對新接觸這種MCU的人很方便。
現在想一想，新華龍這點做的和VISUAL系列的編程語言有點相似。
網友評論：比如換個MCU，所有都不成立。
網友評論：這個項目想做好非常難，因為編程不是技術活，而是體力活，這么大的程序量不是中國程序員業余時間可以完成的。
老外可以做自己愛做的事，我們卻還要為生存而打拼……
“創意”諸如“選一個串口控件，則自動生成串口模式選擇、波特率等配置”誰都能想到，但是一旦具體開了，I2C呢，SPI呢，沒有的話軟件模擬實現呢……定時器資源太少呢……模型可能很難統一，所以到了最后很可能是每種單片機一類模型（根據具體型號又有所不同），每種類型還需要針對keil，IAR……搞出N個版本……
前段時間裝了個“SUPERPROUSBseries”編程器軟件，很是驚訝它居然占了150M的空間，但是打開它的目錄，看到了數不清的EPROM,MCU,GAI……每個型號一個庫文件……又想想也許真的要占那么大的空間。
OFFICE也是啊，幾百兆的空間看似很臃腫，但是你想要什么它幾乎都能實現；而WPS看似精巧，確只能在網頁里復制文字，連圖片都沒法復制……所以wps可能很適合一部分人，卻遠遠不是office的對手。
網友評論：http://www.cpubbs.com/forum/viewthread.php?tid=53355&extra=page%3D1&frombbs=1
網友評論：和俺想的差得太遠
網友評論：都太初級了
比如換個MCU，所有都不成立。
==================================================
你肯定沒有用過CW的PE:
如果換CPU,那么固定IO的(比如串口,i2c,不變),通用IO和AD自己到菜單選擇.程序不要作修改的.現在還支持8bit升級32bit的CPU(QE128).
估計中國人十年內不可能有這樣的軟件面世.
網友評論：其實我倒是覺得硬件調試是很麻煩的,最耗費時間的.新CPU上手,要看N多E文資料.用CW基本簡單帶過.CW的介紹講用PE可以節約70%的時間.
PE也可以自己擴充的,網上有很多型號的LCD,
DS1302,EEPROM,FLASH....等各種接口的bean,只要下載了,就可以直接調用.水平好的也可以直接編自己的bean.
網友評論：不局限于特定MCU
編程方法一致，使用嵌入裸奔，快速定制程序，立等可取，具備很強的健壯性
包含豐富的硬件庫，從EEPROM到LCD，可以具體到型號
支持軟件擴展包，嵌入數據庫、嵌入GUI、TCP/IP、各種使用協議
大眾維護特性
就EEPROM來說，不僅提供讀寫函數，還提供與之配套的使用緩沖的操作函數，使大眾使用EEPROM可最大效率最可靠完成程序。同時還擴展簡單的數據管理和復雜的數據庫。
LCD也類似，不光有硬件函數，還應該包含系統級別的圖形設計函數，和很多具備前瞻性設計理論掛鉤。
等等，一環環相扣，從硬件到系統。
網友評論：所謂單片機，跨度也挺大的吧
高端的“單片機”，似乎已經很成熟了，所以這里說的應該是低端的吧？
所謂“平臺”，其實包含了兩層含義：
1.約束，也就是框架（Framework），從頂層出發的，例如微軟的MFC，Delphi/BCB的VCL/CLX，首先就是Framework。Framework就是一套游戲規則，規定建筑物應該蓋成什么樣，但不是具體的設計，而是風格和結構形式上的規定，什么明清風格、西洋風格、哥特風格、虹橋、懸索斜拉橋……說到底就是為了盡量去符合軟件工程學里的那些理想。（有一本書說的更宏觀，叫“模式Pattern”）
2.程序庫（Library），具體可能叫例程庫、函數庫、類庫。這是從底層出發的，初級目的是為了減輕程序員的工作量，其次是為了是代碼更簡短清晰，再次是提高代碼質量，最后還是為了與Framework配合。
當然這種劃分是人為的，實際Framework都是包含Library的。
在非常正規的企業里，給員工定一套從軟件工程角度非常完整的開發規則，也可能成為Framework，這完全是靠“紀律”約束的，不易操作。通常Framework離開Library就成了虛的。沒有一套好用的Library支持，別人憑什么遵循你的約束？好多單片機程序員，連個意義準確的符號名都懶得取。
低層次的Library倒是可以不管什么Framework。
不知這里要做的是什么？
要是在低端單片機上做Framework＋Library，可真是了不起的志向。
低端單片機系統的硬件結構個性都太強了，要在這上面做出“共性”，很有挑戰啊。
還有一個問題，就是效率的問題。
以51為例，就說最普通的strcpy之流吧，需要用指針，要通用，就要用3字節的通用指針，代碼實在笨拙。所以我實際開發時一般都是用專用的，XDATA一個，IDATA一個，XDATA和IDATA交互的又是兩個，源代碼很麻煩，但目標碼效率高了。
網友評論：太耗資源，耗不起，只有不缺錢的投資商肯贊助，估計能做成。
網友評論：做過嵌入式開發的朋友應該會深有體會，俺倒想做個通用的ARM開發硬件平臺，大家在上面玩驅動，玩中間件架構，大家才能共鳴。
單片機就選AT91SAM7S64，有了USB接口，再整一個網絡接口，搭好大舞臺，大家來唱戲。
網友評論：FreeScale的開發工具里面有一個ProcessorExpert，就是一個可視化編成工具，他將每個部件叫做一個"Bean"，其實就是C++中的Class，每個對象都有屬性方法事件三個部件卡，自己選擇哪些方法或事件需要生成代碼。比如要用串口，就從CPU資源庫里拖一個UART出來，配置一下波特率緩沖區大小之類的屬性，選擇需要哪些方法，比如字節發送、緩沖區發送、清空緩存等，再選擇需要哪些事件觸發，比如OnReceive,發送結束TxEnd，等等。很爽，開發幾乎不需要碰底層，連寄存器表都不用看，拿來就會用。他生成的代碼非常優秀，我們移植了很多到其他單片機上。
如果連過程也懶得自己動手，還有個可視化的好冬冬，叫VisualState，只要用狀態圖描述你的系統功能，他會自動生成代碼并能進行測試。可惜只支持IAR的開發環境，正在研究怎么玩MSP430可視化開發。
網友評論：好事情!理論上可以為所有的器件，協議，功能等做標準庫，但需要大量的人力，物力。需要相應的組織去維護等等。
網友評論：！！！
網友評論：IAR不也有什么可視化設計嗎？誰用啊！
庫函數倒是確實該讓國人擺脫全手工勞動了。
網友評論：可望而不可及啊!
其實我倒是希望有人能來點現實的,幫助大家"脫貧致富",
比如:SD卡文件系統,TCP/IP網絡協議移植,GUI,中文輸入...等.最好是具體到每個型號的CPU,對應有完整的原程序等.大家不要再去研究移植了,copy一下就能用,或者干脆把庫加進去,源代碼也不要了.
可能我是好吃懶做,只想坐享其成,不過LZ的設想應該就是能讓大家坐享其成的吧.
網友評論：呵呵，沒戲
網友評論：有個問題,假如某個通信協議做成庫,時序什么的都比較好做,但是如果需要個穩定的速率,是否需要調用時鐘,還是關中斷?如果要調用時鐘,是否這個時鐘就被完全調用了(時鐘的復用如何實現)?
一定需要操作系統嗎?
網友評論：http://www.cpubbs.com/forum/viewthread.php?tid=18681&extra=page%3D1
這個和大家說的功能一樣，并且庫和編譯器可以擴展的，只要擴展好，可以支持到任意的CPU芯片！
網友評論：http://www.cpubbs.com/forum/viewthread.php?tid=18681&extra=page%3D1
網友評論：不過是商業性的產品，呵呵，如果是共享版就好了
待本人不愁吃穿的時候，時間多了，俺一定面向開源的方向，組積一個志愿者隊伍，為中國的開源出一分力量
早兩天去了銘源電子搞的沙龍，被他感染了，嘿嘿～～～～～～
網友評論：不是僅僅一個庫，而是包含嵌入規則的庫。
一如赤鑄大俠描述的，佩服佩服。
網友評論：赤鑄一說，頓時整個構思明了了：Framework＋Library
呵呵，能實現，工作量大而已。
網友評論：真的，我覺得這不是個人干的事。必須找商業模式。
Linux的成功，一方面有UNIX的源碼，還有就是有一大批拿高薪卻沒什么事的UNIX管理員為義務勞動群體基礎才發展出來的。
網友評論：
其實微軟一直在開發基于ARM平臺的oop開發環境
不過是給它自己的WINDOWSMOBILE用的
但是這個是趨勢
感覺未來早晚要統一
先頂一個
網友評論：個人觀點：
可視化開發環境倒是次要的，主要的是系統的架構和類庫。
架構要靈活，支持擴充，支持用戶繼承才有類的意義。這點不是很容易實現的
類庫要能夠支持不斷有新的硬件驅動加入，并方便內核調用。
以前在51上面做菜單顯示和鍵盤的時候，參考了MFC的消息機制。有過與樓主類似的想法。
建議LZ在google上見一個PROJECT。方便大家分工。
PC軟件俺只對DELPHI比較熟，需要的話愿意加入。
網友評論：不局限于特定MCU----首先必須要有BSP,板級開發包.
最主要，需要將軟件和硬件操作完全分開，應用程序部分不能對硬件直接操作，必須通過中間層，這樣才能實現移植到不同的CPU,
關鍵是一個問題，這樣一來，必然代碼量會大大增加，需要RAM的量也大大增加，成本？而且調試起來也未必簡單。
至于所長后面的想法，如果有個操作系統，實現起來起不是太容易了？何必自己搞呢？
我想倒不如針對某一個廠家的某一類CPU，做這么個系統，只支持標準的某一類器件，做出函數庫，可以直接調用，至于（LCD也類似，不光有硬件函數，還應該包含系統級別的圖形設計函數）我看還是提供模板吧，并且提供幾個型號的開源代碼，類似驅動程序，用戶可以自行修改！這個可以賣給芯片廠家換錢呀！
網友評論：
對于在應用C++Builder方面我是個菜鳥希望前輩指點迷津！！
百贏商務系統http://www.icwinner.com專業ic管理軟件
相關鏈接:http://www.icwinner.com/index.asp
網友評論：軟件拷貝畢竟比硬件抄板容易多了
所以嵌入式開發也只能靠具體的產品（軟＋硬＋客戶關系）掙錢，做什么通用平臺，注定要餓死，除非已經吃飽了:)
還要搞個硬件抽象層HAL，讓軟件和硬件徹底完全獨立，蒼天哪！
網友評論：不過肯定支持不到8位機。
網友評論：1,失去了使用單片機的意義了.
2,造成大量設計人員下崗.
網友評論：我覺得51的程序本來就不復雜,作arm的怎么樣?
網友評論：嵌入式裸奔，手動切散任務。切的顆粒大小是硬件相關的。標準庫咋通用？
網友評論：到開源社區注冊個項目即可
網友評論：否則哪能做的過來？這么多的8位的cpu？
網友評論：我的QQ:32692180
網友評論：這個想法很好，未必非得用在8位的低端應用
網友評論：真正的核心只有少數人在玩，大多的人就只要移植就可以了。
如果有那么的一個平臺（軟件），他的模式和C++Builder、VB差不多
要單片機實現那個功能，就調用相應的控件，更改控件的屬性就對功能的初始化和操作。
以前用ARM＋Linux構建過，在PC里做了一個平臺，在平臺了里可視化地設計介面和功能，然后以任務的方式下載到ARMLinux里，運行、更改這個任務。這樣，靈活，簡便地在同一平臺快速地開發不同的功能。
歡迎討論
網友評論：所以我現在喜歡用freescale的CPU
網友評論：太好了，作好以后俺菜鳥做個PLC玩玩
網友評論：新華龍的C8051F自帶一個軟件，好象叫個config2什么的了。可以選擇每個型號，然后在調試軟件里選擇配置芯片里自帶資源配置，比如引腳初始化、串口波特率什么的。每當選擇完畢，它就會根據你的配置生成一段代碼。然后你可以COPY到程序中，這個對新接觸這種MCU的人很方便。
現在想一想，新華龍這點做的和VISUAL系列的編程語言有點相似。
網友評論：比如換個MCU，所有都不成立。
網友評論：這個項目想做好非常難，因為編程不是技術活，而是體力活，這么大的程序量不是中國程序員業余時間可以完成的。
老外可以做自己愛做的事，我們卻還要為生存而打拼……
“創意”諸如“選一個串口控件，則自動生成串口模式選擇、波特率等配置”誰都能想到，但是一旦具體開了，I2C呢，SPI呢，沒有的話軟件模擬實現呢……定時器資源太少呢……模型可能很難統一，所以到了最后很可能是每種單片機一類模型（根據具體型號又有所不同），每種類型還需要針對keil，IAR……搞出N個版本……
前段時間裝了個“SUPERPROUSBseries”編程器軟件，很是驚訝它居然占了150M的空間，但是打開它的目錄，看到了數不清的EPROM,MCU,GAI……每個型號一個庫文件……又想想也許真的要占那么大的空間。
OFFICE也是啊，幾百兆的空間看似很臃腫，但是你想要什么它幾乎都能實現；而WPS看似精巧，確只能在網頁里復制文字，連圖片都沒法復制……所以wps可能很適合一部分人，卻遠遠不是office的對手。
網友評論：http://www.cpubbs.com/forum/viewthread.php?tid=53355&extra=page%3D1&frombbs=1
網友評論：和俺想的差得太遠
網友評論：都太初級了
比如換個MCU，所有都不成立。
==================================================
你肯定沒有用過CW的PE:
如果換CPU,那么固定IO的(比如串口,i2c,不變),通用IO和AD自己到菜單選擇.程序不要作修改的.現在還支持8bit升級32bit的CPU(QE128).
估計中國人十年內不可能有這樣的軟件面世.
網友評論：其實我倒是覺得硬件調試是很麻煩的,最耗費時間的.新CPU上手,要看N多E文資料.用CW基本簡單帶過.CW的介紹講用PE可以節約70%的時間.
PE也可以自己擴充的,網上有很多型號的LCD,
DS1302,EEPROM,FLASH....等各種接口的bean,只要下載了,就可以直接調用.水平好的也可以直接編自己的bean.網友評論：不局限于特定MCU
編程方法一致，使用嵌入裸奔，快速定制程序，立等可取，具備很強的健壯性
包含豐富的硬件庫，從EEPROM到LCD，可以具體到型號
支持軟件擴展包，嵌入數據庫、嵌入GUI、TCP/IP、各種使用協議
大眾維護特性
就EEPROM來說，不僅提供讀寫函數，還提供與之配套的使用緩沖的操作函數，使大眾使用EEPROM可最大效率最可靠完成程序。同時還擴展簡單的數據管理和復雜的數據庫。
LCD也類似，不光有硬件函數，還應該包含系統級別的圖形設計函數，和很多具備前瞻性設計理論掛鉤。
等等，一環環相扣，從硬件到系統。
網友評論：所謂單片機，跨度也挺大的吧
高端的“單片機”，似乎已經很成熟了，所以這里說的應該是低端的吧？
所謂“平臺”，其實包含了兩層含義：
1.約束，也就是框架（Framework），從頂層出發的，例如微軟的MFC，Delphi/BCB的VCL/CLX，首先就是Framework。Framework就是一套游戲規則，規定建筑物應該蓋成什么樣，但不是具體的設計，而是風格和結構形式上的規定，什么明清風格、西洋風格、哥特風格、虹橋、懸索斜拉橋……說到底就是為了盡量去符合軟件工程學里的那些理想。（有一本書說的更宏觀，叫“模式Pattern”）
2.程序庫（Library），具體可能叫例程庫、函數庫、類庫。這是從底層出發的，初級目的是為了減輕程序員的工作量，其次是為了是代碼更簡短清晰，再次是提高代碼質量，最后還是為了與Framework配合。
當然這種劃分是人為的，實際Framework都是包含Library的。
在非常正規的企業里，給員工定一套從軟件工程角度非常完整的開發規則，也可能成為Framework，這完全是靠“紀律”約束的，不易操作。通常Framework離開Library就成了虛的。沒有一套好用的Library支持，別人憑什么遵循你的約束？好多單片機程序員，連個意義準確的符號名都懶得取。
低層次的Library倒是可以不管什么Framework。
不知這里要做的是什么？
要是在低端單片機上做Framework＋Library，可真是了不起的志向。
低端單片機系統的硬件結構個性都太強了，要在這上面做出“共性”，很有挑戰啊。
還有一個問題，就是效率的問題。
以51為例，就說最普通的strcpy之流吧，需要用指針，要通用，就要用3字節的通用指針，代碼實在笨拙。所以我實際開發時一般都是用專用的，XDATA一個，IDATA一個，XDATA和IDATA交互的又是兩個，源代碼很麻煩，但目標碼效率高了。
網友評論：太耗資源，耗不起，只有不缺錢的投資商肯贊助，估計能做成。
網友評論：做過嵌入式開發的朋友應該會深有體會，俺倒想做個通用的ARM開發硬件平臺，大家在上面玩驅動，玩中間件架構，大家才能共鳴。
單片機就選AT91SAM7S64，有了USB接口，再整一個網絡接口，搭好大舞臺，大家來唱戲。
網友評論：FreeScale的開發工具里面有一個ProcessorExpert，就是一個可視化編成工具，他將每個部件叫做一個"Bean"，其實就是C++中的Class，每個對象都有屬性方法事件三個部件卡，自己選擇哪些方法或事件需要生成代碼。比如要用串口，就從CPU資源庫里拖一個UART出來，配置一下波特率緩沖區大小之類的屬性，選擇需要哪些方法，比如字節發送、緩沖區發送、清空緩存等，再選擇需要哪些事件觸發，比如OnReceive,發送結束TxEnd，等等。很爽，開發幾乎不需要碰底層，連寄存器表都不用看，拿來就會用。他生成的代碼非常優秀，我們移植了很多到其他單片機上。
如果連過程也懶得自己動手，還有個可視化的好冬冬，叫VisualState，只要用狀態圖描述你的系統功能，他會自動生成代碼并能進行測試。可惜只支持IAR的開發環境，正在研究怎么玩MSP430可視化開發。
網友評論：好事情!理論上可以為所有的器件，協議，功能等做標準庫，但需要大量的人力，物力。需要相應的組織去維護等等。
網友評論：！！！
網友評論：IAR不也有什么可視化設計嗎？誰用啊！
庫函數倒是確實該讓國人擺脫全手工勞動了。
網友評論：可望而不可及啊!
其實我倒是希望有人能來點現實的,幫助大家"脫貧致富",
比如:SD卡文件系統,TCP/IP網絡協議移植,GUI,中文輸入...等.最好是具體到每個型號的CPU,對應有完整的原程序等.大家不要再去研究移植了,copy一下就能用,或者干脆把庫加進去,源代碼也不要了.
可能我是好吃懶做,只想坐享其成,不過LZ的設想應該就是能讓大家坐享其成的吧.
網友評論：呵呵，沒戲
網友評論：有個問題,假如某個通信協議做成庫,時序什么的都比較好做,但是如果需要個穩定的速率,是否需要調用時鐘,還是關中斷?如果要調用時鐘,是否這個時鐘就被完全調用了(時鐘的復用如何實現)?
一定需要操作系統嗎?
網友評論：http://www.cpubbs.com/forum/viewthread.php?tid=18681&extra=page%3D1
這個和大家說的功能一樣，并且庫和編譯器可以擴展的，只要擴展好，可以支持到任意的CPU芯片！
網友評論：http://www.cpubbs.com/forum/viewthread.php?tid=18681&extra=page%3D1
網友評論：不過是商業性的產品，呵呵，如果是共享版就好了
待本人不愁吃穿的時候，時間多了，俺一定面向開源的方向，組積一個志愿者隊伍，為中國的開源出一分力量
早兩天去了銘源電子搞的沙龍，被他感染了，嘿嘿～～～～～～
網友評論：不是僅僅一個庫，而是包含嵌入規則的庫。
一如赤鑄大俠描述的，佩服佩服。
網友評論：赤鑄一說，頓時整個構思明了了：Framework＋Library
呵呵，能實現，工作量大而已。
網友評論：真的，我覺得這不是個人干的事。必須找商業模式。
Linux的成功，一方面有UNIX的源碼，還有就是有一大批拿高薪卻沒什么事的UNIX管理員為義務勞動群體基礎才發展出來的。
網友評論：
其實微軟一直在開發基于ARM平臺的oop開發環境
不過是給它自己的WINDOWSMOBILE用的
但是這個是趨勢
感覺未來早晚要統一
先頂一個
網友評論：個人觀點：
可視化開發環境倒是次要的，主要的是系統的架構和類庫。
架構要靈活，支持擴充，支持用戶繼承才有類的意義。這點不是很容易實現的
類庫要能夠支持不斷有新的硬件驅動加入，并方便內核調用。
以前在51上面做菜單顯示和鍵盤的時候，參考了MFC的消息機制。有過與樓主類似的想法。
建議LZ在google上見一個PROJECT。方便大家分工。
PC軟件俺只對DELPHI比較熟，需要的話愿意加入。
網友評論：不局限于特定MCU----首先必須要有BSP,板級開發包.
最主要，需要將軟件和硬件操作完全分開，應用程序部分不能對硬件直接操作，必須通過中間層，這樣才能實現移植到不同的CPU,
關鍵是一個問題，這樣一來，必然代碼量會大大增加，需要RAM的量也大大增加，成本？而且調試起來也未必簡單。
至于所長后面的想法，如果有個操作系統，實現起來起不是太容易了？何必自己搞呢？
我想倒不如針對某一個廠家的某一類CPU，做這么個系統，只支持標準的某一類器件，做出函數庫，可以直接調用，至于（LCD也類似，不光有硬件函數，還應該包含系統級別的圖形設計函數）我看還是提供模板吧，并且提供幾個型號的開源代碼，類似驅動程序，用戶可以自行修改！這個可以賣給芯片廠家換錢呀！
網友評論：
對于在應用C++Builder方面我是個菜鳥希望前輩指點迷津！！
百贏商務系統http://www.icwinner.com專業ic管理軟件
相關鏈接:http://www.icwinner.com/index.asp
網友評論：軟件拷貝畢竟比硬件抄板容易多了
所以嵌入式開發也只能靠具體的產品（軟＋硬＋客戶關系）掙錢，做什么通用平臺，注定要餓死，除非已經吃飽了:)
還要搞個硬件抽象層HAL，讓軟件和硬件徹底完全獨立，蒼天哪！
網友評論：不過肯定支持不到8位機。
網友評論：1,失去了使用單片機的意義了.
2,造成大量設計人員下崗.
網友評論：我覺得51的程序本來就不復雜,作arm的怎么樣?
網友評論：嵌入式裸奔，手動切散任務。切的顆粒大小是硬件相關的。標準庫咋通用？
網友評論：到開源社區注冊個項目即可
網友評論：否則哪能做的過來？這么多的8位的cpu？
網友評論：我的QQ:32692180
網友評論：這個想法很好，未必非得用在8位的低端應用
網友評論：真正的核心只有少數人在玩，大多的人就只要移植就可以了。
瀏覽：(716)| 評論(
0
)
- 下一篇： 單片機如何深入學習
