- CoIDE Manual V2.0
- Introduction
- 1. How to Contribute to this Manual
- 2. Getting-Started
- 3. Project-Management
- 4. Component-Workflow
- 5. Create-a-Component
- 6. Maintain-a-Component
- 7. Document-for-Code
- 8. Compiler
CoIDE component workflow
The local component library, Remote component library
The local component library
Repos ├─paulniu │ └─sd.git ├─ahnniu │ ├─fatfs.git │ ├─lcd1602.git │ └─usb.git ├─ anonymous │ ├─ stm32.git └─...
The local component library, is a bunch of git bare warehouse,according to the user name,two layer catalogue of the name of component to organize.
User name needs to be the only one, so is the component in each user name.
The local component library, no rights management,local user / computer users (no matter whether you log in coocox or not )has the absolute right of control on the local component library in principle.
The source of the local component library: he is Remote warehouse's incomplete copy, or is downloaded from Remote warehouse;component submitted to the local computer.
No local login / non network situation is regard as an anonymous user (anonymous)
Remote component library
As same as the local component library,it is also a bunch of git bare warehouse,according to the user name,two layer catalogue of the name of component to organize.
The Remote library has a clear user authentication, and rights management system
+ permissions: can let people who need to access, but reading and writing Remote warehouse are unable to visit without a designated person.Each user, has his own user space in the Remote end, and the absolute control rights in this space.
The Remote library, has the function of fork, equal to put a copy of someone else's warehouse in remote (no write permission) in your space, and can continue to maintain, upgrade, such as paul/sd.git - > ahnniu/sd.git, ahnniu is unable to operate paul's sd component but is able to operate ahnniu/sd.git.
Git's workflow
Centralized workflow
Usually, centralized workflow uses single collaboration model. Warehouse's center server that stores code can accept codes all the developers submitted. All developers are ordinary nodes, as the consumer of the central hub, the usual work is synchronized date with the central warehouse.
Integrated manager workflow
Due to Git's allowance of using multiple remote warehouse, then developers can build their own public warehouse, write data and share with others,at the same time, they also can extract others' updated date from their warehouse.Under this situation, there is usually a blessed repository which represents the official. Developers thus cloned its own public warehouse,and then pushed their own submission to ask upholder of official warehouse to pull, update, and merge it into the main project. Upholder also has a clone warehouse in their local place, he can add in your public warehouse as a remote warehouse, through testing without fault then merges it into the main branch, finally pushes it to the official warehouse.
- the project maintainer can push data to a public repository.
- contributors clone the repository, revise or write new code.
- contributors push data to their own public repository.
- contributors e-mail the maintainers, request to pull the latest revision of its own.
- maintainers in their own local integration manger repository, add the repository of contributors as remote repository, then merge, update and test it.
- maintainers push the merged update into the main repository.
This workflow uses most in GitHub web site. People can copy (i.e., clone fork) a project to their own lists, then let it be their own public repository. Next, submit their own update to the repository, and everyone can see every time update of yours. The main advantages is that you can continue to work at your own rhythm, without waiting for the maintainers to deal with your submitted update. For the maintainers, they can also follow their own rhythm, and come to deal with or accept your contribution at any time.
Application of Git workflow in CooCox component
-Centralized workflow scenarios
+We are a team, we push code together
+ a component of my, joined a very positive contribution, I trust him, release authority, write for him directly
+ Wiki, everyone can write
-Integrated manager workflow
+ a component of others with some problems, does not update, I can do nothing but fork directly then,update and maintain
+ a component of people that the demand is not satisfied, needs to customized it as their own
+When want to contribute some of the code with no authority, this is pull request
component /IDE application norms
directory organization
The following is CoIDE application, a directory tissue sample of component class project
Application Project:
C:.
└─CoIDE Projects
├─Application Projects
│ └─SD_MSC
│ │ README.md
│ │ SD_MSC.proj
│ │
│ ├─App
│ │ App.c
│ │ App2.c
│ │
│ └─Components
│ ├─ahnniu
│ │ ├─SDCard
│ │ └─stm32_cmsis
│ ├─paulniu
│ │ └─FatFs
│ └─tom
│ └─SDFileSys
│ │ README.md
│ │
│ ├─HelloWorld
│ │ ├─HelloWorld2
│ │ └─SDFileSys_RW
│ │ SDFileSys_RW.c
│ │ SDFileSys_RW.proj
│ │
│ ├─SourceCode
│ │ SDFileSys.c
│ │ SDFileSys.h
│ │
│ └─Test
│ └─Suit0
│ SDFileSys_Test0.c
│ SDFileSys_Test0.h
│
Component Project
C:.
└─CoIDE Projects
└─Component Projects
└─SDFileSys
│ SDFileSys.Comp.Proj
│
└─Components
├─ahnniu
│ ├─SDCard
│ └─stm32_cmsis
├─new
│ └─SDFileSys
│ │ README.md
│ │
│ ├─Doc
│ │ └─Reference
│ │ image.jpg
│ │
│ ├─HelloWorld
│ │ ├─HelloWorld2
│ │ └─SDFileSys_RW
│ │ README.md
│ │ SDFileSys_RW.c
│ │ SDFileSys_RW.proj
│ │
│ ├─SourceCode
│ │ SDFileSys.c
│ │ SDFileSys.h
│ │
│ └─Test
│ └─Suit0
│ SDFileSys_Test0.c
│ SDFileSys_Test0.h
| |—— SDFileSys.Comp.Proj
│
└─paulniu
└─FatFs
Several key points:
CoIDE sets the path of default storage project, divides into two categories:
component engineering:
new components also store under the Components directory, just user -- > New
HelloWorld is an independent project, the component file it used will be used multiplex by system
engineering, component and HelloWorld, all have README.md, exist under the corresponding root directory
testing norms
testing framework
testing framework transplants in different platform
using Git Ignore
Generated files of temporary, and so on, need to be neglected automatically
Norm & IDE cooperation, automatic / semi-automatic
Only reach the semi automation or automation, can let norms be the fact, otherwise, it is difficult to ask everyone to follow the paper.
component's life cycle
The reason to create component
When do you need to create a component? What is the influence of creating a component ? What is his results / the output?
Motivation
+When you hope a reusable code can be turned into CoIDE components, and reused in other projects
results
+The results of creating a component is that there is other component in the list of components
Create a component engineering
-Input parameters
+ the component name
+ the path name, used to save the project in the file system
-Output parameters
+ in the specified path, create a git repository (not bare), and some necessary engineering documents
+ component engineering has norms(including directory components, and so on), IDE will be generated in accordance with the norms
Component engineering catalogue organization:
According to the directory norms above.
Create the entrance of component
Click from the menu and toolbar, the purpose is so direct
When browsering component library, one of components class will trigger creating
components writing
Writing may contain several parts:
add dependence
+ I am writing a high-level component, it needs to rely on some of the basements, or drive component * API calls * through compiling, shakedown test
Add testing components automatically, and generate testing frame code
- Subsequently gradual improvement
write your own reusable code
-Write their own documents, README.md
+ IDE generate README.md automatically
Special attention, when adding dependence:
add a dependence, is just adding, not modifying the dependent components, otherwise, a dependent object has changed, the relationship of dependence is also not existing
+ IDE add dependent sequenceClone, checkout (Master) components to the Components directory from the local component library,keep the user / components'structure
add Src directory to the project compilation group
add the necessary include
Components' compilation, debugging
Components engineering, directly integrates automatic testing, through this process, the quality of components can be ensured
Git Commit
When the project can be compiled, you can commit
Publish to the local
This process, is mainly for making the component place into the list of components, thus, the subsequent other projects, can be imported to components through the way of importing directly.
The input parameters of Publish:
component's owner
+Currently login user name, if not login,you can prompt the user to login, otherwise anymous user will be used
Name of component
- were specified, but the user can modify it
Component's Category
peripheral Library
Driver
if it is Driver, entrance needs to be provided,
if it is Driver, entrance needs to be provided to choice what kind of Driver chip it support. Note: only an Driver chip can be chose, Driver chip here is a general term and will be refined in the document of Driver chip
Middleware
From Publish to server
When Publish is completed to the local, there should have a further tips: whether to publish on the CooCox, several benefits:
cloud storage, cloud synchronization
many people can collaborate
...
Add Hello World for components
entrance
In the components page, Hello World, users should specify the name of Hello World. Note: whether have the same name with the previous Hello World or not
Process of IDE
when does Hardware platform specify?
Step 1 Clone component to a user directory, containing components that it dependents on, according to the directory structure of Components
Step 2 Under the Hello World directory of component, create a project.
Step 3 README.md and a.C file automatically generate by the project are edited by the user
Step 4 compilation, debugging
Step 5 Git commit only when the compiling is passed can commit
Step 6 Push to the distal end (divide into local and server)
modification of component
The component's creation in the same group, just one point:
If the author of the component is the logged in user, then the position of this componen cloned is unchanged, copy remains: (Componnets/tom/sd), if the author and the current user are not the same person, then clone it to the space of user who currently logged in, it's similar to the fork, Publish (effects: create in the position of distal end )
Modification of Hello World
To create, you should clone first, then open the Hello world project, finally, commit, push, and check whether the owner is the current user