【共享】25,000次下載！免費和開源的ARM Cortex CM3&CM0開發工具

Chocore

與之前約每周一次的更新頻率相比，此次CooCox的更新步伐明顯放慢了。

實際上CoIDE V1.2.6的發布籌備已久，之所以仍未更新，一是我們想將最完善的成果呈現給大家，這就需要全面的測試；二是中途根據用戶的反饋和需求又添加了部分功能，修正了一些BUG，使得新版本更加實用、穩定。好湯還需文火熬，好軟件當然亦需時間的雕琢。讓我們拭目以待吧~

之前曾說過CoIDE V1.2.6已支持ST-Link，這一功能留待新版CoIDE發布才能體驗未免遺憾，便先由CoFlash小試牛刀了。
今天，CooCox發布了CoFlash V1.3.6，新增支持ST-Link，Nu-Link-pro，OpenJTAG三大調試器。此外，之前的算法不支持部分版本的STM32F1xx系列芯片，新版CoFlash修復了這一問題。

CooCox CoFlash是專門用于ARM Cortex-M0&Cortex-M3的獨立編程軟件，用戶可方便的自定義算法以支持暫不支持的芯片。詳情請見http://www.coocox.org/CN/CoFlash_Programmer.htm

推薦一篇博文：《CooCox Tool——硬件開發者的新選擇》

這篇對CooCox工具系列介紹得比較全面，節選3張圖片如下：

  

Chocore

CooCox日前更新了STM32F10x及LPC12xx的組件和例程，其中STM32F10x組件為3.5.0版本，LPC12xx為CoIDE新增支持芯片。用戶可以使用CoIDE進行更新，也可訪問http://www.coocox.org/Vendors.php直接下載。

組件更新方法：點擊CoIDE組件視圖右上角的刷新按鈕，CoIDE會鏈接CooCox服務器刷新組件頁面。刷新完成后，用戶可以在每個有更新的組件后面看到update或download的鏈接，點擊該鏈接即可把更新后的組件下載到本地使用。

例子刷新方法：勾選組件后，在左上角的組件視圖點擊組件名稱，CoIDE會后臺刷新和下載例子，等刷新和下載完成后，再次點擊這個組件名稱可以看到有例子被刷新。

CoIDE在編輯模式和調試模式時的視圖如下所示：



CooCox Tools是一套完整的免費開發工具。它由組態式集成開發環境CoIDE，嵌入式實時多任務操作系統CoOS，調試探測器Colink / CoLinkEx，Flash編程軟件CoFlash，智能管腳配置及代碼自動生成工具CoSmart，以及寄存器助手CoAssistant（在線版/CoIDE集成版）組成。

欲了解CooCox更多信息，請訪問CooCox官網http://www.coocox.org/CN/

Chocore

真的免費，真的開源，真的隨意用！無論商用或教學，均無任何限制！這就是CooCox工具。

詢問CooCox工具是否可以商用的郵件一直存在，也許是大家沒有找到網站中的“使用條款”，也許是“使用條款”說的不夠清晰明確，也可能是用戶還是不放心是不是真的可以不負任何責任地用于商業用途。CooCox使用條款中關于軟件使用是這樣約定的：

軟件的使用

CooCox CoOS是免費和開源的， 它遵從BSD（Berkly Software Distribution）許可，并且在這種許可下，它可以用于商業應用。
CooCox Colink插件，CoSmart，CoIDE，CoBuilder，CoDebugger和CoFlash都是免費不開源的，它們均可以免費下載，安裝和使用于非商業應用或商業應用。


這里需要補充說明的是，所有CooCox軟件均可免費使用，但開源的只包括CoOS和Colink以及CoLinkEx硬件電路。此處免費使用包括商用或教學用，均無需承擔任何責任。也無需向CooCox組織申請。我們歡迎您的使用，歡迎您幫我們一起推廣免費的工具。

另外，CooCox可以向廣大用戶承諾，我們絕對不會“先養羊后宰羊”，我們已申明的免費工具將永久免費，絕對不會等聚集了成熟用戶后轉為收費。因為CooCox是希望聚集越累越多的工程師到這個平臺，大家一同貢獻，分享和交流。等到匯聚的資源不計其數后，嵌入式開發可以變得信手拈來——這就是我們的愿景！

文章來源：CooCox新浪官博



【最新資訊】CoIDE V1.2.6發布進入倒計時啦~

新版CoIDE已進入后期測試階段，將于下周與用戶見面。
經測試用戶反饋的調試相關問題已全部解決，包括J-Link，Colink，CoLinkEx在內的各種調試器均可穩定工作，更新增支持ST-Link。
敬請關注http://www.coocox.org/CN/

Chocore

由于架構調整，新版CoIDE不再以V1.2系列命名，正式步入V1.3.0時代。

CoIDE V1.3.0增強
-------------

增加：支持芯片LPC1200系列，TI部分芯片，NUC130和140部分芯片
增加：LPC1200組件庫及例程
更新：STM32組件和例程
增加：支持新加調試器： Nu-Link-pro，ST-Link，OpenJTAG
增加：支持打開MDK工程
修復：修改Nuvoton芯片名稱
增加：登錄和注銷的功能
增加：顯示當前所選芯片的功能
增加：beforebuild 和afterbuild功能
增加：Flash調試和Ram調試選項
修復：進入調試彈出program is not being run的錯誤
修復：Jlink用不起來的bug
修復：修改SAM3U系列芯片的memory.ld生成有錯誤的bug

詳情請見http://www.coocox.org/CN/CooCox_CoIDE.html

用戶手冊即將同步更新，敬請關注！

yinghuayuan

回復1樓Chocore： 感謝分享

Chocore

1. 關于J-link調試

自CoIDE 1.2.5支持J-link后，很多用戶因為J-link的license和jflash腳本的限制，用不起來，所以CoIDE 1.3.0修改了J-link調試的部分，直接用GDB命令下載代碼到芯片中，而不用JFlash的下載方式，程序在進入調試后自動下載。

也是考慮到license的問題，目前的版本移除了J-link直接下載和擦除的功能，下一版本會考慮重新加上這兩個功能并避開license的限制。

點此了解如何在CoIDE 1.3.0中使用J-link 。

2. 關于Include Paths

CoIDE 1.3.0增加了這個功能：

CoIDE編譯時，會自動搜尋工程下面的文件夾，包括Linked Folder文件夾。如果該文件夾下有.h文件，就自動添加到工程的Include Paths里。

所以之前的工程在CoIDE 1.3.0 中編譯可能出現找不到頭文件的情況。

此時你可以手動添加頭文件路徑到build.xml中的Include Paths，或修改Linked Folder的名字，或修改頭文件包含語句（如將#include “grib/grlib.h”改為#include “grlib.h”）。

由于架構調整，可能需要用戶新建工程，或者重復打開才能使用以前的工程。

3. 關于打開MDK工程

通過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

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

沒用過，嘗試一下

Chocore

如先前所說，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

CooCox將于下周發布CoIDE 1.3.1，除修復之前提過的部分BUG外，還將增加Semihosting等功能。

Ps：CoIDE中新唐庫已升級到最新版，新唐組件也已更新。點擊組件頁右上角刷新按鈕，有更新的組件右側會顯示Update，點擊即可更新。

敬請關注CooCox——免費和開源的ARM Cortex M3&M0開發工具

下面是Semihosting學習筆記。

****************Quoted from http://forum.eepw.com.cn/thread/90669/1****************

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的異常向量入口處。

**********Quoted from http://blog.sina.com.cn/s/blog_6bec9cbc0100mpp3.html***********

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

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

看看這個是什么好東東!

Chocore

日前，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

管腳配置與代碼自動生成工具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

之前給大家介紹了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。

詳情請參見http://www.coocox.org/cox/Cox_Github.html

補充：《Git中文幫助文檔》

Chocore

編程時還在隨時隨地開著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

好東西就要支持下哈。

Chocore

感恩節給大家介紹了寄存器助手CooCox CoAssistant。


今天要帶來的好消息是——CoAssitant日前更新了Nuvoton的NUC1xx系列寄存器數據，并添加了對STM32F10x系列芯片的支持。

查看CoAssistant目前支持的芯片 或 使用在線版CoAssitant
請訪問：http://www.coocox.org/CN/CoAssistant.htm

jixzang

謝謝樓主分享。

Chocore

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/。