As an embedded developers (microcontroller direction), whether you have such confusion: we needed to use a chip for a project before, because there was little information online, we had to read the data book to develop, it cost a lot of time and energy to finish the driver of this chip. After a long time, this chip needed in our another project, when we found the driver of this chip again, it turned out that we had to spend a lot of time to learn the the meaning of many parameters of this driven and learn how to configure these parameters again, sometimes we even needed to rewrite the drive.
Had we ever thought whether the extra time we spent was necessary ? Can we spend less or even no time, to directly found the drive we developed previously, and use it to our project ? Coocox can tell you that the answer is positive. In order to help resolve the troubles above, coocox put forward the thinking of component development, and formulated a set of corresponding norms. Only we follow this norm to develop drive, could we find that when we develop a driver, basically, we can use it directly next time.
Although the method of component development has many advantages, but we can't avoid to worry: we had accumulated a lot of function module of components, such as drive, algorithm before. If I follow this new thing to arrange, not only the arranging process of component will cost a lot of time, but also it's losing more than gain if my previous projects function unnormal after using the new component.
The new component norm here coocox proposed is fully considered that. If our previous file just used the source file and header files, so the common reference relations are as follows:
The factors have been considered when Coocox is specified the component norms, the new component on its using arranged according to the new component norms is downward compatible. That is, things in the application layer don't need to modify. At the same time, the arranging of new component documentation does a lot to the component upgrade and maintenance.
There are 4 core files in source file that defines the drive in our norms, they are:
Hw_component_driver.h
Component_driver.h
Component_driver.c
Component_driver_config.h.example (driver configuration files in good order are stored in template form)
Previously, the common drive is:
Component_driver.h
Component_driver.c
Why do we need four documents, what about the two more documents, following we will illustrate intensively the reasons why we do it.
First,let's look at the important ideological of driven development summarized by CooCox.
This interface is not chip's "input interface"when we program, but the user's interface. When we finished a drive, we can extract part of macro definitions and interface function that the users need to be concerned when they use, then, put them in the following documents. component_driver.h
When in the practical use, separate the underlying implementation which is needlessis to care about, then, put it into the following documents.
Hw_component_driver.h
Component_driver.c
Later, we just need to add component_driver.h when we use this component.
Now many chips are designed with many interfaces, such as ILI9325, which is the controller of a common driver TFT. It can support 5 interfaces, they are :
I80-system 16-bit interface
I80-system 8-bit interface
Serial Peripheral interface (SPI)
I80-system 18-bit interface
I80-system 9-bit interface
And in a real project we generally only use one of the interface methods. We can put it's functions into reality, but in the practical use, only need to configure it into one of working modes. In order to make it convenient when we use it next time. When develop, we can extract all the useful configuration informations and put them underneath this file.
Component_driver_config.h.example
According to different circuit to select a different configuration template when you need to use it next time, then, you write a new component_driver_config.h configuration file to join the project.