Mirrors_Framework/nuttx
1
0
Fork 0
mirror of https://github.com/apache/nuttx.git synced 2026-06-05 07:12:54 +08:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge commit '2e43815c929acb818b34a5ff8828494b0c6f6891' into dev

Browse Source 
Change-Id: Idcbac12fec435abff01cfb4efd5a26a02eb08f93
This commit is contained in:
Xiang Xiao
2021-07-13 00:55:36 +08:00
parent eafc254e14 2e43815c92
commit c8f1eeed57
3728 changed files with 185024 additions and 40147 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/workflows/build.yml
+2 -2
View File
@@ -114,7 +114,7 @@ jobs:
strategy:
matrix:
boards: [arm-01, arm-02, arm-03, arm-04, arm-05, arm-06, arm-07, arm-08, arm-09, arm-10, arm-11, arm-12, arm-13, other, risc-v, sim01, sim02, xtensa]
boards: [arm-01, arm-02, arm-03, arm-04, arm-05, arm-06, arm-07, arm-08, arm-09, arm-10, arm-11, arm-12, arm-13, other, risc-v, sim-01, sim-02, xtensa]
steps:
- name: Download Source Artifact
@@ -159,7 +159,7 @@ jobs:
needs: Fetch-Source
strategy:
matrix:
boards: [macos, sim01, sim02]
boards: [macos, sim-01, sim-02]
steps:
- name: Download Source Artifact
uses: actions/download-artifact@v1
Documentation/applications/nsh/commands.rst
+5 -2
View File
@@ -495,8 +495,9 @@ Show Memory Manager Status (free)
example::
nsh> free
total used free largest
Mem: 4194288 1591552 2602736 2601584
total used free largest nused nfree
Mem: 5583024 1614784 3968240 3967792 244 4
nsh>
**Where:**
@@ -506,6 +507,8 @@ total This is the total size of memory allocated for use by malloc in bytes.
used This is the total size of memory occupied by chunks handed out by malloc.
free This is the total size of memory occupied by free (not in use) chunks.
largest Size of the largest free (not in use) chunk.
nused This is the number of allocated chunks
nfree This is the number of free chunks
======= ======================================
.. _cmdget:
Documentation/applications/nsh/login.rst
+1 -1
View File
@@ -57,7 +57,7 @@ credentials at login time:
This is not very flexible since there can be only one user and the
password is fixed in the FLASH image. This option is also not very
secure because a malicious user could get the password by just
looking at the ``.text`` stings in the flash image.
looking at the ``.text`` strings in the flash image.
#. NSH can also be configured to defer the entire user credential
verification to platform-specific logic with this setting::
Documentation/components/drivers/character/foc.rst
+2 -2
View File
@@ -13,11 +13,11 @@ The device on the kernel side is responsible for the following:
#. return ADC current samples
#. synchronize user-space with PWM events
The Nuttx FOC driver is split into two parts:
The NuttX FOC driver is split into two parts:
#. An "upper half", generic driver that provides the common FOC
interface to application level code,
#. A "lower half", platform-specific driver that implemets
#. A "lower half", platform-specific driver that implements
the low-level logic to implement the FOC functionality
Files supporting FOC can be found in the following locations:
Documentation/components/drivers/character/watchdog.rst
+11 -11
View File
@@ -65,7 +65,7 @@ Enabling the Watchdog Support and Example in ``menuconfing``
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.
Go into menu :menuselection:`Build Setup --> Debug Options` and press :kbd:`Enter`. Then enable:
- [x] Enable Debug Features
@@ -79,7 +79,7 @@ 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.
* 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.
@@ -136,7 +136,7 @@ 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 miliseconds.
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
@@ -153,12 +153,12 @@ This command registers an user callback that will be triggered on timeout. It re
.. c:macro:: WDIOC_KEEPALIVE
This command resets the watchdog timer AKA '**ping**", "**kick**", "**pet**", "**feed**" the dog".
This command resets the watchdog timer AKA '**ping**", "**kick**", "**pet**", "**feed**" the dog".
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:
@@ -181,16 +181,16 @@ To enable it, follow the next instructions:
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 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".
``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.
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`.
- [x] Low priority (kernel) worker thread
@@ -200,5 +200,5 @@ To enable it, follow the next instructions:
Go into menu :menuselection:`Device Drivers` and enable:
- [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.
Documentation/components/drivers/special/syslog.rst
+4 -3
View File
@@ -392,7 +392,8 @@ mounting of the file systems.
The interface ``syslog_file_channel()`` is used to configure the
SYSLOG file channel:
.. c:function:: int syslog_file_channel(FAR const char *devpath);
.. c:function:: FAR struct syslog_channel_s *
syslog_file_channel(FAR const char *devpath);
Configure to use a file in a mounted file system
at ``devpath`` as the SYSLOG channel.
@@ -423,8 +424,8 @@ SYSLOG file channel:
``syslog_file_channel()`` will create the file.
:return:
Zero (``OK``) is returned on success; a
negated ``errno`` value is returned on any failure.
A pointer to the new syslog channel; ``NULL`` is returned
on any failure.
References: ``drivers/syslog/syslog_filechannel.c``,
``drivers/syslog/syslog_device.c``, and
Documentation/components/nxgraphics/nxtk.rst
+2 -2
View File
@@ -500,9 +500,9 @@ these sub-windows to be managed more-or-less independently:
:param rect:
The location within the toolbar window to be retrieved.
:param plane:
TSpecifies the color plane to get from.
Specifies the color plane to get from.
:param dest:
TThe location to copy the memory region.
The location to copy the memory region.
:param deststride:
The width, in bytes, of the dest memory.
Documentation/contributing/documentation.rst
+3 -3
View File
@@ -24,7 +24,7 @@ go into ``Documentation`` directory. Then,
$ pip3 install pipenv
$ pipenv install
$ # activate the virtual environent
$ # activate the virtual environment
$ pipenv shell
2. Build documentation:
@@ -82,7 +82,7 @@ sometimes Sphinx's approach is used over standard RST since it is more powerful
Documentation Conventions
=========================
While RST/Sphinx provide many ways to do things, it is best to follow a given convention to mantain consistency and avoid
While RST/Sphinx provide many ways to do things, it is best to follow a given convention to maintain consistency and avoid
pitfalls. For this reason, documentation changes should follow the following set of conventions.
Indentation
@@ -180,7 +180,7 @@ Tips
Spacing
-------
If you are getting formatting errors, be sure to provide the appropiate spacing between a directive and its content.
If you are getting formatting errors, be sure to provide the appropriate spacing between a directive and its content.
Generally, you should follow this format:
.. code-block:: RST
Documentation/contributing/workflow.rst
+2 -2
View File
@@ -13,7 +13,7 @@ You should be aware of the following:
automatically during CI to ensure conformance.
Note that not all existing files in the repository are already adapted to conform to the standard as this is an ongoing effort. Thus,
if you're submitting a patch to an existing file you may have to make the file conform to the standard, even if you are not reponsible
if you're submitting a patch to an existing file you may have to make the file conform to the standard, even if you are not responsible
for those standard violations.
It is also appreciated that you separate any styling fixes in a separate commit from the functional changes so that these are more
@@ -37,6 +37,6 @@ You should be aware of the following:
- If this is from an inactive project, it may be considered for inclusion in NuttX, provided that licensing terms allow to do so
and it is deemed of sufficient value to be included, considering that this code will have to be maintained in NuttX afterwards.
Note that it is undesireable to included non Apache 2.0 Licensed code inside the repository, even if the license itself allows it
Note that it is undesirable to included non Apache 2.0 Licensed code inside the repository, even if the license itself allows it
(for example BSD License).
Documentation/guides/cpp_cmake.rst
+1 -1
View File
@@ -76,7 +76,7 @@ Creating the project
project(HelloCpp
VERSION 1.0
DESCRIPTION "Hello world C++ Nuttx"
DESCRIPTION "Hello world C++ NuttX"
)
set(CMAKE_CXX_STANDARD 17)
Documentation/guides/tasktraceuser.rst
+2 -2
View File
@@ -109,7 +109,7 @@ After getting the trace, the following command displays the accumulated trace da
nsh> trace dump
This will be get the trace results like the followings:
This will get the trace results like the following:
.. code-block::
@@ -266,7 +266,7 @@ The default value is given by the kernel configuration ``CONFIG_SCHED_INSTRUMENT
- ``-a`` : Disable recording the system call arguments.
- ``+i`` : Enable interrupt trace.
It records the event of enter/leave interrupt handler which is occured while the tracing.
It records the event of enter/leave interrupt handler which occurred while tracing.
All IRQs are recorded by default. ``trace irq`` command can filter the IRQs to be recorded.
- ``-i`` : Disable interrupt trace.
Documentation/introduction/detailed_support.rst
+1 -1
View File
@@ -2464,7 +2464,7 @@ Also refer to the NuttX board
file for further information about the current state of the port.
NuttX-9.0 added basic support for Microchip SAME54 Xplained Pro board.
An ethernet driver was also added to the SAME5x familly.
An ethernet driver was also added to the SAME5x family.
STMicro STM32 F72x/F73x
-----------------------
Documentation/introduction/resources.rst
+1 -1
View File
@@ -13,7 +13,7 @@ Here's a list of Apache NuttX resources that you might find helpful:
* `Apache NuttX mailing list <https://nuttx.apache.org/community/>`_ – a very active mailing list, the place to get help with your application or any questions you have about NuttX.
* `Apache NuttX YouTube channel <https://www.youtube.com/channel/UC0QciIlcUnjJkL5yJJBmluw/videos>`_ – Alan Carvalho de Assis's YouTube channel on NuttX. It's a source of a lot of great practical information.
* `Apache NuttX Coding Standard <https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard>`_ — How code should look when you submit new files or modify existing ones.
* `Apache NuttX Code Contribution Guidlines <https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow>`_ — The full workflow to follow for submitting code with all the details.
* `Apache NuttX Code Contribution Guidelines <https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow>`_ — The full workflow to follow for submitting code with all the details.
* Git
Documentation/platforms/arm/imxrt/boards/imxrt1020-evk/index.rst
+103
View File
@@ -0,0 +1,103 @@
===============
i.MX RT1020 EVK
===============
`i.MX RT1020 EVK <https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/i-mx-rt1020-evaluation-kit:MIMXRT1020-EVK>`_
is an evaluation kit by NXP company. This kit uses the i.MX RT1020 crossover MCU in LQFP144 package with ARM Cortex M7 core.
Features
========
- Processor
- MIMXRT1021DAG5A processor
- Memory
- 256 Mb SDRAM memory
- 64 Mb QSPI Flash
- TF socket for SD card
- Display and Audio
- Audio CODEC
- 4-pole audio headphone jack
- External speaker connection
- Microphone
- Connectivity
- Micro USB host and OTG connectors
- Ethernet (10/100T) connector
- CAN transceivers
- Arduino® interface
Serial Console
==============
The EVK default console is on LPUART1, which is multiplexed onto
the debug port (either OpenSDA or SEGGER JLink).
It runs at 115200,n,8,1.
LEDs and Buttons
================
LEDs
----
There is one user accessible LED status indicator located on the 1020-EVK,
USERLED. The function of the LEDs include:
=== ============ ======
Pin Description Colour
=== ============ ======
D3 Power Supply Green
D5 User LED Green
D15 Reset LED Red
=== ============ ======
This LED is not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/imxrt_autoleds.c. The LED is used to encode
OS-related events as documented in board.h
================ ======================= =====
SYMBOL Meaning LED
================ ======================= =====
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt N/C
LED_SIGNAL In a signal handler N/C
LED_ASSERTION An assertion failed N/C
LED_PANIC The system has crashed FLASH
================ ======================= =====
Thus if the LED is statically on, NuttX has successfully booted and is,
apparently, running normally. If the LED is flashing at approximately
2Hz, then a fatal error has been detected and the system has halted.
Buttons
-------
This IMXRT board has three external buttons
=== ============== ========================
SW2 (IRQ88, ONOFF) Not on a GPIO, No muxing
SW3 (IRQ88, POR) Not on a GPIO, No muxing
SW4 (IRQ88, USER) Wakeup, GPIO5-0
=== ============== ========================
Configurations
==============
netnsh
------
This configuration is similar to the nsh configuration except that is
has networking enabled, both IPv4 and IPv6. This NSH configuration is
focused on network-related testing.
nsh
---
Configures the NuttShell (nsh) located at examples/nsh. This NSH
configuration is focused on low level, command-line driver testing.
Built-in applications are supported, but none are enabled. This
configuration does not support a network.
Documentation/platforms/arm/imxrt/boards/imxrt1050-evk/index.rst
+129
View File
@@ -0,0 +1,129 @@
===============
i.MX RT1050 EVK
===============
`i.MX RT1050 EVK <https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/i-mx-rt1050-evaluation-kit:MIMXRT1050-EVK>`_
is an evaluation kit by NXP company. This kit uses the i.MX RT1050 crossover MCU with ARM Cortex M7 core.
Features
========
- Processor
- MIMXRT1052DVL6A processor
- Memory
- 256 Mb SDRAM memory
- 512 Mb Hyper Flash
- Footprint for QSPI Flash
- TF socket for SD card
- Display and Audio
- Parallel LCD connector
- Camera connector
- Audio CODEC
- 4-pole audio headphone jack
- External speaker connection
- Microphone
- SPDIF connector
- Connectivity
- Micro USB host and OTG connectors
- Ethernet (10/100T) connector
- CAN transceivers
- Arduino® interface
Serial Console
==============
Virtual console port provided by OpenSDA:
========= ============= ==========
UART1_TXD GPIO_AD_B0_12 LPUART1_TX
UART1_RXD GPIO_AD_B0_13 LPUART1_RX
========= ============= ==========
Arduino RS-232 Shield:
=== == ======= ============= ==========
J22 D0 UART_RX GPIO_AD_B1_07 LPUART3_RX
J22 D1 UART_TX GPIO_AD_B1_06 LPUART3_TX
=== == ======= ============= ==========
LEDs and buttons
================
LEDs
----
There are four LED status indicators located on the EVK Board. The
functions of these LEDs include:
=== ============
Pin Description
=== ============
D3 Power Supply
D15 Reset LED
D16 OpenSDA
D18 User LED
=== ============
Only a single LED, D18, is under software control. It connects to
GPIO_AD_B0_09 which is shared with JTAG_TDI and ENET_RST
This LED is not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/imxrt_autoleds.c. The LED is used to encode
OS-related events as follows:
================ ======================= =====
SYMBOL Meaning LED
================ ======================= =====
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt N/C
LED_SIGNAL In a signal handler N/C
LED_ASSERTION An assertion failed N/C
LED_PANIC The system has crashed FLASH
================ ======================= =====
Thus if the LED is statically on, NuttX has successfully booted and is,
apparently, running normally. If the LED is flashing at approximately
2Hz, then a fatal error has been detected and the system has halted.
Buttons
-------
There are four user interface switches on the MIMXRT1050 EVK Board:
- SW1: Power Switch (slide switch)
- SW2: ON/OFF Button
- SW3: Reset button
- SW8: User button
Only the user button is available to the software. It is sensed on the
WAKEUP pin which will be pulled low when the button is pressed.
Configurations
==============
knsh
----
This is identical to the nsh configuration below except that NuttX
is built as a protected mode, monolithic module and the user applications
are built separately. For further information about compiling and
running this configuration please refer to imxrt1064-evk documentation.
netnsh
------
This configuration is similar to the nsh configuration except that is
has networking enabled, both IPv4 and IPv6. This NSH configuration is
focused on network-related testing.
nsh
---
Configures the NuttShell (nsh) located at examples/nsh. This NSH
configuration is focused on low level, command-line driver testing.
Built-in applications are supported, but none are enabled. This
configuration does not support a network.
Documentation/platforms/arm/imxrt/boards/imxrt1060-evk/imxrt1060-evk-front.jpg
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 107 KiB

Documentation/platforms/arm/imxrt/boards/imxrt1060-evk/index.rst
+200
View File
@@ -0,0 +1,200 @@
===============
i.MX RT1060 EVK
===============
`i.MX RT1060 EVK <https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/mimxrt1060-evk-i-mx-rt1060-evaluation-kit:MIMXRT1060-EVK>`_
is an evaluation kit by NXP company. This kit uses the i.MX RT1060 crossover MCU with ARM Cortex M7 core.
.. figure:: imxrt1060-evk-front.jpg
:align: center
:width: 50%
i.MX RT1060 EVK
Features
========
- Processor
- MIMXRT1062DVL6A processor
- Memory
- 1 Mb OCRAM memory
- 256 Mb SDRAM memory
- 512 Mb Hyper Flash - Populated but 0 ohm DNP
- 64 Mb QSPI Flash
- TF socket for SD card
- Display and Audio
- Parallel LCD connector
- Camera connector
- Audio CODEC
- 4-pole audio headphone jack
- External speaker connection
- Microphone
- SPDIF connector
- Connectivity
- Micro USB host and OTG connectors
- Ethernet (10/100T) connector
- CAN transceivers (including one CAN FD)
- Arduino® interface
- Sensors
- FXOS8700CQ 6-Axis Ecompass (3-Axis Mag, 3-Axis Accel)
Serial Console
==============
Virtual console port provided by OpenSDA:
========= ============= ==========
UART1_TXD GPIO_AD_B0_12 LPUART1_TX
UART1_RXD GPIO_AD_B0_13 LPUART1_RX
========= ============= ==========
Arduino RS-232 Shield:
=== == ======= ============= ==========
J22 D0 UART_RX GPIO_AD_B1_07 LPUART3_RX
J22 D1 UART_TX GPIO_AD_B1_06 LPUART3_TX
=== == ======= ============= ==========
LEDs and buttons
================
LEDs
----
There are four LED status indicators located on the EVK Board. The
functions of these LEDs include:
=== ============
Pin Description
=== ============
D3 Power Supply
D18 User LED
D20 OpenSDA
D21 Reset LED
=== ============
Only a single LED, D18, is under software control. It connects to
GPIO_AD_B0_09 which is shared with JTAG_TDI and ENET_RST
This LED is not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/imxrt_autoleds.c. The LED is used to encode
OS-related events as follows:
================ ======================= =====
SYMBOL Meaning LED
================ ======================= =====
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt N/C
LED_SIGNAL In a signal handler N/C
LED_ASSERTION An assertion failed N/C
LED_PANIC The system has crashed FLASH
================ ======================= =====
Thus if the LED is statically on, NuttX has successfully booted and is,
apparently, running normally. If the LED is flashing at approximately
2Hz, then a fatal error has been detected and the system has halted.
Buttons
-------
There are five user interface switches on the MIMXRT1050 EVK Board:
- SW1: Power Switch (slide switch fir power from J2)
- SW2: ON/OFF Button
- SW3: Power-on Reset button state forces to reset the system power except SNVS domain
- SW9: Reset button
- SW8: User button GPIO5-00
Only the user button is available to the software. It is sensed on the
WAKEUP pin which will be pulled low when the button is pressed.
J-Link External Debug Probe
===========================
Install the J-Link Debug Host Tools and make sure they are in your search path.
Attach a J-Link 20-pin connector to J21. Check that jumpers J47 and J48 are
off (they are on by default when boards ship from the factory) to ensure SWD
signals are disconnected from the OpenSDA microcontroller.
Configurations
==============
can
---
This is an nsh configuration (see below) with added support of CAN driver.
FlexCAN3 is chosen as default, the change can be made at System type peripheral
selection. Please note that only FlexCAN3 and FlexCAN2 is available on this board.
Bitrate and sample point can be also changed at System type peripheral selection,
basic values are 1 MHz for bitrate and 0.80 for sample point. The FlexCAN driver
for imxrt runs at 80 MHz clock frequency.
The configuration also includes CAN utilities as candump and cansend.
canfd
-----
This is an nsh configuration (see below) with added support of CAN_FD driver.
FlexCAN3 is chosen as default, please note that only FlexCAN3 is capable of
providing CAN_FD support.
Bitrate and sample point can be also changed at System type peripheral selection,
basic values are 1 MHz for bitrate and 0.80 for sample point for arbitration phase
and 4 MHz (bitrate) and 0.90 (sample point) for data phase. The FlexCAN driver
for imxrt runs at 80 MHz clock frequency.
The configuration also includes CAN utilities as candump and cansend.
knsh
----
This is identical to the nsh configuration below except that NuttX
is built as a protected mode, monolithic module and the user applications
are built separately. For further information about compiling and
running this configuration please refer to imxrt1064-evk documentation.
netnsh
------
This configuration is similar to the nsh configuration except that is
has networking enabled, both IPv4 and IPv6. This NSH configuration is
focused on network-related testing.
nsh
---
Configures the NuttShell (nsh) located at examples/nsh. This NSH
configuration is focused on low level, command-line driver testing.
Built-in applications are supported, but none are enabled. This
configuration does not support a network.
lvgl
----
Configures the Littlev graphic library (lvgl) demo located under
examples/lvgldemo. This configuration needs the optional LCD model
RK043FN02H-CT from NXP. The LCD panel comes with the integrated
capacitive touchscreen sensor FT5336GQQ connected to the LPI2C1 bus,
address 0x38. NuttX support such touchscreen device via the driver
ft5x06 (drivers/input/ft5x06.c). At the moment only the polling
method is available, the board features an interrupt line connected
to the touchscreen sensor IC.
IMXRT1060 MCU provides the integrated LCD driver.
The LCD panel features:
- size 4.3"
- resolution 480×272 RGB
- backlight driver
- dimensions [mm]: 105.5 (W) x 67.2(H) x 4.35(D) Max.
To run the lvgl demo please type "lvgldemo" at nsh prompt::
nsh> lvgldemo
Documentation/platforms/arm/imxrt/boards/imxrt1064-evk/index.rst
+277
View File
@@ -0,0 +1,277 @@
===============
i.MX RT1064 EVK
===============
`i.MX RT1064 EVK <https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/mimxrt1064-evk-i-mx-rt1064-evaluation-kit:MIMXRT1064-EVK>`_
is an evaluation kit by NXP company. This kit uses the i.MX RT1064 crossover MCU with ARM Cortex M7 core.
Features
========
- Processor
- MIMXRT1066DVL6A processor
- Memory
- 1 Mb OCRAM memory
- 256 Mb SDRAM memory
- 512 Mb Hyper Flash - Populated but 0 ohm DNP
- 64 Mb QSPI Flash
- TF socket for SD card
- Display and Audio
- Parallel LCD connector
- Camera connector
- Audio CODEC
- 4-pole audio headphone jack
- External speaker connection
- Microphone
- SPDIF connector
- Connectivity
- Micro USB host and OTG connectors
- Ethernet (10/100T) connector
- CAN transceivers
- Arduino® interface
- Sensors
- FXOS8700CQ 6-Axis Ecompass (3-Axis Mag, 3-Axis Accel)
Serial Console
==============
Virtual console port provided by OpenSDA:
========= ============= ==========
UART1_TXD GPIO_AD_B0_12 LPUART1_TX
UART1_RXD GPIO_AD_B0_13 LPUART1_RX
========= ============= ==========
Arduino RS-232 Shield:
=== == ======= ============= ==========
J22 D0 UART_RX GPIO_AD_B1_07 LPUART3_RX
J22 D1 UART_TX GPIO_AD_B1_06 LPUART3_TX
=== == ======= ============= ==========
LEDs and buttons
================
LEDs
----
There are four LED status indicators located on the EVK Board. The
functions of these LEDs include:
=== ============
Pin Description
=== ============
D3 Power Supply
D18 User LED
D20 OpenSDA
D21 Reset LED
=== ============
Only a single LED, D18, is under software control. It connects to
GPIO_AD_B0_09 which is shared with JTAG_TDI and ENET_RST
This LED is not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/imxrt_autoleds.c. The LED is used to encode
OS-related events as follows:
================ ======================= =====
SYMBOL Meaning LED
================ ======================= =====
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt N/C
LED_SIGNAL In a signal handler N/C
LED_ASSERTION An assertion failed N/C
LED_PANIC The system has crashed FLASH
================ ======================= =====
Thus if the LED is statically on, NuttX has successfully booted and is,
apparently, running normally. If the LED is flashing at approximately
2Hz, then a fatal error has been detected and the system has halted.
Buttons
-------
There are five user interface switches on the MIMXRT1050 EVK Board:
- SW1: Power Switch (slide switch fir power from J2)
- SW2: ON/OFF Button
- SW3: Power-on Reset button state forces to reset the system power except SNVS domain
- SW9: Reset button
- SW8: User button GPIO5-00
Only the user button is available to the software. It is sensed on the
WAKEUP pin which will be pulled low when the button is pressed.
J-Link External Debug Probe
===========================
Install the J-Link Debug Host Tools and make sure they are in your search path.
Attach a J-Link 20-pin connector to J21. Check that jumpers J47 and J48 are
off (they are on by default when boards ship from the factory) to ensure SWD
signals are disconnected from the OpenSDA microcontroller.
Configurations
==============
can
---
This is an nsh configuration (see below) with added support of CAN driver.
FlexCAN3 is chosen as default, the change can be made at System type peripheral
selection. Please note that only FlexCAN3 and FlexCAN2 is available on this board.
Bitrate and sample point can be also changed at System type peripheral selection,
basic values are 1 MHz for bitrate and 0.80 for sample point. The FlexCAN driver
for imxrt runs at 80 MHz clock frequency.
The configuration also includes CAN utilities as candump and cansend.
canfd
-----
This is an nsh configuration (see below) with added support of CAN_FD driver.
FlexCAN3 is chosen as default, please note that only FlexCAN3 is capable of
providing CAN_FD support.
Bitrate and sample point can be also changed at System type peripheral selection,
basic values are 1 MHz for bitrate and 0.80 for sample point for arbitration phase
and 4 MHz (bitrate) and 0.90 (sample point) for data phase. The FlexCAN driver
for imxrt runs at 80 MHz clock frequency.
The configuration also includes CAN utilities as candump and cansend.
knsh
----
This is identical to the nsh configuration below except that NuttX
is built as a protected mode, monolithic module and the user applications
are built separately. It is recommends to use a special make command;
not just 'make' but make with the following two arguments:
.. code-block:: console
$ make pass1 pass2
In the normal case (just 'make'), make will attempt to build both user-
and kernel-mode blobs more or less interleaved. This actual works!
However, for me it is very confusing so I prefer the above make command:
Make the user-space binaries first (pass1), then make the kernel-space
binaries (pass2)
NOTES:
At the end of the build, there will be several files in the top-level
NuttX build directory:
PASS1:
- nuttx_user.elf - The pass1 user-space ELF file
- nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
- User.map - Symbols in the user-space ELF file
PASS2:
- nuttx - The pass2 kernel-space ELF file
- nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
- System.map - Symbols in the kernel-space ELF file
The J-Link programmer will except files in .hex, .mot, .srec, and .bin
formats.
Combining .hex files. If you plan to use the .hex files with your
debugger or FLASH utility, then you may need to combine the two hex
files into a single .hex file. Here is how you can do that.
The 'tail' of the nuttx.hex file should look something like this
(with my comments added beginning with #):
.. code-block:: console::
$ tail nuttx.hex
#xx xxxx 00 data records
...
:10 C93C 00 000000000040184000C2010000000000 90
:10 C94C 00 2400080000801B4000C01B4000001C40 5D
:10 C95C 00 00401C4000000C4050BF0060FF000100 74
#xx xxxx 05 Start Linear Address Record
:04 0000 05 6000 02C1 D4
#xx xxxx 01 End Of File record
:00 0000 01 FF
Use an editor such as vi to remove the 05 and 01 records.
The 'head' of the nuttx_user.hex file should look something like
this (again with my comments added beginning with #):
.. code-block:: console::
$ head nuttx_user.hex
#xx xxxx 04 Extended Linear Address Record
:02 0000 04 6020 7A
#xx xxxx 00 data records
:10 0000 00 8905206030002060F2622060FC622060 80
:10 0010 00 0000242008002420080024205C012420 63
:10 0020 00 140024203D0020603100206071052060 14
...
Nothing needs to be done here. The nuttx_user.hex file should
be fine.
Combine the edited nuttx.hex and un-edited nuttx_user.hex
file to produce a single combined hex file:
.. code-block:: console::
$ cat nuttx.hex nuttx_user.hex >combined.hex
Then use the combined.hex file with the to write the FLASH image.
If you do this a lot, you will probably want to invest a little time
to develop a tool to automate these steps.
STATUS: This configuration was added on 8 June 2018 primarily to assure
that all of the components are in place to support the PROTECTED mode
build. This configuration, however, has not been verified as of this
writing.
netnsh
------
This configuration is similar to the nsh configuration except that is
has networking enabled, both IPv4 and IPv6. This NSH configuration is
focused on network-related testing.
nsh
---
Configures the NuttShell (nsh) located at examples/nsh. This NSH
configuration is focused on low level, command-line driver testing.
Built-in applications are supported, but none are enabled. This
configuration does not support a network.
lvgl
----
Configures the Littlev graphic library (lvgl) demo located under
examples/lvgldemo. This configuration needs the optional LCD model
RK043FN02H-CT from NXP. The LCD panel comes with the integrated
capacitive touchscreen sensor FT5336GQQ connected to the LPI2C1 bus,
address 0x38. NuttX support such touchscreen device via the driver
ft5x06 (drivers/input/ft5x06.c). At the moment only the polling
method is available, the board features an interrupt line connected
to the touchscreen sensor IC.
IMXRT1064 MCU provides the integrated LCD driver.
The LCD panel features:
- size 4.3"
- resolution 480×272 RGB
- backlight driver
- dimensions [mm]: 105.5 (W) x 67.2(H) x 4.35(D) Max.
To run the lvgl demo please type "lvgldemo" at nsh prompt::
nsh> lvgldemo
Documentation/platforms/arm/imxrt/boards/teensy-4.x/index.rst
+22 -1
View File
@@ -96,7 +96,17 @@ This configuration can be easily changed to work with Teensy 4.0 by
selecting ``CONFIG_TEENSY_40=y``.
This configuration runs over LPUART1 (pins 24 and 25 on Teensy). Communication
over USB console can be turn on, but it couses problems with FlexCAN.
over USB console can be turn on, but it causes problems with FlexCAN.
enc-4.1
-------
This is an nsh configuration (see above) with added support of incremental
encoder. Phase A is connected to GPIO_EMC_07 (pin 33), phase B to GPIO_EMC_06
(pin 4) and INDEX to GPIO_B0_12 (pin 32). Only encoder 1 is connected to those
pins.
Function of the encoder can be tested by application "qe".
netnsh-4.1
----------
@@ -108,6 +118,17 @@ focused on network-related testing.
This configuration cannot be changed to Teensy 4.0 as this board does
not have Ethernet capability.
pwm-4.1
-------
This configuration is similar to the nsh configuration with enabled
FlexPWM driver. Submodules 1 (pin 4) and 2 (pin 5) of FlexPWM2 are turn
on aswell as ultiple channel PWM output. Functionality can be tested
with example application "pwm". Each channel runs different duty cycle.
This configuration can be easily changed to work with Teensy 4.0 by
selecting ``CONFIG_TEENSY_40=y``.
sd-4.1
------
Documentation/platforms/arm/imxrt/index.rst
+10 -8
View File
@@ -52,7 +52,7 @@ ENET Yes
FlexIO No
GPIO Yes
I2S Yes
PWM No
PWM Yes
SAI No
SPDIF No
SPI Yes
@@ -69,7 +69,7 @@ range of supply voltage (rail-to-rail operation).
ADC
---
ADC driver with the successive approximation analog/digital convertor. The lower-half of
ADC driver with the successive approximation analog/digital converter. The lower-half of
this driver is initialize by calling :c:func:`imxrt_adcinitialize`.
CAN
@@ -82,7 +82,7 @@ calling :c:func:`imxrt_cannitialize()`.
There is an booting option that automatically provides initialization of network interface
in the early stages of booting and therefore calling :c:func:`imxrt_cannitialize()` via
board specific logic is not neccessary. This however works only when there is only one
board specific logic is not necessary. This however works only when there is only one
interface in the chip. For running more interfaces (like CAN and Ethernet), network late
initialization must be turn on by CONFIG_NETDEV_LATEINIT and board specific logic must call
lower-half part of drivers.
@@ -95,7 +95,7 @@ CMOS Sensor interface which enables the chip to connect directly to external CMO
DAC
---
Digital/analog convertor for external signal is only supported in i.MX RT1170 MCU. It is 12 bit
Digital/analog converter for external signal is only supported in i.MX RT1170 MCU. It is 12 bit
lower power, general purpose DAC.
eLCDIF
@@ -117,7 +117,7 @@ by calling :c:func:`imxrt_netnitialize`.
There is an booting option that automatically provides initialization of network interface
in the early stages of booting and therefore calling :c:func:`imxrt_cannitialize()` via
board specific logic is not neccessary. This however works only when there is only one
board specific logic is not necessary. This however works only when there is only one
interface in the chip. For running more interfaces (like CAN and Ethernet), network late
initialization must be turn on by CONFIG_NETDEV_LATEINIT and board specific logic must call
lower-half part of drivers.
@@ -137,7 +137,7 @@ done by :c:func:`imxrt_gpio_write` function and reading is done by :c:func:`imxr
MCUs i.MX RT1060 and higher includes both standard speed GPIOs (1-5) and high speed
GPIOS (6-9). Regular and high speed GPIO share the same pins (GPIO1 is with GPIO6 etc),
therefore IOMUXC_GPR_GPR26-29 registers are used to determine what modue is used for the
therefore IOMUXC_GPR_GPR26-29 registers are used to determine what module is used for the
GPIO pins.
@@ -150,7 +150,9 @@ as a slave. The lower-half of this driver is initialize by calling :c:func:`imxr
PWM
---
Pulse width modulator supported in i.MX RT1010 and higher.
Pulse width modulator supported in i.MX RT1010 and higher. Multiple channels option is evailable.
Output on pin B is currently supported only as a complementary option to pin A.
The lower-half of this driver is initialize by calling :c:func:`imxrt_pwminitialize`.
SAI
---
@@ -160,7 +162,7 @@ Synchronous audio interface provided by I2C module. Supported in i.MX RT1015 and
SPDIF
-----
Sony/Philips digital interface audio block. It is a stereo transciever that allows the
Sony/Philips digital interface audio block. It is a stereo transceiver that allows the
processor to receive and transmit digital audio. Supported in i.MX RT1010 and higher.
SPI
Documentation/platforms/arm/nrf52/index.rst
+5 -5
View File
@@ -63,7 +63,7 @@ GPIO/GPIOTE
-----------
Pins can be configured/operated using ``nrf52_gpio_*`` functions. Interrupts are
handled via the GPIOTE peripheral in one of two ways: via a GPIOTE channel or via
handled via the GPIOTE peripheral in one of two ways: via a GPIOTE channel or via
PORT events. The former allows for simultaneous rising/falling edge-sensitive interrupts
per-pin. However, as there are a limited number of channels (and sometimes these
are used by some drivers for specific tasks), it may not always be possible to use
@@ -88,7 +88,7 @@ is initialized by calling :c:func:`nrf52_adcinitialize`.
I2C
---
I2C is supported both in polling and interrupt mode (via EasyDMA).
I2C is supported both in polling and interrupt mode (via EasyDMA).
.. note:: The I2C peripheral does not support sending two transfers without sending
a START nor RSTART. For this reason, this is supported via an internal buffer where
@@ -105,7 +105,7 @@ SPI is supported both in polling and interrupt-based (via EasyDMA) mode. The lat
supports arbitrarily long transfers using Nordic's list-mode EasyDMA (intermediate
transfers are currently still manually started).
It is possible to use SPI without either MOSI/MISO pin defined by simply not providing
It is possible to use SPI without either MOSI/MISO pin defined by simply not providing
the relevant ``BOARD_SPI*_MISO/MOSI_PIN`` definition.
This implementation support power management hooks, which will disable SPI peripheral when
@@ -115,7 +115,7 @@ UART
----
UART is implemented using polling. UARTE EasyDMA feature is not yet supported.
This may introduce a large number of interrupts which may be undesireable.
This may introduce a large number of interrupts which may be undesirable.
PPI
---
@@ -166,7 +166,7 @@ you need to call :c:func:`nrf52_sdc_initialize` on boot, which will initialize t
SDC support involves registering various high-priority zero-latency interrupts and thus requires
enabling BASEPRI and high-priority interrupt support. On supported boards, a sample ``sdc`` configuration
is provided with settings already set.
is provided with settings already set.
Note that in this case, some peripherals (mostly those related to BLE) will be unavailable. Some PPI
channels will also be ocuppied (``NRF52_PPI_NUM_CONFIGURABLE_CHANNELS`` will be set accordingly in this case).
Documentation/platforms/risc-v/esp32c3/boards/esp32c3-devkit/ESP32-C3-DevKitC-02-v1.1.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.2 MiB

Documentation/platforms/risc-v/esp32c3/boards/esp32c3-devkit/ESP32-C3-DevKitM-1-v1.0.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.5 MiB

Documentation/platforms/risc-v/esp32c3/boards/esp32c3-devkit/index.rst
+97
View File
@@ -0,0 +1,97 @@
===============
ESP32-C3 DevKit
===============
The ESP32-C3 DevKit is an entry-level development board equipped with either
an ESP32-C3-WROOM-02 or an ESP32-C3-MINI-1.
ESP32-C3-WROOM-02 and ESP32-C3-MINI-1 are SoMs based on the RISC-V ESP32-C3 CPU.
Most of the I/O pins are broken out to the pin headers on both sides for easy
interfacing. Developers can either connect peripherals with jumper wires or
mount ESP32-C3 DevKit on a breadboard.
.. list-table::
:align: center
* - .. figure:: ESP32-C3-DevKitC-02-v1.1.png
:align: center
ESP32-C3-DevKitC-02
- .. figure:: ESP32-C3-DevKitM-1-v1.0.png
:align: center
ESP32-C3-DevKitM-1
Buttons and LEDs
================
Buttons
-------
There are two buttons labeled Boot and RST. The RST button is not available
to software. It pulls the chip enable line that doubles as a reset line.
The BOOT button is connected to IO9. On reset it is used as a strapping
pin to determine whether the chip boots normally or into the serial
bootloader. After reset, however, the BOOT button can be used for software
input.
LEDs
----
There is one on-board LED that indicates the presence of power.
Another WS2812 LED is connected to GPIO8 and is available for software.
Configurations
==============
nsh
---
Basic configuration to run the NuttShell (nsh).
gpio
____
This is a test for the GPIO driver. It uses GPIO1 and GPIO2 as outputs and
GPIO9 as an interrupt pin.
At the nsh, we can turn the outputs on and off with the following::
nsh> gpio -o 1 /dev/gpout0
nsh> gpio -o 1 /dev/gpout1
nsh> gpio -o 0 /dev/gpout0
nsh> gpio -o 0 /dev/gpout1
We can use the interrupt pin to send a signal when the interrupt fires::
nsh> gpio -w 14 /dev/gpint2
The pin is configured as a rising edge interrupt, so after issuing the
above command, connect it to 3.3V.
watchdog
--------
This configuration tests the watchdog timers. It includes the 2 MWDTS,
adds driver support, registers the WDTs as devices and includes the watchdog
example application.
To test it, just run the following command::
nsh> wdog -i /dev/watchdogX
Where X is the watchdog instance.
watcher
-------
This configuration tests the watchdog timers in the capture mode.
It includes the 2 MWDTS, adds driver support, registers the WDTs as devices
and includes the watcher and watched example applications.
To test it, just run the following command::
nsh> watcher
nsh> watched
Documentation/platforms/risc-v/esp32c3/index.rst
+127
View File
@@ -0,0 +1,127 @@
==================
Espressif ESP32-C3
==================
The ESP32-C3 is an ultra-low-power and highly integrated SoC with a RISC-V
core and supports 2.4 GHz Wi-Fi and Bluetooth Low Energy.
* Address Space
- 800 KB of internal memory address space accessed from the instruction bus
- 560 KB of internal memory address space accessed from the data bus
- 1016 KB of peripheral address space
- 8 MB of external memory virtual address space accessed from the instruction bus
- 8 MB of external memory virtual address space accessed from the data bus
- 480 KB of internal DMA address space
* Internal Memory
- 384 KB ROM
- 400 KB SRAM (16 KB can be configured as Cache)
- 8 KB of SRAM in RTC
* External Memory
- Up to 16 MB of external flash
* Peripherals
- 35 peripherals
* GDMA
- 7 modules are capable of DMA operations.
ESP32-C3 Toolchain
==================
A generic RISC-V toolchain can be used to build ESP32-C3 projects.
SiFive's toolchain can be downloaded from: https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-ubuntu14.tar.gz
Second stage bootloader and partition table
===========================================
The NuttX port for now relies on IDF's second stage bootloader to carry on some hardware
initializations. The binaries for the bootloader and the partition table can be found in
this repository: https://github.com/espressif/esp-nuttx-bootloader
That repository contains a dummy IDF project that's used to build the bootloader and
partition table, these are then presented as Github assets and can be downloaded
from: https://github.com/espressif/esp-nuttx-bootloader/releases
Download ``bootloader-esp32c3.bin`` and ``partition-table-esp32c3.bin`` and place them
in a folder, the path to this folder will be used later to program them. This
can be: ``../esp-bins``
Building and flashing
=====================
First make sure that ``esptool.py`` is installed. This tool is used to convert
the ELF to a compatible ESP32 image and to flash the image into the board.
It can be installed with: ``pip install esptool``.
Configure the NUttX project: ``./tools/configure.sh esp32c3-devkit:nsh``
Run ``make`` to build the project. Note that the conversion mentioned above is
included in the build process.
The `esptool.py` command to flash all the binaries is::
esptool.py --chip esp32c3 --port /dev/ttyUSBXX --baud 921600 write_flash 0x0 bootloader.bin 0x8000 partition-table.bin 0x10000 nuttx.bin
However, this is also included in the build process and we can build and flash with::
make download ESPTOOL_PORT=<port> ESPTOOL_BINDIR=../esp-bins
Where ``<port>`` is typically ``/dev/ttyUSB0`` or similar and ``../esp-bins`` is
the path to the folder containing the bootloader and the partition table
for the ESP32-C3 as explained above.
Note that this step is required only one time. Once the bootloader and partition
table are flashed, we don't need to flash them again. So subsequent builds
would just require: ``make download ESPTOOL_PORT=/dev/ttyUSBXX``
Debugging with OpenOCD
======================
Download and build OpenOCD from Espressif, that can be found in
https://github.com/espressif/openocd-esp32
If you have an ESP32-C3 ECO3, no external JTAG is required to debug, the ESP32-C3
integrates a USB-to-JTAG adapter.
OpenOCD can then be used::
openocd -c 'set ESP_RTOS none' -f board/esp32c3-builtin.cfg
For versions prior to ESP32-C3 ECO3, an external JTAG adapter is needed.
It can be connected as follows::
TMS -> GPIO4
TDI -> GPIO5
TCK -> GPIO6
TDO -> GPIO7
Furthermore, an efuse needs to be burnt to be able to debug::
espefuse.py -p <port> burn_efuse DIS_USB_JTAG
OpenOCD can then be used::
openocd -c 'set ESP_RTOS none' -f board/esp32c3-ftdi.cfg
Peripheral Support
==================
The following list indicates the state of peripherals' support in NuttX:
========== ======= =====
Peripheral Support NOTES
========== ======= =====
GPIO Yes
UART Yes
SPI Yes
I2C Yes
DMA Yes
Wifi Yes
SPIFLASH Yes
Timers Yes
Watchdog Yes
RTC No
RNG Yes
AES No
eFuse No
ADC No
Bluetooth No
LED_PWM No
SHA No
RSA No
========== ======= =====
Documentation/platforms/risc-v/mpfs/boards/icicle/icicle.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.5 MiB

Documentation/platforms/risc-v/mpfs/boards/icicle/index.rst
+79
View File
@@ -0,0 +1,79 @@
====================
PolarFire Icicle Kit
====================
.. list-table::
:align: center
* - .. figure:: icicle.png
:align: center
CPU
---
PolarFire SoC FPGA (MPFS250T-FCVG484EES)
- SiFive E51 Monitor core (1 x RV64IMAC)
- SiFive U54 Application cores (4 x RV64GC)
- and Secure boot
Memory and storage
------------------
- 2 GB LPDDR4 x 32
- 1 Gb SPI flash
- 8 GB eMMC flash & SD card slot (multiplexed)
Programming & Debugging
-----------------------
Onboard JTAG connector or onboard embedded FlashPro (multiplexed)
- UART via micro USB
- 52 x test points
Interfaces
----------
- 4 x 12.7 Gbps SERDES
- PCIe Gen2 Rootport
- 2 x Gigabit Ethernet
- Micro USB 2.0 Hi-Speed OTG
- 4 x UART (via single micro USB)
- 2 x CAN
- 2 x SPI
- 2 x I²C
Expansion
---------
- Raspberry Pi compatible 40-pin header
- mikroBUS socket
Sensor
------
- Power sensor (pac1934)
Buttons and LEDs
================
Buttons
-------
There are 3 buttons and reset button. The Reset button is not available
to software by default.
LEDs
----
There is 4 user controlled on-board LEDs.
Configurations
==============
nsh
---
Basic configuration to run the NuttShell (nsh).
Documentation/platforms/risc-v/mpfs/index.rst
+82
View File
@@ -0,0 +1,82 @@
===========================
Microchip Polarfile (MPFS)
===========================
RV64 64-bit RISC-V multiprocessor-based Microcontroller Subsystem
(MPFS025T, MPFS095T, MPFS160T, MPFS250T, MPFS460T)
MPFS Toolchain
==============
A generic RISC-V toolchain can be used to build MPFS projects.
Like: https://xpack.github.io/riscv-none-embed-gcc or https://github.com/sifive/freedom-tools/releases
Booting
=======
The NuttX port for now relies on HSS bootloader to carry on some hardware initializations.
Building and flashing
=====================
First make sure that ``hss-payload-generator`` is installed.
Available from: https://github.com/polarfire-soc/hart-software-services
This tool is used to convert the ELF/bin to a compatible HSS payload image
Configure the NuttX project: ``./tools/configure.sh icicle:nsh``
Run ``make`` to build the project.
Create HSS payload bin::
hss-payload-generator -v -c hss-nuttx.yml payload.bin
Debugging with OpenOCD
======================
Compatible OpenOCD and configs can be downloaded from:
https://www.microsemi.com/product-directory/design-tools/4879-softconsole#downloads
OpenOCD can then be used::
openocd -c "set DEVICE MPFS" --file board/microsemi-riscv.cfg
Peripheral Support
==================
The following list indicates the state of peripherals' support in NuttX:
============ ======= =====
Peripheral Support NOTES
============ ======= =====
GPIO Yes
MMUART Yes Uart mode only
SPI Yes
I2C Yes
Timers No
Watchdog No
RTC No
CAN No
eNVM No
USB No
eMMC SD/SDIO No
============ ======= =====
Supported Boards
================
.. toctree::
:glob:
:maxdepth: 1
boards/*/*
Documentation/platforms/xtensa/esp32/index.rst
+1 -1
View File
@@ -417,7 +417,7 @@ I assume that:
- You did not install OpenOCD; binaries are available at
openocd-esp32/src and interface scripts are in
openocd-eps32/tcl/interface
openocd-esp32/tcl/interface
- I select the configuration for the Olimex ARM-USB-OCD
debugger.
Documentation/quickstart/compiling.rst
+3 -3
View File
@@ -21,7 +21,7 @@ a pre-existing configuration. To list all supported configurations you can do:
$ ./tools/configure.sh -L | less
The output is in the format ``<board name>:<board configuration>``. You will see that
generally all boards support the ``nsh`` configuration which is a good sarting point
generally all boards support the ``nsh`` configuration which is a good starting point
since it enables booting into the interactive command line
:doc:`/applications/nsh/index`.
@@ -43,7 +43,7 @@ configuration system with:
$ cd nuttx/
$ make menuconfig
Modifying the configuration is covered in :doc:`configuring`.
Build NuttX
@@ -66,7 +66,7 @@ To clean the build, you can do:
.. code-block:: console
$ make clean
.. tip::
To increase build speed (or of any other target such as ``clean``), you can
Documentation/quickstart/install.rst
+3 -2
View File
@@ -61,7 +61,7 @@ First, install the following set of system dependencies according to your Operat
KConfig frontend
----------------
NuttX configuration system uses `KConfig <https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt>`_ which is exposed via a series of interactive menu-based *frontends*, part of the ``kconfig-frontends`` package. Depending on your OS you may use a precompiled package or you will have to build it from source:
NuttX configuration system uses `KConfig <https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt>`_ which is exposed via a series of interactive menu-based *frontends*, part of the ``kconfig-frontends`` package. Depending on your OS you may use a precompiled package or you will have to build it from source, which is available in the `NuttX tools repository <https://bitbucket.org/nuttx/tools/src/master/kconfig-frontends/>`_:
.. tabs::
@@ -71,12 +71,13 @@ NuttX configuration system uses `KConfig <https://www.kernel.org/doc/Documentati
.. code-tab:: console MacOS, Ubuntu 18.04 LTS and earlier
$ git clone https://bitbucket.org/nuttx/tools.git
$ cd tools/kconfig-frontends
$ # on MacOS do the following:
$ patch < ../kconfig-macos.diff -p 1
$ ./configure --enable-mconf --disable-shared --enable-static --disable-gconf --disable-qconf --disable-nconf
$ # on Linux do the following:
$ ./configure --enable-mconf --disable-nconf --disable-gconf --disable-qconf
$ ./configure --enable-mconf --disable-nconf --disable-gconf --disable-qconf
$ make
$ make install
Documentation/quickstart/running.rst
+8 -8
View File
@@ -11,7 +11,7 @@ which also integrates the debugger/programmer in the board itself exposed via US
connector.
A good choice is a Nucleo or Discovery board from ST Microelectronics,
as there is a wide choice of suported boards for the STM32 architecture in NuttX.
as there is a wide choice of supported boards for the STM32 architecture in NuttX.
Also, these boards expose an UART port over the USB connection which allows you
to interact with NuttX via the interactive console without any extra hardware.
For the purposes of this guide, we will use the Nucleo F103RB board.
@@ -25,7 +25,7 @@ of programmers and target microcontrollers.
You should note that ``openocd`` project has not made stable releases for long
time and support for newer hardware will probably be only available in the
latest Git version, so it is actually recommended to install latest development
latest Git version, so it is actually recommended to install latest development
version.
.. tabs::
@@ -37,7 +37,7 @@ version.
.. tab:: Install latest version from source
.. code-block:: console
$ git clone git://git.code.sf.net/p/openocd/code openocd
$ cd openocd
$ ./bootstrap
@@ -46,7 +46,7 @@ version.
The resulting installation will be under ``openocd/install``. You can add
``openocd/install/bin`` to your ``PATH``.
Now, to flash the binary to your board, connect the USB cable and do:
.. code-block:: console
@@ -72,15 +72,15 @@ if you don't see anything):
.. code-tab:: console gtkterm (GUI)
$ gtkterm -s 115200 -p /dev/ttyUSB0
.. tip::
You may have to add yourself to the ``dialout`` group on Linux to have permission
to access serial ports:
.. code-block:: console
$ gpasswd -a <user> dialout
Where ``<user>`` is your username. You will need to log out from your desktop
for the change to have effect.
Documentation/reference/os/iob.rst
+26 -13
View File
@@ -164,7 +164,8 @@ Public Function Prototypes
- :c:func:`iob_remove_queue()`
- :c:func:`iob_peek_queue()`
- :c:func:`iob_free_queue()`
- :c:func:`iob_destroy_queue()`
- :c:func:`iob_free_queue_qentry()`
- :c:func:`iob_get_queue_size()`
- :c:func:`iob_copyin()`
- :c:func:`iob_trycopyin()`
- :c:func:`iob_copyout()`
@@ -192,23 +193,25 @@ Public Function Prototypes
buffer at the head of the free list without waiting for a buffer
to become free.
.. c:function:: FAR struct iob_s *iob_free(FAR struct iob_s *iob);
.. c:function:: FAR struct iob_s *iob_free(FAR struct iob_s *iob, \
enum iob_user_e producerid);
Free the I/O buffer at the head of a buffer chain
returning it to the free list. The link to the next I/O buffer in
the chain is return.
.. c:function:: void iob_free_chain(FAR struct iob_s *iob);
.. c:function:: void iob_free_chain(FAR struct iob_s *iob, \
enum iob_user_e producerid);
Free an entire buffer chain, starting at the
beginning of the I/O buffer chain
.. c:function:: int iob_add_queue(FAR struct iob_s *iob, FAR void *priv, FAR struct iob_queue_s *iobq)
.. c:function:: int iob_add_queue(FAR struct iob_s *iob, FAR struct iob_queue_s *iobq)
Add one I/O buffer chain to the end of a queue.
May fail due to lack of resources.
.. c:function:: void iob_tryadd_queue(FAR struct iob_s *iob, FAR void *priv, FAR struct iob_queue_s *iobq)
.. c:function:: void iob_tryadd_queue(FAR struct iob_s *iob, FAR struct iob_queue_s *iobq)
Add one I/O buffer chain to the end of a queue
without waiting for resources to become free.
@@ -232,13 +235,19 @@ Public Function Prototypes
:return: Returns a reference to the I/O buffer chain at
the head of the queue.
.. c:function:: void iob_free_queue(FAR struct iob_s *iob, FAR struct iob_queue_s *iobq);
.. c:function:: void iob_free_queue(FAR struct iob_queue_s *qhead, \
enum iob_user_e producerid);
Free an entire queue of I/O buffer chains.
.. c:function:: void iob_destroy_queue(FAR struct iob_queue_s *qhead);
.. c:function:: void iob_free_queue_qentry(FAR struct iob_s *iob, \
FAR struct iob_queue_s *iobq);
Destroy all I/O buffer chains from the iob queue.
Queue helper for get the iob queue buffer size.
.. c:function:: unsigned int iob_get_queue_size(FAR struct iob_queue_s *queue);
Free an iob entire queue of I/O buffer chains.
.. c:function:: int iob_copyin(FAR struct iob_s *iob, FAR const uint8_t *src, \
unsigned int len, unsigned int offset, bool throttled);
@@ -270,14 +279,15 @@ Public Function Prototypes
Concatenate iob_s chain iob2 to iob1.
.. c:function:: FAR struct iob_s *iob_trimhead(FAR struct iob_s *iob, unsigned int trimlen)
.. c:function:: FAR struct iob_s *iob_trimhead(FAR struct iob_s *iob, \
unsigned int trimlen, enum iob_user_e producerid)
Remove bytes from the beginning of an I/O chain.
Emptied I/O buffers are freed and, hence, the beginning of the
chain may change.
.. c:function:: FAR struct iob_s *iob_trimhead_queue(FAR struct iob_queue_s *qhead, \
unsigned int trimlen);
unsigned int trimlen, enum iob_user_e producerid);
Remove bytes from the beginning of an I/O chain
at the head of the queue. Emptied I/O buffers are freed and,
@@ -290,19 +300,22 @@ Public Function Prototypes
:return: The new iob at the head of the queue is
returned.
.. c:function:: FAR struct iob_s *iob_trimtail(FAR struct iob_s *iob, unsigned int trimlen);
.. c:function:: FAR struct iob_s *iob_trimtail(FAR struct iob_s *iob, \
unsigned int trimlen, enum iob_user_e producerid);
Remove bytes from the end of an I/O chain.
Emptied I/O buffers are freed NULL will be returned in the special
case where the entry I/O buffer chain is freed.
.. c:function:: FAR struct iob_s *iob_pack(FAR struct iob_s *iob);
.. c:function:: FAR struct iob_s *iob_pack(FAR struct iob_s *iob, \
enum iob_user_e producerid);
Pack all data in the I/O buffer chain so that the
data offset is zero and all but the final buffer in the chain are
filled. Any emptied buffers at the end of the chain are freed.
.. c:function:: int iob_contig(FAR struct iob_s *iob, unsigned int len);
.. c:function:: int iob_contig(FAR struct iob_s *iob, unsigned int len, \
enum iob_user_e producerid);
Ensure that there is ``len`` bytes of contiguous
space at the beginning of the I/O buffer chain starting at
Documentation/reference/os/wqueue.rst
+25 -25
View File
@@ -10,10 +10,10 @@ for delayed processing, or for serializing activities.
Classes of Work Queues
======================
There are three different classes of
work queues, each with different properties and intended usage.
These class of work queues along with the common work queue
interface are described in the following paragraphs.
There are three different classes of work queues, each with
different properties and intended usage. These classes of work
queues along with the common work queue interface are described in
the following paragraphs.
High Priority Kernel Work queue
-------------------------------
@@ -60,7 +60,7 @@ to match the highest priority client.
**Configuration Options**.
- ``CONFIG_SCHED_HPWORK``. Enables the hight priority work queue.
- ``CONFIG_SCHED_HPWORK``. Enables the high priority work queue.
- ``CONFIG_SCHED_HPNTHREADS``. The number of threads in the
high-priority queue's thread pool. Default: 1
- ``CONFIG_SCHED_HPWORKPRIORITY``. The execution priority of the
@@ -72,7 +72,8 @@ to match the highest priority client.
queues:
- ``CONFIG_SIG_SIGWORK`` The signal number that will be used to
wake-up the worker thread. This same signal is used with the
wake-up the worker thread. This same signal is used with various
internal worker threads.
Default: 17
Low Priority Kernel Work Queue
@@ -88,9 +89,9 @@ work queue runs at a lower priority than the high priority work
queue, of course, and so is inappropriate to serve as a driver
*bottom half*. It is, otherwise, very similar to the high priority
work queue and most of the discussion above for the high priority
work queue applies equally here. The lower priority work queue
does have one important, however, that make it better suited for
some tasks:
work queue applies equally here. The lower priority work queue does
have one important property, however, that makes it better suited
for some tasks:
**Priority Inheritance**. The lower priority worker thread(s)
support *priority inheritance* (if <config>
@@ -99,8 +100,8 @@ lower priority worker thread can then be adjusted to match the
highest priority client.
**NOTE:** This priority inheritance feature is not automatic.
The lower priority worker thread will always a fixed priority
unless additional logic implements that calls
The lower priority worker thread will always have a fixed
priority unless additional logic calls
``lpwork_boostpriority()`` to raise the priority of the lower
priority worker thread (typically called before scheduling the
work) and then calls the matching ``lpwork_restorepriority()``
@@ -143,19 +144,18 @@ User-Mode Work Queue
**Work Queue Accessibility**. The high- and low-priority worker
threads are kernel-mode threads. In the normal, *flat* NuttX
build, these work queues are are useful to application code and
build, these work queues are useful to application code and
may be shared. However, in the NuttX protected and kernel build
modes, kernel mode code is isolated and cannot be accessed from
user-mode code.
**User-Mode Work Queue**. if either ``CONFIG_BUILD_PROTECTED`` or
``CONFIG_BUILD_KERNEL`` are selected, then the option to enable a
special user-mode work queue is enable. The interface to the
user-mode work queue is identical to the interface to the
kernel-mode work queues and the user-mode work queue is
functionally equivalent to the high priority work queue. It
differs in that its implementation does not depend on internal,
kernel-space facilities.
special user-mode work queue is enabled. The interface to the user-
mode work queue is identical to that of the kernel-mode work queues
and the user-mode work queue is functionally equivalent to the high
priority work queue. It differs in that its implementation does not
depend on internal, kernel-space facilities.
**Configuration Options**.
@@ -181,10 +181,10 @@ interface function identifies the work queue:
**Kernel-Mode Work Queue IDs:**
- ``HPWORK``. This ID of the high priority work queue that should
only be used for hi-priority, time-critical, driver bottom-half
only be used for high-priority, time-critical, driver bottom-half
functions.
- ``LPWORK``. This is the ID of the low priority work queue that
can be used for any purpose. if ``CONFIG_SCHED_LPWORK`` is not
can be used for any purpose. If ``CONFIG_SCHED_LPWORK`` is not
defined, then there is only one kernel work queue and
``LPWORK`` is equal to ``HPWORK``.
@@ -192,7 +192,7 @@ interface function identifies the work queue:
- ``USRWORK``. This is the ID of the user-mode work queue that
can be used for any purpose by applications. In a flat build,
``LPWORK`` is equal to ``LPWORK`` so that user applications
``USRWORK`` is equal to ``LPWORK`` so that user applications
will use the lower priority work queue (if there is one).
Work Queue Interface Types
@@ -221,14 +221,14 @@ Work Queue Interfaces
zero by the caller. Otherwise, the work structure is completely
managed by the work queue logic. The caller should never modify
the contents of the work queue structure directly. If
``work_queue()`` is called before the previous work as been
``work_queue()`` is called before the previous work has been
performed and removed from the queue, then any pending work will
be canceled and lost.
:param qid: The work queue ID.
:param work: The work structure to queue
:param worker: The worker callback to be invoked. The callback
will invoked on the worker thread of execution.
will be invoked on the worker thread of execution.
:param arg: The argument that will be passed to the worker
callback function when it is invoked.
@@ -243,10 +243,10 @@ Work Queue Interfaces
Cancel previously queued work. This removes work
from the work queue. After work has been cancelled, it may be
re-queue by calling ``work_queue()`` again.
re-queued by calling ``work_queue()`` again.
:param qid: The work queue ID.
:param work: The previously queue work structure to cancel.
:param work: The previously queued work structure to cancel.
:return: Zero is returned on success; a negated ``errno`` is returned on
failure.
Documentation/reference/user/01_task_control.rst
+1 -1
View File
@@ -199,7 +199,7 @@ Functions
- Deletion of self is supported, but only because ``task_delete()``
will re-direct processing to ``exit()``.
.. :c:funcion:: int task_restart(pid_t pid)
.. :c:function:: int task_restart(pid_t pid)
This function *restarts* a task. The task is first
terminated and then reinitialized with same ID, priority, original entry
Documentation/reference/user/02_task_scheduling.rst
+2 -1
View File
@@ -54,7 +54,8 @@ Functions
**POSIX Compatibility:** Comparable to the POSIX interface of the same
name. Differences from the full POSIX implementation include:
- The range of priority values for the POSIX call is 0 to 255.
- The range of priority values for the POSIX call is 0 to 255. The
priority 0 is the lowest priority and 255 is the highest priority.
.. note:: Setting a task's priority to the same value has the similar effect
to ``sched_yield()``: The task will be moved to after all other tasks
Documentation/reference/user/03_task_control.rst
+1 -9
View File
@@ -86,15 +86,7 @@ there are three important configuration options that can change that.
allocations and to improve allocation performance, child task exit
status structures are pre-allocated when the system boots. This
setting determines the number of child status structures that will be
pre-allocated. If this setting is not defined or if it is defined to
be zero then a value of 2\*\ ``MAX_TASKS`` is used.
Note that there cannot be more that ``CONFIG_MAX_TASKS`` tasks in
total. However, the number of child status structures may need to be
significantly larger because this number includes the maximum number
of tasks that are running PLUS the number of tasks that have exit'ed
without having their exit status reaped (via :c:func:`wait`,
:c:func:`waitpid` or :c:func:`waitid`).
pre-allocated.
Obviously, if tasks spawn children indefinitely and never have the
exit status reaped, then you may have a memory leak! (See **Warning**
Documentation/reference/user/04_message_queue.rst
+43 -48
View File
@@ -19,11 +19,10 @@ handlers may send messages via named message queues.
.. c:function:: mqd_t mq_open(const char *mqName, int oflags, ...)
Establishes a connection between a named
message queue and the calling task. After a successful call of
mq_open(), the task can reference the message queue using the address
returned by the call. The message queue remains usable until it is
closed by a successful call to mq_close().
Establishes a connection between a named message queue and the calling
task. After a successful call of mq_open(), the task can reference the
message queue using the address returned by the call. The message queue
remains usable until it is closed by a successful call to mq_close().
:param mqName: Name of the queue to open
:param oflags: Open flags. These may be any combination of:
@@ -65,10 +64,10 @@ handlers may send messages via named message queues.
.. c:function:: int mq_close(mqd_t mqdes)
Used to indicate that the calling task
is finished with the specified message queued mqdes. The mq_close()
deallocates any system resources allocated by the system for use by this
task for its message queue.
Used to indicate that the calling task is finished with the specified
message queued ``mqdes``. The ``mq_close()`` deallocates any system
resources allocated by the system for use by this task for its message
queue.
If the calling task has attached a notification request to the message
queue via this ``mqdes`` (see ``mq_notify()``), this attachment will be
@@ -104,10 +103,10 @@ handlers may send messages via named message queues.
.. c:function:: int mq_send(mqd_t mqdes, const void *msg, size_t msglen, int prio)
Adds the specified message, ``msg``, to
the message queue, ``mqdes``. The ``msglen`` parameter specifies the
length of the message in bytes pointed to by ``msg``. This length must
not exceed the maximum message length from the ``mq_getattr()``.
Adds the specified message, ``msg``, to the message queue, ``mqdes``.
The ``msglen`` parameter specifies the length of the message in bytes
pointed to by ``msg``. This length must not exceed the maximum message
length from the ``mq_getattr()``.
If the message queue is not full, ``mq_send()`` will place the ``msg``
in the message queue at the position indicated by the ``prio`` argument.
@@ -125,14 +124,14 @@ handlers may send messages via named message queues.
However, it behaves differently when called from the interrupt level:
- It does not check the size of the queue. It will always post the
message, even if there is already too many messages in queue. This is
message, even if there are already too many messages in queue. This is
because the interrupt handler does not have the option of waiting for
the message queue to become non-full.
- It doesn't allocate new memory (because you cannot allocate memory
from an interrupt handler). Instead, there are are pool of
pre-allocated message structures that may be used just for sending
messages from interrupt handlers. The number of such pre-allocated
messages is a configuration parameter.
from an interrupt handler). Instead, there is a pool of pre-allocated
message structures that may be used just for sending messages from
interrupt handlers. The number of such pre-allocated messages is set
by the ``PREALLOC_MQ_IRQ_MSGS`` configuration parameter.
:param mqdes: Message queue descriptor.
:param msg: Message to send.
@@ -157,10 +156,10 @@ handlers may send messages via named message queues.
.. c:function:: int mq_timedsend(mqd_t mqdes, const char *msg, size_t msglen, int prio, \
const struct timespec *abstime);
Adds the specified message, ``msg``, to
the message queue, ``mqdes``. The ``msglen`` parameter specifies the
length of the message in bytes pointed to by ``msg``. This length must
not exceed the maximum message length from the ``mq_getattr()``.
Adds the specified message, ``msg``, to the message queue, ``mqdes``.
The ``msglen`` parameter specifies the length of the message in bytes
pointed to by ``msg``. This length must not exceed the maximum message
length from the ``mq_getattr()``.
If the message queue is not full, ``mq_timedsend()`` will place the
``msg`` in the message queue at the position indicated by the ``prio``
@@ -203,12 +202,11 @@ handlers may send messages via named message queues.
.. c:function:: ssize_t mq_receive(mqd_t mqdes, void *msg, size_t msglen, int *prio)
Receives the oldest of the highest
priority messages from the message queue specified by ``mqdes``. If the
size of the buffer in bytes, ``msgLen``, is less than the ``mq_msgsize``
attribute of the message queue, ``mq_receive()`` will return an error.
Otherwise, the selected message is removed from the queue and copied to
``msg``.
Receives the oldest of the highest priority messages from the message
queue specified by ``mqdes``. If the size of the buffer in bytes,
``msgLen``, is less than the ``mq_msgsize`` attribute of the message
queue, ``mq_receive()`` will return an error. Otherwise, the selected
message is removed from the queue and copied to ``msg``.
If the message queue is empty and ``O_NONBLOCK`` was not set,
``mq_receive()`` will block until a message is added to the message
@@ -223,8 +221,8 @@ handlers may send messages via named message queues.
:param msg: Buffer to receive the message.
:param msglen: Size of the buffer in bytes.
:param prio: If not NULL, the location to store message priority.
:return: One success, the length of the selected message in
bytes is returned. On failure, -1 (``ERROR``) is returned and the
:return: On success, the length of the selected message in bytes is
returned. On failure, -1 (``ERROR``) is returned and the
```errno`` <#ErrnoAccess>`__ is set appropriately:
- ``EAGAIN`` The queue was empty and the ``O_NONBLOCK`` flag was set
@@ -241,12 +239,11 @@ handlers may send messages via named message queues.
.. c:function:: ssize_t mq_timedreceive(mqd_t mqdes, void *msg, size_t msglen, \
int *prio, const struct timespec *abstime);
Receives the oldest of the highest
priority messages from the message queue specified by ``mqdes``. If the
size of the buffer in bytes, ``msgLen``, is less than the ``mq_msgsize``
attribute of the message queue, ``mq_timedreceive()`` will return an
error. Otherwise, the selected message is removed from the queue and
copied to ``msg``.
Receives the oldest of the highest priority messages from the message
queue specified by ``mqdes``. If the size of the buffer in bytes,
``msgLen``, is less than the ``mq_msgsize`` attribute of the message
queue, ``mq_timedreceive()`` will return an error. Otherwise, the
selected message is removed from the queue and copied to ``msg``.
If the message queue is empty and ``O_NONBLOCK`` was not set,
``mq_timedreceive()`` will block until a message is added to the message
@@ -270,8 +267,8 @@ handlers may send messages via named message queues.
:param prio: If not NULL, the location to store message priority.
:param abstime: The absolute time to wait until a timeout is declared.
:return: One success, the length of the selected message in
bytes is returned. On failure, -1 (``ERROR``) is returned and the
:return: On success, the length of the selected message in bytes is
returned. On failure, -1 (``ERROR``) is returned and the
```errno`` <#ErrnoAccess>`__ is set appropriately:
- ``EAGAIN``: The queue was empty and the ``O_NONBLOCK`` flag was set
@@ -289,11 +286,10 @@ handlers may send messages via named message queues.
.. c:function:: int mq_notify(mqd_t mqdes, FAR const struct sigevent *notification)
If the ``notification`` input parameter is not
``NULL``, this function connects the task with the message queue such
that the specified signal will be sent to the task whenever the message
changes from empty to non-empty. One notification can be attached to a
message queue.
If the ``notification`` input parameter is not ``NULL``, this function
connects the task with the message queue such that the specified signal
will be sent to the task whenever the message queue changes from empty
to non-empty. One notification can be attached to a message queue.
If ``notification``; is ``NULL``, the attached notification is detached
(if it was held by the calling task) and the queue is available to
@@ -337,9 +333,8 @@ handlers may send messages via named message queues.
.. c:function:: int mq_setattr(mqd_t mqdes, const struct mq_attr *mqStat, \
struct mq_attr *oldMqStat);
Sets the attributes associated with the
specified message queue "mqdes." Only the "O_NONBLOCK" bit of the
"mq_flags" can be changed.
Sets the attributes associated with the specified message queue "mqdes."
Only the "O_NONBLOCK" bit of the "mq_flags" can be changed.
If ``oldMqStat`` is non-null, mq_setattr() will store the previous message
queue attributes at that location (just as would have been returned by
@@ -357,8 +352,8 @@ handlers may send messages via named message queues.
.. c:function:: int mq_getattr(mqd_t mqdes, struct mq_attr *mqStat)
Gets status information and attributes
associated with the specified message queue.
Gets status information and attributes associated with the specified
message queue.
:param mqdes: Message queue descriptor
:param mqStat: Buffer in which to return attributes. The returned
Kconfig
+3 -1
View File
@@ -1766,7 +1766,9 @@ config STACK_USAGE_SAFE_PERCENT
---help---
Stack usage precent = up_check_tcbstack() * 100 / tcb->adj_stack_size,
this should lower then STACK_USAGE_SAFE_PERCENT.
Idle thread will timely check stack usage when this marco value > 0.
Idle thread will timely check stack usage when this macro value > 0.
N.B. This feature should not be used in production code.
config STACK_CANARIES
bool "Compiler stack canaries"
LICENSE
+40 -7
View File
@@ -205,21 +205,54 @@
uIP
===
Many lower-level networking components of NuttX derive from uIP which
has a similar BSD style license:
Many lower-level networking components of NuttX derive from uIP:
Copyright (c) 2001-2003, Adam Dunkels.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. The name of the author may not be used to endorse or promote
products derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Rhombus Math Library
====================
The math library used in NuttX derives from the Rhombus OS by Nick Johnson
(with many, many addtions). The Rhombus OS is/was distributed under the ISC
license. The ISC licsense is a permissive license that allows people do
anything with your code with proper attribution and without warranty. The
ISC license is functionally equivalent to the BSD 2-Clause and MIT licenses,
removing some language that is no longer necessary.
(with many, many additions):
Copyright (C) 2009-2011 Nick Johnson <nickbjohnson4224 at gmail.com>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
IGMP
====
README.md
+2
View File
@@ -2092,6 +2092,8 @@ Below is a guide to the available README files in the NuttX source tree:
| | | | `- README.txt
| | | |- cloudctrl/
| | | | `- README.txt
| | | |- emw3162/
| | | | `- README.txt
| | | |- fire-stm32v2/
| | | | `- README.txt
| | | |- hymini-stm32v/
ReleaseNotes
+248
View File
@@ -27123,6 +27123,254 @@ NuttX-9.1.0 Release Notes -------------------------
- PR-287 PR-290 examples: Update nxflat and thttpd Makefile's to fix
a build breakage.
* Compatibility Concerns -- Changes to Build System:
If you are building NuttX for a custom board, you may need to make
some of the following changes in build-related files for your board:
* Rename EXTRADEFINES to EXTRAFLAGS
In your custom board's scripts/Make.defs file, rename EXTRADEFINES to
EXTRAFLAGS.
For example, these lines:
```
CFLAGS = $(ARCHCFLAGS) $(ARCHWARNINGS) $(ARCHOPTIMIZATION) $(ARCHCPUFLAGS) $(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES) -pipe
...
CXXFLAGS = $(ARCHCXXFLAGS) $(ARCHWARNINGSXX) $(ARCHOPTIMIZATION) $(ARCHCPUFLAGS) $(ARCHXXINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES) -pipe
...
CPPFLAGS = $(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES)
```
would change as follows:
```
CFLAGS = $(ARCHCFLAGS) $(ARCHWARNINGS) $(ARCHOPTIMIZATION) $(ARCHCPUFLAGS) $(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRAFLAGS) -pipe
...
CXXFLAGS = $(ARCHCXXFLAGS) $(ARCHWARNINGSXX) $(ARCHOPTIMIZATION) $(ARCHCPUFLAGS) $(ARCHXXINCLUDES) $(ARCHDEFINES) $(EXTRAFLAGS) -pipe
...
CPPFLAGS = $(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRAFLAGS)
```
See git commit # 459ad9937377a42785692098ff0d73baaa9551e6 in the main
NuttX repository.
If you forget to do this, memory allocations on the heap probably won't
work and your user tasks won't start.
To see why, tools/Config.mk assigns a value to KDEFINE such that the
preprocessor symbol __KERNEL__ will be defined when certain source
files are compiled. KDEFINE is passed to nested invocations of 'make'
as EXTRAFLAGS. If your board's scripts/Make.defs still attempts to use
EXTRADEFINES, the preprocessor symbol __KERNEL__ will not be defined in
some of the places that it should be. Suppose you're building a FLAT
build. In this case, include/nuttx/mm/mm.h will not define
MM_KERNEL_USRHEAP_INIT like it should, which will cause nx_start.c not
to call up_allocate_heap() at startup. Therefore, any attempt to
allocate memory on the heap will fail.
* Rename src/Makefile to src/Make.defs and Modify
This item pertains only to custom boards that are developed in- tree,
meaning under the NuttX boards/ subdirectory. Out-of-tree boards are
not affected.
If your custom board directory is in-tree and in a board family that
uses a 'boards/ARCH/FAMILY/common' directory (such as
boards/arm/stm32/common, boards/arm/cxd56xx/common, etc), then you'll
need to make two minor changes to your custom board's src/Makefile:
(1) Rename it from src/Makefile to src/Make.defs, and
(2) Near the end of that file, replace this line, which usually
appears at the end:
```
include $(TOPDIR)/boards/Board.mk
```
with these three lines:
```
DEPPATH += --dep-path board
VPATH += :board
CFLAGS += $(shell $(INCDIR) $(INCDIROPT) "$(CC)" $(TOPDIR)$(DELIM)arch$(DELIM)$(CONFIG_ARCH)$(DELIM)src$(DELIM)board$(DELIM)board)
```
See git commit # 6ca46520df38854bf660f9be54957cceede39ded in the main
NuttX repository.
If you forget to do this, 'make' will report an error, "no rule to make
libboard.a," and the build will fail.
* Rename WINTOOL to CONFIG_CYGWIN_WINTOOL
In your custom board's scripts/Make.defs file, rename any instances of
WINTOOL to CONFIG_CYGWIN_WINTOOL.
For example, change this line:
```
ifeq ($(WINTOOL),y)
```
to this:
```
ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
```
See git commit # bd656888f26c92e8832f0e76b395a5ece7704530 in the main
NuttX repository.
* Remove INCDIROPT
In your custom board's src/Make.defs file, remove INCDIROPT from CFLAGS.
For example, change this line:
```
CFLAGS += $(shell $(INCDIR) $(INCDIROPT) "$(CC)" $(TOPDIR)$(DELIM)arch$(DELIM)$(CONFIG_ARCH)$(DELIM)src$(DELIM)board$(DELIM)board)
```
to this:
```
CFLAGS += $(shell $(INCDIR) "$(CC)" $(TOPDIR)$(DELIM)arch$(DELIM)$(CONFIG_ARCH)$(DELIM)src$(DELIM)board$(DELIM)board)
```
This option, which resolves to -w when CONFIG_CYGWIN_WINTOOL is
configured, is now appended to INCDIR in tools/Config.mk.
See git commit # 5eae32577e5d5226e5d3027c169eeb369f83f77d in the main
NuttX repository.
* Remove Unnecessary Variables
In your custom board's scripts/Make.defs file, It is no longer
necessary to define the following variables unless your build requires
that you assign special values to them:
- DIRLINK
- DIRUNLINK
- MKDEP
- ASMEXT
- OBJEXT
- LIBEXT
- EXEEXT
These variables have been refactored into tools/Config.mk.
See these git commits in the main NuttX repository:
9ec9431706fd0eb7c4c4410d84dafff68ff31366 (DIRLINK and DIRUNLINK),
8b42ee421a41214093c0238e479d73a1099b0e82 (MKDEP), and
567962bd6263bf8809fb63c739f6ec668c69c416 (ASMEXT, OBJEXT, LIBEXT, EXEEXT)
* Change ${TOPDIR} to $(TOPDIR)
In your custom board's scripts/Make.defs file, it is recommended to
change ${TOPDIR} to $(TOPDIR) for consistency (change curly braces to
parenthesis).
See git commit # faf3c0254bb63af89f9eb59beefacb4cba26dd9 in the main
NuttX repository.
* Remove Workaround For Missing $(TOPDIR)/Make.defs
In src/Make.defs or src/Makefile for your custom board or custom apps,
the workaround for missing $(TOPDIR)/.config and/or
$(TOPDIR)/Make.defs is no longer needed. To remove the workaround,
delete the minus sign in front of include .config. This is now handled
in the main Makefile and, if those files are missing, will print an
error message with hint to run tools/configure.sh <target>.
Change this line, located near the top of the file:
```
-include $(TOPDIR)/Make.defs
```
to this:
```
include $(TOPDIR)/Make.defs
```
See git commit # 1a95cce1a3c3ed8b04d1d86b7bd744352cca45a2 in the main
NuttX repository, and git commit
# ead498a7883a654b1d542da94a5fab3ce163361e in the apps repository.
* Simplify ARCHINCLUDES and ARCHXXINCLUDES
In your custom board's scripts/Make.defs, ARCHINCLUDES and
ARCHXXINCLUDES can be defined without maintaining two different
versions conditioned upon CONFIG_CYGWIN_WINTOOL (renamed from WINTOOL).
Replace syntax similar to the following:
```
ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
# Windows-native toolchains
ARCHINCLUDES = -I. -isystem "${shell cygpath -w $(TOPDIR)$(DELIM)include}"
ARCHXXINCLUDES = -I. -isystem "${shell cygpath -w $(TOPDIR)$(DELIM)include}" -isystem "${shell cygpath -w $(TOPDIR)$(DELIM)include$(DELIM)cxx}"
else
# Linux/Cygwin-native toolchain
ARCHINCLUDES = -I. -isystem $(TOPDIR)$(DELIM)include
ARCHXXINCLUDES = -I. -isystem $(TOPDIR)$(DELIM)include -isystem $(TOPDIR)$(DELIM)include$(DELIM)cxx
endif
```
with syntax similar to:
```
ARCHINCLUDES += ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include$(DELIM)cxx}
INCDIR is defined in tools/Config.mk and resolves to a shell script or batch file that constructs the appropriate command line argument string to specify include directories for your compiler.
```
See git commit # 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 in the main
NuttX repository.
* Simplify Board Directory Handling With BOARD_DIR
In your custom board's Make.defs or Makefile, when setting up build
variables containing paths inside your board directory, a new variable
BOARD_DIR has been introduced that simplifies the syntax:
Replace syntax like this:
```
$(TOPDIR)$(DELIM)boards$(DELIM)$(CONFIG_ARCH)$(DELIM)$(CONFIG_ARCH_CHIP)$(DELIM)$(CONFIG_ARCH_BOARD)
```
with this variable:
```
$(BOARD_DIR)
```
For example, change this:
```
ARCHSCRIPT = -T$(TOPDIR)$(DELIM)boards$(DELIM)$(CONFIG_ARCH)$(DELIM)$(CONFIG_ARCH_CHIP)$(DELIM)$(CONFIG_ARCH_BOARD)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
```
to this much simpler syntax:
```
ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
```
You may find the old syntax being used for variables like ARCHSCRIPT,
LDELFFLAGS, LINKCMDTEMPLATE, SCRIPTDIR, USER_LDSCRIPT, or others.
BOARD_DIR is defined in tools/Config.mk.
See git commit # e83c1400b65c65cbdf59c5abcf2ae368f540faef in the main
NuttX repository.
NuttX-10.0.0 Release Notes
------------------------
arch/Kconfig
+14 -6
View File
@@ -259,9 +259,17 @@ config ARCH_NEED_ADDRENV_MAPPING
bool
default n
config ARCH_HAVE_MODULE_TEXT
bool "Special memory region for dynamic code loading"
config ARCH_HAVE_EXTRA_HEAPS
bool
default n
---help---
Special memory regions used as separate heaps
config ARCH_HAVE_TEXT_HEAP
bool
default n
---help---
Special memory region for dynamic code loading
config ARCH_HAVE_MULTICPU
bool
@@ -371,12 +379,12 @@ config ARCH_USE_MPU
is enabled by other, platform-specific logic. In those cases, this
selection will always be forced.
config ARCH_USE_MODULE_TEXT
bool "Enable module text allocator"
config ARCH_USE_TEXT_HEAP
bool "Enable separate text allocation for dynamic code loading"
default n
depends on ARCH_HAVE_MODULE_TEXT
depends on ARCH_HAVE_TEXT_HEAP
---help---
This option enable architecture-sepecific memory allocator
This option enables architecture-sepecific memory allocator
for dynamic code loading. For example, ESP32 has a separate memory
regions for instruction and data and the memory region used for
usual malloc doesn't work for instruction.
arch/arm/Kconfig
+1
View File
@@ -456,6 +456,7 @@ config ARCH_CHIP_CXD56XX
select ARCH_HAVE_FPU
select ARCH_HAVE_HEAPCHECK
select ARCH_HAVE_MULTICPU
select ARCH_HAVE_TEXT_HEAP
select ARCH_HAVE_SDIO if MMCSD
select ARCH_HAVE_MATH_H
---help---
arch/arm/include/cxd56xx/chip.h
+4
View File
@@ -25,6 +25,10 @@
* Pre-processor Prototypes
****************************************************************************/
/* physical address conversion macro */
#define CXD56_PHYSADDR(a) ((uint32_t)((uint32_t)(a) & 0x9ffffffful))
#define CXD56M4_SYSH_PRIORITY_MIN 0xe0 /* All bits[7:5] set is minimum priority */
#define CXD56M4_SYSH_PRIORITY_DEFAULT 0x80 /* Midpoint is the default */
#define CXD56M4_SYSH_PRIORITY_MAX 0x00 /* Zero is maximum priority */
arch/arm/include/cxd56xx/hostif.h
+136
View File
@@ -0,0 +1,136 @@
/****************************************************************************
* arch/arm/include/cxd56xx/hostif.h
*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership. The
* ASF licenses this file to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance with the
* License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*
****************************************************************************/
#ifndef __ARCH_ARM_INCLUDE_CXD56XX_HOSTIF_H
#define __ARCH_ARM_INCLUDE_CXD56XX_HOSTIF_H
/****************************************************************************
* Included Files
****************************************************************************/
#include <nuttx/config.h>
#include <stdint.h>
/****************************************************************************
* Pre-processor Definitions
****************************************************************************/
/* Host interface maximum number of buffers */
#define MAX_BUFFER_NUM 32
/* Host interface buffer attributes */
#define HOSTIF_BUFF_ATTR_ADDR_OFFSET(n) (((n) & 0x3) << 4)
/* 2 to the power of n */
#define HOSTIF_BUFF_ATTR_FIXLEN (0 << 2) /* fixed length */
#define HOSTIF_BUFF_ATTR_VARLEN (1 << 2) /* variable length */
#define HOSTIF_BUFF_ATTR_WRITE (0 << 1) /* from target to host */
#define HOSTIF_BUFF_ATTR_READ (1 << 1) /* from host to target */
/****************************************************************************
* Public Types
****************************************************************************/
/* Common buffer configuration */
struct hostif_buff_s
{
uint16_t size;
uint16_t flag;
};
/* I2C buffer configuration */
struct hostif_i2cconf_s
{
int address; /* slave address */
struct hostif_buff_s buff[MAX_BUFFER_NUM];
};
/* SPI buffer configuration */
struct hostif_spiconf_s
{
struct hostif_buff_s buff[MAX_BUFFER_NUM];
};
#ifndef __ASSEMBLY__
#undef EXTERN
#if defined(__cplusplus)
#define EXTERN extern "C"
extern "C"
{
#else
#define EXTERN extern
#endif
/****************************************************************************
* Public Function Prototypes
****************************************************************************/
/****************************************************************************
* Name: hostif_i2cinitialize
*
* Description:
* Initialize the host interface for I2C slave
*
* Input Parameter:
* config - pointer to I2C buffer configuration
*
* Returned Value:
* Return 0 on success. Otherwise, return a negated errno.
*
****************************************************************************/
int hostif_i2cinitialize(FAR struct hostif_i2cconf_s *config);
/****************************************************************************
* Name: hostif_spiinitialize
*
* Description:
* Initialize the host interface for SPI slave
*
* Input Parameter:
* config - pointer to SPI buffer configuration
*
* Returned Value:
* Return 0 on success. Otherwise, return a negated errno.
*
****************************************************************************/
int hostif_spiinitialize(FAR struct hostif_spiconf_s *config);
/****************************************************************************
* Name: hostif_uninitialize
*
* Description:
* Uninitialize the host interface
*
* Returned Value:
* Return 0 on success. Otherwise, return a negated errno.
*
****************************************************************************/
int hostif_uninitialize(void);
#endif /* __ASSEMBLY__ */
#endif /* __ARCH_ARM_INCLUDE_CXD56XX_HOSTIF_H */
arch/arm/include/cxd56xx/pm.h
+5 -3
View File
@@ -25,6 +25,7 @@
* Included Files
****************************************************************************/
#include <nuttx/config.h>
#include <queue.h>
/****************************************************************************
@@ -62,8 +63,9 @@
/* FrequencyLock request flag definitions */
#define PM_CPUFREQLOCK_FLAG_HV (0x0001) /* request HV */
#define PM_CPUFREQLOCK_FLAG_LV (0x4000) /* request LV */
#define PM_CPUFREQLOCK_FLAG_HV (0x0001) /* request HV */
#define PM_CPUFREQLOCK_FLAG_LV (0x4000) /* request LV */
#define PM_CPUFREQLOCK_FLAG_HOLD (0x8000) /* hold the current frequency */
/* FrequencyLock identifier tag helper macro function */
@@ -160,7 +162,7 @@ extern "C"
int up_pmramctrl(int cmd, uintptr_t addr, size_t size);
#ifdef CONFIG_DEBUG_PM
#ifdef CONFIG_CXD56_PM_DEBUG_INFO
/****************************************************************************
* Name: up_pmstatdump
*
arch/arm/include/imxrt/imxrt102x_irq.h
+12 -28
View File
@@ -1,36 +1,20 @@
/****************************************************************************
* arch/arm/include/imxrt/imxrt102x_irq.h
*
* Copyright (C) 2018 Gregory Nutt. All rights reserved.
* Author: Gregory Nutt <gnutt@nuttx.org>
* Dave Marples <dave@marples.net>
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership. The
* ASF licenses this file to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance with the
* License. You may obtain a copy of the License at
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* http://www.apache.org/licenses/LICENSE-2.0
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
* 3. Neither the name NuttX nor the names of its contributors may be
* used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
* AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*
****************************************************************************/
arch/arm/include/kinetis/kinetis_dma.h
+12 -27
View File
@@ -1,35 +1,20 @@
/****************************************************************************
* arch/arm/include/kinetis/kinetis_dma.h
*
* Copyright (C) 2018 Gregory Nutt. All rights reserved.
* Authors: Jan Okle <jan@leitwert.ch>
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership. The
* ASF licenses this file to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance with the
* License. You may obtain a copy of the License at
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* http://www.apache.org/licenses/LICENSE-2.0
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
* 3. Neither the name NuttX nor the names of its contributors may be
* used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
* AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*
****************************************************************************/
arch/arm/include/kinetis/kinetis_dmamux.h
+12 -27
View File
@@ -1,35 +1,20 @@
/****************************************************************************
* arch/arm/include/kinetis/kinetis_dmamux.h
*
* Copyright (C) 2018 Gregory Nutt. All rights reserved.
* Authors: Jan Okle <jan@leitwert.ch>
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership. The
* ASF licenses this file to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance with the
* License. You may obtain a copy of the License at
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* http://www.apache.org/licenses/LICENSE-2.0
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
* 3. Neither the name NuttX nor the names of its contributors may be
* used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
* AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*
****************************************************************************/

Some files were not shown because too many files have changed in this diff Show More