mirror of
https://github.com/apache/nuttx.git
synced 2026-08-01 20:28:58 +00:00
!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:
parent
8e91dd60a0
commit
48db502daf
1631 changed files with 579 additions and 2753 deletions
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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``.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 --->
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
=========================================== ===================================================
|
||||
|
||||
=============================================== ============================================
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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*
|
||||
|
|
|
|||
|
|
@ -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*
|
||||
|
|
|
|||
|
|
@ -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*
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.:
|
||||
|
||||
|
|
|
|||
|
|
@ -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.:
|
||||
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
||||
|
|
|
|||
|
|
@ -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::
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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::
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
----
|
||||
|
|
|
|||
|
|
@ -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
|
||||
----
|
||||
|
|
|
|||
|
|
@ -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
|
||||
----
|
||||
|
|
|
|||
|
|
@ -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
|
||||
=======================
|
||||
|
|
|
|||
|
|
@ -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::
|
||||
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
----
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
||||
|
|
|
|||
1
LICENSE
1
LICENSE
|
|
@ -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
|
||||
=======================================================
|
||||
|
|
|
|||
|
|
@ -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);
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
Loading…
Add table
Add a link
Reference in a new issue