mirror of
https://github.com/apache/nuttx.git
synced 2026-06-06 00:14:22 +08:00
Merge commit '2e43815c929acb818b34a5ff8828494b0c6f6891' into dev
Change-Id: Idcbac12fec435abff01cfb4efd5a26a02eb08f93
This commit is contained in:
Xiang Xiao
@@ -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
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -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::
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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).
|
||||
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
-----------------------
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 107 KiB |
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
------
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
---
|
||||
|
||||
BIN
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 1.5 MiB |
@@ -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
|
||||
|
||||
@@ -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
|
||||
========== ======= =====
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 2.5 MiB |
@@ -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).
|
||||
|
||||
@@ -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/*/*
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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`.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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**
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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"
|
||||
|
||||
@@ -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
|
||||
====
|
||||
|
||||
@@ -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/
|
||||
|
||||
+248
@@ -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
|
||||
------------------------
|
||||
|
||||
|
||||
+14
-6
@@ -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.
|
||||
|
||||
@@ -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---
|
||||
|
||||
@@ -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 */
|
||||
|
||||
@@ -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 */
|
||||
@@ -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
|
||||
*
|
||||
|
||||
@@ -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.
|
||||
*
|
||||
****************************************************************************/
|
||||
|
||||
|
||||
@@ -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.
|
||||
*
|
||||
****************************************************************************/
|
||||
|
||||
|
||||
@@ -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
Reference in New Issue
Block a user