通過Open Project，選擇以.uvproj為后綴的文件，打開，即可轉換MDK工程為CoIDE工程。
現在這個功能還有一些限制，比如只支持一種配置模式，只能打開在MDK下打開過的工程（編譯需要.dep文件），涉及到編譯器的文件需要用戶手動修改（MDK和CoIDE的編譯器不同，與編譯器相關的文件在轉換時沒有被拷貝）等。
但這只是一個嘗試和開始，我們可以期待這個功能將來越做越好。如果用戶在使用中有任何問題和建議，歡迎聯系CooCox！
4. 關于RAM調試
CoIDE 1.3.0在build.xml文件中增加了Flash調試和RAM調試的選項。
Flash調試是默認的，RAM調試則還需一些額外的設置。不同芯片設置方法也可能不同。
例如：
1）STM32F10X系列芯片
在cmsis_boot文件夾，system_stm32f10x.c文件，SystemInit()函數中，有這樣的語句
#ifdef VECT_TAB_SRAM
SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM. */
#else
SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH. */
#endif
所以只需打開build.xml文件，選擇Debug in RAM，并在Defined Symbols中添加VECT_TAB_SRAM宏即可。
2）LPC17xx系列芯片
在cmsis_boot文件夾，system_LPC17xx.c文件，SystemInit()函數中，有這樣的語句
#if (__RAM_MODE__==1)
SCB->VTOR= 0x10000000 & 0x3FFFFF80;
#else
SCB->VTOR= 0x00000000 & 0x3FFFFF80;
#endif
所以只需選擇Debug in RAM，并在system_LPC17xx.c文件中加入語句#define
__RAM_MODE__ 1即可。
3）找不到如1）2）中語句的芯片如LM3S系列
選擇Debug in RAM后，在cmsis_boot文件夾，system_lm3s.c文件，SystemInit()函數中，添加語句
SCB->VTOR = 0x20000000 | 0x0; /* Vector Table Relocation in Internal SRAM. */
由于VTOR定義在core_cm3.h文件中，還需添加頭文件包含語句#include "core_cm3.h"。
CoIDE 1.3.0在線用戶手冊英文版已更新，點此查看。 中文版用戶手冊及PDF版用戶手冊也即將更新，敬請關注。
作者: Chocore 時間: 2011-9-21 16:52
標題: 【重要說明之二】CoIDE 1.3.0的J-link Edit Scripts，Other-adapter，及Include Paths
1.關于J-link Edit Scripts & Other-adapter
CoIDE 1.3.0中，J-link的調試啟動腳本（包括復位方式，是否運行到main）已經固化到代碼里了，所以腳本編輯框是空的，用戶編輯腳本時只需填充GDB設置腳本。
CoIDE 1.3.0移除了調試配置中的Other-adapter項。該項是參照J-link的配置設置的，如果有需要，用戶可以將J-link項當做Other-adpter項使用。
例如有用戶用Other-adpter實現了在CoIDE中使用LPC-link（LPCXpresso），詳情見http://www.coocox.org/Forum/topic.php?id=741
2. 關于Include Paths
有用戶反饋如果Include Paths中的文件不在工程目錄下，則手動添加的包含路徑就不能保存。這是一個BUG。
避免這一BUG的方法是使用Add Linked File / Add Linked Folder功能（工程名處點擊右鍵，或點擊菜單欄的File），把想參與編譯的文件或文件夾鏈接進來就行。
還有用戶反饋，Build工程時，工程文件夾中的源文件會全部自動編譯鏈接，從而出錯。
下一版本的CoIDE會修復這兩個BUG，并添加從工程中移除文件但不刪除文件的功能。
有用戶對CooCox提出了Wishlist，你是不是也和他有類似的想法呢？歡迎提出你的問題或建議！
你還可以加入CooCox工具群167693982 / CoOS群77814606參與交流討論。
PS:最新消息，CoIDE用戶手冊在線版已全部更新~
作者: tlk632 時間: 2011-9-24 23:41
沒用過，嘗試一下
作者: Chocore 時間: 2011-9-28 18:54
標題: 【總要有個規范才放心】開源許可證GPL、BSD、MIT、Mozilla、Apache和LGPL的區別
如先前所說，CooCox工具均是免費的，其中開源的有CoOS和Colink / CoLinkEx硬件電路。
“免費”和“開源”這樣的詞，總會讓人既躍躍欲試，又有所顧慮：真的可以隨意用？后續會不會有什么麻煩？商用也行嗎？
為了讓用戶完全放心，CooCox將規范用戶協議。新的協議即將發布，原始協議見http://www.coocox.com/CN/policy.htm
下面這篇文章轉載自CooCox新浪官博。
因CooCox用戶數及影響力越來越大，CooCox團隊也逐漸提高了對軟件及代碼協議的重視。在收集整理的過程中，一些歸納好的信息和大家分享一下。
首先借用有心人士的一張相當直觀清晰的圖來劃分各種協議：
以下是上述協議的簡單介紹。
BSD開源協議
BSD開源協議是一個給予使用者很大自由的協議。基本上使用者可以“為所欲為”，可以自由的使用、修改源代碼，也可以將修改后的代碼作為開源或者專有軟件再發布。
但“為所欲為”的前提當你發布使用了BSD協議的代碼，或則以BSD協議代碼為基礎做二次開發自己的產品時，需要滿足三個條件：
1. 如果再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSD協議。
2. 如果再發布的只是二進制類庫/軟件，則需要在類庫/軟件的文檔和版權聲明中包含原來代碼中的BSD協議。
3. 不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。
BSD協議鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD由于允許使用者修改和重新發布代碼，也允許使用或在BSD代碼上開發商業軟件發布和銷售，因此是對商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議，因為可以完全控制這些第三方的代碼，在必要的時候可以修改或者二次開發。
Apache License 2.0
Apache License是著名的非盈利開源組織Apache采用的協議。該協議和BSD類似，同樣鼓勵代碼共享和尊重原作者的著作權，同樣允許代碼修改，再發布（作為開源或商業軟件）。需要滿足的條件也和BSD類似：
1. 需要給代碼的用戶一份Apache License。
2. 如果你修改了代碼，需要再被修改的文件中說明。
3. 在延伸的代碼中（修改和有源代碼衍生的代碼中）需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明。
4. 如果再發布的產品中包含一個Notice文件，則在Notice文件中需要帶有Apache License。你可以在Notice中增加自己的許可，但不可以表現為對Apache License構成更改。
Apache License也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要并作為開源或商業產品發布/銷售。
GPL
我們很熟悉的Linux就是采用了GPL、GPL協議和BSD， Apache License等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用，但不允許修改后和衍生的代碼做為閉源的商業軟件發布和銷售。這也就是為什么我們能用免費的各種linux，包括商業公司的linux和linux上各種各樣的由個人，組織，以及商業軟件公司開發的免費軟件了。
GPL協議的主要內容是只要在一個軟件中使用（“使用”指類庫引用，修改后的代碼或者衍生代碼）GPL 協議的產品，則該軟件產品必須也采用GPL協議，既必須也是開源和免費。這就是所謂的“傳染性”。GPL協議的產品作為一個單獨的產品使用沒有任何問題，還可以享受免費的優勢。
由于GPL嚴格要求使用了GPL類庫的軟件產品必須使用GPL協議，對于使用GPL協議的開源代碼，商業軟件或者對代碼有保密要求的部門就不適合集成/采用作為類庫和二次開發的基礎。
其它細節如再發布的時候需要伴隨GPL協議等和BSD/Apache等類似。
LGPL
LGPL是GPL的一個為主要為類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的軟件必須采用GPL協議不同。LGPL 允許商業軟件通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟件的代碼。這使得采用LGPL協議的開源代碼可以被商業軟件作為類庫引用并發布和銷售。
但是如果修改LGPL協議的代碼或者衍生，則所有修改的代碼，涉及修改部分的額外代碼和衍生的代碼都必須采用LGPL協議。因此LGPL協議的開源代碼很適合作為第三方類庫被商業軟件引用，但不適合希望以LGPL協議代碼為基礎，通過修改和衍生的方式做二次開發的商業軟件采用。
GPL/LGPL都保障原作者的知識產權，避免有人利用開源代碼復制并開發類似的產品。
MIT
MIT是和BSD一樣寬泛的許可協議，作者只想保留版權，而無任何其他了限制。也就是說，你必須在你的發行版里包含原許可協議的聲明，無論你是以二進制發布的還是以源代碼發布的。
MPL
MPL是The Mozilla Public License的簡寫，是1998年初Netscape的 Mozilla小組為其開源軟件項目設計的軟件許可證。MPL許可證出現的最重要原因就是，Netscape公司認為GPL許可證沒有很好地平衡開發者對源代碼的需求和他們利用源代碼獲得的利益。同著名的GPL許可證和BSD許可證相比，MPL在許多權利與義務的約定方面與它們相同（因為都是符合OSIA 認定的開源軟件許可證）。但是，相比而言MPL還有以下幾個顯著的不同之處：
◆ MPL雖然要求對于經MPL許可證發布的源代碼的修改也要以MPL許可證的方式再許可出來，以保證其他人可以在MPL的條款下共享源代碼。但是，在MPL 許可證中對“發布”的定義是“以源代碼方式發布的文件”，這就意味著MPL允許一個企業在自己已有的源代碼庫上加一個接口，除了接口程序的源代碼以MPL 許可證的形式對外許可外，源代碼庫中的源代碼就可以不用MPL許可證的方式強制對外許可。這些，就為借鑒別人的源代碼用做自己商業軟件開發的行為留了一個豁口。
◆ MPL許可證第三條第7款中允許被許可人將經過MPL許可證獲得的源代碼同自己其他類型的代碼混合得到自己的軟件程序。
◆ 對軟件專利的態度，MPL許可證不像GPL許可證那樣明確表示反對軟件專利，但是卻明確要求源代碼的提供者不能提供已經受專利保護的源代碼（除非他本人是專利權人，并書面向公眾免費許可這些源代碼），也不能在將這些源代碼以開放源代碼許可證形式許可后再去申請與這些源代碼有關的專利。
◆ 對源代碼的定義
而在MPL（1.1版本）許可證中，對源代碼的定義是：“源代碼指的是對作品進行修改最優先擇取的形式，它包括:所有模塊的所有源程序，加上有關的接口的定義，加上控制可執行作品的安裝和編譯的‘原本’（原文為‘Script’），或者不是與初始源代碼顯著不同的源代碼就是被源代碼貢獻者選擇的從公共領域可以得到的程序代碼。”
◆ MPL許可證第3條有專門的一款是關于對源代碼修改進行描述的規定，就是要求所有再發布者都得有一個專門的文件就對源代碼程序修改的時間和修改的方式有描述。
英文原文：http://www.mozilla.org/MPL/MPL-1.1.html
作者: Chocore 時間: 2011-10-13 15:59
標題: 【學習筆記之Semihosting】CoIDE 1.3.1即將發布，新增支持Semihosting功能
CooCox將于下周發布CoIDE 1.3.1，除修復之前提過的部分BUG外，還將增加Semihosting等功能。
Ps：CoIDE中新唐庫已升級到最新版，新唐組件也已更新。點擊組件頁右上角刷新按鈕，有更新的組件右側會顯示Update，點擊即可更新。
下面是Semihosting學習筆記。
1、ARM公司對Semihosting的中文解釋是半主機機制。為什么叫半主機呢？主要是指應用程序的代碼運行在目標系統上，當需要類似PC平臺下的控制臺輸入輸出時，會調用Semihosting去利用PC上的控制臺輸入輸出設備：如打開關閉文件，PC顯示器輸出，鍵盤輸入等等。
2、Semihosting在ADS1.2的開發環境下，只能在以下調試代理上運行，ARMulator, RealMonitor, Multi-ICE以及Angle。這就是為什么周工的EasyJTAG不支持Semihosting的原理，因為它不屬于上述四種調試代理中的任何一種。
3、Semihosting是一段功能代碼，這段功能代碼主要運行在PC上，并由調試工具上的固件來激活調用。而周工的EasyJTAG沒有實現這個激活調用功能。
4、對于開發用戶來說，Semihosting是目標系統通過調用SWI
0x123456或 SWI 0xAB來調用的。前者ARM狀態下的專用操作號，后者是THUMB狀態的專用操作號。當開發者的軟硬件調試工具配置正確時，可以正確執行Semihosting功能。打個比方說，你在ARMulator下仿真指令
MOV
R1， 0x18
SWI
0x123456
ARMulator會正確終止你的程序執行。
而在EasyJTAG下仿真時，卻會跳入0x08的異常向量入口處。
Semihosting主要是針對I/O操作的，在嵌入式開發過程當中，通過Semihosting，可以把輸入輸出定向到HOST上，利用HOST的輸入和輸出。
從用戶的角度來看，printf好像和普通的一樣，關鍵的區別在于printf的實現。一般的調試器都提供兩個版本的IO庫，一個式標準的庫，另外一個是支持Semihosting的庫。其實現有區別。下面以printf舉例說明其原理：
支持Semihosting的printf的實現和標準的printf不同，支持Semihosting的printf用SWI指令來通知仿真器。仿真器在地址0x8處設置斷點，但SWI指令執行后，仿真器可以捕獲到該SWI指令。根據SWI的number來判斷這個SWI是不是Semihosting請求，如果是，再根據具體的Semihosting number響應用戶的Semihosting請求，完成用戶的Semihosting請求后，返回到SWI的后面一條指令，繼續執行。所以，對用戶來說，這是透明的。
/**********
文檔：《基于ARM的Semihosting的分析與實現》
作者: Chocore 時間: 2011-10-14 17:54
標題: 【再上層樓】CooCox優化了CoX——基于ARM Cortex-M處理器的設備驅動統一接口
9月底，CooCox發布了CoX 2.0.0。
什么是CoX呢？CoX是基于ARM Cortex-M處理器的設備驅動統一接口。從下面這張圖可以直觀地看出使用CoX的好處——方便移植。
另外，要使用CooCox提供的外圍驅動，即Repository頁DRIVER.COX標簽下的組件，也需使用CoX。
CoX 1.0.0是2010年9月發布的，CooCox將它成功地移植到了多種MCU上，如LPC11xx, NUC1xx等等。
雖然CoX 1.0.0實現了外設的通用功能，但它還存在如下缺點：
w 不支持中斷
w API功能不全面。只實現了一些通用功能，沒有充分實現特殊專用芯片的功能。
w 未囊括所有外設。使用某些外設時，用戶需要借助其他廠商庫，從而增大代碼量，甚至出現代碼邏輯沖突。
鑒于此，我們重寫了CoX。我們準備了將近一年的時間，每定義一個接口前都閱讀并比較了數份芯片制造商手冊。新版本的CoX不僅解決了上面提到的問題，并且添加了一些新功能。
CoX 2.0.0特征：
w 基于BSD協議，免費&開源
w 統一標準的外設接口（功能，中斷……），包含強制和非強制接口，適用范圍更廣
w 滿足不同MCU私有特性，實現各類外設全功能API
w 輕量級接口，無損CodeSize和Speed
w 豐富的Doxygen規范幫助文檔，包含電路圖
詳情參見http://www.coocox.org/Cox.html
作者: uzufk 時間: 2011-10-18 22:53
看看這個是什么好東東!
作者: Chocore 時間: 2011-10-29 16:32
標題: 【CoIDE換血升級】支持Semihosting，改版GCC/CoX，支持NUC122&更新芯唐組件及例程
日前，CooCox發布了CoIDE V1.3.1。與1.3.0相比，1.3.1又有哪些進步呢？
1. 支持Semihosting功能
經過簡單三步配置，調試時函數printf()可輸出到Semihosting窗口，直觀方便~
1）在組件頁勾選Semihosting，在調試配置窗口勾選Enable Semihosting
2）在printf.c的Printchar函數中加入SH_SendChar(c);，包含頭文件"semihosting.h”
3）在需要的地方添加printf("Hello world!\n\r");，包含頭文件
Ps: 大部分芯片配置如上所述，少數芯片如Atmel的SAM3U系列配置略有不同，可View Semihosting組件的例程查看說明。
2. 支持NUC122系列芯片，更新了Nuvoton NUC1xx，M051系列的廠商庫組件和例子
CoIDE對芯唐的支持進一步加強。
3. CoX升級為新版本
繼CooCox發布CoX 2.0版本后，基于CoX的組件也將逐步更新。可以看我前一篇帖子對CoX的介紹。
4. GCC編譯器替換為CooCox重編譯版本
如果說編譯器是IDE的血液，那本次CoIDE可謂換血升級了。
隨著CodeSourcery被收購，為避免版權糾紛，GCC版本的替換勢在必行。CooCox重編譯的GCC編譯器經過測試，工作穩定可靠，用戶可放心使用。
除此之外，新版CoIDE還修正了之前提到的Include Paths的BUG。下個月計劃發布的版本將添加選擇工程內參與編譯文件的功能，敬請期待~
欲下載CoIDE或了解更多信息，請訪問http://www.coocox.org/cn/CooCox_CoIDE.html
作者: Chocore 時間: 2011-11-13 20:44
標題: 【管腳配置與代碼自動生成工具】CoSmart升級到1.2.0啦~新唐用戶不可錯過
管腳配置與代碼自動生成工具CooCox CoSmart目前已升級到V1.2.0。
CoSmart V1.2.0增強
-----------------------------
增加：對一些沒有引腳的外設如DMA，RCC等也支持配置功能
增加：支持NUC100，NUC120，NUC130，NUC140及M051系列的芯片
改善：支持保存引腳選擇，模塊配置為cos文件
改善：對耗時較長的操作，顯示進度條
改善：切換芯片或者配置文件后，清空source窗口中顯示的代碼
改善：勾選外設過多時界面較卡的問題
更新：更新NUC1xx系列代碼模板，與Nuvoton的1.05.002 版本的廠商庫同步
CoSmart功能
--------------------
配置管腳復用設置
分析管腳配置沖突
指明I/O引腳特征
生成可用的C代碼
未來CoSmart會逐步添加對ST、NXP等廠商芯片的支持，敬請關注~！
CoSmart更多信息見http://www.coocox.org/CN/CoSmart.html
作者: Chocore 時間: 2011-11-21 11:04
標題: 【開發者總動員】CoX在Github上落戶啦~快加入CoX開源項目，暢享資源&助力開發
之前給大家介紹了CooCox歷時一年的嘔心瀝血之作CoX。
今天要帶來的好消息是CooCox在Github上創建了CoX倉庫，您可以通過Git系統方便地得到CoX相關資源或為CoX的發展出力。CoX的Github主頁：https://github.com/coocox/cox
什么是Github和Git？
Github為使用Git版本控制系統的軟件開發項目提供基于互聯網的主機托管業務。
Git是由Github提供的快速、高效、分布式的版本控制系統，適用于軟件協作開發。
與其他版本控制系統相比，Git的優勢：
1. 直接記錄快照，而非差異比較，十分方便分支及合并
2. 近乎所有操作都是本地執行，無網絡也能提交更新，處理速度飛快
3. 時刻保持數據完整性
4. 多數操作僅添加數據，一旦提交快照后就不用擔心數據丟失
如何貢獻？
CooCox使用集成管理員工具流模式進行開發。
由于 Git 允許使用多個遠程倉庫，開發者便可以建立自己的公共倉庫，往里面寫數據并共享給他人，而同時又可以從別人的倉庫中提取他們的更新過來。這種情形通常都會有個代表著官方發布的項目倉庫（blessed repository），開發者們由此倉庫克隆出一個自己的公共倉庫（developer public），然后將自己的提交推送上去，請求官方倉庫的維護者拉取更新合并到主項目。維護者在自己的本地也有個克隆倉庫（integration manager），他可以將你的公共倉庫作為遠程倉庫添加進來，經過測試無誤后合并到主干分支，然后再推送到官方倉庫。工作流程如下圖：
- 項目維護者可以推送數據到公共倉庫 blessed repository。 2. 貢獻者克隆此倉庫，修訂或編寫新代碼。
- 貢獻者推送數據到自己的公共倉庫 developer public。 4. 貢獻者給維護者發送郵件，請求拉取自己的最新修訂。
- 維護者在自己本地的 integration manger 倉庫中，將貢獻者的倉庫加為遠程倉庫，合并更新并做測試。
- 維護者將合并后的更新推送到主倉庫 blessed repository。
作者: Chocore 時間: 2011-11-24 18:01
標題: 【感恩Day，減負Day】CooCox CoAssistant，讓寄存器信息一目了然~
編程時還在隨時隨地開著User Manual文檔嗎？你out啦！
查個寄存器，還得在一份幾百頁的手冊中前找后找，累不累啊？難得今天感恩節，從現在開始，給自己辛苦操勞的眼睛也減減負吧~
CooCox CoAssistant是一款簡單實用的寄存器助手，專為進行ARM Cortex M3和M0開發的嵌入式軟硬件工程師設計。
推薦理由：
1. 免費輔助工具
CooCox家的系列工具都是免費的（部分工具開源），這個就不多說了。初次聽說的筒子可以查看我以前的帖子或訪問CooCox官網自行了解。
2. 有CoIDE集成版和在線版，雙重選擇
在CoIDE中選擇View > Peripherals 即可打開寄存器助手。
助手詳細介紹及在線版入口，見http://www.coocox.org/CN/CoAssistant.htm
3. 直觀的呈現寄存器細節信息
通過助手，你可以方便地獲取這些信息：
芯片所有寄存器組，寄存器組基地址及描述，寄存器組所有寄存器，單個寄存器的描述信息、訪問類型、偏移值、復位值，及各位域的詳細信息。
單步調試時，值有變化的寄存器還會以醒目的紅色顯示。
4. 支持多種方式修改寄存器值，且修改的值在硬件上實時反應
1）修改寄存器的二進制或十六進制值，各位域值也將快速對應轉換。
例如在調試暫停時，我修改GPIOC_ODR的值0x00000240為0x00000200，反應到硬件上PC6的LED燈熄滅，PC9的LED燈仍亮。
2）對有枚舉類型的位域，可以通過單擊位域or通過位域選項的下拉框，選擇該位域的值
CoAssistant目前支持Nuvoton，Energy Micro，和NXP的大部分芯片，下一版本的CoIDE還將添加對STM32F100系列及LPC11C1x系列芯片的支持，敬請關注~
觀望百次不如動手一試，你還在猶豫什么呢？
作者: chinajiagege 時間: 2011-11-24 20:59
好東西就要支持下哈。
作者: Chocore 時間: 2011-12-5 16:41
標題: 【開發必備】寄存器助手CoAssistant新增支持STM32F10x系列
感恩節給大家介紹了寄存器助手CooCox CoAssistant。
今天要帶來的好消息是——CoAssitant日前更新了Nuvoton的NUC1xx系列寄存器數據，并添加了對STM32F10x系列芯片的支持。
查看CoAssistant目前支持的芯片 或 使用在線版CoAssitant
請訪問：http://www.coocox.org/CN/CoAssistant.htm
作者: jixzang 時間: 2011-12-7 10:53
謝謝樓主分享。
作者: Chocore 時間: 2011-12-10 16:50
標題: 【永不止步】CoFlash支持Mini51及NUC122系列啦~新唐巡回研討會你報名了沒？
CooCox于本周發布了CoFlash V1.4.0。
新版CoFlash添加了對新唐Mini51系列及NUC122系列芯片的支持，具體有：
Mini51LAN, Mini51ZAN, Mini52LAN, Mini52ZAN, Mini54LAN, Mini54ZAN
NUC122LC1AN, NUC122LD2AN, NUC122SC1AN, NUC122SD2AN, NUC122ZC1AN, NUC122ZD2AN
此外，本次發布的CoFlash還進一步改善了Flash燒寫速度，添加了復位模式選擇功能，歡迎體驗~
從雙十二開始，新唐 NuMicro Mini51 技術巡回研討會將陸續于全國十個城市舉辦。會上將贈送CooCox工具組特別制作的光盤和彩頁，CoFans&新唐用戶都不可錯過哦~活動介紹見http://www.nuvoton.com/nuvotonMOSS/event/Mini51/Microsite.aspx。
欲了解CooCox更多信息及動態，請訪問http://www.coocox.org/CN/。
作者: Chocore 時間: 2012-1-4 18:09
標題: 【MDK調試插件】CoMDKPlugin已更新至V1.4.0，CoLinkEx固件及驅動需升級
與CoFlash V1.4.0同時發布的還有MDK調試插件CoMDKPlugin V1.4.0。
新設備支持方面CoMDKPlugin與CoFlash同步，均添加了對如下芯片的支持：
Mini51LAN, Mini51ZAN, Mini52LAN, Mini52ZAN, Mini54LAN, Mini54ZAN
NUC122LC1AN, NUC122LD2AN, NUC122SC1AN, NUC122SD2AN, NUC122ZC1AN, NUC122ZD2AN
CoLinkEx方面，不僅提升了Flash燒寫速度，還新增支持在MDK中的trace功能。
從12月起，所有新版的CooCox軟件，支持下載和調試功能的，都要求CoLinkEx使用新版本的固件和驅動了。
新版的固件和驅動的下載頁面：http://www.coocox.com/CN/Colinkex.htm
固件更新方法如下：
1. 短接JP1。
2. 上電(ColinkEX連接到PC)。
3. 等待PC枚舉出卷標為"CRP2 ENABLD"的可移動磁盤，如果沒有出現，請多按幾次復位鍵(BP1)或重新上電。
4. 把CRP2 DISABLD可移動磁盤中的firmware.bin刪除。
5. 把下載好的CoLinkEx固件復制到此可移動磁盤中。
6. 斷開JP1，重新上電后即可使用
推薦的驅動更新方法如下：
1. 根據使用的Windows系統的版本下載驅動
2. 卸載舊驅動
3. 連上固件更新后的CoLinkEx
4. 安裝新版驅動。
CoLinkEx安裝好后，設備管理器中可以看到CoLinkEx Debug Interface，USB Composite device和一個CooCox 虛擬串口。
作者: Chocore 時間: 2012-1-13 14:56
標題: 【免費驅動源碼】CooCox已實現NUC122外設庫
之前給大家介紹過CooCox專注打造的CoX庫&驅動（見前面的【再上層樓】CooCox優化了CoX——基于ARM Cortex-M處理器的設備驅動統一接口）。
除了GitHub開源項目，正在籌備中的組件平臺也是CooCox提供給開發者的又一大參與渠道。CooCox希望能通過組件平臺簡化開發流程，方便更多開發者的加入。
目前CoX開發的主力還是CooCox工程師。上周，基于NUC122系列的CoX外設庫已經實現。
在CoIDE中刷新NUC122的組件頁，PERIPHERAL.COX分支即為NUC122的通用外設驅動，勾選即可用。
用戶還可以從http://www.coocox.org/COX.html獲取免費驅動源碼及配套文檔。
------------------
如果您有任何CooCox工具相關問題和建議，歡迎到論壇或QQ群提（CooCox工具群167693982，CooCox_CoOS群77814606），在線答疑時間為周一到周五8:30~18:00。
【論壇近期FAQ】
CoIDE如何輸出浮點數
CoIDE如何設置heap size
作者: yang_gh 時間: 2012-1-30 15:50
用用看先
作者: Chocore 時間: 2012-3-18 22:57
標題: 【FAQ】如何在CoIDE中使用C++
CooCox論壇上時不時有人問：CoIDE是否支持C++？
CoIDE默認支持C語言，工程中的*.cpp或*.C（大寫的C，會默認為cpp文件）不參與編譯。這讓不少慣用C++的用戶覺得可惜。
好在這個世界上解決問題的方法永遠比問題多得多，感謝用戶Yury Kuchura的貢獻和分享，現在只需要幾處改動，CoIDE中就能使用C++了。步驟如下：
1. 修改build.xml文件，使*.cpp文件能被編譯
2. 修改link.ld文件，使連接時C++所需的段能被識別
/* Section Definitions */
SECTIONS
{
.text :
{
KEEP(*(.isr_vector .isr_vector.*))
*(.text .text.* .gnu.linkonce.t.*)
*(.glue_7t) *(.glue_7)
*(.rodata .rodata* .gnu.linkonce.r.*)
/* C++ Static constructors/destructors (eabi) */
. = ALIGN(4);
KEEP(*(.init))
. = ALIGN(4);
__preinit_array_start = .;
KEEP (*(.preinit_array))
__preinit_array_end = .;
. = ALIGN(4);
__init_array_start = .;
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array))
__init_array_end = .;
. = ALIGN(4);
KEEP(*(.fini))
. = ALIGN(4);
__fini_array_start = .;
KEEP (*(.fini_array))
KEEP (*(SORT(.fini_array.*)))
__fini_array_end = .;
/* C++ Static constructors/destructors (elf) */
. = ALIGN(4);
_ctor_start = .;
KEEP (*crtbegin.o(.ctors))
KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*crtend.o(.ctors))
_ctor_end = .;
. = ALIGN(4);
KEEP (*crtbegin.o(.dtors))
KEEP (*(EXCLUDE_FILE (*crtend.o) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*crtend.o(.dtors))
} > rom
.ARM.extab :
{
*(.ARM.extab* .gnu.linkonce.armextab.*)
} > rom
…
…
/* stack section */
.co_stack (NOLOAD):
{
. = ALIGN(8);
*(.co_stack .co_stack.*)
} > ram
__exidx_start = .;
.ARM.exidx :
{
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
} > rom
__exidx_end = .;
. = ALIGN(4);
_end = . ;
}
3. 修改啟動代碼，使構造和析構函數能被正確調用
…
extern unsigned long __preinit_array_start;
extern unsigned long __preinit_array_end;
extern unsigned long __init_array_start;
extern unsigned long __init_array_end;
extern unsigned long _ctor_start;
extern unsigned long _ctor_end;
static void call_constructors(unsigned long *start, unsigned long *end) __attribute__((noinline));
static void call_constructors(unsigned long *start, unsigned long *end)
{
unsigned long *i;
void (*funcptr)();
for ( i = start; i < end; i++)
{
funcptr=(void (*)())(*i);
funcptr();
}
}
…
void Default_Reset_Handler(void)
{
…
/* Setup the microcontroller system. */
SystemInit();
//Initialize CoOS (in order the new/delete operators to work properly
//prior to calling constructors). Comment it out if you don't use CoOS!
CoInitOS();
//Call C++ global constructors
call_constructors(&__preinit_array_start, &__preinit_array_end);
call_constructors(&__init_array_start, &__init_array_end);
call_constructors(&_ctor_start, &_ctor_end);
/* Call the application's entry point.*/
main();
}
4. 在組件頁勾選C Library和Retarget printf，之后注釋掉printf.c文件中的如下語句，以避免重定義_impure_ptr
struct _reent *_impure_ptr = &r;
5. 在工程配置（Project configuration）中添加Linked Libraries libstdc++和libsupc++，它們可以從GCC tool chain的庫中找到
來源：
http://www.coocox.org/Forum/topic.php?id=730
http://www.coocox.org/Forum/topic.php?id=873
例程：
103vb_cpp.zip
(220.71 KB)
2012-3-18 22:57 上傳
點擊文件名下載附件
下載積分: 積分 -1
STM32103vb + CoIDE 1.3.1 + 閃燈
說明——因CoIDE 1.4.0存在bug“修改build.xml文件后無法保存”，故使用CoIDE 1.3.1版本。此bug在新版CoIDE中將被修復。
歡迎大家常來CooCox論壇交流討論~
作者: zhengtiantong 時間: 2012-3-30 19:38
很好，很強大
作者: 100home 時間: 2012-4-2 22:26
及時雨
作者: Chocore 時間: 2012-4-10 10:14
標題: 【與時俱進】CoIDE 1.4.1支持Cortex M4和ARM GCC啦
Cortex M4芯片上市以來，論壇上用戶要求CooCox支持M4的呼聲一直很高。經過一段時間的奮戰，在本月最歡樂的日子，CooCox發布了CoIDE 1.4.1版本，滿足了用戶的這一需求^_^
為了盡早支持M4，新版CoIDE沒有移植廠商庫，所以在勾選包含啟動代碼（startup code）的CMSIS BOOT和專用于M4的CMSIS core之后，用戶還需手動從廠商庫添加需要的外設組件。
之后CooCox會逐步添加STM32F4的Peripheral components（外設組件）到Repository View，并添加其他的M4的芯片。目前STM32F4以外的M4芯片用戶可以選擇ARM (Manufacturers) ---> M4 (Chips)進行開發。
M4芯片的FPU配置
編譯M4前，需選擇合適的FPU。工程配置（Project ---> configuration）中提供了三種選擇：無FPU，soft FPU ，hard FPU。默認配置為soft FPU。
選擇使用FPU后，還需在程序中使能FPU模塊，否則程序運行時會進入hardfault錯誤。
將如下代碼添加到啟動代碼（如startup_stm32f4xx.c）的Default_Reset_Handler()函數中，main();之前，使能FPU：
*((volatile unsigned long *) 0xE000ED88) |= (0xF << 20);
或者
__asm(" LDR.W R0, =0xE000ED88\n"
" LDR R1, [R0]\n"
" ORR R1, R1, #(0xF << 20)\n"
" STR R1, [R0]");
除M4外，CoIDE 1.4.1新增的另一大亮點是對ARM GCC的支持。
ARM GCC是ARM官方新近推出的GCC編譯器，功能強大，推薦用戶使用。
編譯器設置方法：http://www.coocox.org/cn/CoIDE/Compiler_Settings.html
Colink和CoLinkEx調試器已支持STM32F4系列芯片，支持M4的CoFlash和MDK插件也即將發布，敬請關注~
作者: james_138139 時間: 2012-8-9 21:46
盡管用不到，還是要支持以下
作者: lsx435372 時間: 2012-10-10 18:20
看這樣不錯啊
作者: jixzang 時間: 2012-10-23 14:41
不錯，謝謝樓主
作者: caipeng521 時間: 2012-12-7 07:56
作者: guluguluchui 時間: 2012-12-7 21:23
Coos 很好用 ，頂
作者: UltraBird 時間: 2012-12-11 23:50
不懂
作者: david-xia 時間: 2013-1-6 09:42
頂。。。。。。。。。。。。。。
作者: taxuelangzi110 時間: 2013-1-9 19:09
標記一個，呵呵。。
作者: loikey 時間: 2013-1-11 16:19
感覺很好用，試試看
作者: yxd201971 時間: 2013-1-17 10:48
了解一下
作者: jh_wang 時間: 2014-9-12 08:33
路過 看看
| 歡迎光臨 電子工程網 (http://m.qingdxww.cn/) |
Powered by Discuz! X3.4 |
主站蜘蛛池模板：
国产成人福利在线视频播放尤物
|
青在线视频
|
手机在线播放av
|
国产成人三级视频在线观看播放
|
国产手机国产手机在线
|
国产精品福利在线
|
国产成人精品免费影视大全
|
两个人日本免费完整版在线观看1
|
91青青草原|
青青青视频免费
|
丁香婷婷久久
|
日韩毛片基地
|
日韩一级一欧美一级国产
|
五月天久久婷婷
|
一级欧美一级日韩
|
四虎永久免费地址在线网站
|
99爱在线视频
|
日本黄色app|
国产精品免费精品自在线观看
|
亚洲一区二区观看
|
伊人狼人在线
|
4hc44四虎www在线观看
|
99精品国产高清一区二区麻豆
|
爱福利视频网
|
国产三级日产三级
|
欧美精品成人一区二区视频一
|
国产a国产片国产
|
亚洲片在线观看
|
99爱视频免费高清在线观看
|
男男羞羞视频网站免费
|
岛田阳子五十路在线观看
|
99这里|
日韩第四页
|
欧美人与动交片免费播放
|
国产蝌蚪
|
亚洲精品tv久久久久久久久久
|
国产三级高清
|
精品精品国产yyy5857香蕉
|
亚洲一区二区精品视频
|
国产日产欧产麻豆精品精品推荐
|
99精品国产免费久久国语
|
CoCenter-1.4.3.rar
(1.07 MB)
