OrgApache/incubator-nuttx
OrgApache
/
incubator-nuttx
mirror of https://github.com/apache/incubator-nuttx.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Documentation: Minor improve to improve readability of text.

This commit is contained in:
Gregory Nutt 2018-02-14 14:17:44 -06:00
parent 75ae584922
commit b8a47f9b0f
1 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
Documentation/NuttxPortingGuide.html
View File

@ -1570,7 +1570,7 @@ The specific environmental definitions are unique for each board but should incl
Through these include paths, the NuttX build system also enforces modularity in the design.
For example, one important design principle is architectural <i>layering</i>.
In this case I am referring to the OS as layered into application interface, common internal OS logic, and lower level platform-specific layers.
The platform-specific layers all reside in the either <code>arch/</code> sub-directorories on the <code>config/</code> subdirectories: The former sub-directories are reserved for microcontroller-specific logic and the latter for board-specific logic.
The platform-specific layers all reside in the either <code>arch/</code> sub-directories on the <code>config/</code> subdirectories: The former sub-directories are reserved for microcontroller-specific logic and the latter for board-specific logic.
</p>
<p>
In the strict, layered NuttX architecture, the upper level OS services are always available to platform-specific logic. However, the opposite is <i>not</i> true: Common OS logic must never have any dependency on the lower level platform-specific code. The OS logic must be totally agnostic about its hardware environment. Similarly, microcontroller-specific logic was be completely ignorant of board-specific logic.
@ -1583,8 +1583,10 @@ The specific environmental definitions are unique for each board but should incl
Similarly, the board-specific include directory will be linked at <code>include/arch/board</code> and, hence, can be included like <code>#include &lt;arch/board/board.h</code>.
</p>
<p>
Keeping in the spirit of the layered architecture, this publicly visible header files must <i>not</i> export platform-specific definitions; Only standardized definitions should be visible such as those provided in <code>include/nuttx/arch.h</code> or <code>include/nuttx/board.h</code>.
And, similarly, these publicly visible header file must <i>not</i> include files that reside in the inaccessible platform-specific source directories.
Keeping in the spirit of the layered architecture, these publicly visible header files must <i>not</i> export platform-specific definitions; Only platform-specific realizations of standardized declarations should be visible.
Those <i>standardized declarations</i> should appear in common header files such as those provided by <code>include/nuttx/arch.h</code> and <code>include/nuttx/board.h</code>.
Similarly, these publicly visible header file must <i>not</i> include files that reside in the inaccessible platform-specific source directories.
For example, the board-specific <code>configs/&lt;board&gt;/include/board.h</code> header file must never include microcontroller-specific header files that reside in <code>arch/&lt;arch&gt;/src/</code>.
That practice will cause inclusion failures when the publicly visible file is included in common logic outside of the platform-specific source directories.
</p>
</li>