!boards: Remove NSH_ARCHINIT and board_app_initialize

BREAKING: In an effort to simplify NuttX initialization, NSH_ARCHINIT is
removed. board_app_initialize is also removed. BOARD_LATE_INITIALIZE now
performs all board initialization logic, and is by default enabled. All
references to these symbols are removed. BOARDIOC_INIT remains, but will
result in -ENOTTY when called. It is to be removed in a later commit.

Quick fix: Boards relying on NSH_ARCHINIT should now enable
CONFIG_BOARD_LATE_INITIALIZE instead. If the application needs
fine-grained control over board initialization from userspace, the logic
performed by BOARDIOC_INIT may be copied to the board_finalinitialize
function and used instead via BOARDIOC_FINALINIT. All
board_app_initialize logic provided by NuttX is now moved to
board_late_initialize, and the same should be done for out-of-tree
boards.

Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
This commit is contained in:
Matteo Golin 2026-02-16 14:24:28 -05:00 committed by Xiang Xiao
parent 8e91dd60a0
commit 48db502daf
1631 changed files with 579 additions and 2753 deletions

View file

@ -178,3 +178,4 @@ libs/libc/tre-mem.c
#define RTPROT_RA 9 /* RDISC/ND router advertisements */
/* Followed by one or more ND options */
* message using the Neighbor Discovery (ND) protocol. It then listens
PIO DUE SCHEM. PIN MAPPING SAM3X DUE SCHEM. BOARD LABEL

View file

@ -6,7 +6,6 @@ LVGL application that executes NuttShell (NSH) commands entered with a
Touchscreen Keyboard and displays the NSH output. Prerequisite configuration
settings:
- ``CONFIG_NSH_ARCHINIT=n`` NSH architecture initialization must be disabled.
- ``CONFIG_NSH_CONSOLE=y`` NSH must be configured to use a console.
- ``CONFIG_LIBC_EXECFUNCS=y`` posix_spawn() must be enabled.
- ``CONFIG_PIPES=y`` Pipes must be enabled.

View file

@ -374,12 +374,6 @@ Configuration Description
``CONFIG_NSH_TELNET`` If ``CONFIG_NSH_TELNET`` is set to *y*, then a TELNET server
front-end is selected. When this option is provided, you may log
into NuttX remotely using telnet in order to access NSH.
``CONFIG_NSH_ARCHINIT`` Set ``CONFIG_NSH_ARCHINIT`` if your board provides architecture
specific initialization via the board-specific function
``board_app_initialize()``. This function will be called early in
NSH initialization to allow board logic to do such things as
configure MMC/SD slots.
=================================== ==================================
.. _nsh_vars_table:

View file

@ -108,13 +108,6 @@ The NSH initialization function, ``nsh_initialize()``, be found in
``apps/nshlib/rc.sysinit.template``. The resulting ROMFS file system can be
found in ``apps/nshlib/nsh_romfsimg.h``.
#. ``board_app_initialize()``: Next any architecture-specific NSH
initialization will be performed (if any). For the STM3240G-EVAL,
this architecture specific initialization can be found at
``boards/arm/stm32/stm3240g-eval/src/stm32_appinit.c``. This it does
things like: (1) Initialize SPI devices, (2) Initialize SDIO, and (3)
mount any SD cards that may be inserted.
#. ``nsh_netinit()``: The ``nsh_netinit()`` function can be found in
``apps/nshlib/nsh_netinit.c``.

View file

@ -6,11 +6,6 @@ Customizing NSH Initialization
customize the NSH start-up behavior. Here they are presented in order of
increasing difficulty:
#. You can extend the initialization logic in
``boards/arm/stm32/stm3240g-eval/src/stm32_appinit.c``. The logic
there is called each time that NSH is started and is good place in
particular for any device-related initialization.
#. You replace the sample code at ``apps/examples/nsh/nsh_main.c`` with
whatever start-up logic that you want. NSH is a library at
``apps/nshlib``. ``apps.examples/nsh`` is just a tiny, example

View file

@ -498,8 +498,7 @@ To enable this feature, set the following configuration options:
CONFIG_TIMER=y
CONFIG_TIMER_WDOG=y
Then call ``timer_wdog_initialize()`` from your board initialization code
(typically in ``board_late_initialize()`` or ``board_app_initialize()``):
Then call ``timer_wdog_initialize()`` from your board initialization code.
.. code-block:: c

View file

@ -8,7 +8,7 @@ USB Host-Side Drivers
``struct usbhost_connection_s`` defined in
``include/nuttx/usb/usbhost.h``.
- ``struct usbhost_driver_s`` provides the interface between
- ``struct usbhost_driver_s`` provides the interface between
the USB host driver and the USB host class driver.
- ``struct usbhost_connection_s`` provides the interface between
@ -91,9 +91,6 @@ USB Host-Side Drivers
registered USB host class driver to the USB host controller
driver.
**Examples**: The function ``nsh_waiter()`` in the file
``boards/arm/lpc17xx_40xx/olimex-lpc1766stk/src/lpc17_40_appinit.c``.
#. As part of its operation during the binding operation, the
USB host class driver will register an instances of a
standard NuttX driver under the ``/dev`` directory. To

View file

@ -149,12 +149,10 @@ Why after putting my application on ENTRYPOINT it stops to work?
----------------------------------------------------------------
When you replace the ENTRYPOINT from "nsh_main" to your application some
initialization flow are changed, for instance the NSH_ARCHINIT is not
executed anymore and so some drivers initialization that are called from
it also stops to work.
initialization flow are changed.
You can fix it enabling the Board Late Initialization that will replace the
NSH_ARCHINIT to call those drivers initialization. Just enable it::
You can fix it enabling the Board Late Initialization that will
perform driver initialization. Just enable it::
RTOS Features --->
RTOS hooks --->

View file

@ -3,24 +3,24 @@ NuttX Protected Build
=====================
.. warning::
Migrated from :
Migrated from :
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+Protected+Build
The Traditional "Flat" Build
============================
The traditional NuttX build is a "flat" build. By flat, I mean that when
you build NuttX, you end up with a single "blob" called ``nuttx``. All of the
components of the build reside in the same address space. All components
The traditional NuttX build is a "flat" build. By flat, I mean that when
you build NuttX, you end up with a single "blob" called ``nuttx``. All of the
components of the build reside in the same address space. All components
of the build can access all other components of the build.
The "Two Pass" Protected Build
==============================
The NuttX protected build, on the other hand, is a "two-pass" build and
generates two "blobs": (1) a separately compiled and linked `kernel` blob
called, again, `nuttx` and separately compiled and linked `user` blob called
in ``nuttx_user.elf`` (in the existing build configurations). The user blob
The NuttX protected build, on the other hand, is a "two-pass" build and
generates two "blobs": (1) a separately compiled and linked `kernel` blob
called, again, `nuttx` and separately compiled and linked `user` blob called
in ``nuttx_user.elf`` (in the existing build configurations). The user blob
is created on pass 1 and the kernel blob is created on pass2.
These two make commands are identical:
@ -30,10 +30,10 @@ These two make commands are identical:
make
make pass1 pass2
But the second is clearer and I prefer to use it for the protected build.
In the second case, the user and kernel blobs are built separately; in the
first, the kernel and user blob builds may be intermixed and somewhat
confusing. You can also build the kernel and user blobs separately with
But the second is clearer and I prefer to use it for the protected build.
In the second case, the user and kernel blobs are built separately; in the
first, the kernel and user blob builds may be intermixed and somewhat
confusing. You can also build the kernel and user blobs separately with
one of the following commands:
.. code-block:: bash
@ -56,46 +56,46 @@ From Pass 2:
The Memory Protection Unit
==========================
If the MCU supports a Memory Protection Unit (MPU), then the logic within
the kernel blob all execute in kernel-mode, i.e., with all privileges.
These privileged threads can access all memory, all CPU instructions,
and all MCU registers. The logic executing within the user-mode blob,
on the other hand, all execute in user-mode with certain restrictions
as enforced by the MCU and by the MPU. The MCU may restrict access to
certain registers and machine instructions; with the MPU, access to all
kernel memory resources are prohibited from the user logic. This includes
If the MCU supports a Memory Protection Unit (MPU), then the logic within
the kernel blob all execute in kernel-mode, i.e., with all privileges.
These privileged threads can access all memory, all CPU instructions,
and all MCU registers. The logic executing within the user-mode blob,
on the other hand, all execute in user-mode with certain restrictions
as enforced by the MCU and by the MPU. The MCU may restrict access to
certain registers and machine instructions; with the MPU, access to all
kernel memory resources are prohibited from the user logic. This includes
the kernel blob's FLASH, .bss/.data storage, and the kernel heap memory.
Advantages of the Protected Build
=================================
The advantages of such a protected build are (1) security and (2)
modularity. Since the kernel resources are protected, it will be much
less likely that a misbehaving task will crash the system or that a
wild pointer access will corrupt critical memory. This security also
provides a safer environment in which to execute 3rd party software
The advantages of such a protected build are (1) security and (2)
modularity. Since the kernel resources are protected, it will be much
less likely that a misbehaving task will crash the system or that a
wild pointer access will corrupt critical memory. This security also
provides a safer environment in which to execute 3rd party software
and prevents "snooping" into the kernel memory from the hosted applications.
Modularity is assured because there is a strict control of the exposed
kernel interfaces. In the flat build, all symbols are exposed and there
is no enforcement of a kernel API. With the protected build, on the
other hand, all interactions with the kernel from the user application
logic must use `system calls` (or `syscalls`) to interface with the OS. A
system call is necessary to transition from user-mode to kernel-mode;
all user-space operating system interfaces are via syscall `proxies`.
Then, while in kernel mode, the kernel system call handler will
perform the OS service requested by the application. At the
conclusion of system processing, user-privileges are restored
and control is return to the user application. Since the only
interactions with the kernel can be through support system calls,
Modularity is assured because there is a strict control of the exposed
kernel interfaces. In the flat build, all symbols are exposed and there
is no enforcement of a kernel API. With the protected build, on the
other hand, all interactions with the kernel from the user application
logic must use `system calls` (or `syscalls`) to interface with the OS. A
system call is necessary to transition from user-mode to kernel-mode;
all user-space operating system interfaces are via syscall `proxies`.
Then, while in kernel mode, the kernel system call handler will
perform the OS service requested by the application. At the
conclusion of system processing, user-privileges are restored
and control is return to the user application. Since the only
interactions with the kernel can be through support system calls,
modularity of the OS is guaranteed.
User-Space Proxies/Kernel-Space Stubs
=====================================
The same OS interfaces are exposed to the application in both the "flat"
build and the protected build. The difference is that in the protected
build, the user-code interfaces with a `proxy` for the OS function. For
The same OS interfaces are exposed to the application in both the "flat"
build and the protected build. The difference is that in the protected
build, the user-code interfaces with a `proxy` for the OS function. For
example, here is what a proxy for the OS ``getpid()`` interface:
.. code-block:: c
@ -107,26 +107,26 @@ example, here is what a proxy for the OS ``getpid()`` interface:
return (pid_t)sys_call0(SYS_getpid);
}
Thus the ``getpid()`` proxy is a stand-in for the real OS ``getpid()`` interface
that executes a system call so the kernel code can perform the real
``getpid()`` operation on behalf of the user application. Proxies are
auto-generated for all exported OS interfaces using the CSV file
``syscall/syscall.csv`` and the program ``tools/mksyscalls``. Similarly,
on the kernel-side, there are auto-generated `stubs` that map the
system calls back into real OS calls. These, however, are internal
to the OS and the implementation may be architecture-specific.
Thus the ``getpid()`` proxy is a stand-in for the real OS ``getpid()`` interface
that executes a system call so the kernel code can perform the real
``getpid()`` operation on behalf of the user application. Proxies are
auto-generated for all exported OS interfaces using the CSV file
``syscall/syscall.csv`` and the program ``tools/mksyscalls``. Similarly,
on the kernel-side, there are auto-generated `stubs` that map the
system calls back into real OS calls. These, however, are internal
to the OS and the implementation may be architecture-specific.
See the ``README.txt`` files in those directories for further information.
Combining Intel HEX Files
=========================
One issue that you may face is that the two pass builds creates two
FLASH images. Some debuggers that I use will allow me to write each
image to FLASH separately. Others will expect to have a single Intel
HEX image. In this latter case, you may need to combine the two Intel
One issue that you may face is that the two pass builds creates two
FLASH images. Some debuggers that I use will allow me to write each
image to FLASH separately. Others will expect to have a single Intel
HEX image. In this latter case, you may need to combine the two Intel
HEX files into one. Here is how you can do that:
1) The `tail` of the ``nuttx.hex`` file should look something like this
1) The `tail` of the ``nuttx.hex`` file should look something like this
(with my comments and spaces added):
.. code-block:: bash
@ -144,10 +144,10 @@ HEX files into one. Here is how you can do that:
Use an editor such as vi to remove the 05 and 01 records.
2) The `head` of the ``nuttx_user.hex`` file should look something like this
2) The `head` of the ``nuttx_user.hex`` file should look something like this
(again with my comments and spaces added):
.. code-block:: bash
.. code-block:: bash
$ head nuttx_user.hex
# 04, Extended Linear Address Record
@ -160,94 +160,94 @@ Use an editor such as vi to remove the 05 and 01 records.
Nothing needs to be done here. The ``nuttx_user.hex`` file should be fine.
3) Combine the edited nuttx.hex and un-edited ``nuttx_user.hex`` file to produce
3) Combine the edited nuttx.hex and un-edited ``nuttx_user.hex`` file to produce
a single combined hex file:
.. code-block:: bash
$ cat nuttx.hex nuttx_user.hex >combined.hex
Then use the ``combined.hex`` file with for FLASH/JTAG tool. If you do this
a lot, you will probably want to invest a little time to develop a tool
Then use the ``combined.hex`` file with for FLASH/JTAG tool. If you do this
a lot, you will probably want to invest a little time to develop a tool
to automate these steps.
Files and Directories
=====================
Here is a summary of directories and files used by the STM32F4Discovery
Here is a summary of directories and files used by the STM32F4Discovery
protected build:
* ``boards/arm/stm32/stm32f4discovery/configs/kostest``. This is the kernel
mode OS test configuration. The two standard configuration files
* ``boards/arm/stm32/stm32f4discovery/configs/kostest``. This is the kernel
mode OS test configuration. The two standard configuration files
can be found in this directory: (1) ``defconfig`` and (2) ``Make.defs``.
* ``boards/arm/stm32/stm32f4discovery/kernel``. This is the first past
build directory. The Makefile in this directory is invoked to
produce the pass1 object (``nuttx_user.elf`` in this case). The
second pass object is created by ``arch/arm/src/Makefile``. Also
in this directory is the file ``userspace.c``. The user-mode blob
contains a header that includes information need by the kernel
blob in order to interface with the user-code. That header is
* ``boards/arm/stm32/stm32f4discovery/kernel``. This is the first past
build directory. The Makefile in this directory is invoked to
produce the pass1 object (``nuttx_user.elf`` in this case). The
second pass object is created by ``arch/arm/src/Makefile``. Also
in this directory is the file ``userspace.c``. The user-mode blob
contains a header that includes information need by the kernel
blob in order to interface with the user-code. That header is
defined in by this file.
* ``boards/arm/stm32/stm32f4discovery/scripts``. Linker scripts for
the kernel mode build are found in this directory. This includes
(1) ``memory.ld`` which hold the common memory map, (2) ``user-space.ld``
that is used for linking the pass1 user-mode blob, and (3)
* ``boards/arm/stm32/stm32f4discovery/scripts``. Linker scripts for
the kernel mode build are found in this directory. This includes
(1) ``memory.ld`` which hold the common memory map, (2) ``user-space.ld``
that is used for linking the pass1 user-mode blob, and (3)
``kernel-space.ld`` that is used for linking the pass1 kernel-mode blob.
Alignment, Regions, and Subregions
==================================
There are some important comments in the ``memory.ld``
There are some important comments in the ``memory.ld``
file that are worth duplicating here:
"The STM32F407VG has 1024Kb of FLASH beginning at address
"The STM32F407VG has 1024Kb of FLASH beginning at address
0x0800:0000 and 192Kb of SRAM. SRAM is split up into three blocks:
* "112KB of SRAM beginning at address 0x2000:0000
* "16KB of SRAM beginning at address 0x2001:c000
* "64KB of CCM SRAM beginning at address 0x1000:0000
"When booting from FLASH, FLASH memory is aliased to address
0x0000:0000 where the code expects to begin execution by jumping
"When booting from FLASH, FLASH memory is aliased to address
0x0000:0000 where the code expects to begin execution by jumping
to the entry point in the 0x0800:0000 address range.
"For MPU support, the kernel-mode NuttX section is assumed to
be 128Kb of FLASH and 4Kb of SRAM. That is an excessive amount
for the kernel which should fit into 64KB and, of course, can
be optimized as needed... Allowing the additional memory does
permit addition debug instrumentation to be added to the kernel
"For MPU support, the kernel-mode NuttX section is assumed to
be 128Kb of FLASH and 4Kb of SRAM. That is an excessive amount
for the kernel which should fit into 64KB and, of course, can
be optimized as needed... Allowing the additional memory does
permit addition debug instrumentation to be added to the kernel
space without overflowing the partition.
"Alignment of the user space FLASH partition is also a critical
factor: The user space FLASH partition will be spanned with a
single region of size 2||n bytes. The alignment of the user-space
region must be the same. As a consequence, as the user-space
"Alignment of the user space FLASH partition is also a critical
factor: The user space FLASH partition will be spanned with a
single region of size 2||n bytes. The alignment of the user-space
region must be the same. As a consequence, as the user-space
increases in size, the alignment requirement also increases.
"This alignment requirement means that the largest user space
FLASH region you can have will be 512KB at it would have to be
positioned at 0x08800000. If you change this address, don't
forget to change the ``CONFIG_NUTTX_USERSPACE`` configuration
"This alignment requirement means that the largest user space
FLASH region you can have will be 512KB at it would have to be
positioned at 0x08800000. If you change this address, don't
forget to change the ``CONFIG_NUTTX_USERSPACE`` configuration
setting to match and to modify the check in ``kernel/userspace.c``.
"For the same reasons, the maximum size of the SRAM mapping is
limited to 4KB. Both of these alignment limitations could be
reduced by using multiple MPU regions to map the FLASH/SDRAM
"For the same reasons, the maximum size of the SRAM mapping is
limited to 4KB. Both of these alignment limitations could be
reduced by using multiple MPU regions to map the FLASH/SDRAM
range or perhaps with some clever use of subregions."
Memory Management
=================
At present, there are two options for memory management in the
At present, there are two options for memory management in the
NuttX protected build:
Single User Heap
----------------
By default, there is only a single user-space heap and heap
allocator that is shared by both kernel- and user-modes.
PROs: Simple and makes good use of the heap memory space,
CONs: Awkward architecture and no security for kernel-mode
By default, there is only a single user-space heap and heap
allocator that is shared by both kernel- and user-modes.
PROs: Simple and makes good use of the heap memory space,
CONs: Awkward architecture and no security for kernel-mode
allocations.
Dual, Partitioned Heaps
@ -255,70 +255,70 @@ Dual, Partitioned Heaps
Two configuration options can change this behavior:
* ``CONFIG_MM_MULTIHEAP=y``. This changes internal memory manager interfaces
* ``CONFIG_MM_MULTIHEAP=y``. This changes internal memory manager interfaces
so that multiple heaps can be supported.
* ``CONFIG_MM_KERNEL_HEAP=y``. Uses the multi-heap capability to enable
* ``CONFIG_MM_KERNEL_HEAP=y``. Uses the multi-heap capability to enable
a kernel heap
If this both options are defined defined, the two heap partitions and
If this both options are defined defined, the two heap partitions and
two copies of the memory allocators are built:
One un-protected heap partition that will allocate user accessible memory
that is shared by both the kernel- and user-space code. That allocator
physically resides in the user address space so that it can be called
directly by both the user- and kernel-space code. There is a header at
the beginning of the user-space blob; the kernel-space code gets
One un-protected heap partition that will allocate user accessible memory
that is shared by both the kernel- and user-space code. That allocator
physically resides in the user address space so that it can be called
directly by both the user- and kernel-space code. There is a header at
the beginning of the user-space blob; the kernel-space code gets
address of the user-space allocator from this header.
And another protected heap partition that will allocate protected
memory that is only accessible from the kernel code. This allocator
is built into the kernel block. This separate protected heap is
And another protected heap partition that will allocate protected
memory that is only accessible from the kernel code. This allocator
is built into the kernel block. This separate protected heap is
required if you want to support security features.
NOTE: There are security issues with calling into the user space
allocators in kernel mode. That is a security hole that could be
exploit to gain control of the system! Instead, the kernel code
should switch to user mode before entering the memory allocator
stubs (perhaps via a trap). The memory allocator stubs should
NOTE: There are security issues with calling into the user space
allocators in kernel mode. That is a security hole that could be
exploit to gain control of the system! Instead, the kernel code
should switch to user mode before entering the memory allocator
stubs (perhaps via a trap). The memory allocator stubs should
then trap to return to kernel mode (as does the signal handler now).
The Traditional Approach
------------------------
A more traditional approach would use something like the interface
``sbrk()``. The ``sbrk()`` function adds memory to the heap space
allocation of the calling process. In this case, there would
still be kernel- and user-mode instances of the memory allocators.
Each would ``sbrk()`` as necessary to extend their heap; the pages
allocated for the kernel-mode allocator would be protected but
the pages allocated for the user-mode allocator would not.
PROs: Meets all of the needs. CONs: Complex. Memory losses
A more traditional approach would use something like the interface
``sbrk()``. The ``sbrk()`` function adds memory to the heap space
allocation of the calling process. In this case, there would
still be kernel- and user-mode instances of the memory allocators.
Each would ``sbrk()`` as necessary to extend their heap; the pages
allocated for the kernel-mode allocator would be protected but
the pages allocated for the user-mode allocator would not.
PROs: Meets all of the needs. CONs: Complex. Memory losses
due to quantization.
This approach works well with CPUs that have very capable
Memory Management Units (MMUs) that can coalesce the
srbk-ed chunks to a contiguous, `virtual` heap region.
Without an MMU, the sbrk-ed memory would not be
contiguous; this would limit the sizes of allocations
This approach works well with CPUs that have very capable
Memory Management Units (MMUs) that can coalesce the
srbk-ed chunks to a contiguous, `virtual` heap region.
Without an MMU, the sbrk-ed memory would not be
contiguous; this would limit the sizes of allocations
due to the physical pages.
Many MCUs will have Memory Protection Units (MPUs) that can
support the security features (only). However these lower
end MPUs may not support sufficient mapping capability to
support this traditional approach. The ARMv7-M MPU, for
example, only supports eight protection regions to manage
all FLASH and SRAM and so this approach would not be
Many MCUs will have Memory Protection Units (MPUs) that can
support the security features (only). However these lower
end MPUs may not support sufficient mapping capability to
support this traditional approach. The ARMv7-M MPU, for
example, only supports eight protection regions to manage
all FLASH and SRAM and so this approach would not be
technically feasible for th ARMv7-M family (Cortex-M3/4).
Comparing the "Flat" Build Configuration with the Protected Build Configuration
===============================================================================
Compare, for example the configuration
``boards/arm/stm32/stm32f4discovery/configs/ostest`` and the
configuration ``boards/arm/stm32/stm32f4discovery/configs/kostest``.
These two configurations are identical except that one builds a
"flat" version of OS test and the other builds a kernel version
of the OS test. See the file ``boards/arm/stm32/stm32f4discovery/README.txt``
Compare, for example the configuration
``boards/arm/stm32/stm32f4discovery/configs/ostest`` and the
configuration ``boards/arm/stm32/stm32f4discovery/configs/kostest``.
These two configurations are identical except that one builds a
"flat" version of OS test and the other builds a kernel version
of the OS test. See the file ``boards/arm/stm32/stm32f4discovery/README.txt``
for more details about those configurations.
The configurations can be compared using the ``cmpconfig`` tool:
@ -330,120 +330,116 @@ The configurations can be compared using the ``cmpconfig`` tool:
cd ..
tools/cmpconfig boards/arm/stm32/stm32f4discovery/configs/ostest/defconfig boards/arm/stm32/stm32f4discovery/configs/kostest/defconfig
Here is a summary of the meaning of all of the important differences in the
configurations. This should be enough information for you to convert any
Here is a summary of the meaning of all of the important differences in the
configurations. This should be enough information for you to convert any
configuration from a "flat" to a protected build:
* ``CONFIG_BUILD_2PASS=y``. This enables the two pass build.
* ``CONFIG_BUILD_PROTECTED=y``. This option enables the "two pass"
* ``CONFIG_BUILD_PROTECTED=y``. This option enables the "two pass"
protected build.
* ``CONFIG_PASS1_BUILDIR="boards/arm/stm32/stm32f4discovery/kernel"``.
* ``CONFIG_PASS1_BUILDIR="boards/arm/stm32/stm32f4discovery/kernel"``.
This tells the build system the (relative) location of the pass1 build directory.
* ``CONFIG_PASS1_OBJECT=""``. In some "two pass" build configurations,
the build system need to know the name of the first pass object.
* ``CONFIG_PASS1_OBJECT=""``. In some "two pass" build configurations,
the build system need to know the name of the first pass object.
This setting is not used for the protected build.
* ``CONFIG_NUTTX_USERSPACE=0x08020000``. This is the expected location
where the user-mode blob will be located. The user-mode blob
contains a header that includes information need by the kernel
blob in order to interface with the user-code. That header will
* ``CONFIG_NUTTX_USERSPACE=0x08020000``. This is the expected location
where the user-mode blob will be located. The user-mode blob
contains a header that includes information need by the kernel
blob in order to interface with the user-code. That header will
be expected to reside at this location.
* ``CONFIG_PASS1_TARGET="all"``. This is the build target to use for
* ``CONFIG_PASS1_TARGET="all"``. This is the build target to use for
invoking the pass1 make.
* ``CONFIG_MM_MULTIHEAP=y``. This changes internal memory manager
* ``CONFIG_MM_MULTIHEAP=y``. This changes internal memory manager
interfaces so that multiple heaps can be supported.
* ``CONFIG_MM_KERNEL_HEAP=y``. NuttX supports the option of using a
single user-accessible heap or, if this options is defined,
two heaps: (1) one that will allocate user accessible memory
that is shared by both the kernel- and user-space code, and
(2) one that will allocate protected memory that is only
accessible from the kernel code. Separate heap memory is required
* ``CONFIG_MM_KERNEL_HEAP=y``. NuttX supports the option of using a
single user-accessible heap or, if this options is defined,
two heaps: (1) one that will allocate user accessible memory
that is shared by both the kernel- and user-space code, and
(2) one that will allocate protected memory that is only
accessible from the kernel code. Separate heap memory is required
if you want to support security features.
* ``CONFIG_MM_KERNEL_HEAPSIZE=8192``. This determines an approximate
size for the kernel heap. The standard heap space is partitioned
into a kernel- and user-heap space. This size of the kernel heap
is only approximate because the user heap is subject to stringent
alignment requirements. Because of the alignment requirements, the
* ``CONFIG_MM_KERNEL_HEAPSIZE=8192``. This determines an approximate
size for the kernel heap. The standard heap space is partitioned
into a kernel- and user-heap space. This size of the kernel heap
is only approximate because the user heap is subject to stringent
alignment requirements. Because of the alignment requirements, the
actual size of the kernel heap could be considerable larger than this.
* ``CONFIG_BOARD_EARLY_INITIALIZE=y``. This setting enables a special,
* ``CONFIG_BOARD_EARLY_INITIALIZE=y``. This setting enables a special,
`early` initialization call to initialize board-specific resources.
* ``CONFIG_BOARD_LATE_INITIALIZE=y``. This setting enables a special
initialization call to initialize `late` board-specific resources.
The difference between ``CONFIG_BOARD_EARLY_INITIALIZE`` and
``CONFIG_BOARD_LATE_INITIALIZE`` is that the ``CONFIG_BOARD_EARLY_INITIALIZE``
logic runs earlier in initialization before the full operating
system is up and running. ``CONFIG_BOARD_LATE_INITIALIZE``, on the
other hand, runs at the completion of initialization, just before
the user applications are started. Neither ``CONFIG_BOARD_EARLY_INITIALIZE``
nor ``CONFIG_BOARD_LATE_INITIALIZE`` are used in the OS test
configuration but other configurations (such as NSH)
require some application-specific initialization before
the application can run. In the "flat" build, such initialization
is performed as part of the application start-up sequence.
These includes such things as initializing device drivers.
These same initialization steps must be performed in kernel
mode for the protected build and ``CONFIG_BOARD_LATE_INITIALIZE``.
See ``boards/arm/stm32/stm32f4discovery/src/up_boot.c`` for an
* ``CONFIG_BOARD_LATE_INITIALIZE=y``. This setting enables a special
initialization call to initialize `late` board-specific resources.
The difference between ``CONFIG_BOARD_EARLY_INITIALIZE`` and
``CONFIG_BOARD_LATE_INITIALIZE`` is that the ``CONFIG_BOARD_EARLY_INITIALIZE``
logic runs earlier in initialization before the full operating
system is up and running. ``CONFIG_BOARD_LATE_INITIALIZE``, on the
other hand, runs at the completion of initialization, just before
the user applications are started. Neither ``CONFIG_BOARD_EARLY_INITIALIZE``
nor ``CONFIG_BOARD_LATE_INITIALIZE`` are used in the OS test
configuration but other configurations (such as NSH)
require some application-specific initialization before
the application can run. In the "flat" build, such initialization
is performed as part of the application start-up sequence.
These includes such things as initializing device drivers.
These same initialization steps must be performed in kernel
mode for the protected build and ``CONFIG_BOARD_LATE_INITIALIZE``.
See ``boards/arm/stm32/stm32f4discovery/src/up_boot.c`` for an
example of such board initialization code.
* ``CONFIG_NSH_ARCHINITIALIZE`` is not defined. The setting
``CONFIG_NSH_ARCHINITIALIZE`` does not apply to the OS test
configuration, however, this is noted here as an example
of initialization that cannot be performed in the protected build.
Architecture-Specific Options:
* ``CONFIG_SYS_RESERVED=8``. The user application logic
interfaces with the kernel blob using system calls.
The architecture-specific logic may need to reserved a
few system calls for its own internal use. The ARMv7-M
* ``CONFIG_SYS_RESERVED=8``. The user application logic
interfaces with the kernel blob using system calls.
The architecture-specific logic may need to reserved a
few system calls for its own internal use. The ARMv7-M
architectures all require 8 reserved system calls.
* ``CONFIG_SYS_NNEST=2``. System calls may be nested. The
system must retain information about each nested system
call and this setting is used to set aside resources for
nested system calls. In the current architecture, a maximum
* ``CONFIG_SYS_NNEST=2``. System calls may be nested. The
system must retain information about each nested system
call and this setting is used to set aside resources for
nested system calls. In the current architecture, a maximum
nesting level of two is all that is needed.
* ``CONFIG_ARMV7M_MPU=y``. This settings enables support for
the ARMv7-M Memory Protection Unit (MPU). The MPU is used
* ``CONFIG_ARMV7M_MPU=y``. This settings enables support for
the ARMv7-M Memory Protection Unit (MPU). The MPU is used
to prohibit user-mode access to kernel resources.
* ``CONFIG_ARMV7M_MPU_NREGIONS=8``. The ARMv7-M MPU supports 8
* ``CONFIG_ARMV7M_MPU_NREGIONS=8``. The ARMv7-M MPU supports 8
protection regions.
Size Expansion
==============
The protected build will, or course, result in a FLASH image that is
larger than that of the corresponding "flat" build. How much larger?
I don't have the numbers in hand, but you can build
``boards/arm/stm32/stm32f4discovery/configs/nsh`` and
``boards/arm/stm32/stm32f4discovery/configs/kostest`` and compare
The protected build will, or course, result in a FLASH image that is
larger than that of the corresponding "flat" build. How much larger?
I don't have the numbers in hand, but you can build
``boards/arm/stm32/stm32f4discovery/configs/nsh`` and
``boards/arm/stm32/stm32f4discovery/configs/kostest`` and compare
the resulting binaries for yourself using the ``size`` command.
Increases in size are expected because:
* The syscall layer is included in the protected build but not the flat
* The syscall layer is included in the protected build but not the flat
build.
* The kernel-size _syscal_l stubs will cause all enabled OS code to be
drawn into the build. In the flat build, only those OS interfaces
* The kernel-size _syscal_l stubs will cause all enabled OS code to be
drawn into the build. In the flat build, only those OS interfaces
actually called by the application will be included in the final objects.
* The dual memory allocators will increase size.
* Code duplication. Some code, such as the C library, will be
* Code duplication. Some code, such as the C library, will be
duplicated in both the kernel- and user-blobs, and
* Alignment. The alignments required by the MPU logic will leave
* Alignment. The alignments required by the MPU logic will leave
relatively large regions of FLASH (and perhaps RAM) is not usable.
Performance Issues
==================
The only performance differences using the protected build should
result as a consequence of the `sycalls` used to interact with the
OS vs. the direct C calls as used in the flat build. If your
performance is highly dependent upon high rate OS calls, then
this could be an issue for you. But, in the typical application,
The only performance differences using the protected build should
result as a consequence of the `sycalls` used to interact with the
OS vs. the direct C calls as used in the flat build. If your
performance is highly dependent upon high rate OS calls, then
this could be an issue for you. But, in the typical application,
OS calls do not often figure into the critical performance paths.
The `syscalls` are, ultimately, software interrupts. If the platform
does not support prioritized, nested interrupts then the `syscall`
execution could also delay other hardware interrupt processing.
However, `sycall` processing is negligible: they really just
configure to return to in supervisor mode and vector to the
`syscall` stub. They should be lightning fast and, for the typical
real-time applications, should cause no issues.
The `syscalls` are, ultimately, software interrupts. If the platform
does not support prioritized, nested interrupts then the `syscall`
execution could also delay other hardware interrupt processing.
However, `sycall` processing is negligible: they really just
configure to return to in supervisor mode and vector to the
`syscall` stub. They should be lightning fast and, for the typical
real-time applications, should cause no issues.

View file

@ -182,10 +182,6 @@ Device Drivers -> USB Device Driver Support .
=========================================== ===================================================
Application Configuration -> NSH LIbrary .
``CONFIG_NSH_USBDEV_TRACE=n`` Make sure that any built-in tracing from NSH is disabled.
``CONFIG_NSH_ARCHINIT=y`` Enable this option only if your board-specific logic
. has logic to automatically start the USB monitor.
. Otherwise the USB monitor can be started or stopped
. with the usbmon_start and usbmon_stop commands from the NSH console.
=========================================== ===================================================
=============================================== ============================================

View file

@ -459,7 +459,6 @@ SD Card Support
CONFIG_SCHED_HPWORK=y
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization, and
CONFIG_BOARDCTL=y : Or
CONFIG_BOARD_LATE_INITIALIZE=y

View file

@ -462,7 +462,6 @@ SD Card Support
CONFIG_SCHED_HPWORK=y
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization, and
CONFIG_BOARDCTL=y : Or
CONFIG_BOARD_LATE_INITIALIZE=y

View file

@ -490,5 +490,3 @@ Where <subdir> is one of the following:
CONFIG_KINETIS_PORTEINTS=y : Enable PortE GPIO interrupts
CONFIG_SCHED_WORKQUEUE=y : Enable the NuttX workqueue
CONFIG_NSH_ARCHINIT=y : Provide NSH initialization logic

View file

@ -591,8 +591,6 @@ Where <subdir> is one of the following:
CONFIG_SCHED_WORKQUEUE=y : Enable the NuttX workqueue
CONFIG_NSH_ARCHINIT=y : Provide NSH initialization logic
netnsh:
------
This is the same config then nsh, but it adds Ethernet support with the

View file

@ -497,7 +497,6 @@ Where <subdir> is one of the following:
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority

View file

@ -5,7 +5,7 @@ Arduino Due
This documentation discusses issues unique to NuttX configurations for the
Arduino DUE board featuring the Atmel ATSAM3X8E MCU running at 84 MHz.
.. note::
.. note::
If found that newer Arduino Due board differ from the older boards mine:
Mine has the 32.768 slow clock crystal and associated caps installed. The newer
@ -25,83 +25,83 @@ Supported Shields
PIO Pin Usage
=============
PORTA
-----
.. csv-table::
:header: PIO,SIGNAL,CONN,PIN
PA0,CANTX0,ADCH,8
PA1,CANRX0,ACDH,7
PA2,AD7,ADCL,8
PA3,AD6,ADCL,7
PA4,AD5,ADCL,6
PA5,EEXTINT,ETH ,8
PA6,AD4,ADCL,5
PA7,PIN31,XIO ,12
PA8,[U]RX,PWML,1
PA9,[U]TX,PWML,2
PA10,RXD2,COMM,6
PA11,TXD2,COMM,5
PA12,RXD1,COMM,4
PA13,TXD1,COMM,3
PA14,PIN23,XIO ,4
PA15,PIN24,XIO ,5
PA16,AD0,ADCL,1
PA17,SDA1,PWMH,9
PA18,SCL1,PWMH,10
PA19,PIN42,XIO ,23
PA20,PIN43,XIO ,24
PA21,TXL,TX,YELLOW LED
PA22,AD3,ADCL,4
PA23,AD2,ADCL,3
PA24,AD1,ADCL,2
PA25,MISO,SPI,1
PA26,MOSI,SPI,4
PA27,SPCK,SPI,3
PA28,SS0/PWM10,(ETH) PWML,10
PA29,SS1/PWM4 ,(SD),
PA30,N/A,N/A,
PA31,N/A,N/A,
PORTB
PORTA
-----
.. csv-table::
:header: PIO,SIGNAL,CONN,PIN
PB0,ETX_CLK,ETH,1
PB1,ETX_EN,ETH,3
PB2,ETXD0,ETH,5
PB3,ETXD1,ETH,7
PB4,ERX_DV,ETH,10
PB5,ERXD0,ETH,9
PB6,ERXD1,ETH,11
PB7,ERX_ER,ETH,13
PB8,EMDC,ETH,14
PB9,EMDIO,ETH,12
PA0,CANTX0,ADCH,8
PA1,CANRX0,ACDH,7
PA2,AD7,ADCL,8
PA3,AD6,ADCL,7
PA4,AD5,ADCL,6
PA5,EEXTINT,ETH ,8
PA6,AD4,ADCL,5
PA7,PIN31,XIO ,12
PA8,[U]RX,PWML,1
PA9,[U]TX,PWML,2
PA10,RXD2,COMM,6
PA11,TXD2,COMM,5
PA12,RXD1,COMM,4
PA13,TXD1,COMM,3
PA14,PIN23,XIO ,4
PA15,PIN24,XIO ,5
PA16,AD0,ADCL,1
PA17,SDA1,PWMH,9
PA18,SCL1,PWMH,10
PA19,PIN42,XIO ,23
PA20,PIN43,XIO ,24
PA21,TXL,TX,YELLOW LED
PA22,AD3,ADCL,4
PA23,AD2,ADCL,3
PA24,AD1,ADCL,2
PA25,MISO,SPI,1
PA26,MOSI,SPI,4
PA27,SPCK,SPI,3
PA28,SS0/PWM10,(ETH) PWML,10
PA29,SS1/PWM4 ,(SD),
PA30,N/A,N/A,
PA31,N/A,N/A,
PORTB
-----
.. csv-table::
:header: PIO,SIGNAL,CONN,PIN
PB0,ETX_CLK,ETH,1
PB1,ETX_EN,ETH,3
PB2,ETXD0,ETH,5
PB3,ETXD1,ETH,7
PB4,ERX_DV,ETH,10
PB5,ERXD0,ETH,9
PB6,ERXD1,ETH,11
PB7,ERX_ER,ETH,13
PB8,EMDC,ETH,14
PB9,EMDIO,ETH,12
PB10,UOTGVBO,Vbus power,
PB11,UOTGID ,USB1,4
PB12,SDA0-3 ,COMM,7
PB13,SCL0-3 ,COMM,8
PB14,CANTX1/IO ,XIO ,34
PB15,DAC0(CANRX1),ADCH,5
PB16,DAC1,ADCH,6
PB17,AD8,ADCH,1
PB18,AD9,ADCH,2
PB19,AD10,ADCH,3
PB20,AD11(TXD3),ADCH,4
PB21,AD14(RXD3),XIO,33
PB22,N/C,N/A,
PB23,SS3,???,
PB24,N/C,N/A,
PB25,PWM2,PWML,3
PB26,PIN22,???,
PB27,PWM13,PWMH,6
PB28,JTAG_TCK,JTAG,4
PB29,JTAG_TDI,JTAG,8
PB30,JTAG_TDO,JTAG,6
PB31,JTAG_TMS,JTAG,2
PB11,UOTGID ,USB1,4
PB12,SDA0-3 ,COMM,7
PB13,SCL0-3 ,COMM,8
PB14,CANTX1/IO ,XIO ,34
PB15,DAC0(CANRX1),ADCH,5
PB16,DAC1,ADCH,6
PB17,AD8,ADCH,1
PB18,AD9,ADCH,2
PB19,AD10,ADCH,3
PB20,AD11(TXD3),ADCH,4
PB21,AD14(RXD3),XIO,33
PB22,N/C,N/A,
PB23,SS3,???,
PB24,N/C,N/A,
PB25,PWM2,PWML,3
PB26,PIN22,???,
PB27,PWM13,PWMH,6
PB28,JTAG_TCK,JTAG,4
PB29,JTAG_TDI,JTAG,8
PB30,JTAG_TDO,JTAG,6
PB31,JTAG_TMS,JTAG,2
PORTC
-----
@ -146,79 +146,79 @@ PORTD
-----
.. csv-table::
:header: PIO,SIGNAL,CONN,PIN
:header: PIO,SIGNAL,CONN,PIN
PD0 , PIN25, XIO ,6
PD1 , PIN26, XIO ,7
PD2 , PIN27, XIO ,8
PD3 , PIN28, XIO ,9
PD4 , TXD0, COMM,1
PD5 , RXD0, COMM,2
PD6 , PIN29, XIO ,10
PD7 , PWM11, PWMH,4
PD8 , PWM12, PWMH,5
PD9 , PIN30, XIO ,11
PD10, PIN32, XIO ,13
PD11, N/A, N/A ,
PD12, N/A, N/A ,
PD13, N/A, N/A ,
PD14, N/A, N/A ,
PD15, N/A, N/A ,
PD16, N/A, N/A ,
PD17, N/A, N/A ,
PD18, N/A, N/A ,
PD19, N/A, N/A ,
PD20, N/A, N/A ,
PD21, N/A, N/A ,
PD22, N/A, N/A ,
PD23, N/A, N/A ,
PD24, N/A, N/A ,
PD25, N/A, N/A ,
PD26, N/A, N/A ,
PD27, N/A, N/A ,
PD28, N/A, N/A ,
PD29, N/A, N/A ,
PD30, N/A, N/A ,
PD31, N/A, N/A ,
PD0 , PIN25, XIO ,6
PD1 , PIN26, XIO ,7
PD2 , PIN27, XIO ,8
PD3 , PIN28, XIO ,9
PD4 , TXD0, COMM,1
PD5 , RXD0, COMM,2
PD6 , PIN29, XIO ,10
PD7 , PWM11, PWMH,4
PD8 , PWM12, PWMH,5
PD9 , PIN30, XIO ,11
PD10, PIN32, XIO ,13
PD11, N/A, N/A ,
PD12, N/A, N/A ,
PD13, N/A, N/A ,
PD14, N/A, N/A ,
PD15, N/A, N/A ,
PD16, N/A, N/A ,
PD17, N/A, N/A ,
PD18, N/A, N/A ,
PD19, N/A, N/A ,
PD20, N/A, N/A ,
PD21, N/A, N/A ,
PD22, N/A, N/A ,
PD23, N/A, N/A ,
PD24, N/A, N/A ,
PD25, N/A, N/A ,
PD26, N/A, N/A ,
PD27, N/A, N/A ,
PD28, N/A, N/A ,
PD29, N/A, N/A ,
PD30, N/A, N/A ,
PD31, N/A, N/A ,
PORTE
PORTE
-----
.. csv-table::
:header: PIO,SIGNAL,CONN,PIN
:header: PIO,SIGNAL,CONN,PIN
PE0 ,N/A,N/A
PE1 ,N/A,N/A
PE2 ,N/A,N/A
PE3 ,N/A,N/A
PE4 ,N/A,N/A
PE5 ,N/A,N/A
PE6 ,N/A,N/A
PE7 ,N/A,N/A
PE8 ,N/A,N/A
PE9 ,N/A,N/A
PE10,N/A,N/A
PE11,N/A,N/A
PE12,N/A,N/A
PE13,N/A,N/A
PE14,N/A,N/A
PE15,N/A,N/A
PE16,N/A,N/A
PE17,N/A,N/A
PE18,N/A,N/A
PE19,N/A,N/A
PE20,N/A,N/A
PE21,N/A,N/A
PE22,N/A,N/A
PE23,N/A,N/A
PE24,N/A,N/A
PE25,N/A,N/A
PE26,N/A,N/A
PE27,N/A,N/A
PE28,N/A,N/A
PE29,N/A,N/A
PE30,N/A,N/A
PE31,N/A,N/A
PE0 ,N/A,N/A
PE1 ,N/A,N/A
PE2 ,N/A,N/A
PE3 ,N/A,N/A
PE4 ,N/A,N/A
PE5 ,N/A,N/A
PE6 ,N/A,N/A
PE7 ,N/A,N/A
PE8 ,N/A,N/A
PE9 ,N/A,N/A
PE10,N/A,N/A
PE11,N/A,N/A
PE12,N/A,N/A
PE13,N/A,N/A
PE14,N/A,N/A
PE15,N/A,N/A
PE16,N/A,N/A
PE17,N/A,N/A
PE18,N/A,N/A
PE19,N/A,N/A
PE20,N/A,N/A
PE21,N/A,N/A
PE22,N/A,N/A
PE23,N/A,N/A
PE24,N/A,N/A
PE25,N/A,N/A
PE26,N/A,N/A
PE27,N/A,N/A
PE28,N/A,N/A
PE29,N/A,N/A
PE30,N/A,N/A
PE31,N/A,N/A
PORTF
-----
@ -362,7 +362,7 @@ Due PIN GPIO FUNCTION SIGNAL ITHEAD PIN ITHEAD SIGNA
a bit-bang SPI interface is used. This includes the touch controller
a bit-bang SPI interface is used. This includes the touch controller
and the SD card.
2. UART0 cannot be used. USARTs on the COMM connector should be available.
3. Parallel data is not contiguous in the PIO register
@ -381,27 +381,27 @@ SD Interface
------------
====== ========= ======== ========= ========
SD PIN SD SIGNAL PIN SIGNAL GPIO
SD PIN SD SIGNAL PIN SIGNAL GPIO
====== ========= ======== ========= ========
1 /CS J2 pin 3 D10 PA28
1 /CS J2 pin 3 D10 PA28
2 DI J2 pin 4 D11 PD7
3 GND --- --- ---
3 GND --- --- ---
4 VCC --- --- ---
5 CLK J2 pin 6 D13 PB27
5 CLK J2 pin 6 D13 PB27
6 GND --- --- ---
7 DO J2 pin 5 D12 PD8
7 DO J2 pin 5 D12 PD8
8 IRQ N/C --- ---
9 N/C --- --- ---
9 N/C --- --- ---
10 SW N/C --- ---
11 WP N/C --- ---
11 WP N/C --- ---
12 CD N/C --- ---
13 CD N/C --- ---
13 CD N/C --- ---
14 GND --- --- ---
15 GND --- --- ---
15 GND --- --- ---
16 GND --- --- ---
====== ========= ======== ========= ========
.. note::
.. note::
* The SD slot shares the pin with LED "L" so LED support must be disabled to
use the MMC/SD card on the ITEAD shield.
@ -412,27 +412,27 @@ Touch Controller Interface
--------------------------
=========== ============== ======== ========= ========
XPT2046 PIN XPT2046 SIGNAL PIN SIGNAL GPIO
XPT2046 PIN XPT2046 SIGNAL PIN SIGNAL GPIO
=========== ============== ======== ========= ========
1 VCC --- --- ---
1 VCC --- --- ---
2 X+ --- --- ---
3 Y+ --- --- ---
3 Y+ --- --- ---
4 X- --- --- ---
5 Y- --- --- ---
5 Y- --- --- ---
6 GND --- --- ---
7 IN3 N/C --- ---
7 IN3 N/C --- ---
8 IN4 N/C --- ---
9 VREF --- --- ---
9 VREF --- --- ---
10 VCC --- --- ---
11 IRQ J2 pin 2 D9 PC21
11 IRQ J2 pin 2 D9 PC21
12 DOUT J2 pin 1 D8 PC22
13 BUSY N/C --- ---
13 BUSY N/C --- ---
14 DIN J1 pin 1 A0/D15 PA16
15 /CS --- --- ---
15 /CS --- --- ---
16 DCLK J1 pin 2 A1/D15 PA24
=========== ============== ======== ========= ========
.. note::
.. note::
CS is connected to ground (XPT2046 is always selected)
@ -465,7 +465,7 @@ defined. In that case, the usage by the board port is defined in
``include/board.h`` and ``src/sam_leds.c``. The LEDs are used to encode
OS-related events as follows:
.. csv-table::
.. csv-table::
:header: SYMBOL,MEANING,L,TX,RX
``LED_STARTED`` ,NuttX has been started ,OFF ,OFF ,OFF
@ -523,7 +523,7 @@ the case of UART0).
Loading Code
============
.. note::
.. note::
I believe that there have been significant changes to the more recent tool
environment such that Bossac may no longer be usable. I don't know that for
@ -712,7 +712,7 @@ a. Write code to FLASH don't change boot mode and don't reset. This lets you
b. Verify the FLASH contents (the bootloader must be running)
.. code:: console
$ bossac.exe --port=COM26 --usb-port=false -v nuttx.bin
Verify 64628 bytes of flash
[==============================] 100% (253/253 pages)
@ -721,7 +721,7 @@ b. Verify the FLASH contents (the bootloader must be running)
c. Read from FLASH to a file (the bootloader must be running):
.. code:: console
$ bossac.exe --port=COM26 --usb-port=false --read=4096 nuttx.dump
Read 4096 bytes from flash
[==============================] 100% (16/16 pages)
@ -729,10 +729,10 @@ c. Read from FLASH to a file (the bootloader must be running):
d. Change to boot from FLASH
.. code:: console
$ bossac.exe --port=COM26 --usb-port=false --boot=1
Set boot flash true
Uploading NuttX to the Due Using JTAG
-------------------------------------
@ -1012,7 +1012,7 @@ This configuration directory will build the NuttShell.
support for the SD card slot can be enabled by making the following
changes to the configuration:
.. note::
.. note::
You cannot use UART0 or LEDs with this ITEAD module. You must switch
to USART0 and disable LED support as described above.
@ -1047,14 +1047,9 @@ This configuration directory will build the NuttShell.
Board Selection -> Common Board Options
* ``CONFIG_NSH_ARCHINIT=y``: Initialize the MMC/SD slot when NSH starts
* ``CONFIG_NSH_MMCSDSLOTNO=0``: Only one MMC/SD slot, slot 0
* ``CONFIG_NSH_MMCSDSPIPORTNO=0``: (does not really matter in this case)
Application Configuration -> NSH Library
* ``CONFIG_NSH_ARCHINIT=y``: Board has architecture-specific initialization
.. warning::
2013-7-2: SD card is not responding. All 0's received on SPI.
@ -1065,7 +1060,7 @@ This configuration directory will build the NuttShell.
an NSH built-in application. You can enable the touchscreen and test
by modifying the default configuration in the following ways:
.. note::
.. note::
You cannot use UART0 or LEDs with this ITEAD module. You must switch
to USART0 and disable LED support as described above.

View file

@ -56,7 +56,7 @@ LED_PANIC The system has crashed FLASH N/C N/C
glow is because of timer interrupts that result in the LED being illuminated
on a small proportion of the time.
.. note::
.. note::
LED2 may also flicker normally if signals are processed.
@ -225,7 +225,7 @@ The ``<subdir>`` that is provided above as an argument to the
a. Build and install the kconfig-mconf tool. See ``nuttx/README.txt``
see additional README.txt files in the NuttX tools repository.
b. Execute ``make menuconfig`` in ``nuttx/`` in order to start the
reconfiguration process.
@ -250,7 +250,7 @@ The ``<subdir>`` that is provided above as an argument to the
Cygwin)
System Type -> Toolchain:
* ``CONFIG_ARM_TOOLCHAIN_BUILDROOT=y``: Buildroot toolchain
* ``CONFIG_ARM_TOOLCHAIN_BUILDROOT_OABI=y``: Older, OABI toolchain
@ -458,10 +458,6 @@ Configuration enables both the serial and telnetd NSH interfaces.
* ``CONFIG_SCHED_WORKQUEUE=y``: Driver needs work queue support
Application Configuration -> NSH Library
* ``CONFIG_NSH_ARCHINIT=y``: NSH board-initialization
.. warning::
* 2013-6-28: The touchscreen is functional.
@ -501,18 +497,18 @@ The NxWM window manager can be found at ``apps/graphics/NxWidgets/nxwm``.
The NxWM unit test can be found at ``apps/graphics/NxWidgets/UnitTests/nxwm``.
.. warning::
.. warning::
1. 2013-6-28: Created the configuration but have not yet done
anything with it.
2. 2013-6-29: Various changes to get a clean build of this
configuration. Still untested.
3. 20113-6-30: I cannot load this program using AtmelStudio6.1.
The total size with DEBUG on is 138.9 KB. I have verified
that the first 128KB may have been written correctly, but then
the code above 128KB wraps and overwrites the code at the
beginning of FLASH, trashing the FLASH images.
Bottom line: Still untested.

View file

@ -161,7 +161,7 @@ LED_ASSERTION An assertion failed FLASH N/C N/C
LED_PANIC The system has crashed FLASH N/C N/C
=================== ================================= ======= ======= =======
.. note::
.. note::
If D2 and D4 are statically on, then NuttX probably failed to boot and these
LEDs will give you some indication of where the failure was
@ -378,7 +378,7 @@ You can also log into the NSH from the host PC like this:
This delay will be especially long if the board is not connected to a network
because additional time will be required to fail with timeout errors.
This delay will be especially long if the board is not connected to a
network. On the order of a minute! You will probably think that NuttX has
crashed! And then, when it finally does come up, the network will not be
@ -473,10 +473,6 @@ FLASH:
Use care if you plan to use FAT long file name feature in a product; There
are issues with certain Microsoft patents on the long file name technology.
Application Configuration -> NSH Library
* ``CONFIG_NSH_ARCHINIT=y``: NSH board-initialization
Board Selection
* ``CONFIG_SAM4EEK_AT25_BLOCKMOUNT=y``: Mounts AT25 for NSH
@ -520,10 +516,6 @@ System Type -> ATSAM3/4 Peripheral Support
* ``CONFIG_SAM34_UDP=y``: Enable UDP Full Speed USB device
Application Configuration -> NSH Library
* ``CONFIG_NSH_ARCHINIT=y``: NSH board-initialization
Mass Storage Class
------------------
@ -693,10 +685,9 @@ serial console in this configuration):
Application Configuration -> NSH LIbrary:
* ``CONFIG_NSH_USBDEV_TRACE=n``: No builtin tracing from NSH
* ``CONFIG_NSH_ARCHINIT=y``: Automatically start the USB monitor
Application Configuration -> System NSH Add-Ons:
* ``CONFIG_USBMONITOR=y``: Enable the USB monitor daemon
* ``CONFIG_USBMONITOR_STACKSIZE=2048``: USB monitor daemon stack size
* ``CONFIG_USBMONITOR_PRIORITY=50``: USB monitor daemon priority
@ -747,7 +738,6 @@ for the SD slot can be enabled with the following settings:
Application Configuration -> NSH Library
* ``CONFIG_NSH_ARCHINIT=y``: NSH board-initialization
* ``CONFIG_NSH_MMCSDSLOTNO=0``: Only one slot, slot 0
After an SD card is successfully initialized, the block device ``/dev/mmcsd0``
@ -792,7 +782,7 @@ following ways:
* ``CONFIG_ADS7843E_THRESHY=39``
System Type -> Peripherals:
* ``CONFIG_SAM34_SPI0=y``: Enable support for SPI
System Type:
@ -865,13 +855,13 @@ PIN PIO SIGNAL NOTES
27 IM1 Grounded
28 GND
29 [PC13] LED-A Backlight controls: PC13 enables AAT3155 charge pump that drives the backlight LEDs
30 [PC13] LEDK1
31 [PC13] LEDK2
30 [PC13] LEDK1
31 [PC13] LEDK2
32 [PC13] LEDK3
33 [PC13] LEDK4
34 [PC13] LEDK1
35 Y+ These go to the ADS7843 touchscreen controller.
36 Y-
36 Y-
37 X+
38 X-
39 NC
@ -929,57 +919,57 @@ SAM4E-EK-specific Configuration Options
* ``CONFIG_ARCH``: Identifies the ``arch/`` subdirectory. This should be set
to:
* ``CONFIG_ARCH=arm``
* ``CONFIG_ARCH_family``: For use in C code:
* ``CONFIG_ARCH_ARM=y``
* ``CONFIG_ARCH_architecture``: For use in C code:
* ``CONFIG_ARCH_CORTEXM3=y``
* ``CONFIG_ARCH_CHIP``: Identifies the ``arch/*/chip`` subdirectory
* ``CONFIG_ARCH_CHIP="sam34"``
* ``CONFIG_ARCH_CHIP_name``: For use in C code to identify the exact chip:
* ``CONFIG_ARCH_CHIP_SAM34``
* ``CONFIG_ARCH_CHIP_SAM3U``
* ``CONFIG_ARCH_CHIP_ATSAM3U4``
* ``CONFIG_ARCH_BOARD``: Identifies the ``boards/`` subdirectory and hence, the
board that supports the particular chip or SoC.
* ``CONFIG_ARCH_BOARD=sam4e:ek`` (for the SAM4E-EK development board)
* ``CONFIG_ARCH_BOARD_name``: For use in C code
* ``CONFIG_ARCH_BOARD_SAM4EEK=y``
* ``CONFIG_ARCH_LOOPSPERMSEC``: Must be calibrated for correct operation of
delay loops
* ``CONFIG_ENDIAN_BIG``: define if big endian (default is little endian)
* ``CONFIG_RAM_SIZE``: Describes the installed DRAM (SRAM in this case):
* ``CONFIG_RAM_SIZE=0x00020000`` (128Kb)
* ``CONFIG_RAM_START``: The start address of installed DRAM
* ``CONFIG_RAM_START=0x20000000``
* ``CONFIG_ARCH_LEDS``: Use LEDs to show state. Unique to boards that have LEDs
* ``CONFIG_ARCH_INTERRUPTSTACK``: This architecture supports an interrupt stack.
If defined, this symbol is the size of the interrupt stack in bytes. If not
defined, the user task stacks will be used during interrupt handling.
* ``CONFIG_ARCH_STACKDUMP``: Do stack dumps after assertions
* ``CONFIG_ARCH_LEDS``: Use LEDs to show state. Unique to board architecture.
Individual subsystems can be enabled:
@ -1447,5 +1437,5 @@ The NxWM unit test can be found at ``apps/graphics/NxWidgets/UnitTests/nxwm``
2014-08-20. I have seen the demo work well but it is not thoroughly
exercised. I suspect some touchscreen issues.
2014-10-11. Today's build crashes in nxwm_main on startup.

View file

@ -419,7 +419,7 @@ The ``<subdir>`` that is provided above as an argument to the
1. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
2. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
@ -428,7 +428,7 @@ The ``<subdir>`` that is provided above as an argument to the
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute ``make menuconfig`` in nuttx/ in order to start the
reconfiguration process.
@ -502,7 +502,7 @@ nsh
This configuration directory will built the NuttShell.
.. note::
.. note::
If you get a compilation error like:
@ -558,10 +558,6 @@ Board Selection -> SAM4L Xplained Pro Modules
* ``CONFIG_SAM4L_XPLAINED_IOMODULE_EXT1=y``: In EXT1, or EXT2
* ``CONFIG_SAM4L_XPLAINED_IOMODULE_EXT2=y``
Application Configuration -> NSH Library
* ``CONFIG_NSH_ARCHINIT=y``: Board has architecture-specific initialization
.. note::
If you enable the I/O1 this configuration with USART0 as the console and with
@ -617,7 +613,7 @@ The NX graphics subsystem also needs to be configured:
* ``CONFIG_NXFONTS_CHARBITS=7``: 7-bit fonts
* ``CONFIG_NXFONT_SANS17X23B=y``: Pick a font (any that will fit)
.. note::
.. note::
This orientation will put the buttons "above" the LCD. The reverse landscape
configuration (CONFIG_LCD_RLANDSCAPE) will "flip" the display so that the
@ -640,18 +636,18 @@ setup for the graphic "Hello, World!" example:
* ``CONFIG_EXAMPLES_NXHELLO_BPP=1``: One bit per pixel
* ``CONFIG_EXAMPLES_NXHELLO_EXTERNINIT=y``: Special initialization is required.
.. note::
.. note::
The OLED is monochrome so the only "colors" are black and white. The default
"colors" will give you while text on a black background. You can override the
faults it you want black text on a while background.
.. warning::
.. warning::
One issue that I have seen with the NXHello example when running as an NSH
command is that it only works the first time. So, after you run the 'nxhello'
command one time, you will have to reset the board before you run it again.
This is clearly some issue with initializing, un-initializing, and then
re-initializing. If you want to fix this, patches are quite welcome.
@ -687,10 +683,6 @@ Application Configuration -> Examples
* ``CONFIG_EXAMPLES_SLCD_DEVNAME="/dev/slcd0"``
* ``CONFIG_EXAMPLES_SLCD_BUFSIZE=64``
Application Configuration -> NSH Library
* ``CONFIG_NSH_ARCHINIT=y``
.. note::
In order to use the segment LCD you *must* open the ``VLCD_A`` and

View file

@ -1134,9 +1134,6 @@ AT25 Serial FLASH
a lot, but at 20MHz, the behavior is not the same with all CM modules. This
lower rate gives more predictable performance.
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
Board Selection
CONFIG_SAMA5D3XPLAINED_AT25_AUTOMOUNT=y : Mounts AT25 for NSH
CONFIG_SAMA5D3XPLAINED_AT25_FTL=y : Create block driver for FAT
@ -1231,9 +1228,6 @@ HSMCI Card Slots
Library Routines
CONFIG_SCHED_WORKQUEUE=y : Driver needs work queue support
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
Using the SD card
-----------------
@ -1374,9 +1368,6 @@ USB High-Speed Device
System Type -> ATSAMA5 Peripheral Support
CONFIG_SAMA5_UDPHS=y : Enable UDPHS High Speed USB device
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
Mass Storage Class
------------------
@ -1471,7 +1462,6 @@ USB High-Speed Device
Application Configuration -> NSH LIbrary:
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
Application Configuration -> System NSH Add-Ons:
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
@ -1515,8 +1505,6 @@ USB High-Speed Host
CONFIG_SCHED_WORKQUEUE=y : High priority worker thread support is required
CONFIG_SCHED_HPWORK=y :
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
file1: CONFIG_USBHOST_ISOC_DISABLE=y
NOTE: When OHCI is selected, the SAMA5 will operate at 384MHz instead of
@ -1553,9 +1541,6 @@ file1: CONFIG_USBHOST_ISOC_DISABLE=y
CONFIG_SCHED_WORKQUEUE=y : High priority worker thread support is required
CONFIG_SCHED_HPWORK=y :
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
USB Hub Support
----------------
@ -1665,7 +1650,6 @@ file1: CONFIG_USBHOST_ISOC_DISABLE=y
Application Configuration -> NSH LIbrary:
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
Application Configuration -> System NSH Add-Ons:
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
@ -1821,9 +1805,6 @@ NAND Support
Defaults for ROM page table addresses should be okay
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : Use architecture-specific initialization
NOTES:
1. WARNING: This will wipe out everything that you may have on the NAND
@ -2868,7 +2849,6 @@ Shields
For testing, you can add the following configuration options to enable the
analog joystick example at apps/examples/ajoystick:
CONFIG_NSH_ARCHINIT=y
CONFIG_EXAMPLES_AJOYSTICK=y
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"

View file

@ -1176,9 +1176,6 @@ AT25 Serial FLASH
a lot, but at 20MHz, the behavior is not the same with all CM modules. This
lower rate gives more predictable performance.
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
Board Selection
CONFIG_SAMA5D3XEK_AT25_BLOCKMOUNT=y : Mounts AT25 for NSH
CONFIG_SAMA5D3XEK_AT25_FTL=y : Create block driver for FAT
@ -1276,9 +1273,6 @@ HSMCI Card Slots
Library Routines
CONFIG_SCHED_WORKQUEUE=y : Driver needs work queue support
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
Using the SD card
-----------------
@ -1418,9 +1412,6 @@ USB High-Speed Device
System Type -> ATSAMA5 Peripheral Support
CONFIG_SAMA5_UDPHS=y : Enable UDPHS High Speed USB device
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
Mass Storage Class
------------------
@ -1508,7 +1499,6 @@ USB High-Speed Device
Application Configuration -> NSH LIbrary:
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
Application Configuration -> System NSH Add-Ons:
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
@ -1552,9 +1542,6 @@ USB High-Speed Host
CONFIG_SCHED_WORKQUEUE=y : High priority worker thread support is required
CONFIG_SCHED_HPWORK=y :
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
EHCI
----
@ -1584,9 +1571,6 @@ USB High-Speed Host
CONFIG_SCHED_WORKQUEUE=y : High priority worker thread support is required
CONFIG_SCHED_HPWORK=y :
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
USB Hub Support
----------------
@ -1692,7 +1676,6 @@ USB High-Speed Host
Application Configuration -> NSH LIbrary:
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
Application Configuration -> System NSH Add-Ons:
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
@ -1883,9 +1866,6 @@ NAND Support
Defaults for ROM page table addresses should be okay
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : Use architecture-specific initialization
NOTES:
1. WARNING: This will wipe out everything that you may have on the NAND
@ -2224,9 +2204,6 @@ AT24 Serial EEPROM
CONFIG_AT24XX_SIZE=512 : Specifies the AT 24C512 part
CONFIG_AT24XX_ADDR=0x53 : AT24 I2C address
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
File systems
CONFIG_NXFFS=y : Enables the NXFFS file system
CONFIG_NXFFS_PREALLOCATED=y : Required

View file

@ -1533,9 +1533,6 @@ AT25 Serial FLASH
a lot, but at 20MHz, the behavior is not the same with all CM modules. This
lower rate gives more predictable performance.
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
Board Selection
CONFIG_SAMA5D4EK_AT25_BLOCKMOUNT=y : Mounts AT25 for NSH
CONFIG_SAMA5D4EK_AT25_FTL=y : Create block driver for FAT
@ -1643,7 +1640,6 @@ HSMCI Card Slots
CONFIG_SCHED_WORKQUEUE=y : Driver needs work queue support
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization, OR
CONFIG_BOARD_LATE_INITIALIZE=y
Using the SD card
@ -1788,9 +1784,6 @@ USB High-Speed Device
System Type -> ATSAMA5 Peripheral Support
CONFIG_SAMA5_UDPHS=y : Enable UDPHS High Speed USB device
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
Mass Storage Class
------------------
@ -1878,7 +1871,6 @@ USB High-Speed Device
Application Configuration -> NSH LIbrary:
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
Application Configuration -> System NSH Add-Ons:
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
@ -1922,9 +1914,6 @@ USB High-Speed Host
CONFIG_SCHED_WORKQUEUE=y : High priority worker thread support is required
CONFIG_SCHED_HPWORK=y :
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
EHCI
----
@ -1957,9 +1946,6 @@ USB High-Speed Host
CONFIG_SCHED_WORKQUEUE=y : High priority worker thread support is required
CONFIG_SCHED_HPWORK=y :
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
USB Hub Support
----------------
@ -2070,7 +2056,6 @@ USB High-Speed Host
Application Configuration -> NSH LIbrary:
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
Application Configuration -> System NSH Add-Ons:
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
@ -2226,9 +2211,6 @@ NAND Support
Defaults for ROM page table addresses should be okay
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : Use architecture-specific initialization
NOTES:
1. WARNING: This will wipe out everything that you may have on the NAND

View file

@ -763,9 +763,6 @@ Configuration sub-directories
CONFIG_SAMD20_XPLAINED_IOMODULE=y : I/O1 module is connected
CONFIG_SAMD20_XPLAINED_IOMODULE_EXT1=y : I/O1 modules is in EXT1
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : Board has architecture-specific initialization
NOTE: If you enable the I/O1 this configuration with SERCOM4 as the
console and with the I/O1 module in EXT1, you *must* remove USART
jumper. Otherwise, you have lookpack on SERCOM4 and NSH will *not*

View file

@ -636,9 +636,6 @@ Configuration sub-directories
CONFIG_SAMD21_XPLAINED_IOMODULE=y : I/O1 module is connected
CONFIG_SAMD21_XPLAINED_IOMODULE_EXT1=y : I/O1 modules is in EXT1
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : Board has architecture-specific initialization
NOTE: If you enable the I/O1 this configuration with SERCOM4 as the
console and with the I/O1 module in EXT1, you *must* remove USART
jumper. Otherwise, you have lookpack on SERCOM4 and NSH will *not*

View file

@ -797,9 +797,6 @@ Configuration sub-directories
CONFIG_SAML21_XPLAINED_IOMODULE=y : I/O1 module is connected
CONFIG_SAML21_XPLAINED_IOMODULE_EXT2=y : I/O1 modules is in EXT2
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : Board has architecture-specific initialization
NOTE: If you enable the I/O1 this configuration with SERCOM4 as the
console and with the I/O1 module in EXT1, you *must* remove USART
jumper. Otherwise, you have lookback on SERCOM4 and NSH will *not*

View file

@ -111,7 +111,6 @@ the SD slots can be enabled with the following settings:
CONFIG_SCHED_WORKQUEUE=y : Driver needs work queue support
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization, OR
CONFIG_BOARD_LATE_INITIALIZE=y
Using the SD card

View file

@ -174,7 +174,6 @@ the SD slots can be enabled with the following settings:
CONFIG_SCHED_WORKQUEUE=y : Driver needs work queue support
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization, OR
CONFIG_BOARD_LATE_INITIALIZE=y
Using the SD card

View file

@ -263,7 +263,6 @@ enabled with the following settings:
``Application Configuration -> NSH Library``::
CONFIG_NSH_ARCHINIT=y : NSH board-initialization, OR
CONFIG_BOARD_LATE_INITIALIZE=y
Using the SD card
@ -2007,7 +2006,7 @@ mxtxplnd
--------
Configures the NuttShell (``nsh``) located at ``examples/nsh``.
There are five very similar NSH configurations:
- ``knsh``. This is a somewhat simplified version of the nsh configuration

View file

@ -173,7 +173,6 @@ the SD slots can be enabled with the following settings:
- ``CONFIG_SCHED_WORKQUEUE=y`` : Driver needs work queue support
- Application Configuration -> NSH Library
- ``CONFIG_NSH_ARCHINIT=y`` : NSH board-initialization, OR
- ``CONFIG_BOARD_LATE_INITIALIZE=y``
The lower-half of this driver is initialized by calling :c:func:`sdio_initialize`.

View file

@ -417,8 +417,6 @@ Differences between the two NSH configurations::
nsh> mount -t vfat /dev/mmcsd0 /mnt/sdcard # Restore the mount
Failure to do this could result in corruption of the SD card format.
(5) Option CONFIG_NSH_ARCHINIT must be enabled in order to call the SDIO slot
initialization code.
usbmsc
------
@ -454,7 +452,6 @@ NOTES:
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority

View file

@ -129,7 +129,7 @@ events as follows:
LED_SIGNAL In a signal handler[3] N/C ON N/C OFF
LED_ASSERTION An assertion failed ON ON N/C OFF
LED_PANIC The system has crashed N/C N/C N/C ON
LED_IDLE STM32 is is sleep mode
LED_IDLE STM32 is is sleep mode
=================== ======================= ======= ======= ======= ======
[1] If LED1, LED2, LED3 are statically on, then NuttX probably failed to boot
@ -186,9 +186,6 @@ configuration options::
CONFIG_LIBM=y
CONFIG_LIBC_FLOATINGPOINT=y
Applications -> NSH Library
CONFIG_NSH_ARCHINIT=y
Applications -> System Add-Ons
CONFIG_SYSTEM_LM75=y
CONFIG_SYSTEM_LM75_DEVNAME="/dev/temp"

View file

@ -323,7 +323,6 @@ NOTES:
CONFIG_USBDEV=y : USB device support must be enabled
CONFIG_CDCACM=y : The CDC/ACM driver must be built
CONFIG_NSH_BUILTIN_APPS=y : NSH built-in application support must be enabled
CONFIG_NSH_ARCHINIT=y : To perform USB initialization
8. Using the USB console.
@ -426,7 +425,6 @@ NOTES:
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority

View file

@ -85,7 +85,7 @@ Problems with both boards:
- No user button
This is the board pinout based on its form-factor for the Blue board:
..
USB
___
@ -536,7 +536,7 @@ The STM32F103C8 has a USB Device controller, then we can use NuttX support
to USB Device. We can the console over USB enabling these options:
::
System Type --->
STM32 Peripheral Support --->
[*] USB Device
@ -891,7 +891,6 @@ NOTES:
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority

View file

@ -283,9 +283,6 @@ Configuration (STM32F103 only)
Library Routines
CONFIG_SCHED_WORKQUEUE=y : Driver needs work queue support
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
Using the SD card
-----------------
@ -418,7 +415,6 @@ enabled support for the barometer::
Drivers -> Sensors
CONFIG_SENSORS=y
CONFIG_SENSORS_MPL115A=y
CONFIG_NSH_ARCHINIT=y
Note: this driver uses SPI3 then since PB3 pin is also use to JTAG TDO you
need to disable JTAG support to get this driver working::
@ -769,7 +765,6 @@ todo::
support the MAX3421E:
CONFIG_EXPERIMENTAL=y # EXPERIMENTAL required for now (might change)
CONFIG_NSH_ARCHINIT=y # Board level initialization required
CONFIG_STM32_SPI1=y # SPI for the MAX3421E (could use SPI2)
CONFIG_USBHOST=y # General USB host support
CONFIG_USBHOST_ISOC_DISABLE=y # Does not support Isochronous endpoints

View file

@ -43,7 +43,7 @@ events as follows:
LED_SIGNAL In a signal handler[3] N/C ON N/C OFF
LED_ASSERTION An assertion failed ON ON N/C OFF
LED_PANIC The system has crashed N/C N/C N/C ON
LED_IDLE STM32 is is sleep mode
LED_IDLE STM32 is is sleep mode
=================== ======================= ======= ======= ======= ======
[1] If LED1, LED2, LED3 are statically on, then NuttX probably failed to boot
@ -278,7 +278,7 @@ NOTES:
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. This example assumes that a network is connected. During its
initialization, it will try to negotiate the link speed. If you have
no network connected when you reset the board, there will be a long
@ -399,8 +399,6 @@ Enable the application configurations that you want to use. As examples::
CONFIG_SCHED_WORKQUEUE : Worker thread support is required for the mass
storage class (both host and device).
CONFIG_NSH_ARCHINIT : Architecture specific USB initialization
is needed
11. This configuration requires that jumper JP22 be set to enable RS-232 operation.

View file

@ -194,7 +194,6 @@ NOTES:
CONFIG_USBDEV=y : USB device support must be enabled
CONFIG_CDCACM=y : The CDC/ACM driver must be built
CONFIG_NSH_BUILTIN_APPS=y : NSH built-in application support must be enabled
CONFIG_NSH_ARCHINIT=y : To perform USB initialization
The CDC/ACM example is included as two NSH "built-in" commands.::
@ -299,7 +298,6 @@ NOTES:
Application Configuration -> NSH LIbrary::
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
Application Configuration -> System NSH Add-Ons::
CONFIG_USBMONITOR=y : Enable the USB monitor daemon

View file

@ -55,8 +55,8 @@ controls the LEDs:
LED_IRQSENABLED Interrupts enabled OFF OFF
LED_STACKCREATED Idle stack created ON OFF
LED_INIRQ In an interrupt N/C ON
LED_SIGNAL In a signal handler N/C N/C
LED_ASSERTION An assertion failed N/C N/C
LED_SIGNAL In a signal handler N/C N/C
LED_ASSERTION An assertion failed N/C N/C
LED_PANIC The system has crashed OFF Blinking
LED_IDLE STM32 is is sleep mode N/U N/U
=================== ======================= ======== ========
@ -362,8 +362,6 @@ summarized below:
7. Initialization hooks are provided to enable the MRF24J40 and to
register the radio character driver.
CONFIG_NSH_ARCHINIT=y
8. Configuration instructions: WPAN configuration must be performed
using the i8sak program. Detailed instructions are provided in a
README.txt file at apps/wireless/ieee802154/i8sak. You should make
@ -776,7 +774,6 @@ NOTES:
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority

View file

@ -348,7 +348,6 @@ NOTES:
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority

View file

@ -320,7 +320,6 @@ There is nothing in the configuration that currently uses the joystick.
For testing, you can add the following configuration options to enable the
analog joystick example at apps/examples/ajoystick::
CONFIG_NSH_ARCHINIT=y
CONFIG_EXAMPLES_AJOYSTICK=y
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"
@ -360,7 +359,7 @@ NOTES:
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. By default, this configuration uses the ARM EABI toolchain
for Linux. That can easily be reconfigured, of course.:

View file

@ -320,7 +320,6 @@ There is nothing in the configuration that currently uses the joystick.
For testing, you can add the following configuration options to enable the
analog joystick example at apps/examples/ajoystick::
CONFIG_NSH_ARCHINIT=y
CONFIG_EXAMPLES_AJOYSTICK=y
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"
@ -360,7 +359,7 @@ NOTES:
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. By default, this configuration uses the ARM EABI toolchain
for Linux. That can easily be reconfigured, of course.:

View file

@ -319,7 +319,6 @@ There is nothing in the configuration that currently uses the joystick.
For testing, you can add the following configuration options to enable the
analog joystick example at apps/examples/ajoystick::
CONFIG_NSH_ARCHINIT=y
CONFIG_EXAMPLES_AJOYSTICK=y
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"

View file

@ -107,10 +107,6 @@ Library Routines::
CONFIG_SCHED_WORKQUEUE=y : Driver needs work queue support
Application Configuration -> NSH Library::
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
Using the SD card
-----------------
@ -437,7 +433,7 @@ NOTES:
reliable.
2. Kernel Modules / Shared Libraries
I used this configuration for testing NuttX kernel modules in the
FLAT build with the following configuration additions to the
configuration file::

View file

@ -601,8 +601,6 @@ NOTES:
CONFIG_STM32_SYSCFG=y : Needed for all USB OTF FS support
CONFIG_SCHED_WORKQUEUE=y : Worker thread support is required for the mass
storage class driver.
CONFIG_NSH_ARCHINIT=y : Architecture specific USB initialization
is needed for NSH
CONFIG_FS_FAT=y : Needed by the USB host mass storage class.
With those changes, you can use NSH with a FLASH pen driver as shown

View file

@ -459,7 +459,6 @@ NOTES:
CONFIG_USBDEV=y : USB device support must be enabled
CONFIG_CDCACM=y : The CDC/ACM driver must be built
CONFIG_NSH_BUILTIN_APPS=y : NSH built-in application support must be enabled
CONFIG_NSH_ARCHINIT=y : To perform USB initialization
8. Using the USB console.
@ -482,7 +481,7 @@ NOTES:
configuration will also create a NSH USB console but this version
will use /dev/console. Instead, it will use the normal /dev/ttyACM0
USB serial device for the console::
CONFIG_STM32_OTGFS=y : STM32 OTG FS support
CONFIG_USART2_SERIAL_CONSOLE=y : Keep the USART2 console
CONFIG_DEV_CONSOLE=y : /dev/console exists (but NSH won't use it)
@ -541,11 +540,7 @@ NOTES:
CONFIG_FS_FAT=y : Needed by the USB host mass storage class.
Board Selection ->
CONFIG_BOARDCTL=y : Needed for CONFIG_NSH_ARCHINIT
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : Architecture specific USB initialization
: is needed for NSH
CONFIG_BOARDCTL=y
With those changes, you can use NSH with a FLASH pen driver as shown
belong. Here NSH is started with nothing in the USB host slot:
@ -617,7 +612,7 @@ NOTES:
2. Stack usage make increase when USB hub support is enabled because
the nesting depth of certain USB host class logic can increase.
STATUS:
2015-04-30
Appears to be fully functional.
@ -638,7 +633,7 @@ UnitTest.
NOTES:
1. The NxWM window manager can be found here::
apps/graphics/NxWidgets/nxwm
The NxWM unit test can be found at::

View file

@ -1646,7 +1646,6 @@ NOTES:
CONFIG_USBDEV=y : USB device support must be enabled
CONFIG_CDCACM=y : The CDC/ACM driver must be built
CONFIG_NSH_BUILTIN_APPS=y : NSH built-in application support must be enabled
CONFIG_NSH_ARCHINIT=y : To perform USB initialization
7. Using the USB console.
@ -1728,11 +1727,7 @@ NOTES:
CONFIG_FS_FAT=y : Needed by the USB host mass storage class.
Board Selection ->
CONFIG_BOARDCTL=y : Needed for CONFIG_NSH_ARCHINIT
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : Architecture specific USB initialization
: is needed for NSH
CONFIG_BOARDCTL=y
With those changes, you can use NSH with a FLASH pen driver as shown
belong. Here NSH is started with nothing in the USB host slot::
@ -2273,7 +2268,6 @@ NOTES:
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority

View file

@ -252,7 +252,7 @@ Since this board is so generic, having a quick way to set the SPI
configuration seams in order. So the board provides a quick test
that can be selected vi CONFIG_NUCLEO_SPI_TEST that will initialize
the selected buses (SPI1-SPI3) and send some text on the bus at
application initialization time board_app_initialize.
application initialization time.
SDIO
----

View file

@ -294,7 +294,7 @@ Since this board is so generic, having a quick way to set the SPI
configuration seams in order. So the board provides a quick test
that can be selected vi CONFIG_NUCLEO_SPI_TEST that will initialize
the selected buses (SPI1-SPI3) and send some text on the bus at
application initialization time board_app_initialize.
application initialization time.
SDIO
----

View file

@ -296,7 +296,7 @@ Since this board is so generic, having a quick way to set the SPI
configuration seams in order. So the board provides a quick test
that can be selected vi CONFIG_NUCLEO_SPI_TEST that will initialize
the selected buses (SPI1-SPI3) and send some text on the bus at
application initialization time board_app_initialize.
application initialization time.
SDIO
----

View file

@ -17,7 +17,7 @@ Peripheral Support Notes
========== ======= =====
FLASH Yes
PM ?
RCC Yes
RCC Yes
GPIO Yes
SYSCFG Yes
DMA Yes
@ -192,7 +192,7 @@ CAN
- CONFIG_CAN_TXFIFOSIZE - The size of the circular tx buffer
of CAN messages.
Default: 8
- CONFIG_CAN_RXFIFOSIZE - The size of the circular rx buffer
of CAN messages.
Default: 8
@ -382,7 +382,6 @@ The builtin SPI test facility can be enabled with the following settings::
+CONFIG_NUCLEO_SPI3_TEST_MODE3=y
+CONFIG_BOARDCTL=y
+CONFIG_NSH_ARCHINIT=y
Development Environment
=======================

View file

@ -293,7 +293,7 @@ NOTES:
CONFIG_WINDOWS_CYGWIN=y : Using Cygwin
System Type::
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
4. SLCD.
@ -318,7 +318,6 @@ NOTES:
Application Configuration -> NSH Library::
CONFIG_NSH_BUILTIN_APPS=y : Enable builtin apps in NSH
CONFIG_NSH_ARCHINIT=y : Needed to initialize the SLCD
Application Configuration -> Examples::

View file

@ -470,7 +470,6 @@ There is nothing in the configuration that currently uses the joystick.
For testing, you can add the following configuration options to enable the
analog joystick example at apps/examples/ajoystick::
CONFIG_NSH_ARCHINIT=y
CONFIG_EXAMPLES_AJOYSTICK=y
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"

View file

@ -50,7 +50,7 @@ information about this board.
Hardware
========
Section needs updating
Section needs updating
GPIO - there are 144 I/O lines on the STM32L4xxZx with various pins pined out
on the Nucleo 144.
@ -193,7 +193,7 @@ Since this board is so generic, having a quick way to vet the SPI
configuration seams in order. So the board provides a quick test
that can be selected vi CONFIG_NUCLEO_SPI_TEST that will initialize
the selected buses (SPI1-SPI3) and send some text on the bus at
application initialization time board_app_initialize.
application initialization time.
SDIO
----

View file

@ -144,7 +144,7 @@ TTL to RS-232 converter connection:
Nucleo CN10 STM32F4x1RE
=========== ============
Pin 21 PA9 USART1_RX
Pin 33 PA10 USART1_TX
Pin 33 PA10 USART1_TX
Pin 20 GND
Pin 8 U5V
=========== ============
@ -181,7 +181,7 @@ TTL to RS-232 converter connection:
Nucleo CN9 STM32F4x1RE
=========== ============
Pin 1 PA3 USART2_RX
Pin 2 PA2 USART2_TX
Pin 2 PA2 USART2_TX
=========== ============
Warning you make need to reverse RX/TX on some RS-232 converters
@ -336,7 +336,6 @@ There is nothing in the configuration that currently uses the joystick.
For testing, you can add the following configuration options to enable the
analog joystick example at apps/examples/ajoystick::
CONFIG_NSH_ARCHINIT=y
CONFIG_EXAMPLES_AJOYSTICK=y
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"

View file

@ -494,9 +494,6 @@ Temperature Sensor
CONFIG_SENSORS_LM75=y
CONFIG_LM75_I2C=y
Applications -> NSH Library
CONFIG_NSH_ARCHINIT=y
Then you can implement logic like the following to use the temperature sensor:
#include <nuttx/sensors/lm75.h>
@ -524,9 +521,6 @@ Temperature Sensor
CONFIG_LIBM=y
CONFIG_LIBC_FLOATINGPOINT=y
Applications -> NSH Library
CONFIG_NSH_ARCHINIT=y
Applications -> System Add-Ons
CONFIG_SYSTEM_LM75=y
CONFIG_SYSTEM_LM75_DEVNAME="/dev/temp"

View file

@ -116,9 +116,6 @@ AT24 Serial EEPROM
CONFIG_AT24XX_SIZE=512 : Specifies the AT 24C512 part
CONFIG_AT24XX_ADDR=0x53 : AT24 I2C address
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
File systems
CONFIG_NXFFS=y : Enables the NXFFS file system
CONFIG_NXFFS_PREALLOCATED=y : Required

View file

@ -913,7 +913,6 @@ Where <subdir> is one of the following:
CONFIG_SST25_SECTOR512=y
CONFIG_DISABLE_MOUNTPOINT=n
CONFIG_FS_NXFFS=y
CONFIG_NSH_ARCHINIT=y
4. Many operating system features are suppressed to produce a smaller
footprint.

View file

@ -617,7 +617,6 @@ Where <subdir> is one of the following:
SD card support is built into this example by default:
CONFIG_PIC32MX_SPI1=y
CONFIG_NSH_ARCHINIT=y
The SD card can be mounted from the NSH command line as follows:

View file

@ -738,9 +738,6 @@ Where <subdir> is one of the following:
To enable apps/examples/slcd to test the LCD:
Application Configuration -> NSH Library:
CONFIG_NSH_ARCHINIT=y : Needed to initialize the SLCD
Application Configuration -> Examples:
CONFIG_EXAMPLES_SLCD=y : Enable apps/examples/slcd use /dev/lcd1602
CONFIG_EXAMPLES_SLCD_DEVNAME="/dev/lcd1602"
@ -855,7 +852,6 @@ Where <subdir> is one of the following:
Application Configuration -> NSH LIbrary:
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
Application Configuration -> System NSH Add-Ons:
CONFIG_USBMONITOR=y : Enable the USB monitor daemon

View file

@ -42,73 +42,55 @@ implementing the :c:func:`board_ioctl` interface.
System state control
--------------------
.. c:macro:: BOARDIOC_INIT
Perform one-time application initialization.
:Argument: The argument is passed to the
:c:func:`board_app_initialize` implementation without modification.
The argument has no meaning to NuttX; the meaning of the
argument is a contract between the board-specific
initialization logic and the matching application logic.
The value could be such things as a mode enumeration value,
a set of DIP switch switch settings, a pointer to
configuration data read from a file or serial FLASH, or
whatever you would like to do with it. Every
implementation should accept zero/NULL as a default
configuration.
:Dependencies: Board logic must provide :c:func:`board_app_initialize`.
.. c:macro:: BOARDIOC_POWEROFF
Power off the board
:Argument: Integer value providing power off status information
:configuration: CONFIG_BOARDCTL_POWEROFF
:dependencies: Board logic must provide the :c:func:`board_power_off` interface.
.. c:macro:: BOARDIOC_RESET
Reset the board
:Argument: Integer value providing power off status information
:configuration: CONFIG_BOARDCTL_RESET
:dependencies: Board logic must provide the :c:func:`board_reset` interface.
Power Management
----------------
.. c:macro:: BOARDIOC_PM_CONTROL
Manage power state transition and query. The supplied argument
indicates the specific PM operation to perform, which map to
corresponding internal ``pm_<operation>`` functions
(see :doc:`/components/drivers/special/power/pm/index`).
With this interface you can interact with PM handling arch/board logic
(typically done in IDLE loop) or you can directly manage state transitions
from userspace.
:Argument: A pointer to an instance of :c:struct:`boardioc_pm_ctrl_s`.
:configuration: CONFIG_PM
Board information
-----------------
.. c:macro:: BOARDIOC_UNIQUEID
Return a unique ID associated with the board (such as a
serial number or a MAC address).
:Argument: A writable array of size :c:macro:`CONFIG_BOARDCTL_UNIQUEID_SIZE` in
which to receive the board unique ID.
:dependencies: Board logic must provide the :c:func:`board_uniqueid` interface.
.. c:macro:: BOARDIOC_MACADDR
@ -120,49 +102,49 @@ Board information
:configuration: CONFIG_BOARDCTL_MACADDR
:dependencies: Board logic must provide the :c:func:`board_macaddr` interface.
Filesystems
-----------
.. c:macro:: BOARDIOC_MKRD
Create a RAM disk
:Argument: Pointer to read-only instance of :c:struct:`boardioc_mkrd_s`.
:configuration: CONFIG_BOARDCTL_MKRD
.. c:macro:: BOARDIOC_ROMDISK
Register a ROM disk
:Argument: Pointer to read-only instance of :c:struct:`boardioc_romdisk_s`.
:configuration: CONFIG_BOARDCTL_ROMDISK
Symbol Handling
---------------
.. c:macro:: BOARDIOC_APP_SYMTAB
Select the application symbol table. This symbol table
provides the symbol definitions exported to application
code from application space.
:Argument: A pointer to an instance of :c:struct:`boardioc_symtab_s`.
:configuration: CONFIG_BOARDCTL_APP_SYMTAB
.. c:macro:: BOARDIOC_OS_SYMTAB
Select the OS symbol table. This symbol table provides
the symbol definitions exported by the OS to kernel
modules.
:Argument: A pointer to an instance of :c:struct:`boardioc_symtab_s`.
:configuration: CONFIG_BOARDCTL_OS_SYMTAB
.. c:macro:: BOARDIOC_BUILTINS
Provide the user-space list of built-in applications for
@ -176,86 +158,86 @@ Symbol Handling
available. (BINFS is not supportable in KERNEL mode since
user-space address have no general meaning that
configuration).
:Argument: A pointer to an instance of :c:struct:`boardioc_builtin_s`.
:configuration: This command is always available when
CONFIG_BUILTIN is enabled, but does nothing unless
CONFIG_BUILD_PROTECTED is also selected.
USB
---
.. c:macro:: BOARDIOC_USBDEV_CONTROL
Manage USB device classes
:Argument: A pointer to an instance of :c:struct:`boardioc_usbdev_ctrl_s`.
:configuration: CONFIG_BOARDCTL && CONFIG_BOARDCTL_USBDEVCTRL
:dependencies: Board logic must provide `board_<usbdev>_initialize()`.
Graphics
--------
.. c:macro:: BOARDIOC_NX_START
Start the NX server
:Argument: Integer display number to be served by this NXMU instance.
:configuration: CONFIG_NX
:dependencies: Base graphics logic provides :c:func:`nxmu_start`.
.. c:macro:: BOARDIOC_VNC_START
Start the NX server and framebuffer driver.
:Argument: A reference readable instance of :c:struct:`boardioc_vncstart_s`.
:configuration: CONFIG_VNCSERVER
:dependencies: VNC server provides :c:func:`nx_vnc_fbinitialize`.
.. c:macro:: BOARDIOC_NXTERM
Create an NX terminal device
:Argument: A reference readable/writable instance of
:c:struct:`boardioc_nxterm_create_s`.
:configuration: CONFIG_NXTERM
:dependencies: Base NX terminal logic provides :c:func:`nx_register` and
:c:func:`nxtk_register`.
.. c:macro:: BOARDIOC_NXTERM_IOCTL
Create an NX terminal IOCTL command. Normal IOCTLs
cannot be be performed in most graphics contexts since
the depend on the task holding an open file descriptor
:Argument: A reference readable/writable instance of
:c:struct:`boardioc_nxterm_ioctl_s`.
:configuration: CONFIG_NXTERM
:dependencies: Base NX terminal logic provides :c:func:`nxterm_ioctl_tap`.
Testing
-------
.. c:macro:: BOARDIOC_TESTSET
Access architecture-specific up_testset() operation
:Argument: A pointer to a write-able spinlock object. On success
the preceding spinlock state is returned: 0=unlocked,
1=locked.
:configuration: CONFIG_BOARDCTL_TESTSET
:dependencies: Architecture-specific logic provides :c:func:`up_testset`.

View file

@ -3216,7 +3216,6 @@ ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
boards/arm/lpc2378/olimex-lpc2378/include/board.h
boards/arm/lpc2378/olimex-lpc2378/src/lpc2378_appinit.c
boards/arm/lpc2378/olimex-lpc2378/src/lpc2378_leds.c
boards/arm/lpc2378/olimex-lpc2378/scripts/ld.script
=======================================================

View file

@ -503,16 +503,14 @@ int scu_i2ctransfer(int port, int slave, uint16_t *inst, uint32_t nr_insts,
/* Initialize SCU
*
* warning: This API called from board_app_initialize().
* Do not call this API from each sensor drivers.
* WARNING: Do not call this API from each sensor drivers.
*/
void scu_initialize(void);
/* Uninitialize SCU
*
* warning: This API called from board_app_initialize().
* Do not call this API from each sensor drivers.
* WARNING: Do not call this API from each sensor drivers.
*/
void scu_uninitialize(void);

View file

@ -36,12 +36,8 @@
* Pre-processor Definitions
****************************************************************************/
#if !defined(CONFIG_BOARD_LATE_INITIALIZE) && !defined(CONFIG_NSH_ARCHINIT)
# error CONFIG_BOARD_LATE_INITIALIZE or CONFIG_NSH_ARCHINIT is required for late initialization
#endif
#if defined(CONFIG_BOARD_LATE_INITIALIZE) && defined(CONFIG_NSH_ARCHINIT)
# error CONFIG_BOARD_LATE_INITIALIZE and CONFIG_NSH_ARCHINIT can not be defined at the same time
#if !defined(CONFIG_BOARD_LATE_INITIALIZE)
# error CONFIG_BOARD_LATE_INITIALIZE is required for late initialization
#endif
/****************************************************************************
@ -102,7 +98,6 @@ void board_late_initialize(void)
#ifdef CONFIG_LIB_BOARDCTL
int board_app_initialize(uintptr_t arg)
{
# ifdef CONFIG_NSH_ARCHINIT
/* Perform the arch late initialization */
ceva_lateinitialize();
@ -110,7 +105,6 @@ int board_app_initialize(uintptr_t arg)
/* Perform the board late initialization */
board_lateinitialize();
# endif
return 0;
}

View file

@ -5270,8 +5270,7 @@ config BOARDCTL
bool "Enable boardctl() interface"
default n
---help---
Enables support for the boardctl() interface. Architecture
specific logic must provide board_app_initialize() interface.
Enables support for the boardctl() interface.
if BOARDCTL

View file

@ -22,7 +22,6 @@ CONFIG_AT32_ADC1=y
CONFIG_AT32_JTAG_SW_ENABLE=y
CONFIG_AT32_PWR=y
CONFIG_AT32_USART1=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=26145
CONFIG_BUILTIN=y
CONFIG_EXAMPLES_ADC=y

View file

@ -20,7 +20,6 @@ CONFIG_AT32_CAN1=y
CONFIG_AT32_JTAG_SW_ENABLE=y
CONFIG_AT32_PWR=y
CONFIG_AT32_USART1=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=26145
CONFIG_BUILTIN=y
CONFIG_EXAMPLES_CAN=y

View file

@ -23,7 +23,6 @@ CONFIG_AT32_CAN_SOCKET=y
CONFIG_AT32_JTAG_SW_ENABLE=y
CONFIG_AT32_PWR=y
CONFIG_AT32_USART1=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=26145
CONFIG_BUILTIN=y
CONFIG_CAN=y

View file

@ -29,7 +29,6 @@ CONFIG_AT32_PHYSR_ALTMODE=0x001c
CONFIG_AT32_PWR=y
CONFIG_AT32_RMII_EXTCLK=y
CONFIG_AT32_USART1=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=26145
CONFIG_BUILTIN=y
CONFIG_ETH0_PHY_LAN8720=y

View file

@ -22,7 +22,6 @@ CONFIG_AT32_OTGFS=y
CONFIG_AT32_PWR=y
CONFIG_AT32_USART1=y
CONFIG_AT32_USBHOST=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=26145
CONFIG_BUILTIN=y
CONFIG_EXAMPLES_HELLO=y

View file

@ -19,7 +19,6 @@ CONFIG_ARCH_STACKDUMP=y
CONFIG_AT32_JTAG_SW_ENABLE=y
CONFIG_AT32_PWR=y
CONFIG_AT32_USART1=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=26145
CONFIG_BUILTIN=y
CONFIG_EXAMPLES_HELLO=y

View file

@ -22,7 +22,6 @@ CONFIG_AT32_TIM20=y
CONFIG_AT32_TIM20_CH1OUT=y
CONFIG_AT32_TIM20_PWM=y
CONFIG_AT32_USART1=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=26145
CONFIG_BUILTIN=y
CONFIG_EXAMPLES_HELLO=y

View file

@ -21,7 +21,6 @@ CONFIG_AT32_PWR=y
CONFIG_AT32_RTC=y
CONFIG_AT32_RTC_LSICLOCK=y
CONFIG_AT32_USART1=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=26145
CONFIG_BUILTIN=y
CONFIG_EXAMPLES_HELLO=y

View file

@ -24,7 +24,6 @@ CONFIG_AT32_JTAG_SW_ENABLE=y
CONFIG_AT32_PWR=y
CONFIG_AT32_SDIO=y
CONFIG_AT32_USART1=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=26145
CONFIG_BUILTIN=y
CONFIG_EXAMPLES_HELLO=y

View file

@ -19,7 +19,6 @@ CONFIG_ARCH_STACKDUMP=y
CONFIG_AT32_JTAG_SW_ENABLE=y
CONFIG_AT32_PWR=y
CONFIG_AT32_USART1=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=26145
CONFIG_BUILTIN=y
CONFIG_DRIVERS_NOTE=y

View file

@ -21,7 +21,6 @@ CONFIG_AT32_OTGFS=y
CONFIG_AT32_PWR=y
CONFIG_AT32_USART1=y
CONFIG_BOARDCTL_USBDEVCTRL=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=26145
CONFIG_BUILTIN=y
CONFIG_CDCACM=y

View file

@ -20,7 +20,6 @@ CONFIG_AT32_JTAG_SW_ENABLE=y
CONFIG_AT32_OTGFS=y
CONFIG_AT32_PWR=y
CONFIG_AT32_USART1=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=26145
CONFIG_BUILTIN=y
CONFIG_CDCACM=y

View file

@ -22,7 +22,6 @@ CONFIG_ARCH_CHIP="csk6"
CONFIG_ARCH_CHIP_CSK6=y
CONFIG_ARCH_STACKDUMP=y
CONFIG_ARMV8M_SYSTICK=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=16717
CONFIG_BUILTIN=y
CONFIG_DEBUG_FEATURES=y

View file

@ -50,7 +50,6 @@ CONFIG_MTD_SMART=y
CONFIG_MTD_SMART_ENABLE_CRC=y
CONFIG_MTD_SMART_SECTOR_SIZE=4096
CONFIG_NAME_MAX=128
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -47,7 +47,6 @@ CONFIG_MTD_SMART=y
CONFIG_MTD_SMART_ENABLE_CRC=y
CONFIG_MTD_SMART_SECTOR_SIZE=4096
CONFIG_NAME_MAX=128
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -50,7 +50,6 @@ CONFIG_MTD_SMART=y
CONFIG_MTD_SMART_ENABLE_CRC=y
CONFIG_MTD_SMART_SECTOR_SIZE=4096
CONFIG_NAME_MAX=128
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -33,7 +33,6 @@ CONFIG_FS_PROCFS_REGISTER=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
CONFIG_INIT_ENTRYPOINT="spresense_main"
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -59,7 +59,6 @@ CONFIG_MTD_SMART=y
CONFIG_MTD_SMART_ENABLE_CRC=y
CONFIG_MTD_SMART_SECTOR_SIZE=4096
CONFIG_NAME_MAX=128
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_NX=y

View file

@ -66,7 +66,6 @@ CONFIG_MTD_SMART=y
CONFIG_MTD_SMART_ENABLE_CRC=y
CONFIG_MTD_SMART_SECTOR_SIZE=4096
CONFIG_NAME_MAX=128
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_NX=y

View file

@ -54,7 +54,6 @@ CONFIG_MTD_SMART=y
CONFIG_MTD_SMART_ENABLE_CRC=y
CONFIG_MTD_SMART_SECTOR_SIZE=4096
CONFIG_NAME_MAX=128
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -57,7 +57,6 @@ CONFIG_MTD_SMART=y
CONFIG_MTD_SMART_ENABLE_CRC=y
CONFIG_MTD_SMART_SECTOR_SIZE=4096
CONFIG_NAME_MAX=128
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -63,7 +63,6 @@ CONFIG_NETUTILS_WEBCLIENT=y
CONFIG_NET_IPv6=y
CONFIG_NET_USRSOCK=y
CONFIG_NET_USRSOCK_UDP=y
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -60,7 +60,6 @@ CONFIG_MTD_SMART=y
CONFIG_MTD_SMART_ENABLE_CRC=y
CONFIG_MTD_SMART_SECTOR_SIZE=4096
CONFIG_NAME_MAX=128
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -30,7 +30,6 @@ CONFIG_FS_PROCFS_REGISTER=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
CONFIG_INIT_ENTRYPOINT="spresense_main"
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -36,7 +36,6 @@ CONFIG_FS_PROCFS_REGISTER=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
CONFIG_INIT_ENTRYPOINT="spresense_main"
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -32,7 +32,6 @@ CONFIG_FS_PROCFS_REGISTER=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
CONFIG_INIT_ENTRYPOINT="spresense_main"
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -99,7 +99,6 @@ CONFIG_NET_TCP=y
CONFIG_NET_TCP_WRITE_BUFFERS=y
CONFIG_NET_UDP=y
CONFIG_NFS=y
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_FILE_APPS=y
CONFIG_NSH_READLINE=y

View file

@ -101,7 +101,6 @@ CONFIG_NET_TCP=y
CONFIG_NET_TCP_WRITE_BUFFERS=y
CONFIG_NET_UDP=y
CONFIG_NFS=y
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_FILE_APPS=y
CONFIG_NSH_READLINE=y

View file

@ -23,7 +23,6 @@ CONFIG_AUDIO=y
CONFIG_AUDIO_CXD56=y
CONFIG_BOARDCTL_RESET=y
CONFIG_BOARDCTL_USBDEVCTRL=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=5434
CONFIG_BOOT_RUNFROMISRAM=y
CONFIG_BUILTIN=y
@ -98,7 +97,6 @@ CONFIG_NET_STATISTICS=y
CONFIG_NET_TCP=y
CONFIG_NET_UDP=y
CONFIG_NFS=y
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_FILE_APPS=y
CONFIG_NSH_READLINE=y

View file

@ -17,7 +17,6 @@ CONFIG_ARCH_INTERRUPTSTACK=2048
CONFIG_ARCH_LEDS_CPU_ACTIVITY=y
CONFIG_ARCH_STACKDUMP=y
CONFIG_BOARDCTL_RESET=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=5434
CONFIG_BOOT_RUNFROMISRAM=y
CONFIG_BUILTIN=y
@ -35,7 +34,6 @@ CONFIG_FS_PROCFS_REGISTER=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
CONFIG_INIT_ENTRYPOINT="spresense_main"
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -52,7 +52,6 @@ CONFIG_MTD_SMART=y
CONFIG_MTD_SMART_ENABLE_CRC=y
CONFIG_MTD_SMART_SECTOR_SIZE=4096
CONFIG_NAME_MAX=128
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -47,7 +47,6 @@ CONFIG_MTD_SMART=y
CONFIG_MTD_SMART_ENABLE_CRC=y
CONFIG_MTD_SMART_SECTOR_SIZE=4096
CONFIG_NAME_MAX=128
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_TIMERS=4

View file

@ -104,7 +104,6 @@ CONFIG_NET_USRSOCK=y
CONFIG_NET_USRSOCK_PREALLOC_CONNS=16
CONFIG_NET_USRSOCK_UDP=y
CONFIG_NFS=y
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_DISABLE_IFUPDOWN=y
CONFIG_NSH_DISABLE_NSLOOKUP=y

View file

@ -24,7 +24,6 @@ CONFIG_ARCH_STACKDUMP=y
CONFIG_AUDIO=y
CONFIG_AUDIO_CXD56=y
CONFIG_BOARDCTL_RESET=y
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=5434
CONFIG_BOOT_RUNFROMISRAM=y
CONFIG_BUILTIN=y
@ -107,7 +106,6 @@ CONFIG_NET_USRSOCK=y
CONFIG_NET_USRSOCK_PREALLOC_CONNS=16
CONFIG_NET_USRSOCK_UDP=y
CONFIG_NFS=y
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_DISABLE_IFUPDOWN=y
CONFIG_NSH_DISABLE_NSLOOKUP=y

View file

@ -30,7 +30,6 @@ CONFIG_FS_ROMFS=y
CONFIG_IDLETHREAD_STACKSIZE=8192
CONFIG_INIT_ENTRYPOINT="nsh_main"
CONFIG_INTELHEX_BINARY=y
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_FILEIOSIZE=512
CONFIG_NSH_READLINE=y

View file

@ -38,7 +38,6 @@ CONFIG_INIT_ENTRYPOINT="nsh_main"
CONFIG_INTELHEX_BINARY=y
CONFIG_LINE_MAX=64
CONFIG_MM_REGIONS=2
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_FILEIOSIZE=512
CONFIG_NSH_READLINE=y

View file

@ -124,7 +124,7 @@ endchoice # GD25 serial FLASH configuration
config GD32F450ZK_EVAL_AT24_TEST
bool "I2C0 EEPROM AT2402 write and read test"
default n
depends on NSH_ARCHINIT && GD32F4_I2C0 && MTD_AT24XX
depends on BOARD_LATE_INITIALIZE && GD32F4_I2C0 && MTD_AT24XX
---help---
Automatically initialize and test the AT24 I2C EEPROM driver when
NSH starts. After test the I2C0 will be released.

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