nuttx/nuttx-mirror
1
2
Fork 0
mirror of https://github.com/apache/nuttx.git synced 2025-01-13 06:18:40 +08:00
Code Issues Projects Releases Packages Wiki Activity Actions

Documentation: cosmetics changes

Browse source 
- various style fixes
- limit the line length to about 80 characters to improve readability in terminal-based IDEs
This commit is contained in:
raiden00pl 2023-10-26 13:10:13 +02:00 committed by Xiang Xiao
parent 5228d773d3
commit d98ae9d3e4
20 changed files with 356 additions and 202 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
Documentation/components/arch/index.rst
View file

@ -59,21 +59,22 @@ Summary of Files
================
``include/<chip-name>/``
This sub-directory contains chip-specific header files.
``include/arch.h``
This is a hook for any architecture specific definitions that may be
needed by the system. It is included by ``include/nuttx/arch.h``
``include/types.h``
This provides architecture/toolchain-specific definitions for standard
types. This file should typedef::
types. This file should typedef: ``_int8_t``, ``_uint8_t``, ``_int16_t``,
``_uint16_t``, ``_int32_t``, ``_uint32_t``
_int8_t, _uint8_t, _int16_t, _uint16_t, _int32_t, _uint32_t
and if the architecture supports 64-bit integers::
_int24_t, _uint24_t, _int64_t, _uint64_t
and if the architecture supports 64-bit integers: ``_int24_t``, ``_uint24_t``,
``_int64_t``, ``_uint64_t``
NOTE that these type names have a leading underscore character. This
file will be included (indirectly) by ``include/stdint.h`` and typedef'ed
@ -83,6 +84,7 @@ Summary of Files
definitions provided by their toolchain header files.
``irqstate_t``
Must be defined to the size required to hold the interrupt
enable/disable state.
@ -90,17 +92,21 @@ Summary of Files
available to all files.
``include/irq.h``
This file needs to define some architecture-specific functions
(usually inline if the compiler supports inlining) and structures.
These include:
``struct xcptcontext``
This structure represents the saved context ofa thread.
``irqstate_t up_irq_save(void)``
Used to disable all interrupts.
``void up_irq_restore(irqstate_t flags)``
Used to restore interrupt enables to the same state as before ``up_irq_save``
was called.
@ -115,9 +121,11 @@ Summary of Files
by the board.
``src/<chip-name>/``
This sub-directory contains chip-specific source files.
``src/Makefile``
This makefile will be executed to build the targets src/libup.a and
src/up_head.o. The up_head.o file holds the entry point into the
system (power-on reset entry point, for example). It will be used in

8
Documentation/components/drivers/character/nullzero.rst
View file

@ -2,7 +2,7 @@
``dev_null.c`` and ``dev_zero.c``
=================================
These files provide the standard /dev/null and /dev/zero devices. See
include/nuttx/drivers/drivers.h for prototypes of functions that should
be called if you want to register these devices (devnull_register()
and devzero_register()).
These files provide the standard ``/dev/null`` and ``/dev/zero`` devices. See
``include/nuttx/drivers/drivers.h`` for prototypes of functions that should
be called if you want to register these devices (``devnull_register()``
and ``devzero_register()``).

1
Documentation/components/drivers/character/quadrature.rst
View file

@ -1,3 +1,4 @@
==========================
Quadrature Encoder Drivers
==========================

1
Documentation/components/drivers/character/rtc.rst
View file

@ -1,3 +1,4 @@
===========
RTC Drivers
===========

91
Documentation/components/drivers/character/timer.rst
View file

@ -17,13 +17,18 @@ locations:
directory for the specific processor *<architecture>* and for
the specific *<chip>* timer peripheral devices.
There are two ways to enable Timer Support along with the Timer Example. The first is faster and simpler. Just run the following command to use a ready config file with timer support and example included. You need to check if there's a timer config file for your specific chip. You may check it at the specific board's path: ``/boards/<arch>/<chip>/<variant>/config``.
There are two ways to enable Timer Support along with the Timer Example. The
first is faster and simpler. Just run the following command to use a ready
config file with timer support and example included. You need to check if there's
a timer config file for your specific chip. You may check it at the specific
board's path: ``/boards/<arch>/<chip>/<variant>/config``.
.. code-block:: console
$ ./tools/configure.sh <variant>:timer
And the second way is creating your own config file. To do so, follow the next instructions.
And the second way is creating your own config file. To do so, follow the next
instructions.
Enabling the Timer Support and Example in ``menuconfing``
----------------------------------------------------------
@ -49,16 +54,28 @@ Enabling the Timer Support and Example in ``menuconfing``
- [x] Timer example
Below the option, it is possible to manually configure some parameters as the standard timer device path, the timeout, the sample rate in which the counter will be read, the number of samples to be executed, and other parameters.
Below the option, it is possible to manually configure some parameters as the
standard timer device path, the timeout, the sample rate in which the counter
will be read, the number of samples to be executed, and other parameters.
Timer Example
--------------
-------------
The previously selected example will basically consult the timer status, set a timer alarm interval, set a timer signal handler function to be notified at the alarm, which only increments a variable, and then it will start the timer. The application will periodically consult the timer status at the sample rate previously configured through the ``menuconfig`` to follow the time left until the timer expires. After the samples have been read, the application stops de timer.
The previously selected example will basically consult the timer status, set a
timer alarm interval, set a timer signal handler function to be notified at the
alarm, which only increments a variable, and then it will start the timer. The
application will periodically consult the timer status at the sample rate
previously configured through the ``menuconfig`` to follow the time left until
the timer expires. After the samples have been read, the application stops the
timer.
The `example code <https://github.com/apache/nuttx-apps/blob/master/examples/timer/timer_main.c>`_ may be explored, its path is at ``/examples/timer/timer_main.c`` in the apps' repository.
The `example code <https://github.com/apache/nuttx-apps/blob/master/examples/timer/timer_main.c>`_
may be explored, its path is at ``/examples/timer/timer_main.c`` in the apps' repository.
In NuttX, the timer driver is a character driver and when a chip supports multiple timers, each one is accessible through its respective file in ``/dev`` directory. Each timer is registered using a unique numeric identifier (i.e. ``/dev/timer0``, ``/dev/timer1``, ...).
In NuttX, the timer driver is a character driver and when a chip supports multiple
timers, each one is accessible through its respective file in ``/dev`` directory.
Each timer is registered using a unique numeric identifier (i.e. ``/dev/timer0``,
``/dev/timer1``, ...).
Use the following command to run the example:
@ -66,22 +83,26 @@ Use the following command to run the example:
`nsh> timer`
This command will use the timer 0. To use the others, specify it through a parameter (where x is the timer number):
This command will use the timer 0. To use the others, specify it through a
parameter (where x is the timer number):
.. code-block:: console
`nsh> timer -d /dev/timerx`
Application Level Interface
----------------------------
---------------------------
The first necessary thing to be done in order to use the timer driver in an application is to include the header file for the NuttX timer driver. It contains the Application Level Interface to the timer driver. To do so, include:
The first necessary thing to be done in order to use the timer driver in an
application is to include the header file for the NuttX timer driver. It contains
the Application Level Interface to the timer driver. To do so, include:
.. code-block:: c
#include <nuttx/timers/timer.h>
At an application level, the timer functionalities may be accessed through ``ioctl`` systems calls. The available ``ioctl`` commands are:
At an application level, the timer functionalities may be accessed through ``ioctl``
systems calls. The available ``ioctl`` commands are:
* :c:macro:`TCIOC_START`
* :c:macro:`TCIOC_STOP`
@ -90,8 +111,11 @@ At an application level, the timer functionalities may be accessed through ``ioc
* :c:macro:`TCIOC_NOTIFICATION`
* :c:macro:`TCIOC_MAXTIMEOUT`
These ``ioctl`` commands internally call lower-half layer operations and the parameters are forwarded to these ops through the ``ioctl`` system call. The return of a system call is the return of an operation.
These ``struct timer_ops_s`` keeps pointers to the implementation of each operation. Following is the struct.
These ``ioctl`` commands internally call lower-half layer operations and the
parameters are forwarded to these ops through the ``ioctl`` system call. The return
of a system call is the return of an operation.
These ``struct timer_ops_s`` keeps pointers to the implementation of each operation.
Following is the struct.
.. c:struct:: timer_ops_s
.. code-block:: c
@ -139,7 +163,9 @@ These ``struct timer_ops_s`` keeps pointers to the implementation of each operat
FAR uint32_t *maxtimeout);
};
Since ``ioctl`` system calls expect a file descriptor, before using these commands, it's necessary to open the timer device special file in order to get a file descriptor. The following snippet demonstrates how to do so:
Since ``ioctl`` system calls expect a file descriptor, before using these commands,
it's necessary to open the timer device special file in order to get a file descriptor.
The following snippet demonstrates how to do so:
.. code-block:: c
@ -161,7 +187,8 @@ The ``TCIOC_START`` command calls the ``start`` operation, which is described be
.. c:function:: int start(void)
The start operation configures the timer, enables the interrupt if ``TCIOC_NOTIFICATION`` has already been called and finally starts the timer.
The start operation configures the timer, enables the interrupt if ``TCIOC_NOTIFICATION``
has already been called and finally starts the timer.
:return: A Linux System Error Code for failing or 0 for success.
@ -215,7 +242,15 @@ The ``TCIOC_GETSTATUS`` command calls the ``getstatus`` operation, which is desc
The getstatus operation gathers the timer's current information.
:param status: A writable pointer to a struct ``timer_status_s``. This struct contains 3 fields: ``flags`` (``uint32_t``), ``timeout`` (``uint32_t``) and ``timeleft`` (``uint32_t``). Bit 0 from `flags` indicates the timer's status, 1 indicates that the timer is running, zero it is stopped. Bit 1 from `flags` indicates if there's a callback registered. The `timeout` indicates the time interval that was configured to trigger an alarm, it is in microseconds. The `timeleft` interval indicates how many microseconds it's missing to trigger the alarm. The following snippet demonstrates how to use it and how to access these fields.
:param status: A writable pointer to a struct ``timer_status_s``. This struct
contains 3 fields: ``flags`` (``uint32_t``), ``timeout`` (``uint32_t``)
and ``timeleft`` (``uint32_t``). Bit 0 from `flags` indicates the timer's
status, 1 indicates that the timer is running, zero it is stopped. Bit 1
from `flags` indicates if there's a callback registered. The `timeout`
indicates the time interval that was configured to trigger an alarm, it
is in microseconds. The `timeleft` interval indicates how many microseconds
it's missing to trigger the alarm. The following snippet demonstrates how
to use it and how to access these fields.
:return: A Linux System Error Code for failing or 0 for success.
@ -245,7 +280,9 @@ The ``TCIOC_SETTIMEOUT`` command calls the ``settimeout`` operation, which is de
.. c:function:: int settimeout(uint32_t timeout)
The getstatus operation sets a timeout interval to trigger the alarm and then trigger an interrupt. It defines the timer interval in which the handler will be called.
The getstatus operation sets a timeout interval to trigger the alarm and then
trigger an interrupt. It defines the timer interval in which the handler will
be called.
:param timeout: An argument of type ``uint32_t`` with the timeout value in microseconds.
@ -270,9 +307,18 @@ This command may be used like so:
.. c:macro:: TCIOC_NOTIFICATION
The ``TCIOC_NOTIFICATION`` is used to configure the timer callback to notify the application via a signal when the timer expires. This command calls the ``setcallback`` operation. Which will not be described here, since the application does not set a callback directly. Instead, the user should configure a signal handler to catch notifications, and then, configure a timer notifier to notify and to signal the previously configured signal handler. For a better performance, a separate pthread may be configured to wait on sigwaitinfo() for timer events.
The ``TCIOC_NOTIFICATION`` is used to configure the timer callback to notify the
application via a signal when the timer expires. This command calls the ``setcallback``
operation. Which will not be described here, since the application does not set a
callback directly. Instead, the user should configure a signal handler to catch
notifications, and then, configure a timer notifier to notify and to signal the
previously configured signal handler. For a better performance, a separate pthread
may be configured to wait on sigwaitinfo() for timer events.
In any case, this command expects a read-only pointer to a struct `timer_notify_s`. This struct contains 2 fields: ``pid`` (``pid_t``), that indicates the ID of the task/thread to receive the signal and ``event`` (``struct sigevent``), which describes the way a task will be notified.
In any case, this command expects a read-only pointer to a struct `timer_notify_s`.
This struct contains 2 fields: ``pid`` (``pid_t``), that indicates the ID of the
task/thread to receive the signal and ``event`` (``struct sigevent``), which
describes the way a task will be notified.
This command may be used like so:
@ -301,7 +347,8 @@ The ``TCIOC_MAXTIMEOUT`` command calls the ``maxtimeout`` operation, which is de
The maxtimeout operation gets the maximum timeout value that can be configured.
:param maxtimeout: A writable pointer to a variable of ``uint32_t`` type in which the value will be stored.
:param maxtimeout: A writable pointer to a variable of ``uint32_t`` type in
which the value will be stored.
:return: A Linux System Error Code for failing or 0 for success.
This command may be used like so:
@ -324,5 +371,5 @@ This command may be used like so:
printf("Maximum supported timeout: %" PRIu32 "\n", max_timeout);
Those snippets were taken from the Example which provides a great resource to demonstrate how to use those ``ioctl`` commands.
Those snippets were taken from the Example which provides a great resource to
demonstrate how to use those ``ioctl`` commands.

143
Documentation/components/drivers/character/watchdog.rst
View file

@ -28,48 +28,62 @@ following locations:
for the specific processor *<architecture>* and for the
specific *<chip>* watchdog timer peripheral devices.
There are two ways to enable Watchdog Timer Support along with the Watchdog Example. The first is faster and simpler. Just run the following command to use a ready config file with watchdog timer support and example included. You need to check if there's a watchdog config file for your specific chip. You may check it at the specific board's path: ``/boards/<arch>/<chip>/<board>/config``.
There are two ways to enable Watchdog Timer Support along with the Watchdog Example.
The first is faster and simpler. Just run the following command to use a ready config
file with watchdog timer support and example included. You need to check if there's a
watchdog config file for your specific chip. You may check it at the specific board's
path: ``/boards/<arch>/<chip>/<board>/config``.
.. code-block:: console
$ ./tools/configure.sh <board>:watchdog
And the second way is creating your own config file. To do so, follow the next instructions.
And the second way is creating your own config file. To do so, follow the next
instructions.
Enabling the Watchdog Support and Example in ``menuconfing``
------------------------------------------------------------
1. Select Watchdog Timer Instances
To select these wdts browse in the ``menuconfig`` using the following path:
To select these wdts browse in the ``menuconfig`` using the following path:
Go into menu :menuselection:`System Type --> <Chip> Peripheral Selection` and press :kbd:`Enter`. Then select one or more watchdog timers according to availability of your chip.
Go into menu :menuselection:`System Type --> <Chip> Peripheral Selection` and
press :kbd:`Enter`. Then select one or more watchdog timers according to
availability of your chip.
2. Enable the Watchdog Timer Support
Go into menu :menuselection:`Device Drivers --> Timer Driver Support` and press :kbd:`Enter`. Then enable:
Go into menu :menuselection:`Device Drivers --> Timer Driver Support` and press
:kbd:`Enter`. Then enable:
- [x] Watchdog Timer Support
- [x] Watchdog Timer Support
3. Include the Watchdog Timer Example
Go into menu :menuselection:`Application Configuration --> Examples` and press :kbd:`Enter`. Then select the Watchdog Timer example.
Go into menu :menuselection:`Application Configuration --> Examples` and press
:kbd:`Enter`. Then select the Watchdog Timer example.
- [x] Watchdog Timer example
Below the option, it is possible to manually configure some standard parameters that will be used by the example, but they also can be passed as command line arguments later.
The parameters are the following: the standard timer device path (which defines the WDT instance), the timeout period (which is the period on which the watchdog will expire),
the ping delay (which is the interval period between feeding the dog) and the ping time (which is the total interval that the example will feed the dog, after this interval,
the dog will starve and the chip will trigger an interrupt or reset.
Below the option, it is possible to manually configure some standard parameters
that will be used by the example, but they also can be passed as command line
arguments later.
The parameters are the following: the standard timer device path (which defines
the WDT instance), the timeout period (which is the period on which the watchdog
will expire), the ping delay (which is the interval period between feeding the dog)
and the ping time (which is the total interval that the example will feed the dog,
after this interval, the dog will starve and the chip will trigger an interrupt or reset.
4. Include the Debug Watchdog Feature
In order to get the watchdog timer status, you need to enable it. For production code and for your application you may disable it.
In order to get the watchdog timer status, you need to enable it. For production
code and for your application you may disable it.
Go into menu :menuselection:`Build Setup --> Debug Options` and press :kbd:`Enter`. Then enable:
Go into menu :menuselection:`Build Setup --> Debug Options` and press :kbd:`Enter`. Then enable:
- [x] Enable Debug Features
- [x] Watchdog Timer Debug Features
- [x] Enable Debug Features
- [x] Watchdog Timer Debug Features
Watchdog Timer Example
----------------------
@ -79,12 +93,19 @@ The previously selected example will basically do the following:
* Open the watchdog device
* Set the watchdog timeout
* Start the watchdog timer
* Ping (feed the dog) during the ``pingtime`` with a delay of ``pingdelay`` and print out the wdt status in case debug was enabled.
* Enter into an endless loop without pinging. It will cause the watchdog timer to reset the chip on timeout, i.e., after timer expiration.
* Ping (feed the dog) during the ``pingtime`` with a delay of ``pingdelay`` and
print out the wdt status in case debug was enabled.
* Enter into an endless loop without pinging. It will cause the watchdog timer
to reset the chip on timeout, i.e., after timer expiration.
The `example code <https://github.com/apache/nuttx-apps/blob/master/examples/watchdog/watchdog_main.c>`_ may be explored, its path is at ``/examples/watchdog/watchdog_main.c`` in the apps' repository.
The `example code <https://github.com/apache/nuttx-apps/blob/master/examples/watchdog/watchdog_main.c>`_
may be explored, its path is at ``/examples/watchdog/watchdog_main.c`` in the
apps' repository.
In NuttX, the watchdog timer driver is a character driver and when a chip supports multiple watchdog timers, each one is accessible through its respective special file in ``/dev`` directory. Each watchdog timer is registered using a unique numeric identifier (i.e. ``/dev/watchdog0``, ``/dev/watchdog1``, ...).
In NuttX, the watchdog timer driver is a character driver and when a chip supports
multiple watchdog timers, each one is accessible through its respective special file
in ``/dev`` directory. Each watchdog timer is registered using a unique numeric
identifier (i.e. ``/dev/watchdog0``, ``/dev/watchdog1``, ...).
Use the following command to run the example:
@ -92,7 +113,8 @@ Use the following command to run the example:
nsh> wdog
This command will use the watchdog timer 0. To use the others, specify it through a parameter (where x is the timer number):
This command will use the watchdog timer 0. To use the others, specify it through
a parameter (where x is the timer number):
.. code-block:: console
@ -101,13 +123,20 @@ This command will use the watchdog timer 0. To use the others, specify it throug
Application Level Interface
----------------------------
The first necessary thing to be done in order to use the watchdog timer driver in an application is to include the header file for the NuttX Watchdog timer driver. It contains the Application Level Interface to the timer driver. To do so, include:
The first necessary thing to be done in order to use the watchdog timer driver
in an application is to include the header file for the NuttX Watchdog timer
driver. It contains the Application Level Interface to the timer driver. To do so,
include:
.. code-block:: c
#include <nuttx/timers/watchdog.h>
At an application level, the watchdog timer functionalities may be accessed through ``ioctl`` systems calls. These ``ioctl`` commands internally call lower-half layer operations and the parameters are forwarded to these operations through the ``ioctl`` system call. The example provides a great resource to demonstrate how to use those ``ioctl`` commands. The available ``ioctl`` commands are:
At an application level, the watchdog timer functionalities may be accessed through
``ioctl`` systems calls. These ``ioctl`` commands internally call lower-half layer
operations and the parameters are forwarded to these operations through the ``ioctl``
system call. The example provides a great resource to demonstrate how to use those
``ioctl`` commands. The available ``ioctl`` commands are:
.. c:macro:: WDIOC_START
@ -119,7 +148,9 @@ This command stops the watchdog timer.
.. c:macro:: WDIOC_GETSTATUS
This command gets the status of the watchdog timer. It receives a writeable pointer to struct ``watchdog_status_s`` as parameter. The lower-half driver writes the current status in this struct.
This command gets the status of the watchdog timer. It receives a writeable
pointer to struct ``watchdog_status_s`` as parameter. The lower-half driver
writes the current status in this struct.
.. c:struct:: watchdog_status_s
.. code-block:: c
@ -134,11 +165,16 @@ This command gets the status of the watchdog timer. It receives a writeable poin
.. c:macro:: WDIOC_SETTIMEOUT
This command sets the timeout value, i.e., the value that will trigger the reset or interrupt. The argument is a ``uint32_t`` value in milliseconds.
This command sets the timeout value, i.e., the value that will trigger the reset
or interrupt. The argument is a ``uint32_t`` value in milliseconds.
.. c:macro:: WDIOC_CAPTURE
This command registers an user callback that will be triggered on timeout. It receives as argument a pointer to struct ``watchdog_capture_s``. If the user callback is NULL, then it configures only to reset. Not all chips support interrupt on timeout. This command is optional, i.e., if it's not used, the standard behaviour is to reset on timeout.
This command registers an user callback that will be triggered on timeout. It
receives as argument a pointer to struct ``watchdog_capture_s``. If the user
callback is NULL, then it configures only to reset. Not all chips support
interrupt on timeout. This command is optional, i.e., if it's not used, the
standard behaviour is to reset on timeout.
.. c:struct:: watchdog_capture_s
.. code-block:: c
@ -156,7 +192,8 @@ This command registers an user callback that will be triggered on timeout. It re
Enable Built in System Monitoring to reset the watchdog
-------------------------------------------------------
The auto-monitor provides an OS-internal mechanism to automatically start and repeatedly reset the watchdog.
The auto-monitor provides an OS-internal mechanism to automatically start and
repeatedly reset the watchdog.
To enable it, follow the next instructions:
@ -164,39 +201,55 @@ To enable it, follow the next instructions:
To select the wdt browse in the ``menuconfig`` using the following path:
Go into menu :menuselection:`System Type --> <Chip> Peripheral Selection` and press :kbd:`Enter`. Then select one watchdog timer.
Go into menu :menuselection:`System Type --> <Chip> Peripheral Selection` and
press :kbd:`Enter`. Then select one watchdog timer.
2. Enable the Auto-monitor option
Go into menu :menuselection:`Device Drivers --> Timer Driver Support` and press :kbd:`Enter`. Then enable:
Go into menu :menuselection:`Device Drivers --> Timer Driver Support` and press
:kbd:`Enter`. Then enable:
- [x] Watchdog Timer Support
- [x] Watchdog Timer Support
Then press :kbd:`Enter` again to enter into the Watchdog Timer Support menu. And finally enable the Auto-monitor option:
Then press :kbd:`Enter` again to enter into the Watchdog Timer Support menu. And
finally enable the Auto-monitor option:
- [x] Auto-monitor
- [x] Auto-monitor
After selecting the option you may want to configure some parameters:
After selecting the option you may want to configure some parameters:
* **Timeout**: It is the watchdog timer expiration time in seconds.
* **Keep a live interval**: This is the interval in which the watchdog will be fed. It is in seconds. It can't be bigger than the timeout. If this interval is equal to timeout interval, than this interval will automatically change to half timeout.
* **Keep alive by**: This is a choice to determine who is going to feed the dog. There are 4 possible choices that are described as follows.
* **Timeout**: It is the watchdog timer expiration time in seconds.
* **Keep a live interval**: This is the interval in which the watchdog will be
fed. It is in seconds. It can't be bigger than the timeout. If this interval
is equal to timeout interval, than this interval will automatically change to
half timeout.
* **Keep alive by**: This is a choice to determine who is going to feed the dog.
There are 4 possible choices that are described as follows.
``Capture callback``: This choice registers a watchdog timer callback to reset the watchdog every time it expires, i.e., on timeout.
``Capture callback``: This choice registers a watchdog timer callback to reset
the watchdog every time it expires, i.e., on timeout.
``Timer callback``: This choice also uses a timer callback to reset the watchdog, but it will reset the watchdog every "keep a live interval".
``Timer callback``: This choice also uses a timer callback to reset the watchdog,
but it will reset the watchdog every "keep a live interval".
``Worker callback``: This choice uses a Work Queue to reset the watchdog every "keep a live interval". This choice depends on having the Low or High Priority Work Queue enabled.
If only the High Priority Work Queue is enabled, this one will be used, otherwise Low Priority Work Queue is used.
``Worker callback``: This choice uses a Work Queue to reset the watchdog every
"keep a live interval". This choice depends on having the Low or High Priority
Work Queue enabled.
If only the High Priority Work Queue is enabled, this one will be used, otherwise
Low Priority Work Queue is used.
So, before enabling it, go into menu :menuselection:`RTOS Features --> Work queue support` and press :kbd:`Enter`.
So, before enabling it, go into menu :menuselection:`RTOS Features --> Work queue support`
and press :kbd:`Enter`.
- [x] Low priority (kernel) worker thread
- [x] Low priority (kernel) worker thread
``Idle callback``: This choice sets an Idle callback to feed the dog. It depends on the PM module, because this callback is triggered by the PM state change. To enable it do the following:
``Idle callback``: This choice sets an Idle callback to feed the dog. It depends
on the PM module, because this callback is triggered by the PM state change.
To enable it do the following:
Go into menu :menuselection:`Device Drivers` and enable:
Go into menu :menuselection:`Device Drivers` and enable:
- [x] Power Management Support
- [x] Power Management Support
After selecting one of these choices, the chip will keep itself alive by one of these options.
After selecting one of these choices, the chip will keep itself alive by one of
these options.

6
Documentation/components/filesystem/binfs.rst
View file

@ -1,6 +1,6 @@
============
``fs/binfs``
============
=====
BINFS
=====
This is the binfs file system that allows "fake" execution of NSH built-
in applications via the file system. The binfs fs file system can be

6
Documentation/components/filesystem/mmap.rst
View file

@ -1,6 +1,6 @@
===========
``fs/mmap``
===========
=============================
File mapping emulation (mmap)
=============================
NuttX operates in a flat open address space and is focused on MCUs that do
support Memory Management Units (MMUs). Therefore, NuttX generally does not

6
Documentation/components/filesystem/procfs.rst
View file

@ -1,6 +1,6 @@
=============
``fs/procfs``
=============
======
PROCFS
======
This is a tiny procfs file system that allows read-only access to a few
attributes of a task or thread. This tiny procfs fs file system can be

5
Documentation/components/index.rst
View file

@ -1,7 +1,10 @@
OS Components
=============
NuttX is very feature-rich RTOS and is thus composed of various different subsystems. The following sections explain how each of these main RTOS components work and can be used. For detailed documentation on the specific API used in this case, you can head to the :doc:`reference <../reference/index>`.
NuttX is very feature-rich RTOS and is thus composed of various different
subsystems. The following sections explain how each of these main RTOS components
work and can be used. For detailed documentation on the specific API used in this
case, you can head to the :doc:`reference <../reference/index>`.
.. toctree::
:maxdepth: 2

6
Documentation/components/libs/index.rst
View file

@ -6,15 +6,15 @@ This page discusses the NuttX libraries that can be found in ``libs/``
Libraries in NuttX are very special creatures. They have these properties:
1. They can be shared by both application logic and logic within the OS when
#. They can be shared by both application logic and logic within the OS when
using the FLAT build.
2. But in PROTECTED and KERNEL modes, they must be built differently: The
#. But in PROTECTED and KERNEL modes, they must be built differently: The
copies used by applications and the OS cannot be the same. Rather,
separate versions of libraries must be built for the kernel and for
applications.
3. When used by the OS, some special care must be taken to assure that the
#. When used by the OS, some special care must be taken to assure that the
OS logic does not disrupt the user's errno value and that the OS does
not create inappropriate cancellation points.

11
Documentation/components/libs/libc/index.rst
View file

@ -12,7 +12,7 @@ mode. In that model, there is no real architectural distinction between
what is a kernel-mode program and what is a user-mode program; the system is
more like on multi-threaded program that all runs in kernel-mode.
But if the CONFIG_BUILD_PROTECTED option is selected, NuttX will be built
But if the ``CONFIG_BUILD_PROTECTED`` option is selected, NuttX will be built
into distinct user-mode and kernel-mode sections. In that case, most of the
code in the ``nuttx/`` directory will run in kernel-mode with exceptions
of (1) the user-mode "proxies" found in syscall/proxies, and (2) the
@ -117,17 +117,17 @@ system and C library services/functions to the application and NSH.
Symbol tables have differing usefulness in different NuttX build modes:
1. In the FLAT build (``CONFIG_BUILD_FLAT``), symbol tables are used to bind
#. In the FLAT build (``CONFIG_BUILD_FLAT``), symbol tables are used to bind
addresses in loaded ELF or NxFLAT modules to base code that usually
resides in FLASH memory. Both OS interfaces and user/application
libraries are made available to the loaded module via symbol tables.
2. Symbol tables may be of value in a protected build
#. Symbol tables may be of value in a protected build
(``CONFIG_BUILD_PROTECTED``) where the newly started user task must
share resources with other user code (but should use system calls to
interact with the OS).
3. But in the kernel build mode (``CONFIG_BUILD_LOADABLE``), only fully linked
#. But in the kernel build mode (``CONFIG_BUILD_LOADABLE``), only fully linked
executables loadable via ``execl()``, ``execv()``, or ``posix_spawan()`` can used.
There is no use for a symbol table with the kernel build since all
memory resources are separate; nothing is share-able with the newly
@ -135,6 +135,7 @@ Symbol tables have differing usefulness in different NuttX build modes:
Code/Text Size Implications
---------------------------
The option can have substantial effect on system image size, mainly
code/text. That is because the instructions to generate symtab.inc
above will cause EVERY interface in the NuttX RTOS and the C library to be
@ -144,6 +145,8 @@ In order to reduce the code/text size, you may want to manually prune the
auto-generated symtab.inc file to remove all interfaces that you do
not wish to include into the base FLASH image.
Implementation Details
======================
.. toctree::
:maxdepth: 1

2
Documentation/components/libs/libnx/index.rst
View file

@ -5,7 +5,7 @@ libnx
The graphics capability consist both of components internal to the RTOS
and of user-callable interfaces. In the NuttX kernel mode build there are
some components of the graphics subsystem are callable in user mode and
other components that are internal to the RTOS. This directory, libs/libnx/,
other components that are internal to the RTOS. This directory, ``libs/libnx/``,
contains only those user-callable components.
The RTOS internal functions are contained in the ``graphics/`` directory.

28
Documentation/components/libs/libnx/nxfonts.rst
View file

@ -15,25 +15,25 @@ into fonts that can be used in the NX graphics system.
Below are general instructions for creating and installing a new font
in the NX graphic system:
1. Locate a font in BDF format,
2. Use the bdf-converter program to convert the BDF font to the NuttX
#. Locate a font in BDF format,
#. Use the bdf-converter program to convert the BDF font to the NuttX
font format. This will result in a C header file containing
definitions. That header file should be installed at, for example,
graphics/nxfonts/nxfonts_myfont.h.
``graphics/nxfonts/nxfonts_myfont.h``.
Create a new NuttX configuration variable. For example, suppose
you define the following variable: CONFIG_NXFONT_MYFONT. Then
you would need to:
3. Define CONFIG_NXFONT_MYFONT=y in your NuttX configuration file.
#. Define ``CONFIG_NXFONT_MYFONT=y`` in your NuttX configuration file.
A font ID number has to be assigned for each new font. The font ID
is defined in the file include/nuttx/nx/nxfonts.h. Those definitions
is defined in the file ``include/nuttx/nx/nxfonts.h``. Those definitions
have to be extended to support your new font. Look at how the font ID
enabled by CONFIG_NXFONT_SANS23X27 is defined and add an ID for your
enabled by ``CONFIG_NXFONT_SANS23X27`` is defined and add an ID for your
new font in a similar fashion:
4. include/nuttx/nx/nxfonts.h. Add you new font as a possible system
3. ``include/nuttx/nx/nxfonts.h`` Add you new font as a possible system
default font:
.. code-block:: C
@ -62,11 +62,11 @@ New Add the font to the NX build system. There are several files that
you have to modify to do this. Look how the build system uses the
font CONFIG_NXFONT_SANS23X27 for examaples:
5. nuttx/graphics/Makefile. This file needs logic to auto-generate
#. ``nuttx/graphics/Makefile`` This file needs logic to auto-generate
a C source file from the header file that you generated with the
the bdf-converter program. Notice NXFONTS_FONTID=2; this must be
set to the same font ID value that you defined in the
include/nuttx/nx/nxfonts.h file.
``include/nuttx/nx/nxfonts.h`` file.
.. code-block:: make
@ -78,7 +78,7 @@ font CONFIG_NXFONT_SANS23X27 for examaples:
@$(MAKE) -C nxfonts -f Makefile.sources NXFONTS_FONTID=2 EXTRAFLAGS=$(EXTRAFLAGS)
endif
6. nuttx/graphics/nxfonts/Make.defs. Set the make variable NXFSET_CSRCS.
#. ``nuttx/graphics/nxfonts/Make.defs``. Set the make variable NXFSET_CSRCS.
NXFSET_CSRCS determines the name of the font C file to build when
NXFONTS_FONTID=2:
@ -91,7 +91,7 @@ font CONFIG_NXFONT_SANS23X27 for examaples:
NXFSET_CSRCS += nxfonts_bitmaps_myfont.c
endif
7. nuttx/graphics/nxfonts/Makefile.sources. This is the Makefile used
#. ``nuttx/graphics/nxfonts/Makefile.sources``. This is the Makefile used
in step 5 that will actually generate the font C file. So, given
your NXFONTS_FONTID=2, it needs to determine a prefix to use for
auto-generated variable and function names and (again) the name of
@ -109,9 +109,9 @@ font CONFIG_NXFONT_SANS23X27 for examaples:
GEN_CSRC = nxfonts_bitmaps_myfont.c
endif
8. graphics/nxfonts/nxfonts_bitmaps.c. This is the file that contains
#. ``graphics/nxfonts/nxfonts_bitmaps.c``. This is the file that contains
the generic font structures. It is used as a "template" file by
nuttx/graphics/nxfonts/Makefile.sources to create your customized
``nuttx/graphics/nxfonts/Makefile.sources`` to create your customized
font data set.
.. code-block:: C
@ -127,7 +127,7 @@ font CONFIG_NXFONT_SANS23X27 for examaples:
Where nxfonts_myfont.h is the NuttX font file that we generated in
step 2 using the bdf-converter tool.
9. graphics/nxfonts/nxfonts_getfont.c. Finally, we need to extend the
#. ``graphics/nxfonts/nxfonts_getfont.c``. Finally, we need to extend the
logic that does the run-time font lookups so that can find our new
font. The lookup function is NXHANDLE nxf_getfonthandle(enum nx_fontid_e fontid).
The new font information needs to be added to data structures used by

39
Documentation/components/libs/libxx.rst
View file

@ -10,15 +10,32 @@ This directory contains three C++ library:
At present, only the following are supported here:
- ``void *operator new(std::size_t nbytes)``
- ``void operator delete(void* ptr)``
- ``void operator delete[](void *ptr)``
- ``void __cxa_pure_virtual(void)``
- ``int __aeabi_atexit(void* object, void (*destroyer)(void*), void *dso_handle)``
- ``int __cxa_atexit(__cxa_exitfunc_t func, FAR void *arg, FAR void *dso_handle)``
.. code-block:: C
This implementation is selected when neither of the following
two options are enabled.
void *operator new(std::size_t nbytes)
.. code-block:: C
void operator delete(void* ptr)
.. code-block:: C
void operator delete[](void *ptr)
.. code-block:: C
void __cxa_pure_virtual(void)
.. code-block:: C
int __aeabi_atexit(void* object, void (*destroyer)(void*), void *dso_handle)
.. code-block:: C
int __cxa_atexit(__cxa_exitfunc_t func, FAR void *arg, FAR void *dso_handle)
This implementation is selected when neither of the following
two options are enabled.
- LLVM "libc++" C++ library (http://libcxx.llvm.org/)
This implementation is selected with CONFIG_LIBCXX=y.
@ -29,10 +46,10 @@ This directory contains three C++ library:
operator new
------------
This operator should take a type of size_t. But size_t has an unknown underlying
type. In the nuttx sys/types.h header file, size_t is typed as uint32_t
This operator should take a type of ``size_t``. But size_t has an unknown underlying
type. In the nuttx ``sys/types.h`` header file, ``size_t`` is typed as ``uint32_t``
(which is determined by architecture-specific logic). But the C++
compiler may believe that size_t is of a different type resulting in
compiler may believe that ``size_t`` is of a different type resulting in
compilation errors in the operator. Using the underlying integer type
instead of size_t seems to resolve the compilation issues. Need to
REVISIT this.

108
Documentation/components/mm/index.rst
View file

@ -52,14 +52,18 @@ This allocator can be used to manage multiple heaps (albeit with some
non-standard interfaces). A heap is represented by ``struct mm_heap_s``
as defined in the file ``include/nuttx/mm/mm.h``. To create another heap
instance, you would allocate a heap structure, most likely statically
in memory::
in memory:
include <nuttx/mm/mm.h>
static struct mm_heap_s *g_myheap;
.. code-block:: C
Then initialize the heap using::
include <nuttx/mm/mm.h>
static struct mm_heap_s *g_myheap;
g_myheap = mm_initialize(myheap_start, myheap_size);
Then initialize the heap using:
.. code-block:: C
g_myheap = mm_initialize(myheap_start, myheap_size);
Where ``mm_initialize()`` and all related interfaces are prototyped in the
header file ``include/nuttx/mm/mm.h``.
@ -77,8 +81,8 @@ same mechanism, but with a global heap structure called ``g_mmheap``.
User/Kernel Heaps
~~~~~~~~~~~~~~~~~
This multiple heap capability is exploited in some of the more complex NuttX
build configurations to provide separate kernel-mode and user-mode heaps.
This multiple heap capability is exploited in some of the more complex NuttX
build configurations to provide separate kernel-mode and user-mode heaps.
Sub-Directories
~~~~~~~~~~~~~~~
@ -92,39 +96,41 @@ Debugging
Please follow these steps to hook all memory related routines:
1.Add a new header file(e.g. ``xxx_malloc.h``)::
1. Add a new header file(e.g. ``xxx_malloc.h``):
...
#include <malloc.h>
#include <stdlib.h>
#include <string.h>
#include <strings.h>
.. code-block:: C
#ifndef __ASSEMBLY__
FAR void *xxx_malloc(FAR const char *file, int line, size_t size);
void xxx_free(FAR const char *file, int line, FAR const void *ptr);
FAR void *xxx_memcpy(FAR const char *file, int line,
...
#include <malloc.h>
#include <stdlib.h>
#include <string.h>
#include <strings.h>
#ifndef __ASSEMBLY__
FAR void *xxx_malloc(FAR const char *file, int line, size_t size);
void xxx_free(FAR const char *file, int line, FAR const void *ptr);
FAR void *xxx_memcpy(FAR const char *file, int line,
FAR void *dst, FAR const void *src, size_t len);
...
#define malloc(s) xxx_malloc(__FILE__, __LINE__, s)
#define free(p) xxx_free(__FILE__, __LINE__, p)
#define memcpy(d, s, l) xxx_memcpy(__FILE__, __LINE__, d, s, l)
...
#endif
...
...
#define malloc(s) xxx_malloc(__FILE__, __LINE__, s)
#define free(p) xxx_free(__FILE__, __LINE__, p)
#define memcpy(d, s, l) xxx_memcpy(__FILE__, __LINE__, d, s, l)
...
#endif
...
2.Implement ``xxx_malloc``, ``xxx_free``, ``xxx_memcpy``... in source code,
you can:
2. Implement ``xxx_malloc``, ``xxx_free``, ``xxx_memcpy``... in source code,
you can:
- Modify some arguments(e.g. extend the allocation size for redzone)
- Check the critical arguments(e.g. pointer and length) in the range
- Forward to the original implementation(call malloc/free/memcpy)
- Attach the context info(e.g. file and line) before return
- Modify some arguments(e.g. extend the allocation size for redzone)
- Check the critical arguments(e.g. pointer and length) in the range
- Forward to the original implementation(call malloc/free/memcpy)
- Attach the context info(e.g. file and line) before return
3.Enable the hook by either:
3. Enable the hook by either:
- Include xxx_malloc.h in your source code to hook one file
- Add ``-include xxx_malloc.h`` to ``CFLAGS`` to hook all source code
- Include ``xxx_malloc.h`` in your source code to hook one file
- Add ``-include xxx_malloc.h`` to ``CFLAGS`` to hook all source code
Granule Allocator
-----------------
@ -134,10 +140,9 @@ granule allocator allocates memory in units of a fixed sized block ("granule").
Allocations may be aligned to a user-provided address boundary.
The granule allocator interfaces are defined in ``nuttx/include/nuttx/mm/gran.h``.
The granule allocator consists of these files in this directory::
mm_gran.h, mm_granalloc.c, mm_grancritical.c, mm_granfree.c
mm_graninit.c
The granule allocator consists of these files in this directory:
``mm_gran.h``, ``mm_granalloc.c``, ``mm_grancritical.c``, ``mm_granfree.c``
``mm_graninit.c``
The granule allocator is not used anywhere within the base NuttX code
as of this writing. The intent of the granule allocator is to provide
@ -156,29 +161,36 @@ to 32 granules. That restriction could be eliminated with some
additional coding effort, but currently requires larger granule
sizes for larger allocations.
General Usage Example.
General Usage Example
~~~~~~~~~~~~~~~~~~~~~
This is an example using the GCC section attribute to position a DMA
heap in memory (logic in the linker script would assign the section
.dmaheap to the DMA memory::
.dmaheap to the DMA memory:
FAR uint32_t g_dmaheap[DMAHEAP_SIZE] locate_data(.dmaheap);
.. code-block:: C
FAR uint32_t g_dmaheap[DMAHEAP_SIZE] locate_data(.dmaheap);
The heap is created by calling gran_initialize. Here the granule size
is set to 64 bytes and the alignment to 16 bytes::
is set to 64 bytes and the alignment to 16 bytes:
GRAN_HANDLE handle = gran_initialize(g_dmaheap, DMAHEAP_SIZE, 6, 4);
.. code-block:: C
Then the GRAN_HANDLE can be used to allocate memory::
GRAN_HANDLE handle = gran_initialize(g_dmaheap, DMAHEAP_SIZE, 6, 4);
FAR uint8_t *dma_memory = (FAR uint8_t *)gran_alloc(handle, 47);
Then the ``GRAN_HANDLE`` can be used to allocate memory:
.. code-block:: C
FAR uint8_t *dma_memory = (FAR uint8_t *)gran_alloc(handle, 47);
The actual memory allocates will be 64 byte (wasting 17 bytes) and
will be aligned at least to (``1 << log2align``).
Sub-Directories:
- ``mm/mm_gran`` - Holds the granule allocation logic
- ``mm/mm_gran`` - Holds the granule allocation logic
Page Allocator
--------------
@ -215,8 +227,8 @@ The iob subdirectory contains a simple allocator of I/O buffers. These
I/O buffers, IOBs, are used extensively for networking but are generally
available for usage by drivers. The I/O buffers have these properties:
1. Uses a pool of a fixed number of fixed fixed size buffers.
2. Free buffers are retained in free list: When a buffer is allocated
#. Uses a pool of a fixed number of fixed fixed size buffers.
#. Free buffers are retained in free list: When a buffer is allocated
it is removed from the free list; when a buffer is freed it is
returned to the free list.
3. The calling application will wait if there are not free buffers.
#. The calling application will wait if there are not free buffers.

18
Documentation/components/mm/shm.rst
View file

@ -42,7 +42,9 @@ information common to all threads in the group. If ``CONFIG_MM_SHM=y``, then
this includes data structures for the per-process shared memory virtual
page allocator.
A memory region is accessed using::
A memory region is accessed using:
.. code-block:: C
int shmget(key_t key, size_t size, int shmflg);
@ -60,7 +62,7 @@ created, the following things happen:
identifier.
- The requested size is rounded up to rounded up to full pages, each of
size CONFIG_MM_PGSIZE.
size ``CONFIG_MM_PGSIZE``.
- A set of physical pages are allocated and the physical address of
these pages is retained in the internal data set.
@ -74,12 +76,16 @@ physical memory, i.e., do not allocate the physical memory until the
memory is required, for example, when a page fault occurs when a
application tries to allocate the memory.
A shared memory region is destroyed via::
A shared memory region is destroyed via:
.. code-block:: C
int shmctl(int shmid, int cmd, struct shmid_ds *buf);
In order for a process to make use of the memory region, it must be
"attached" the process using::
"attached" the process using:
.. code-block:: C
FAR void *shmat(int shmid, FAR const void *shmaddr, int shmflg);
@ -100,7 +106,9 @@ following steps:
- Return the allocated virtual base address to the caller.
The memory region can be detached from the user process using::
The memory region can be detached from the user process using:
.. code-block:: C
int shmdt(FAR const void *shmaddr);

16
Documentation/components/net/sixlowpan.rst
View file

@ -61,12 +61,12 @@ outside of the WPAN.
Optimal 6LoWPAN Configuration
-----------------------------
1. Link local IP addresses::
#. Link local IP addresses::
128 112 96 80 64 48 32 16
fe80 0000 0000 0000 xxxx xxxx xxxx xxxx
2. MAC-based IP addresses::
#. MAC-based IP addresses::
128 112 96 80 64 48 32 16
---- ---- ---- ---- ---- ---- ---- ----
@ -79,17 +79,17 @@ Optimal 6LoWPAN Configuration
For link-local address, AAAA is 0xfe80
3. MAC based link-local addresses::
#. MAC based link-local addresses::
128 112 96 80 64 48 32 16
---- ---- ---- ---- ---- ---- ---- ----
fe80 0000 0000 0000 0000 00ff fe00 MMMM 2-byte short address IEEE 48-bit MAC
fe80 0000 0000 0000 NNNN NNNN NNNN NNNN 8-byte extended address IEEE EUI-64
4. To be compressible, port numbers must be in the range 0xf0b0-0xf0bf,
#. To be compressible, port numbers must be in the range 0xf0b0-0xf0bf,
hexadecimal. That is 61616-61631 decimal.
5. IOBs: Must be big enough to hold one IEEE802.15.4 frame (typically 127).
#. IOBs: Must be big enough to hold one IEEE802.15.4 frame (typically 127).
There must be enough IOBs to decompose the largest IPv6 packet
(``CONFIG_NET_6LOWPAN_PKTSIZE``, default 1294, plus per frame overhead).
@ -101,10 +101,10 @@ after the MAC header when the payload is too large to fit in a single IEEE
802.15.4 frame. The fragment header contains three fields: Datagram size,
datagram tag and datagram offset.
1. Datagram size describes the total (un-fragmented) payload.
2. Datagram tag identifies the set of fragments and is used to match
#. Datagram size describes the total (un-fragmented) payload.
#. Datagram tag identifies the set of fragments and is used to match
fragments of the same payload.
3. Datagram offset identifies the fragment’s offset within the un-
#. Datagram offset identifies the fragment’s offset within the un-
fragmented payload (in units of 8 bytes).
The length of the fragment header length is four bytes for the first header

3
Documentation/components/nxflat.rst
View file

@ -147,7 +147,8 @@ Here are some general build instructions:
- You must have already configured NuttX in ``<some-dir>/nuttx``
- Download the buildroot package ``buildroot-0.x.y`` into
``<some-dir>``
- Unpack ``<some-dir>/buildroot-0.x.y.tar.gz`` using a command like ``tar zxf buildroot-0.x.y``. This will result in a new directory like ``<some-dir>/buildroot-0.x.y``
- Unpack ``<some-dir>/buildroot-0.x.y.tar.gz`` using a command like ``tar zxf buildroot-0.x.y``.
This will result in a new directory like ``<some-dir>/buildroot-0.x.y``
- Move this into position:
``mv <some-dir>/buildroot-0.x.y``\ <some-dir>/buildroot
- ``cd``\ <some-dir>/buildroot

40
Documentation/components/syscall.rst
View file

@ -26,70 +26,70 @@ and handle in kernel-mode.
Header Files
------------
include/syscall.h
~~~~~~~~~~~~~~~~~
``include/syscall.h``
~~~~~~~~~~~~~~~~~~~~~
This header file supports general access to SWI facilities. It is simply
a wrapper file that includes ``include/sys/syscall.h`` and
``include/arch/syscall.h``.
include/sys/syscall.h
~~~~~~~~~~~~~~~~~~~~~
``include/sys/syscall.h``
~~~~~~~~~~~~~~~~~~~~~~~~~
The SWIs received by the kernel are distinguish by a code that identifies
how to process the SWI. This header file defines all such codes understood
by the NuttX kernel.
include/arch/syscall.h (or arch/<cpu>/include/syscall.h)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
``include/arch/syscall.h`` (or ``arch/<cpu>/include/syscall.h``)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This header file is provided by the platform-specific logic and declares
(or defines) the mechanism for providing software interrupts on this
platform. The following functions must be declared (or defined) in this
header file:
- ``SWI`` with ``SYS_`` call number and one parameter
- ``SWI`` with ``SYS_`` call number and one parameter:
.. code-block:: C
.. code-block:: C
uintptr_t sys_call0(unsigned int nbr);
- ``SWI`` with ``SYS_`` call number and one parameter
- ``SWI`` with ``SYS_`` call number and one parameter:
.. code-block:: C
.. code-block:: C
uintptr_t sys_call1(unsigned int nbr, uintptr_t parm1);
- ``SWI`` with ``SYS_`` call number and two parameters
- ``SWI`` with ``SYS_`` call number and two parameters:
.. code-block:: C
.. code-block:: C
uintptr_t sys_call2(unsigned int nbr, uintptr_t parm1, uintptr_t parm2);
- ``SWI`` with ``SYS_`` call number and three parameters
- ``SWI`` with ``SYS_`` call number and three parameters:
.. code-block:: C
.. code-block:: C
uintptr_t sys_call3(unsigned int nbr, uintptr_t parm1,
uintptr_t parm2, uintptr_t parm3);
- ``SWI`` with ``SYS_`` call number and four parameters
- ``SWI`` with ``SYS_`` call number and four parameters:
.. code-block:: C
.. code-block:: C
uintptr_t sys_call4(unsigned int nbr, uintptr_t parm1, uintptr_t parm2,
uintptr_t parm3, uintptr_t parm4);
- ``SWI`` with ``SYS_`` call number and five parameters
- ``SWI`` with ``SYS_`` call number and five parameters:
.. code-block:: C
.. code-block:: C
uintptr_t sys_call5(unsigned int nbr, uintptr_t parm1, uintptr_t parm2,
uintptr_t parm3, uintptr_t parm4, uintptr_t parm5);
- ``SWI`` with ``SYS_`` call number and six parameters
- ``SWI`` with ``SYS_`` call number and six parameters:
.. code-block:: C
.. code-block:: C
uintptr_t sys_call6(unsigned int nbr, uintptr_t parm1, uintptr_t parm2,
uintptr_t parm3, uintptr_t parm4, uintptr_t parm5,