mirror of
https://github.com/apache/nuttx.git
synced 2026-08-01 20:28:58 +00:00
0cfa6f1b96
* This completes task list in https://github.com/apache/nuttx/issues/11127. * This preserves selected content from cwiki and moves it to new docs. * Most pages are simple copy-paste with a simple RST formatting updates, with minor updates. * Content update / reorganization will follow later on when needed. * Files added (or updated title from cwiki -> current docs): * Documentation/implementation: * index. * cancellation_points. * Asynchronous vs. Synchronous Context Switches -> context_switches.rst. * ARMv7-M Hardfaults, SVCALL, and Debuggers -> hardfatuls.rst. * chip.h FAQ -> chip_h.rst. * Debug Output (SYSLOG) Issues -> syslog.rst. * Detaching File Descriptors -> file_descriptors.rst. * device_nodes.rst. * Dynamic Clocking -> power_management.rst. * ENOTTY ioctl() Return Value -> ioctl.rst. * memory_configurations.rst. * kernel_modules_vs_shared_libraries.rst. * NAKing USB OUT/IN Tokens -> usb.rst. * naming_arch_mcu_board_interfaces.rst. * naming_os_internals.rst. * nuttx_tasking.rst. * oneshot_timers_and_cpu_load.rst. * nuttx_initialization_sequence.rst. * short_time_delays.rst. * Signal Handler Tour -> signal_handlers.rst. * smp.rst. * syslog.rst. * Task Exit Sequence -> nuttx_tasking.rst. * tasks_vs_threads.rst. * tls.rst. * tickless_os.rst. * Why Can't Kernel Threads Have pthreads -> kernel_threads_vs_pthreads.rst. * Documentation/components/filesystem: * smartfs.rst. Signed-off-by: Tomasz 'CeDeROM' CEDRO <tomek@cedro.info>
76 lines
3.2 KiB
ReStructuredText
76 lines
3.2 KiB
ReStructuredText
=================================================
|
|
Naming of Architecture, MCU, and Board Interfaces
|
|
=================================================
|
|
|
|
What's the meaning of the prefix ``up_`` in NuttX?
|
|
Which functions should be prefixed with ``up_``?
|
|
|
|
``up_`` is supposed to stand for **microprocessor**;
|
|
the `u` is like the Greek letter micron: µ. So it would be **µP** which
|
|
is a common shortening of the word microprocessor.
|
|
I don't like that name very much. I wish I would have used ``arch_`` instead.
|
|
But now I think I am stuck with ``up_``.
|
|
|
|
Common Microcontroller Interfaces
|
|
=================================
|
|
|
|
Any interface that is common to all microcontroller and is used throughout
|
|
the system should be prefixed with ``up_`` and prototyped in
|
|
``include/nuttx/arch.h``. The definitions in that header file provide the
|
|
common interface between NuttX and the architecture-specific implementation
|
|
in ``arch/``.
|
|
|
|
Microcontroller-Specific Interfaces
|
|
===================================
|
|
|
|
An interface which is unique to a certain microcontroller should be prefixed
|
|
with the name of the microcontroller, for example ``stm32_``,
|
|
and be prototyped in some header file in the ``arch/`` directories.
|
|
These are interfaces used only by logic within the ``arch/`` and ``boards/``
|
|
directories.
|
|
|
|
Architecture-Specific Interfaces
|
|
================================
|
|
|
|
An interface which is unique to a CPU architecture, but shared among
|
|
microcontrollers that implement that CPU architecture should be prefixed
|
|
with the name of architecture. For example, the architecture-specific
|
|
interfaces used by STM32 would begin with ``arm_``.
|
|
These are interfaces used only by logic within the ``arch/`` and ``boards/``
|
|
directories.
|
|
|
|
There is also a ``arch/<architecture>/include/<chip>/chip.h`` header file
|
|
that can be used to communicate other microprocessor-specific information
|
|
between the board logic and even application logic.
|
|
|
|
Application logic may, for example, need to know specific capabilities
|
|
of the chip. Prototypes in that ``chip.h`` header file should follow
|
|
the microprocessor-specific naming convention.
|
|
|
|
Common Board Interfaces
|
|
=======================
|
|
|
|
Any interface that is common to all boards should be prefixed with ``board_``
|
|
and should also be prototyped in ``include/nuttx/arch.h``.
|
|
|
|
These ``board_`` definitions provide the interface between the board-level
|
|
logic and the architecture-specific logic.
|
|
|
|
There is also a ``boards/<arch>/<chip>/<board>/include/board.h`` header file
|
|
that can be used to communicate other board-specific information between
|
|
the architecture logic and even application logic.
|
|
|
|
Any definitions which are common between a single architecture and several
|
|
boards should go in this ``board.h`` header file;
|
|
``include/nuttx/arch.h`` is reserved for board-related definitions common
|
|
to all architectures.
|
|
|
|
Specific Interfaces
|
|
===================
|
|
|
|
Any interface which is unique to a board should be prefixed with the board
|
|
name, for example ``stm32f4discovery_``. Sometimes the board name is too long
|
|
so ``stm32_`` would be okay too. These should be prototyped in
|
|
``boards/<arch>/<chip>/<board>/src/<board>.h`` and should not be used outside
|
|
of that directory since board-specific definitions have no meaning outside
|
|
of the board directory.
|