mirror of
https://github.com/apache/nuttx.git
synced 2026-06-05 15:58:59 +08:00
Merge remote-tracking branch 'mirtos/master' into dev
Last commit id:
commit 649f99ce30 (mirtos/master)
Author: FASTSHIFT <vifextech@foxmail.com>
Date: Wed Sep 22 15:38:43 2021 +0800
libc/misc: add lib_glob.
Signed-off-by: FASTSHIFT <vifextech@foxmail.com>
Signed-off-by: liuhaitao <liuhaitao@xiaomi.com>
Change-Id: I2f584a4432f835c661e3c02cf7324d5e92e9c738
This commit is contained in:
@@ -18,7 +18,7 @@ inputs:
|
||||
required: true
|
||||
runs:
|
||||
using: 'docker'
|
||||
image: 'docker.pkg.github.com/apache/incubator-nuttx/apache-nuttx-ci-linux'
|
||||
image: 'ghcr.io/apache/incubator-nuttx/apache-nuttx-ci-linux'
|
||||
args:
|
||||
- "/bin/bash"
|
||||
- "-ce"
|
||||
|
||||
@@ -127,12 +127,12 @@ jobs:
|
||||
- name: Docker Login
|
||||
uses: azure/docker-login@v1
|
||||
with:
|
||||
login-server: docker.pkg.github.com
|
||||
login-server: ghcr.io
|
||||
username: ${GITHUB_ACTOR}
|
||||
password: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
- name: Docker Pull
|
||||
run: docker pull docker.pkg.github.com/apache/incubator-nuttx/apache-nuttx-ci-linux
|
||||
run: docker pull ghcr.io/apache/incubator-nuttx/apache-nuttx-ci-linux
|
||||
- name: Export NuttX Repo SHA
|
||||
run: echo "nuttx_sha=`git -C sources/nuttx rev-parse HEAD`" >> $GITHUB_ENV
|
||||
- name: Run builds
|
||||
|
||||
@@ -36,12 +36,12 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
env:
|
||||
DOCKER_BUILDKIT: 1
|
||||
IMAGE_TAG: docker.pkg.github.com/${{ github.repository }}/apache-nuttx-ci-linux
|
||||
IMAGE_TAG: ghcr.io/${{ github.repository }}/apache-nuttx-ci-linux
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
|
||||
- name: Log into registry
|
||||
run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login docker.pkg.github.com -u ${{ github.actor }} --password-stdin
|
||||
run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
|
||||
|
||||
- name: Build Linux image
|
||||
run: |
|
||||
|
||||
@@ -6,10 +6,15 @@ ICLA
|
||||
Abdelatif Guettouche
|
||||
Adam Porter
|
||||
Alan Carvalho de Assis
|
||||
Aleksandr Vyhovanec
|
||||
Alin Jerpelea
|
||||
Anton D. Kachalov
|
||||
Anthony Merlino
|
||||
Augusto Fraga Giachero
|
||||
Beat Kung
|
||||
Bill Gatliff
|
||||
Chao An
|
||||
Daniel P. Carvalho
|
||||
David S. Alessio
|
||||
David Sidrane
|
||||
Dong Heng
|
||||
@@ -40,8 +45,10 @@ Masayuki Ishikawa
|
||||
Mateusz Tomasz Szafoni (Mateusz Szafoni)
|
||||
Matias Nitsche
|
||||
Matous Pokorny
|
||||
Matt Poppe
|
||||
Matthew Trescott
|
||||
Mattias Edlund
|
||||
Max Holtzberg
|
||||
Michael Jung
|
||||
Michal Lyszczek
|
||||
Miguel Ángel Herranz Trillo (Miguel Herranz)
|
||||
@@ -83,10 +90,13 @@ DS Automotion GmbH
|
||||
Espressif Systems (Shanghai) Co. Ltd.
|
||||
Falker Atomação Agrícola Ltda
|
||||
Gregory Ellis Nutt
|
||||
Hexagon AB
|
||||
Max Holtzberg
|
||||
RAF Research LLC
|
||||
Software Grant from Uniquix Technologia Ltda
|
||||
Sony
|
||||
UVC Ingenieure
|
||||
Verge Aero
|
||||
Zhu Yan Lin
|
||||
|
||||
NOTE:
|
||||
|
||||
@@ -82,6 +82,53 @@ You need to enable these options in the menuconfig:
|
||||
[*] Support SIGINT
|
||||
(0x03) Serial parse SIGINT characters
|
||||
|
||||
Board Initialization
|
||||
====================
|
||||
|
||||
How to start directly my application instead starting NSH?
|
||||
----------------------------------------------------------
|
||||
|
||||
You can start you application directly instead of starting the default
|
||||
NSH terminal. Lets support your application is called "hello", then you
|
||||
will modify the ENTRYPOINT to call "hello_main" instead of "nsh_main":
|
||||
|
||||
RTOS Features --->
|
||||
Tasks and Scheduling --->
|
||||
(hello_main) Application entry point
|
||||
|
||||
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 instace the NSH_ARCHINIT is not
|
||||
executed anymore and so some drivers initialiation that are called from
|
||||
it also stops to work.
|
||||
|
||||
You can fix it enabling the Board Late Initialization that will replace the
|
||||
NSH_ARCHINIT to call those drivers initialization. Just enable it:
|
||||
|
||||
RTOS Features --->
|
||||
RTOS hooks --->
|
||||
[*] Custom board late initialization
|
||||
|
||||
Also you need to disable the architecture-specific initialization:
|
||||
|
||||
Application Configuration --->
|
||||
NSH Library --->
|
||||
[ ] Have architecture-specific initialization
|
||||
|
||||
Why isn't /dev/ttySx created when using USB Console even when UART is enabled?
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
If you don't use serial console then /dev/ttyS0 will not be created,
|
||||
even if you enable the UART peripheral at "System Type".
|
||||
|
||||
You can fix it enabling the Serial Upper-Half Driver:
|
||||
|
||||
Device Drivers --->
|
||||
Serial Driver Support --->
|
||||
[*] Enable standard "upper-half" serial driver
|
||||
|
||||
Network
|
||||
=======
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 79 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
@@ -11,3 +11,4 @@ Guides
|
||||
drivers.rst
|
||||
tasktrace.rst
|
||||
cpp_cmake.rst
|
||||
pysimcoder.rst
|
||||
|
||||
@@ -0,0 +1,158 @@
|
||||
.. include:: /substitutions.rst
|
||||
.. _pysimcoder:
|
||||
|
||||
pysimCoder integration with NuttX
|
||||
=================================
|
||||
|
||||
`PysimCoder <https://github.com/robertobucher/pysimCoder>`_ is as an open source
|
||||
Rapid Control Application Development Tool which is able to transfer block diagrams into C code.
|
||||
Combined with NuttX, it can be used in real time control application and as an alternative to
|
||||
expensive licensed programs and prototyping platforms. Example of `DC motor control application
|
||||
<https://www.youtube.com/watch?v=6HlGk3ecPNQ>`_ with PID controller and blocks for encoder,
|
||||
PWM, GPIO and sending data over TCP to real time plotter can be seen on `NuttX Channel
|
||||
<https://www.youtube.com/channel/UC0QciIlcUnjJkL5yJJBmluw>`_.
|
||||
|
||||
This documentation describes the steps that are needed to run application generated by pysimCoder
|
||||
on NuttX and also keeps the track of peripherals that are supported by pysimCoder for NuttX RTOS.
|
||||
|
||||
Peripheral Support
|
||||
------------------
|
||||
|
||||
The following list shows the peripherals and fuctionalities supported in pysimCoder for NuttX RTOS.
|
||||
|
||||
========== =======================
|
||||
Peripheral Notes
|
||||
========== =======================
|
||||
ADC
|
||||
CAN Including SocketCAN
|
||||
DAC
|
||||
ENC
|
||||
GPIO
|
||||
PWM Multichannel support
|
||||
UART Serial output
|
||||
Sensors Basic support for DHTXX
|
||||
TCP
|
||||
UDP
|
||||
========== =======================
|
||||
|
||||
Please note that the actual support for NuttX peripherals can be wider that what is mentioned here
|
||||
in case this documentation was not updated when new fuctionalities were added to pysimCoder.
|
||||
|
||||
NuttX Configuration
|
||||
-------------------
|
||||
|
||||
Several configuration options are neccessary to be set in order to succesfully compile pysimCoder
|
||||
with NuttX. The list is the following:
|
||||
|
||||
==================================== =====================================
|
||||
``CONFIG_ARCH_RAMVECTORS=y`` ``CONFIG_NSH_FILE_APPS=y``
|
||||
``CONFIG_BOARDCTL_APP_SYMTAB=y`` ``CONFIG_NSH_LINELEN=64``
|
||||
``CONFIG_BOARDCTL_OS_SYMTAB=y`` ``CONFIG_NSH_READLINE=y``
|
||||
``CONFIG_BUILTIN=y`` ``CONFIG_NSH_ROMFSETC=y``
|
||||
``CONFIG_CLOCK_MONOTONIC=y`` ``CONFIG_PSEUDOTERM=y``
|
||||
``CONFIG_ELF=y`` ``CONFIG_PTHREAD_CLEANUP=y``
|
||||
``CONFIG_FS_BINFS=y`` ``CONFIG_PTHREAD_MUTEX_TYPES=y``
|
||||
``CONFIG_FS_PROCFS=y`` ``CONFIG_PTHREAD_MUTEX_TYPES=y``
|
||||
``CONFIG_FS_PROCFS_REGISTER=y`` ``CONFIG_PTHREAD_STACK_MIN=1024``
|
||||
``CONFIG_FS_ROMFS=y`` ``CONFIG_RR_INTERVAL=10``
|
||||
``CONFIG_FS_TMPFS=y`` ``CONFIG_SCHED_WAITPID=y``
|
||||
``CONFIG_IDLETHREAD_STACKSIZE=2048`` ``CONFIG_SERIAL_TERMIOS=y``
|
||||
``CONFIG_LIBC_EXECFUNCS=y`` ``CONFIG_SYMTAB_ORDEREDBYNAME=y``
|
||||
``CONFIG_LIBC_STRERROR=y`` ``CONFIG_SYSTEM_NSH=y``
|
||||
``CONFIG_MAX_TASKS=16`` ``CONFIG_SYSTEM_NSH_STACKSIZE=4096``
|
||||
``CONFIG_NSH_BUILTIN_APPS=y`` ``CONFIG_USER_ENTRYPOINT="nsh_main"``
|
||||
``CONFIG_NSH_FILEIOSIZE=512``
|
||||
==================================== =====================================
|
||||
|
||||
In case you want to use Network and blocks like TCP or UDP, following configuration
|
||||
options are required:
|
||||
|
||||
============================== ==================================
|
||||
``CONFIG_NET=y`` ``CONFIG_NET_ROUTE=y``
|
||||
``CONFIG_NETDB_DNSCLIENT=y`` ``CONFIG_NET_SOLINGER=y``
|
||||
``CONFIG_NETDEV_LATEINIT=y`` ``CONFIG_NET_STATISTICS=y``
|
||||
``CONFIG_NETDEV_STATISTICS=y`` ``CONFIG_NET_TCP=y``
|
||||
``CONFIG_NETINIT_DHCPC=y`` ``CONFIG_NET_TCPBACKLOG=y``
|
||||
``CONFIG_NETINIT_NOMAC=y`` ``CONFIG_NET_TCP_KEEPALIVE=y``
|
||||
``CONFIG_NETUTILS_FTPC=y`` ``CONFIG_NET_TCP_WRITE_BUFFERS=y``
|
||||
``CONFIG_NETUTILS_TELNETD=y`` ``CONFIG_NET_UDP=y``
|
||||
``CONFIG_NETUTILS_TFTPC=y`` ``CONFIG_SYSTEM_DHCPC_RENEW=y``
|
||||
``CONFIG_NET_ARP_SEND=y`` ``CONFIG_SYSTEM_NTPC=y``
|
||||
``CONFIG_NET_BROADCAST=y`` ``CONFIG_SYSTEM_PING6=y``
|
||||
``CONFIG_NET_IPv6=y`` ``CONFIG_SYSTEM_PING=y``
|
||||
``CONFIG_NET_LOOPBACK=y`` ``CONFIG_SYSTEM_TEE=y``
|
||||
``CONFIG_NET_PKT=y``
|
||||
============================== ==================================
|
||||
|
||||
Board and application specific configuration like setting up peripherals or boot options might also be required,
|
||||
please refer to board and platform documentation for those information. Once NuttX is configured it can be build
|
||||
by simply running:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ make
|
||||
|
||||
Then we need to export build NuttX which can be done by executing command
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ make export
|
||||
|
||||
This creates a zip file nuttx-export-xx.x.x.zip where xx.x.x is the version of NuttX. This file then have to be
|
||||
moved to pysimCoder directory pysimCoder/CodeGen/nuttx, unzip there and then renamed just to nuttx-export. Then
|
||||
enter the pysimCoder/CodeGen/nuttx/device directory and execute
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ make
|
||||
|
||||
This compiles pysimCoder files that controls functions of separate blocks. PysimCoder can be either installed
|
||||
on the system (please refer to the `pysimCoder manual <https://github.com/robertobucher/pysimCoder/blob/master/README.md>`_)
|
||||
or script pysim-run.sh can be used to run pysimCoder without the installation. This script can be found in pysimCoder
|
||||
root directory and is run by executing command
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./pysim-run.sh
|
||||
|
||||
Please note that PYSUPSICTRL variable has to be set/exported in order to succesfully compile NuttX application
|
||||
designed with pysimCoder.
|
||||
|
||||
Using pysimCoder to design NuttX application
|
||||
--------------------------------------------
|
||||
|
||||
After running pysimCoder, separate blocks can be selected from the library menu on the left hand side. The menu contains
|
||||
several libraries, NuttX specific blocks can be found in library "NuttX". It is also possible to use blocks from other
|
||||
libraries like "input", "output", "math" and so on. Several blocks can have specific parameter options and various number
|
||||
of inputs/outputs. Double left click on the block openes parameter settings while single right click on the block leads
|
||||
to number of inputs/outputs setup. The pysimCoder interface can be seen in the picture below.
|
||||
|
||||
.. figure:: image/interface.png
|
||||
:align: center
|
||||
:width: 100%
|
||||
|
||||
pysimCoder interface: library menu can be seen on the left hand side
|
||||
|
||||
The NuttX template Makefile nuttx.tmf has to be selected in order to generate code for NuttX target.
|
||||
This can be done in the top menu by clicking on Block settings icon which is highlighted in the red circle.
|
||||
|
||||
.. figure:: image/menu.png
|
||||
:align: center
|
||||
:width: 100%
|
||||
|
||||
pysimCoder menu: red block settings, green generate C-code
|
||||
|
||||
Block settings option open the following window (showed in the picture below) where you can set template Makefile and
|
||||
also Python skript with parameters for the controllers.
|
||||
|
||||
.. figure:: image/template.png
|
||||
:align: center
|
||||
:width: 100%
|
||||
|
||||
pysimCoder Block settings menu
|
||||
|
||||
C code can be generated by selecting Generate C-code icon (highlighted in the green cirle). Executeble files are then
|
||||
generated and can be flashed into the target. The flashing procedure can be target specific, please refer to plaftorm´s
|
||||
documentation. The generated application can be then run from NuttX command line by executing::
|
||||
|
||||
nsh> main
|
||||
@@ -22,6 +22,7 @@ Last Updated: |today|
|
||||
Home <self>
|
||||
introduction/index.rst
|
||||
quickstart/index.rst
|
||||
contributing/index.rst
|
||||
introduction/inviolables.rst
|
||||
platforms/index.rst
|
||||
components/index.rst
|
||||
@@ -29,7 +30,6 @@ Last Updated: |today|
|
||||
reference/index.rst
|
||||
faq/index.rst
|
||||
guides/index.rst
|
||||
contributing/index.rst
|
||||
glossary.rst
|
||||
|
||||
.. include:: substitutions.rst
|
||||
|
||||
@@ -118,6 +118,20 @@ focused on network-related testing.
|
||||
This configuration cannot be changed to Teensy 4.0 as this board does
|
||||
not have Ethernet capability.
|
||||
|
||||
pikron-bb
|
||||
---------
|
||||
|
||||
This is a configuration that compiles the NuttX for use with
|
||||
open source/hardware `Base Board for Teensy 4.1
|
||||
<https://gitlab.com/pikron/projects/imxrt-devel/-/wikis/teensy_bb>`_.
|
||||
It includes CAN drivers, communication over serial port, Ethernet
|
||||
support, support for 240 x 320 pixels LCD display and configuration
|
||||
options for using NuttX with pysimCoder. NuttX also runs in
|
||||
tickless mode with the resolution 10 usec.
|
||||
|
||||
This configuration cannot be changed to Teensy 4.0 as base board
|
||||
is not designed for that.
|
||||
|
||||
pwm-4.1
|
||||
-------
|
||||
|
||||
|
||||
@@ -33,6 +33,21 @@ set as write-through but can be changed to write-back via Kconfig. While write-b
|
||||
performance than write-through, it is not supported for all peripherals in NuttX yet. Write-back data
|
||||
cache can not be selected while running Ethernet or serial port over USB.
|
||||
|
||||
Tickless OS
|
||||
===========
|
||||
|
||||
With Tickless OS, the periodic, timer interrupt is eliminated and replaced with a one-shot,
|
||||
interval timer, that becomes event driven instead of polled. This allows to run the MCU with
|
||||
higher resolution without using more of the CPU bandwidth processing useless interrupts.
|
||||
|
||||
Only tickless via an alarm is currently supported for i.MX RT MCU, which can be selected by
|
||||
CONFIG_SCHED_TICKLESS_ALARM option. CONFIG_USEC_PER_TICK option determines the resolution
|
||||
of time reported by :c:func:`clock_systime_ticks()` and the resolution of times that can be set
|
||||
for certain delays including watchdog timers and delayed work. It is important that value set in
|
||||
CONFIG_USEC_PER_TICK represents the frequency of GPT timer that runs the tickless mode. Clock
|
||||
source of the timer is 16.6 MHz, which is then devided by the prescaler value from 1 to 4096.
|
||||
Possible values for CONFIG_USEC_PER_TICK are 10 or 100 for example.
|
||||
|
||||
Peripheral Support
|
||||
==================
|
||||
|
||||
|
||||
@@ -2,11 +2,213 @@
|
||||
Bouffalo Lab BL602
|
||||
==================
|
||||
|
||||
Toolchain
|
||||
=========
|
||||
BL602/BL604 is Wi-Fi + BLE combo chipset for ultra-low-cost and
|
||||
low-power application. Wireless subsystem contains 2.4G radio, Wi-Fi
|
||||
802.11b/g/n and BLE 5.0 baseband/MAC designs. Microcontroller subsystem
|
||||
contains a low-power 32-bit RISC CPU, high-speed cache and memories.
|
||||
Power Management Unit controls low-power modes. Moreover, variety of
|
||||
security features are supported.
|
||||
|
||||
OpenOCD
|
||||
-------
|
||||
- 32-bit RISC CPU with FPU (floating point unit)
|
||||
|
||||
Peripheral Support
|
||||
==================
|
||||
- 276KB RAM
|
||||
|
||||
- 128KB ROM
|
||||
|
||||
- 1Kb eFuse
|
||||
|
||||
- Embedded Flash (Optional)
|
||||
|
||||
- Four DMA channels
|
||||
|
||||
BL602 Toolchain
|
||||
===============
|
||||
|
||||
Toolchain can be obtained from
|
||||
`bl_iot_sdk/toolchain/riscv <https://github.com/bouffalolab/bl_iot_sdk/tree/master/toolchain/riscv/Linux>`__
|
||||
|
||||
In addition, SiFive’s toolchain can be downloaded from:
|
||||
|
||||
https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-ubuntu14.tar.gz
|
||||
|
||||
Building
|
||||
========
|
||||
|
||||
nsh
|
||||
---
|
||||
|
||||
First make sure the ``riscv-gnu-toolchain`` has been installed
|
||||
correctly.
|
||||
|
||||
Configure the NuttX project: ``./tools/configure.sh bl602evb:nsh``. Run
|
||||
``make`` to build the project.
|
||||
|
||||
.. code:: shell
|
||||
|
||||
root@pc:~/nuttx$ tools/configure.sh bl602evb:nsh
|
||||
|
||||
root@pc:~/nuttx$ make
|
||||
|
||||
wifi
|
||||
----
|
||||
|
||||
Configure the NuttX project: ``./tools/configure.sh bl602evb:wifi``. Run
|
||||
``make`` to build the project.
|
||||
|
||||
.. code:: shell
|
||||
|
||||
root@pc:~/nuttx$ tools/configure.sh bl602evb:wifi
|
||||
|
||||
root@pc:~/nuttx$ make
|
||||
|
||||
Flashing
|
||||
========
|
||||
|
||||
Dev Cube is a chip integrated development tool provided by Bouffalolab,
|
||||
which includes three functions: IOT program download, MCU program
|
||||
download and RF performance test.
|
||||
|
||||
Dev Cube provides users with the function of downloading programs, and
|
||||
supports the configuration of parameters such as clock and flash. Users
|
||||
can decide whether to encrypt the program, add signatures, and replace
|
||||
the information file, user resource file, partition table and other
|
||||
functional configurations according to their own needs when the program
|
||||
is started.
|
||||
|
||||
Users can get the latest version of Dev Cube through `Bouffalo Lab
|
||||
Dev <https://dev.bouffalolab.com/download>`__.
|
||||
|
||||
Config download
|
||||
---------------
|
||||
|
||||
**Configuration parameters include:**
|
||||
|
||||
- **Interface**: Select the communication interface for flashing, here
|
||||
select Uart to download
|
||||
|
||||
- **COM Port**: When select UART for downloading, select the COM port
|
||||
number connected to the chip, and you can click the Refresh button to
|
||||
refresh the COM port
|
||||
|
||||
- **Uart Rate**: When select UART for downloading, fill in the baud
|
||||
rate. The recommended download baud rate is 2MHz,
|
||||
|
||||
- **Xtal**: Select the crystal oscillator frequency when downloading.
|
||||
If the board does not have a soldered crystal oscillator, the
|
||||
internal RC32M clock source should be selected here,default is 40M
|
||||
|
||||
- **Chip Erase**: default setting is False
|
||||
|
||||
**Configuration parameters include:**
|
||||
|
||||
- **Factory Params**: Use the dts file in the device_tree folder of the
|
||||
corresponding chip model in the Dev Cube directory. The default
|
||||
selection is 40M.
|
||||
|
||||
- **Partition Table**: Use the partition table in the partition folder
|
||||
of the corresponding chip model in the Dev Cube directory, and 2M
|
||||
files are selected by default for BL602
|
||||
|
||||
**For the nuttx, BL602 has a dedicated partition file. It is placed
|
||||
in** ``nuttx/tools/bl602``
|
||||
|
||||
- **Boot2 Bin**: It is the first Flash program that runs after the
|
||||
system is started. It is responsible for establishing the BLSP
|
||||
security environment and guiding the main program to run. It uses the
|
||||
Boot2 file in the builtin_imgs folder of the corresponding chip model
|
||||
in the Dev Cube directory.
|
||||
|
||||
- **Firmware Bin**: Bin file path generated by user compilation
|
||||
|
||||
- **Media/Romfs**: Choose one of Media and Romfs. If you check media,
|
||||
you should provide a file. If you check Romfs, a folder should be
|
||||
provided.
|
||||
|
||||
- **MFG Bin**: Select MFG file
|
||||
|
||||
- **AES-Encrypt**: If you use the encryption function, you need to
|
||||
select the AES-Encrypt option, and enter the Key and IV used for
|
||||
encryption. Hexadecimal characters should be entered, and a Byte is
|
||||
composed of two characters, so the Key and IV require 32 characters
|
||||
to be input respectively. It should be noted that the last 8
|
||||
characters of the IV (ie 4Bytes) must be all 0
|
||||
|
||||
- **Single Download Config**: you can download a single file. Fill in
|
||||
the starting address of the download, starting with 0x
|
||||
|
||||
For details, please refer to `BLFlashEnv — BL602 IoT
|
||||
SDK <https://bouffalolab.github.io/bl_iot_sdk/Developer_Environment/BLFlashEnv/BLFlashEnv.html#iot>`__
|
||||
|
||||
Debuging with OpenOCD
|
||||
=====================
|
||||
|
||||
Download OpenOCD `RISC‑V
|
||||
OpenOCD <https://static.dev.sifive.com/dev-tools/freedom-tools/v2020.12/riscv-openocd-0.10.0-2020.12.1-x86_64-linux-ubuntu14.tar.gz>`__.
|
||||
|
||||
Start OpenOCD:
|
||||
|
||||
.. code:: shell
|
||||
|
||||
root@pc:~$ openocd -f ~/bl_iot_sdk/tools/debug/if_bflb_link.cfg -f ~/bl_iot_sdk/tools/debug/tgt_602_xip.cfg
|
||||
|
||||
Start GDB:
|
||||
|
||||
.. code:: shell
|
||||
|
||||
root@pc:~$ riscv64-unknown-elf-gdb ~/nuttx/nuttx -x ~/bl_iot_sdk/tools/debug/602.init
|
||||
|
||||
Connect OpenOCD:
|
||||
|
||||
.. code:: shell
|
||||
|
||||
(gdb) target remote :3333
|
||||
|
||||
(gdb) c
|
||||
|
||||
BL602 Peripheral Support
|
||||
========================
|
||||
|
||||
- One SDIO 2.0 slave
|
||||
|
||||
- One SPI master/slave
|
||||
|
||||
- Two UART
|
||||
|
||||
- One I2C master
|
||||
|
||||
- Five PWM channels
|
||||
|
||||
- 10-bit general DAC
|
||||
|
||||
- 12-bit general ADC
|
||||
|
||||
- Two general analog comparators (ACOMP)
|
||||
|
||||
- PIR (Passive Infra-Red) detection
|
||||
|
||||
- IR remote HW accelerator
|
||||
|
||||
- 16 or 23 GPIOs
|
||||
|
||||
========== ======= =====
|
||||
Peripheral Support NOTES
|
||||
========== ======= =====
|
||||
GPIO Yes
|
||||
UART Yes
|
||||
SPI Yes
|
||||
I2C Yes
|
||||
DMA Yes
|
||||
Wifi Yes
|
||||
SPI FLASH Yes
|
||||
Timers Yes
|
||||
Watchdog Yes
|
||||
RTC Yes
|
||||
RNG No
|
||||
AES No
|
||||
eFuse Yes
|
||||
ADC No
|
||||
Bluetooth No
|
||||
LED_PWM No
|
||||
SHA No
|
||||
RSA No
|
||||
========== ======= =====
|
||||
|
||||
@@ -113,15 +113,15 @@ Wifi Yes
|
||||
SPIFLASH Yes
|
||||
Timers Yes
|
||||
Watchdog Yes
|
||||
RTC No
|
||||
RTC Yes
|
||||
RNG Yes
|
||||
AES No
|
||||
eFuse No
|
||||
ADC No
|
||||
Bluetooth No
|
||||
LED_PWM No
|
||||
SHA No
|
||||
RSA No
|
||||
AES Yes
|
||||
eFuse Yes
|
||||
ADC Yes
|
||||
Bluetooth Yes
|
||||
LED_PWM Yes
|
||||
SHA Yes
|
||||
RSA Yes
|
||||
========== ======= =====
|
||||
|
||||
|
||||
|
||||
@@ -59,13 +59,13 @@ GPIO Yes
|
||||
MMUART Yes Uart mode only
|
||||
SPI Yes
|
||||
I2C Yes
|
||||
eMMC SD/SDIO Yes eMMC not fully tested
|
||||
Timers No
|
||||
Watchdog No
|
||||
RTC No
|
||||
CAN No
|
||||
eNVM No
|
||||
USB No
|
||||
eMMC SD/SDIO No
|
||||
============ ======= =====
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
==========
|
||||
Simulators
|
||||
==========
|
||||
|
||||
The following Simulator/Emulators are supported:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:glob:
|
||||
|
||||
*/*
|
||||
@@ -0,0 +1,56 @@
|
||||
===
|
||||
SIM
|
||||
===
|
||||
|
||||
It is possible to run NuttX in a simulator called ``sim``, but some features
|
||||
currently are supported only on Linux host (i.e.: Bluetooth, I2C, SPI, etc).
|
||||
|
||||
Using ``sim`` you can test many of NuttX features without a supported board.
|
||||
Examples of supported features: Audio, Bluetooth, ELF, I2C, SPI, LVGL, Flash
|
||||
File System, NX Serves, NX Demos, NX Window Manager, ROMFS, Network: TCP,
|
||||
UDP, IP,6LoWPAN, and many more.
|
||||
|
||||
Toolchain
|
||||
=========
|
||||
|
||||
All you need is your machine ``gcc`` working.
|
||||
|
||||
Compiling
|
||||
=========
|
||||
|
||||
All you need to do is select your desired board profile configuratioon
|
||||
(see: nuttx/sim/sim/sim/configs for the listing) ::
|
||||
|
||||
$ ./tools/configure.sh sim:nsh
|
||||
|
||||
$ make
|
||||
|
||||
|
||||
Running
|
||||
=======
|
||||
|
||||
When the compilation finishes it will create a ``nuttx`` binary, then run it::
|
||||
|
||||
$ ./nuttx
|
||||
login: admin
|
||||
password: Administrator
|
||||
User Logged-in!
|
||||
|
||||
NuttShell (NSH) NuttX-10.1.0
|
||||
MOTD: username=admin password=Administrator
|
||||
nsh> ?
|
||||
help usage: help [-v] [<cmd>]
|
||||
|
||||
. cd echo hexdump mkfatfs pwd source unset
|
||||
[ cp exec kill mkrd readlink test usleep
|
||||
? cmp exit losetup mount rm time xd
|
||||
basename dirname false ln mv rmdir true
|
||||
break dd free ls poweroff set uname
|
||||
cat df help mkdir ps sleep umount
|
||||
|
||||
Builtin Apps:
|
||||
sh hello nsh
|
||||
nsh> uname -a
|
||||
NuttX 10.1.0 508215581f Sep 3 2021 10:47:34 sim sim
|
||||
nsh>
|
||||
|
||||
@@ -119,7 +119,44 @@ USB connection by means of CP2102 converter, at 115200 bps).
|
||||
wapi
|
||||
----
|
||||
|
||||
Enables WiFi support
|
||||
Enables WiFi support. You can define your credentials this way::
|
||||
|
||||
$ make menuconfig
|
||||
-> Application Configuration
|
||||
-> Network Utilities
|
||||
-> Network initialization (NETUTILS_NETINIT [=y])
|
||||
-> WAPI Configuration
|
||||
|
||||
Or if you don't want to keep it saved in the firmware you can do it
|
||||
at runtime::
|
||||
|
||||
nsh> wapi psk wlan0 mypasswd 1
|
||||
nsh> wapi essid wlan0 myssid 1
|
||||
nsh> renew wlan0
|
||||
|
||||
wifinsh
|
||||
-------
|
||||
|
||||
The ``wifinsh`` is similar to the ``wapi`` board example, but it will connect
|
||||
automatically to your Access Point (Wi-Fi Router) and will run telnet daemon
|
||||
in the board. Then you can connect to your board from your computer using the
|
||||
telnet program.
|
||||
|
||||
After configuring the ``esp32-devkit:wifinsh`` you need to define your creden-
|
||||
tials in the menuconfig. You can define your credentials this way::
|
||||
|
||||
$ make menuconfig
|
||||
-> Application Configuration
|
||||
-> Network Utilities
|
||||
-> Network initialization (NETUTILS_NETINIT [=y])
|
||||
-> WAPI Configuration
|
||||
|
||||
Find your board IP using ``nsh> ifconfig`` and then from your computer::
|
||||
|
||||
$ telnet 192.168.x.y
|
||||
|
||||
Where x and y are the last two numbers of the IP that your router gave to
|
||||
your board.
|
||||
|
||||
mqttc
|
||||
-----
|
||||
@@ -129,14 +166,14 @@ This configuration tests the MQTT-C publisher example.
|
||||
From the host, start the broker and subscribe to the :code:`test` topic. Using
|
||||
`mosquitto` this should be::
|
||||
|
||||
mosquitto&
|
||||
mosquitto_sub -t test
|
||||
$ mosquitto&
|
||||
$ mosquitto_sub -t test
|
||||
|
||||
From the NSH, connect to an access point::
|
||||
|
||||
wapi psk wlan0 mypasswd 1
|
||||
wapi essid wlan0 myssid 1
|
||||
renew wlan0
|
||||
nsh> wapi psk wlan0 mypasswd 1
|
||||
nsh> wapi essid wlan0 myssid 1
|
||||
nsh> renew wlan0
|
||||
|
||||
Publish to the broker::
|
||||
|
||||
@@ -211,7 +248,7 @@ SPI2 is used and kept with the default IOMUX pins, i.e.::
|
||||
|
||||
Once booted the following command is used to mount a FAT file system::
|
||||
|
||||
mount -t vfat /dev/mmcsd0 /mnt
|
||||
nsh> mount -t vfat /dev/mmcsd0 /mnt
|
||||
|
||||
module
|
||||
------
|
||||
@@ -232,8 +269,8 @@ through SPI1.
|
||||
By default a SmartFS file system is selected.
|
||||
Once booted you can use the following commands to mount the file system::
|
||||
|
||||
mksmartfs /dev/smart0
|
||||
mount -t smartfs /dev/smart0 /mnt
|
||||
nsh> mksmartfs /dev/smart0
|
||||
nsh> mount -t smartfs /dev/smart0 /mnt
|
||||
|
||||
Note that mksmartfs is only needed the first time.
|
||||
|
||||
|
||||
@@ -107,7 +107,7 @@ At the nsh, we can turn LEDs on and off with the following::
|
||||
|
||||
We can use the interrupt pin to send a signal when the interrupt fires::
|
||||
|
||||
nsh> gpio -w 14 /dev/gpint3
|
||||
nsh> gpio -w 14 /dev/gpint0
|
||||
|
||||
The pin is configured to as a rising edge interrupt, so after issuing the
|
||||
above command, connect it to 3.3V.
|
||||
|
||||
@@ -25,7 +25,7 @@ for ESP32 by Espressif.
|
||||
|
||||
For flashing firmware, you will need to install ``esptool.py`` by running::
|
||||
|
||||
pip install esptool
|
||||
$ pip install esptool
|
||||
|
||||
Building from source
|
||||
--------------------
|
||||
@@ -37,7 +37,7 @@ build the toolchain with crosstool-NG on Linux are as follows
|
||||
|
||||
$ git clone https://github.com/espressif/crosstool-NG.git
|
||||
$ cd crosstool-NG
|
||||
$ git checkout esp-2019r2
|
||||
$ git checkout esp-2021r1
|
||||
$ git submodule update --init
|
||||
|
||||
$ ./bootstrap && ./configure --enable-local && make
|
||||
@@ -49,15 +49,18 @@ build the toolchain with crosstool-NG on Linux are as follows
|
||||
|
||||
$ export PATH="crosstool-NG/builds/xtensa-esp32-elf/bin:$PATH"
|
||||
|
||||
These steps are given in setup guide in
|
||||
`ESP-IDF repository <https://docs.espressif.com/projects/esp-idf/en/latest/get-started/linux-setup-scratch.html>`_.
|
||||
These steps are given in the setup guide in
|
||||
`ESP-IDF documentation <https://docs.espressif.com/projects/esp-idf/en/latest/get-started/linux-setup-scratch.html>`_.
|
||||
|
||||
Flashing
|
||||
========
|
||||
|
||||
Firmware for ESP32 is flashed via the USB/UART interface using the ``esptool.py`` tool. To flash your NuttX firmware simply run::
|
||||
Firmware for ESP32 is flashed via the USB/UART interface using the ``esptool.py`` tool.
|
||||
It's a two step process where the first converts the ELF file into a ESP32-compatible binary
|
||||
and the second flashes it to the board. These steps are included into the build system and you can
|
||||
flash your NuttX firmware simply by running::
|
||||
|
||||
make download ESPTOOL_PORT=<port>
|
||||
$ make download ESPTOOL_PORT=<port>
|
||||
|
||||
where ``<port>`` is typically ``/dev/ttyUSB0`` or similar. You can change the baudrate by passing ``ESPTOOL_BAUD``.
|
||||
|
||||
@@ -288,10 +291,10 @@ WiFi
|
||||
|
||||
A standard network interface will be configured and can be initialized such as::
|
||||
|
||||
ifup wlan0
|
||||
wapi psk wlan0 mypasswd 1
|
||||
wapi essid wlan0 myssid 1
|
||||
renew wlan0
|
||||
nsh> ifup wlan0
|
||||
nsh> wapi psk wlan0 mypasswd 3
|
||||
nsh> wapi essid wlan0 myssid 1
|
||||
nsh> renew wlan0
|
||||
|
||||
In this case a connection to AP with SSID ``myssid`` is done, using ``mypasswd`` as
|
||||
password. IP address is obtained via DHCP using ``renew`` command. You can check
|
||||
@@ -299,373 +302,29 @@ the result by running ``ifconfig`` afterwards.
|
||||
|
||||
.. tip:: Boards usually expose a ``wapi`` defconfig which enables WiFi
|
||||
|
||||
WiFi SoftAP
|
||||
===========
|
||||
|
||||
It is possible to use ESP32 as an Access Point (SoftAP). Actually there are some
|
||||
boards with a ``sta_softap`` which enables this support.
|
||||
|
||||
If you are using this board config profile you can run these commands to be able
|
||||
to connect your smartphone or laptop to your board::
|
||||
|
||||
nsh> ifup wlan1
|
||||
nsh> dhcpd_start wlan1
|
||||
nsh> wapi psk wlan0 mypasswd 1
|
||||
nsh> wapi essid wlan1 nuttxap 1
|
||||
|
||||
In this case, you are creating the access point ``nuttxapp`` in your board and to
|
||||
connect to it on your smartphone you will be required to type the password ``mypasswd``.
|
||||
The ``dhcpd_start`` is necessary to let your board to associate an IP to your smartphone.
|
||||
|
||||
Bluetooth
|
||||
=========
|
||||
|
||||
Bluetooth is not currently supported.
|
||||
|
||||
Debugging with OpenOCD
|
||||
======================
|
||||
|
||||
First you in need some debug environment which would be a JTAG emulator
|
||||
and the ESP32 OpenOCD software which is available here:
|
||||
https://github.com/espressif/openocd-esp32
|
||||
|
||||
OpenOCD Documentation
|
||||
---------------------
|
||||
|
||||
There is on overview of the use of OpenOCD `here <https://dl.espressif.com/doc/esp-idf/latest/openocd.html>`.
|
||||
This document is also available in `ESP-IDF source tree <https://github.com/espressif/esp-idf>`_
|
||||
in ``docs`` directory.
|
||||
|
||||
OpenOCD Configuration File
|
||||
--------------------------
|
||||
|
||||
A template ESP32 OpenOCD configuration file is provided in
|
||||
ESP-IDF ``docs`` directory (``esp32.cfg``). Since you are not using
|
||||
FreeRTOS, you will need to uncomment the line::
|
||||
|
||||
set ESP32_RTOS none
|
||||
|
||||
in the OpenOCD configuration file. You will also need to change
|
||||
the source line from::
|
||||
|
||||
find interface/ftdi/tumpa.cfg
|
||||
|
||||
to reflect the physical JTAG adapter connected.
|
||||
|
||||
A copy of this OpenOCD configuration file available in the NuttX
|
||||
source tree at ``nuttx/boards/xtensa/esp32/esp32-devkitc/scripts/esp32.cfg``.
|
||||
It has these modifications:
|
||||
|
||||
- The referenced "set ESP32_RTOS none" line has been uncommented
|
||||
- The "find interface/ftdi/tumpa.cfg" was removed. This means that you will
|
||||
need to specify the interface configuration file on the OpenOCD
|
||||
command line.
|
||||
|
||||
Another OpenOCD configuration file is available in the NuttX source tree at
|
||||
``nuttx/boards/xtensa/esp32/esp32-devkitc/scripts/esp32-ft232h.cfg``.
|
||||
It has been tested with:
|
||||
|
||||
- `ESP32-DevKitC V4 <https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-devkitc.html>`_
|
||||
|
||||
- Akizukidenshi's FT232HL, a FT232H based JTAG adapter
|
||||
(http://akizukidenshi.com/catalog/g/gK-06503/) with JP3 and JP4 closed,
|
||||
and connected to ESP32 as:
|
||||
|
||||
+------------------+-------------+
|
||||
| ESP32-DevKitC V4 | FT232HL |
|
||||
+=======+==========+=============+
|
||||
| J2 | J3 | J2 |
|
||||
+-------+----------+-------------+
|
||||
| IO13 | | AD0 (TCK) |
|
||||
+-------+----------+-------------+
|
||||
| IO12 | | AD1 (TDI) |
|
||||
+-------+----------+-------------+
|
||||
| | IO15 | AD2 (TDO) |
|
||||
+-------+----------+-------------+
|
||||
| IO14 | | AD3 (TMS) |
|
||||
+-------+----------+-------------+
|
||||
| GND | | GND |
|
||||
+-------+----------+-------------+
|
||||
|
||||
The following version of OpenOCD from ESP-IDF (macOS version)::
|
||||
|
||||
% openocd --version
|
||||
Open On-Chip Debugger v0.10.0-esp32-20191114 (2019-11-14-14:19)
|
||||
Licensed under GNU GPL v2
|
||||
For bug reports, read
|
||||
http://openocd.org/doc/doxygen/bugs.html
|
||||
|
||||
General OpenOCD build instructions
|
||||
----------------------------------
|
||||
|
||||
Installing OpenOCD. The sources for the ESP32-enabled variant of
|
||||
OpenOCD are available from Espressifs GitHub. To download the source,
|
||||
use the following commands:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ git clone https://github.com/espressif/openocd-esp32.git
|
||||
$ cd openocd-esp32
|
||||
$ git submodule init
|
||||
$ git submodule update
|
||||
|
||||
Then look at the README and the docs/INSTALL.txt files in the
|
||||
openocd-esp32 directory for further instructions. There area
|
||||
separate README files for Linux/Cygwin, macOS, and Windows. Here
|
||||
is what I ended up doing (under Linux):
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cd openocd-esp32
|
||||
$ ./bootstrap
|
||||
$ ./configure
|
||||
$ make
|
||||
|
||||
If you do not do the install step, then you will have a localhost
|
||||
version of the OpenOCD binary at ``openocd-esp32/src``.
|
||||
|
||||
Starting the OpenOCD Server
|
||||
---------------------------
|
||||
|
||||
- cd to openocd-esp32 directory
|
||||
- copy the modified esp32.cfg script to this directory
|
||||
|
||||
Then start OpenOCD by executing a command like the following. Here
|
||||
I assume that:
|
||||
|
||||
- You did not install OpenOCD; binaries are available at
|
||||
openocd-esp32/src and interface scripts are in
|
||||
openocd-esp32/tcl/interface
|
||||
- I select the configuration for the Olimex ARM-USB-OCD
|
||||
debugger.
|
||||
|
||||
Then the command to start OpenOCD is:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./src/openocd -s ./tcl -f tcl/interface/ftdi/olimex-arm-usb-ocd.cfg -f ./esp32.cfg
|
||||
|
||||
I then see::
|
||||
|
||||
Open On-Chip Debugger 0.10.0-dev-g3098897 (2016-11-14-12:19)
|
||||
Licensed under GNU GPL v2
|
||||
For bug reports, read
|
||||
http://openocd.org/doc/doxygen/bugs.html
|
||||
adapter speed: 200 kHz
|
||||
force hard breakpoints
|
||||
Info : clock speed 200 kHz
|
||||
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
|
||||
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
|
||||
Info : esp32.cpu0: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
|
||||
Info : esp32.cpu0: Core was reset (pwrstat=0x5F, after clear 0x0F).
|
||||
|
||||
Connecting a debugger to OpenOCD
|
||||
--------------------------------
|
||||
|
||||
OpenOCD should now be ready to accept gdb connections. If you have
|
||||
compiled the ESP32 toolchain using Crosstool-NG, or if you have
|
||||
downloaded a precompiled toolchain from the Espressif website, you
|
||||
should already have xtensa-esp32-elf-gdb, a version of gdb that can
|
||||
be used for this
|
||||
|
||||
First, make sure the project you want to debug is compiled and
|
||||
flashed into the ESP32’s SPI flash. Then, in a different console
|
||||
than OpenOCD is running in, invoke gdb. For example, for the
|
||||
template app, you would do this like such::
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cd nuttx
|
||||
$ xtensa-esp32-elf-gdb -ex 'target remote localhost:3333' nuttx
|
||||
|
||||
This should give you a gdb prompt.
|
||||
|
||||
Breakpoints
|
||||
-----------
|
||||
|
||||
You can set up to 2 hardware breakpoints, which can be anywhere in the
|
||||
address space. Also 2 hardware watchpoints.
|
||||
|
||||
The openocd esp32.cfg file currently forces gdb to use hardware
|
||||
breakpoints, I believe because software breakpoints (or, at least, the
|
||||
memory map for automatically choosing them) aren't implemented yet
|
||||
(as of 2016-11-14).
|
||||
|
||||
JTAG Emulator
|
||||
-------------
|
||||
|
||||
The documentation indicates that you need to use an external JTAG
|
||||
like the TIAO USB Multi-protocol Adapter and the Flyswatter2.
|
||||
The instructions at http://www.esp32.com/viewtopic.php?t=381 show
|
||||
use of an FTDI C232HM-DDHSL-0 USB 2.0 high speed to MPSSE cable.
|
||||
|
||||
The ESP32 DevkitC v4 board has no on board JTAG connector. It will
|
||||
be necessary to make a cable or some other board to connect a JTAG
|
||||
emulator. Refer to http://www.esp32.com/viewtopic.php?t=381 "How
|
||||
to debug ESP32 with JTAG / OpenOCD / GDB 1st part connect the
|
||||
hardware."
|
||||
|
||||
Relevant pin-out:
|
||||
|
||||
========= =============
|
||||
PIN LABEL JTAG FUNCTION
|
||||
========= =============
|
||||
IO14 TMS
|
||||
IO12 TDI
|
||||
GND GND
|
||||
IO13 TCK
|
||||
x x
|
||||
IO15 TDO
|
||||
========= =============
|
||||
|
||||
You can find the mapping of JTAG signals to ESP32 GPIO numbers in
|
||||
"ESP32 Pin List" document found
|
||||
`here <http://espressif.com/en/support/download/documents?keys=&field_type_tid%5B%5D=13>`_.
|
||||
|
||||
I put the ESP32 on a prototyping board and used a standard JTAG 20-pin
|
||||
connector with an older Olimex JTAG that I had. Here is how I wired
|
||||
the 20-pin connector:
|
||||
|
||||
===================== ===============
|
||||
20-PIN JTAG CONNECTOR ESP32 PIN LABEL
|
||||
===================== ===============
|
||||
1 VREF INPUT 3V3
|
||||
3 nTRST OUTPUT N/C
|
||||
5 TDI OUTPUT IO12
|
||||
7 TMS OUTPUT IO14
|
||||
9 TCLK OUTPUT IO13
|
||||
11 RTCK INPUT N/C
|
||||
13 TDO INPUT IO15
|
||||
15 RESET I/O N/C
|
||||
17 DBGRQ OUTPUT N/C
|
||||
19 5V OUTPUT N/C
|
||||
2 VCC INPUT 3V3
|
||||
4 GND N/A GND
|
||||
6 GND N/A GND
|
||||
8 GND N/A GND
|
||||
10 GND N/A GND
|
||||
12 GND N/A GND
|
||||
14 GND N/A GND
|
||||
16 GND N/A GND
|
||||
18 GND N/A GND
|
||||
20 GND N/A GND
|
||||
===================== ===============
|
||||
|
||||
Executing and Debugging from FLASH and IRAM
|
||||
===========================================
|
||||
|
||||
FLASH
|
||||
-----
|
||||
|
||||
OpenOCD currently doesn't have a FLASH driver for ESP32, so you can load
|
||||
code into IRAM only via JTAG. FLASH-resident sections like .FLASH.rodata
|
||||
will fail to load. The bootloader in ROM doesn't parse ELF, so any image
|
||||
which is bootloaded from FLASH has to be converted into a custom image
|
||||
format first.
|
||||
|
||||
The tool esp-idf uses for flashing is a command line Python tool called
|
||||
"esptool.py" which talks to a serial bootloader in ROM. A version is
|
||||
supplied in the esp-idf codebase in components/esptool_py/esptool, the
|
||||
"upstream" for that tool is here and now supports ESP32::
|
||||
|
||||
https://github.com/espressif/esptool/
|
||||
|
||||
To FLASH an ELF via the command line is a two step process, something like
|
||||
this::
|
||||
|
||||
esptool.py --chip esp32 elf2image --flash_mode dio --flash_size 4MB -o nuttx.bin nuttx
|
||||
esptool.py --chip esp32 --port COMx write_flash 0x1000 bootloader.bin 0x8000 partition_table.bin 0x10000 nuttx.bin
|
||||
|
||||
The first step converts an ELF image into an ESP32-compatible binary
|
||||
image format, and the second step flashes it (along with bootloader image and
|
||||
partition table binary.)
|
||||
The offset for the partition table may vary, depending on ESP-IDF
|
||||
configuration, ``CONFIG_PARTITION_TABLE_OFFSET``, which is by default 0x8000
|
||||
as of writing this.
|
||||
|
||||
To put the ESP32 into serial flashing mode, it needs to be reset with IO0 held
|
||||
low. On the Core boards this can be accomplished by holding the button marked
|
||||
"Boot" and pressing then releasing the button marked "EN". Actually, esptool.py
|
||||
can enter bootloader mode automatically (via RTS/DTR control lines), but
|
||||
unfortunately a timing interaction between the Windows CP2012 driver and the
|
||||
hardware means this doesn't currently work on Windows.
|
||||
|
||||
Secondary Boot Loader / Partition Table
|
||||
---------------------------------------
|
||||
|
||||
See:
|
||||
|
||||
- https://github.com/espressif/esp-idf/tree/master/components/bootloader
|
||||
- https://github.com/espressif/esp-idf/tree/master/components/partition_table .
|
||||
|
||||
The secondary boot loader by default programs a RTC watchdog timer.
|
||||
As NuttX doesn't know the timer, it reboots every ~9 seconds. You can
|
||||
disable the timer by tweaking sdkconfig CONFIG_BOOTLOADER_WDT_ENABLE
|
||||
and rebuild the boot loader.
|
||||
|
||||
Running from IRAM with OpenOCD
|
||||
------------------------------
|
||||
|
||||
Running from IRAM is a good debug option. You should be able to load the
|
||||
ELF directly via JTAG in this case, and you may not need the bootloader.
|
||||
|
||||
NuttX supports a configuration option, CONFIG_ESP32_DEVKITC_RUN_IRAM, that may be
|
||||
selected for execution from IRAM. This option simply selects the correct
|
||||
linker script for IRAM execution.
|
||||
|
||||
Skipping the Secondary Bootloader
|
||||
---------------------------------
|
||||
|
||||
It is possible to skip the secondary bootloader and run out of IRAM using
|
||||
only the primary bootloader if your application of small enough (< 128KiB code,
|
||||
<180KiB data), then you can simplify initial bring-up by avoiding second stage
|
||||
bootloader. Your application will be loaded into IRAM using first stage
|
||||
bootloader present in ESP32 ROM. To achieve this, you need two things:
|
||||
|
||||
1. Have a linker script which places all code into IRAM and all data into
|
||||
IRAM/DRAM
|
||||
|
||||
2. Use "esptool.py" utility to convert application .elf
|
||||
file into binary format which can be loaded by first stage bootloader.
|
||||
|
||||
Again you would need to link the ELF file and convert it to binary format suitable
|
||||
for flashing into the board. The command should to convert ELF file to binary
|
||||
image looks as follows::
|
||||
|
||||
esptool.py --chip esp32 elf2image --flash_mode "dio" --flash_freq "40m" --flash_size "2MB" -o nuttx.bin nuttx
|
||||
|
||||
To flash binary image to your development board, use the same esptool.py utility::
|
||||
|
||||
esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 write_flash -z --flash_mode dio --flash_freq 40m --flash_size 2MB 0x1000 nuttx.bin
|
||||
|
||||
The argument before app.bin (0x1000) indicates the offset in flash where binary
|
||||
will be written. ROM bootloader expects to find an application (or second stage
|
||||
bootloader) image at offset 0x1000, so we are writing the binary there.
|
||||
|
||||
Sample OpenOCD Debug Steps
|
||||
--------------------------
|
||||
|
||||
I did the initial bring-up using the IRAM configuration and OpenOCD. Here
|
||||
is a synopsis of my debug steps:
|
||||
|
||||
boards/xtensa/esp32/esp32-devkitc/configs/nsh with::
|
||||
|
||||
CONFIG_DEBUG_ASSERTIONS=y
|
||||
CONFIG_DEBUG_FEATURES=y
|
||||
CONFIG_DEBUG_SYMBOLS=y
|
||||
CONFIG_ESP32_DEVKITC_RUN_IRAM=y
|
||||
|
||||
I also made this change configuration which will eliminate all attempts to
|
||||
re-configure serial. It will just use the serial settings as they were left
|
||||
by the bootloader::
|
||||
|
||||
CONFIG_SUPPRESS_UART_CONFIG=y
|
||||
|
||||
Start OpenOCD::
|
||||
|
||||
cd ../openocde-esp32
|
||||
cp ../nuttx/boards/xtensa/esp32/esp32-devkitc/scripts/esp32.cfg .
|
||||
sudo ./src/openocd -s ./tcl/ -f tcl/interface/ftdi/olimex-arm-usb-ocd.cfg -f ./esp32.cfg
|
||||
|
||||
Start GDB and load code::
|
||||
|
||||
cd ../nuttx
|
||||
xtensa-esp32-elf-gdb -ex 'target remote localhost:3333' nuttx
|
||||
(gdb) load nuttx
|
||||
(gdb) mon reg pc [value report by load for entry point]
|
||||
(gdb) s
|
||||
|
||||
Single stepping works fine for me as do breakpoints::
|
||||
|
||||
Breakpoint 1, up_timer_initialize () at chip/esp32_timerisr.c:172
|
||||
72 {
|
||||
(gdb) n
|
||||
esp32.cpu0: Target halted, pc=0x400835BF
|
||||
187 g_tick_divisor = divisor;
|
||||
(gdb) ...
|
||||
|
||||
Using QEMU
|
||||
==========
|
||||
|
||||
@@ -704,8 +363,6 @@ Things to Do
|
||||
|
||||
3. See SMP-related issues above
|
||||
|
||||
4. See OpenOCD for the ESP32 above
|
||||
|
||||
Supported Boards
|
||||
================
|
||||
|
||||
|
||||
@@ -165,8 +165,8 @@ Apache NuttX is actively developed on GitHub. There are two main repositories, `
|
||||
$ cd nuttx
|
||||
$ curl -L https://github.com/apache/incubator-nuttx/tarball/master -o nuttx.tar.gz
|
||||
$ curl -L https://github.com/apache/incubator-nuttx-apps/tarball/master -o apps.tar.gz
|
||||
$ tar zxf nuttx.tar.gz
|
||||
$ tar zxf apps.tar.gz
|
||||
$ tar zxf nuttx.tar.gz --one-top-level=nuttx --strip-components 1
|
||||
$ tar zxf apps.tar.gz --one-top-level=apps --strip-components 1
|
||||
|
||||
There are also ``.zip`` archives available (useful for Windows users): just replace ``tarball`` with
|
||||
``zipball``.
|
||||
@@ -174,13 +174,13 @@ Apache NuttX is actively developed on GitHub. There are two main repositories, `
|
||||
.. tab:: Download stable release
|
||||
|
||||
Go to `releases <https://nuttx.apache.org/download/>`_ and choose a version to download. The following
|
||||
example uses version 9.1.0:
|
||||
example uses version 10.1.0:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ mkdir nuttx
|
||||
$ cd nuttx
|
||||
$ curl -L https://downloads.apache.org/incubator/nuttx/9.1.0/apache-nuttx-9.1.0-incubating.tar.gz -o nuttx.tar.gz
|
||||
$ curl -L https://downloads.apache.org/incubator/nuttx/9.1.0/apache-nuttx-apps-9.1.0-incubating.tar.gz -o apps.tar.gz
|
||||
$ curl -L https://www.apache.org/dyn/closer.lua/incubator/nuttx/10.1.0/apache-nuttx-10.1.0-incubating.tar.gz?action=download -o nuttx.tar.gz
|
||||
$ curl -L https://www.apache.org/dyn/closer.lua/incubator/nuttx/10.1.0/apache-nuttx-apps-10.1.0-incubating.tar.gz?action=download -o apps.tar.gz
|
||||
$ tar zxf nuttx.tar.gz
|
||||
$ tar zxf apps.tar.gz
|
||||
|
||||
@@ -9,6 +9,39 @@ config APPSDIR
|
||||
string
|
||||
option env="APPSDIR"
|
||||
|
||||
menu "License Setup"
|
||||
config ALLOW_BSD_COMPONENTS
|
||||
bool "Use components that have BSD licenses"
|
||||
default n
|
||||
---help---
|
||||
When this option is enabled the project will allow the use
|
||||
of components that have BSD licenses.
|
||||
|
||||
NOTE: Please check that the license for each enabled
|
||||
component matches your project license.
|
||||
|
||||
NOTE: If this option is not set the following components
|
||||
are not included in the setup menu:
|
||||
Crypto
|
||||
AES cypher support
|
||||
FS
|
||||
NFS client file system
|
||||
SPIFFS File System
|
||||
Wireless
|
||||
Bluetooth LE support
|
||||
|
||||
config ALLOW_GPL_COMPONENTS
|
||||
bool "Use components that have GPL/LGPL licenses"
|
||||
default n
|
||||
---help---
|
||||
When this option is enabled the project will allow the use
|
||||
of components that have GPL/LGPL licenses.
|
||||
|
||||
NOTE: Please check that the license for each enabled
|
||||
component matches your project license.
|
||||
|
||||
endmenu # License Setup
|
||||
|
||||
menu "Build Setup"
|
||||
|
||||
config EXPERIMENTAL
|
||||
@@ -1107,7 +1140,7 @@ comment "Driver Debug Options"
|
||||
config DEBUG_LCD
|
||||
bool "Low-level LCD Debug Features"
|
||||
default n
|
||||
depends on LCD
|
||||
depends on LCD || SLCD
|
||||
---help---
|
||||
Enable LCD driver debug features.
|
||||
|
||||
@@ -1741,6 +1774,38 @@ config DEBUG_MOTOR_INFO
|
||||
Enable motor informational output to SYSLOG.
|
||||
|
||||
endif # DEBUG_MOTOR
|
||||
|
||||
config DEBUG_VIDEO
|
||||
bool "Video Debug Features"
|
||||
default n
|
||||
depends on DRIVERS_VIDEO
|
||||
---help---
|
||||
Enable video debug features.
|
||||
|
||||
if DEBUG_VIDEO
|
||||
|
||||
config DEBUG_VIDEO_ERROR
|
||||
bool "Video Error Output"
|
||||
default n
|
||||
depends on DEBUG_ERROR
|
||||
---help---
|
||||
Enable video error output to SYSLOG.
|
||||
|
||||
config DEBUG_VIDEO_WARN
|
||||
bool "Video Warnings Output"
|
||||
default n
|
||||
depends on DEBUG_WARN
|
||||
---help---
|
||||
Enable video warning output to SYSLOG.
|
||||
|
||||
config DEBUG_VIDEO_INFO
|
||||
bool "Video Informational Output"
|
||||
default n
|
||||
depends on DEBUG_INFO
|
||||
---help---
|
||||
Enable video informational output to SYSLOG.
|
||||
|
||||
endif # DEBUG_VIDEO
|
||||
endif # DEBUG_FEATURES
|
||||
|
||||
config ARCH_HAVE_STACKCHECK
|
||||
@@ -1759,14 +1824,16 @@ config STACK_COLORATION
|
||||
Only supported by a few architectures.
|
||||
|
||||
config STACK_USAGE_SAFE_PERCENT
|
||||
int "Stack usage safe precent"
|
||||
int "Stack usage safe percent"
|
||||
default 0
|
||||
range 0 100
|
||||
depends on STACK_COLORATION
|
||||
---help---
|
||||
Stack usage precent = up_check_tcbstack() * 100 / tcb->adj_stack_size,
|
||||
this should lower then STACK_USAGE_SAFE_PERCENT.
|
||||
Idle thread will timely check stack usage when this macro value > 0.
|
||||
Stack usage percent = up_check_tcbstack() * 100 / tcb->adj_stack_size,
|
||||
this should be lower than STACK_USAGE_SAFE_PERCENT.
|
||||
|
||||
Idle thread will periodically check stack usage when this macro
|
||||
value > 0.
|
||||
|
||||
N.B. This feature should not be used in production code.
|
||||
|
||||
|
||||
@@ -854,6 +854,39 @@ arch/arm/src/armv8-m/arm_exception.S
|
||||
|
||||
arch/arm/src/armv7-m/etm.h
|
||||
arch/arm/src/armv8-m/etm.h
|
||||
arch/arm/src/efm32/efm32_flash.c
|
||||
arch/arm/src/efm32/hardware/efm32_acmp.h
|
||||
arch/arm/src/efm32/hardware/efm32_adc.h
|
||||
arch/arm/src/efm32/hardware/efm32_aes.h
|
||||
arch/arm/src/efm32/hardware/efm32_burtc.h
|
||||
arch/arm/src/efm32/hardware/efm32_calibrate.h
|
||||
arch/arm/src/efm32/hardware/efm32_cmu.h
|
||||
arch/arm/src/efm32/hardware/efm32_dac.h
|
||||
arch/arm/src/efm32/hardware/efm32_devinfo.h
|
||||
arch/arm/src/efm32/hardware/efm32_dma.h
|
||||
arch/arm/src/efm32/hardware/efm32_emu.h
|
||||
arch/arm/src/efm32/hardware/efm32_flash.h
|
||||
arch/arm/src/efm32/hardware/efm32gg_memorymap.h
|
||||
arch/arm/src/efm32/hardware/efm32g_memorymap.h
|
||||
arch/arm/src/efm32/hardware/efm32_gpio.h
|
||||
arch/arm/src/efm32/hardware/efm32_i2c.h
|
||||
arch/arm/src/efm32/hardware/efm32_lcd.h
|
||||
arch/arm/src/efm32/hardware/efm32_lesense.h
|
||||
arch/arm/src/efm32/hardware/efm32_letimer.h
|
||||
arch/arm/src/efm32/hardware/efm32_leuart.h
|
||||
arch/arm/src/efm32/hardware/efm32_memorymap.h
|
||||
arch/arm/src/efm32/hardware/efm32_msc.h
|
||||
arch/arm/src/efm32/hardware/efm32_pcnt.h
|
||||
arch/arm/src/efm32/hardware/efm32_prs.h
|
||||
arch/arm/src/efm32/hardware/efm32_rmu.h
|
||||
arch/arm/src/efm32/hardware/efm32_romtable.h
|
||||
arch/arm/src/efm32/hardware/efm32_rtc.h
|
||||
arch/arm/src/efm32/hardware/efm32tg_memorymap.h
|
||||
arch/arm/src/efm32/hardware/efm32_timer.h
|
||||
arch/arm/src/efm32/hardware/efm32_usart.h
|
||||
arch/arm/src/efm32/hardware/efm32_usb.h
|
||||
arch/arm/src/efm32/hardware/efm32_vcmp.h
|
||||
arch/arm/src/efm32/hardware/efm32_wdog.h
|
||||
==========================
|
||||
|
||||
Copyright 2014 Silicon Laboratories, Inc. http://www.silabs.com</b>
|
||||
@@ -2142,3 +2175,286 @@ arch/arm/src/tiva/cc13xx/cc13x0_rom.h
|
||||
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
fs/nfs
|
||||
============
|
||||
Copyright (C) 2012 Gregory Nutt. All rights reserved.
|
||||
Copyright (C) 2012 Jose Pablo Rojas Vargas. All rights reserved.
|
||||
Author: Jose Pablo Rojas Vargas <jrojas@nx-engineering.com>
|
||||
Gregory Nutt <gnutt@nuttx.org>
|
||||
|
||||
Leveraged from OpenBSD:
|
||||
|
||||
Copyright (c) 1989, 1993
|
||||
The Regents of the University of California. All rights reserved.
|
||||
|
||||
This code is derived from software contributed to Berkeley by
|
||||
Rick Macklem at The University of Guelph.
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
modification, are permitted provided that the following conditions
|
||||
are met:
|
||||
|
||||
1. Redistributions of source code must retain the above copyright
|
||||
notice, this list of conditions and the following disclaimer.
|
||||
2. Redistributions in binary form must reproduce the above copyright
|
||||
notice, this list of conditions and the following disclaimer in the
|
||||
documentation and/or other materials provided with the distribution.
|
||||
4. Neither the name of the University nor the names of its contributors
|
||||
may be used to endorse or promote products derived from this software
|
||||
without specific prior written permission.
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
||||
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
||||
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
||||
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
||||
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
||||
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
||||
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
||||
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
||||
SUCH DAMAGE.
|
||||
|
||||
fs/spiffs
|
||||
=========
|
||||
Copyright (C) 2018 Gregory Nutt. All rights reserved.
|
||||
Author: Gregory Nutt <gnutt@nuttx.org>
|
||||
|
||||
This is a port of version 0.3.7 of SPIFFS by Peter Andersion. That
|
||||
version was originally released under the MIT license but is here re-
|
||||
released under the NuttX BSD license.
|
||||
|
||||
Copyright (c) 2013-2017 Peter Andersson (pelleplutt1976@gmail.com)
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
modification, are permitted provided that the following conditions
|
||||
are met:
|
||||
|
||||
1. Redistributions of source code must retain the above copyright
|
||||
notice, this list of conditions and the following disclaimer.
|
||||
2. Redistributions in binary form must reproduce the above copyright
|
||||
notice, this list of conditions and the following disclaimer in
|
||||
the documentation and/or other materials provided with the
|
||||
distribution.
|
||||
3. Neither the name NuttX nor the names of its contributors may be
|
||||
used to endorse or promote products derived from this software
|
||||
without specific prior written permission.
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
drivers/mtd/hamming.c
|
||||
drivers/mtd/mtd_modeltab.c
|
||||
drivers/mtd/mtd_nand.c
|
||||
drivers/mtd/mtd_nandecc.c
|
||||
drivers/mtd/mtd_nandmodel.c
|
||||
drivers/mtd/mtd_nandscheme.c
|
||||
drivers/mtd/mtd_onfi.c
|
||||
include/nuttx/mtd/hamming.h
|
||||
include/nuttx/mtd/nand.h
|
||||
include/nuttx/mtd/nand_config.h
|
||||
include/nuttx/mtd/nand_ecc.h
|
||||
include/nuttx/mtd/nand_model.h
|
||||
include/nuttx/mtd/nand_raw.h
|
||||
include/nuttx/mtd/nand_scheme.h
|
||||
include/nuttx/mtd/onfi.h
|
||||
========================
|
||||
|
||||
Copyright (c) 2011, Atmel Corporation
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
modification, are permitted provided that the following conditions
|
||||
are met:
|
||||
|
||||
1. Redistributions of source code must retain the above copyright
|
||||
notice, this list of conditions and the following disclaimer.
|
||||
2. Redistributions in binary form must reproduce the above copyright
|
||||
notice, this list of conditions and the following disclaimer in
|
||||
the documentation and/or other materials provided with the
|
||||
distribution.
|
||||
3. Neither the names NuttX nor Atmel nor the names of its contributors
|
||||
may be used to endorse or promote products derived from this software
|
||||
without specific prior written permission.
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
|
||||
drivers/usbhost/hid_parser.c
|
||||
=============================
|
||||
Copyright (C) 2011 Gregory Nutt. All rights reserved.
|
||||
|
||||
Adapted from the LUFA Library:
|
||||
|
||||
Copyright 2011 Dean Camera (dean [at] fourwalledcubicle [dot] com)
|
||||
dean [at] fourwalledcubicle [dot] com, www.lufa-lib.org
|
||||
|
||||
Permission to use, copy, modify, distribute, and sell this
|
||||
software and its documentation for any purpose is hereby granted
|
||||
without fee, provided that the above copyright notice appear in
|
||||
all copies and that both that the copyright notice and this
|
||||
permission notice and warranty disclaimer appear in supporting
|
||||
documentation, and that the name of the author not be used in
|
||||
advertising or publicity pertaining to distribution of the
|
||||
software without specific, written prior permission.
|
||||
|
||||
The author disclaim all warranties with regard to this
|
||||
software, including all implied warranties of merchantability
|
||||
and fitness. In no event shall the author be liable for any
|
||||
special, indirect or consequential damages or any damages
|
||||
whatsoever resulting from loss of use, data or profits, whether
|
||||
in an action of contract, negligence or other tortious action,
|
||||
arising out of or in connection with the use or performance of
|
||||
this software.
|
||||
|
||||
libs/libc/machine/arm/armv8-m
|
||||
=============================
|
||||
Copyright (c) 2011, 2012 ARM Ltd. All rights reserved.
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
modification, are permitted provided that the following conditions
|
||||
are met:
|
||||
|
||||
1. Redistributions of source code must retain the above copyright
|
||||
notice, this list of conditions and the following disclaimer.
|
||||
2. Redistributions in binary form must reproduce the above copyright
|
||||
notice, this list of conditions and the following disclaimer in the
|
||||
documentation and/or other materials provided with the distribution.
|
||||
3. The name of the company may not be used to endorse or promote
|
||||
products derived from this software without specific prior written
|
||||
permission.
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY ARM LTD ``AS IS'' AND ANY EXPRESS OR IMPLIED
|
||||
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
||||
IN NO EVENT SHALL ARM LTD BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
||||
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
|
||||
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
|
||||
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
|
||||
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
|
||||
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
|
||||
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
libs/libc/math/__cos.c
|
||||
libs/libc/math/__sin.c
|
||||
libs/libc/math/lib_lgamma.c
|
||||
libs/libc/math/lib_copysignf.c
|
||||
======================
|
||||
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
|
||||
|
||||
Developed at SunSoft, a Sun Microsystems, Inc. business.
|
||||
Permission to use, copy, modify, and distribute this
|
||||
software is freely granted, provided that this notice
|
||||
is preserved.
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
modification, are permitted provided that the following conditions
|
||||
are met:
|
||||
|
||||
1. Redistributions of source code must retain the above copyright
|
||||
notice, this list of conditions and the following disclaimer.
|
||||
2. Redistributions in binary form must reproduce the above copyright
|
||||
notice, this list of conditions and the following disclaimer in
|
||||
the documentation and/or other materials provided with the
|
||||
distribution.
|
||||
3. Neither the name NuttX nor the names of its contributors may be
|
||||
used to endorse or promote products derived from this software
|
||||
without specific prior written permission.
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
drivers/wireless/bluetooth/bt_uart.c
|
||||
drivers/wireless/bluetooth/bt_uart.h
|
||||
wireless/bluetooth
|
||||
===========================
|
||||
Copyright (c) 2016, Intel Corporation
|
||||
All rights reserved.
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
modification, are permitted provided that the following conditions are
|
||||
met:
|
||||
|
||||
1. Redistributions of source code must retain the above copyright notice,
|
||||
this list of conditions and the following disclaimer.
|
||||
|
||||
2. Redistributions in binary form must reproduce the above copyright
|
||||
notice, this list of conditions and the following disclaimer in the
|
||||
documentation and/or other materials provided with the distribution.
|
||||
|
||||
3. Neither the name of the copyright holder nor the names of its
|
||||
contributors may be used to endorse or promote products derived from
|
||||
this software without specific prior written permission.
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
|
||||
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
||||
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
|
||||
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
|
||||
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
|
||||
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS
|
||||
; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
|
||||
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
|
||||
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
|
||||
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
drivers/wireless/spirit/
|
||||
=======================
|
||||
Copyright(c) 2015 STMicroelectronics
|
||||
Author: VMA division - AMS
|
||||
Version 3.2.2 08-July-2015
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
modification, are permitted provided that the following conditions
|
||||
are met:
|
||||
|
||||
1. Redistributions of source code must retain the above copyright
|
||||
notice, this list of conditions and the following disclaimer.
|
||||
2. Redistributions in binary form must reproduce the above copyright
|
||||
notice, this list of conditions and the following disclaimer in the
|
||||
documentation and/or other materials provided with the distribution.
|
||||
3. Neither the name of STMicroelectronics nor the names of its
|
||||
contributors may be used to endorse or promote products derived from
|
||||
this software without specific prior written permission.
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
|
||||
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
||||
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
|
||||
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
|
||||
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
|
||||
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
|
||||
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
|
||||
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
|
||||
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
|
||||
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
@@ -2284,6 +2284,8 @@ Below is a guide to the available README files in the NuttX source tree:
|
||||
| | | `- ubw32/
|
||||
| | | `- README.txt
|
||||
| | `-pic32mz/
|
||||
| | |- chipkit-wifire/
|
||||
| | | `- README.txt
|
||||
| | |- flipnclick-pic32mz/
|
||||
| | | `- README.txt
|
||||
| | `- pic32mz-starterkit/
|
||||
|
||||
@@ -348,6 +348,10 @@ config ARCH_HAVE_BACKTRACE
|
||||
bool
|
||||
default n
|
||||
|
||||
config ARCH_HAVE_BOOTLOADER
|
||||
bool
|
||||
default n
|
||||
|
||||
config ARCH_FPU
|
||||
bool "FPU support"
|
||||
default y
|
||||
|
||||
@@ -21,54 +21,6 @@
|
||||
#ifndef __ARCH_ARM_INCLUDE_CXD56XX_CISIF_H
|
||||
#define __ARCH_ARM_INCLUDE_CXD56XX_CISIF_H
|
||||
|
||||
/****************************************************************************
|
||||
* Public Types
|
||||
****************************************************************************/
|
||||
|
||||
typedef void (*notify_callback_t)(uint8_t code,
|
||||
uint32_t size,
|
||||
uint32_t addr);
|
||||
typedef void (*comp_callback_t)(uint8_t code,
|
||||
uint32_t size,
|
||||
uint32_t addr);
|
||||
|
||||
struct cisif_init_yuv_param_s
|
||||
{
|
||||
uint16_t hsize;
|
||||
uint16_t vsize;
|
||||
uint32_t notify_size;
|
||||
notify_callback_t notify_func;
|
||||
};
|
||||
|
||||
typedef struct cisif_init_yuv_param_s cisif_init_yuv_param_t;
|
||||
|
||||
struct cisif_init_jpeg_param_s
|
||||
{
|
||||
uint32_t notify_size;
|
||||
notify_callback_t notify_func;
|
||||
};
|
||||
|
||||
typedef struct cisif_init_jpeg_param_s cisif_init_jpeg_param_t;
|
||||
|
||||
struct cisif_sarea_s
|
||||
{
|
||||
uint8_t *strg_addr;
|
||||
uint32_t strg_size;
|
||||
};
|
||||
|
||||
typedef struct cisif_sarea_s cisif_sarea_t;
|
||||
|
||||
struct cisif_param_s
|
||||
{
|
||||
uint32_t format;
|
||||
cisif_init_yuv_param_t yuv_param;
|
||||
cisif_init_jpeg_param_t jpg_param;
|
||||
cisif_sarea_t sarea;
|
||||
comp_callback_t comp_func;
|
||||
};
|
||||
|
||||
typedef struct cisif_param_s cisif_param_t;
|
||||
|
||||
#ifndef __ASSEMBLY__
|
||||
|
||||
#undef EXTERN
|
||||
@@ -84,11 +36,7 @@ extern "C"
|
||||
* Public Function Prototypes
|
||||
****************************************************************************/
|
||||
|
||||
int cxd56_cisifinit(void);
|
||||
int cxd56_cisiffinalize(void);
|
||||
int cxd56_cisifstartcapture(cisif_param_t *param, cisif_sarea_t *sarea);
|
||||
int cxd56_cisifstopcapture(void);
|
||||
int cxd56_cisifsetdmabuf(cisif_sarea_t *sarea);
|
||||
int cxd56_cisif_initialize(void);
|
||||
|
||||
#undef EXTERN
|
||||
#if defined(__cplusplus)
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
############################################################################
|
||||
|
||||
include $(TOPDIR)/Make.defs
|
||||
-include chip/Make.defs
|
||||
include chip/Make.defs
|
||||
|
||||
ifeq ($(CONFIG_ARCH_ARMV7A),y) # ARMv7-A
|
||||
ARCH_SUBDIR = armv7-a
|
||||
@@ -56,7 +56,7 @@ endif
|
||||
# Additional rules for system call wrapper
|
||||
|
||||
ifeq ($(CONFIG_SCHED_INSTRUMENTATION_SYSCALL),y)
|
||||
EXTRALINKCMDS += -Wl,@$(TOPDIR)/syscall/syscall_wraps.ldcmd
|
||||
EXTRALINKCMDS += @$(TOPDIR)/syscall/syscall_wraps.ldcmd
|
||||
endif
|
||||
|
||||
# The "head" object
|
||||
@@ -93,8 +93,8 @@ LDFLAGS += $(ARCHSCRIPT) $(EXTRALINKCMDS)
|
||||
|
||||
# Override in Make.defs if linker is not 'ld'
|
||||
|
||||
LDSTARTGROUP ?= -Wl,--start-group
|
||||
LDENDGROUP ?= -Wl,--end-group
|
||||
LDSTARTGROUP ?= --start-group
|
||||
LDENDGROUP ?= --end-group
|
||||
|
||||
BOARDMAKE = $(if $(wildcard board$(DELIM)Makefile),y,)
|
||||
|
||||
@@ -153,7 +153,7 @@ board$(DELIM)libboard$(LIBEXT):
|
||||
|
||||
nuttx$(EXEEXT): $(HEAD_OBJ) board$(DELIM)libboard$(LIBEXT)
|
||||
$(Q) echo "LD: nuttx"
|
||||
$(Q) $(LD) -Wl,--entry=__start $(LDFLAGS) $(LIBPATHS) $(EXTRA_LIBPATHS) \
|
||||
$(Q) $(LD) --entry=__start $(LDFLAGS) $(LIBPATHS) $(EXTRA_LIBPATHS) \
|
||||
-o $(NUTTX) $(filter-out board/libboard$(LIBEXT), $^) $(EXTRA_OBJS) \
|
||||
$(LDSTARTGROUP) $(LDLIBS) $(EXTRA_LIBS) $(LDENDGROUP)
|
||||
ifneq ($(CONFIG_WINDOWS_NATIVE),y)
|
||||
@@ -193,8 +193,6 @@ depend: .depend
|
||||
|
||||
context::
|
||||
|
||||
clean_context::
|
||||
|
||||
clean:
|
||||
ifeq ($(BOARDMAKE),y)
|
||||
$(Q) $(MAKE) -C board clean
|
||||
@@ -206,7 +204,7 @@ ifneq ($(EXTRADELFILE),)
|
||||
endif
|
||||
$(call CLEAN)
|
||||
|
||||
distclean: clean
|
||||
distclean:: clean
|
||||
ifeq ($(BOARDMAKE),y)
|
||||
$(Q) $(MAKE) -C board distclean
|
||||
endif
|
||||
|
||||
@@ -88,7 +88,7 @@ endif
|
||||
CC = $(CROSSDEV)gcc
|
||||
CXX = $(CROSSDEV)g++
|
||||
CPP = $(CROSSDEV)gcc -E -P -x c
|
||||
LD = $(CROSSDEV)gcc
|
||||
LD = $(CROSSDEV)ld
|
||||
STRIP = $(CROSSDEV)strip --strip-unneeded
|
||||
AR = $(CROSSDEV)gcc-ar rcs
|
||||
NM = $(CROSSDEV)gcc-nm
|
||||
|
||||
@@ -51,8 +51,7 @@
|
||||
* 1) The priority of the currently running task drops and the next
|
||||
* task in the ready to run list has priority.
|
||||
* 2) An idle, ready to run task's priority has been raised above the
|
||||
* the priority of the current, running task and it now has the
|
||||
* priority.
|
||||
* priority of the current, running task and it now has the priority.
|
||||
*
|
||||
* Input Parameters:
|
||||
* tcb: The TCB of the task that has been reprioritized
|
||||
@@ -110,7 +109,6 @@ void up_reprioritize_rtr(struct tcb_s *tcb, uint8_t priority)
|
||||
{
|
||||
/* If we are going to do a context switch, then now is the right
|
||||
* time to add any pending tasks back into the ready-to-run list.
|
||||
* task list now
|
||||
*/
|
||||
|
||||
if (g_pendingtasks.head)
|
||||
|
||||
@@ -80,7 +80,7 @@ endif
|
||||
CC = $(CROSSDEV)gcc
|
||||
CXX = $(CROSSDEV)g++
|
||||
CPP = $(CROSSDEV)gcc -E -P -x c
|
||||
LD = $(CROSSDEV)gcc
|
||||
LD = $(CROSSDEV)ld
|
||||
STRIP = $(CROSSDEV)strip --strip-unneeded
|
||||
AR = $(CROSSDEV)gcc-ar rcs
|
||||
NM = $(CROSSDEV)gcc-nm
|
||||
|
||||
@@ -71,7 +71,7 @@
|
||||
*/
|
||||
|
||||
up_vector_t g_ram_vectors[ARMV6M_VECTAB_SIZE]
|
||||
__attribute__ ((section (".ram_vectors"), aligned (RAMVEC_ALIGN)));
|
||||
locate_data(".ram_vectors") aligned_data(RAMVEC_ALIGN);
|
||||
|
||||
/****************************************************************************
|
||||
* Public Functions
|
||||
|
||||
@@ -50,8 +50,7 @@
|
||||
* 1) The priority of the currently running task drops and the next
|
||||
* task in the ready to run list has priority.
|
||||
* 2) An idle, ready to run task's priority has been raised above the
|
||||
* the priority of the current, running task and it now has the
|
||||
* priority.
|
||||
* priority of the current, running task and it now has the priority.
|
||||
*
|
||||
* Input Parameters:
|
||||
* tcb: The TCB of the task that has been reprioritized
|
||||
@@ -111,7 +110,6 @@ void up_reprioritize_rtr(struct tcb_s *tcb, uint8_t priority)
|
||||
{
|
||||
/* If we are going to do a context switch, then now is the right
|
||||
* time to add any pending tasks back into the ready-to-run list.
|
||||
* task list now
|
||||
*/
|
||||
|
||||
if (g_pendingtasks.head)
|
||||
|
||||
@@ -81,7 +81,7 @@ extern void exception_common(void);
|
||||
* Note that the [ ... ] desginated initialiser is a GCC extension.
|
||||
*/
|
||||
|
||||
unsigned _vectors[] __attribute__((section(".vectors"))) =
|
||||
unsigned _vectors[] locate_data(".vectors") =
|
||||
{
|
||||
/* Initial stack */
|
||||
|
||||
|
||||
@@ -57,7 +57,7 @@
|
||||
*/
|
||||
|
||||
extern up_vector_t g_ram_vectors[ARMV6M_VECTAB_SIZE]
|
||||
__attribute__ ((section (".ram_vectors"), aligned (128)));
|
||||
locate_data(".ram_vectors") aligned_data(128);
|
||||
|
||||
/****************************************************************************
|
||||
* Public Function Prototypes
|
||||
|
||||
@@ -106,7 +106,7 @@ endif
|
||||
CC = $(CROSSDEV)gcc
|
||||
CXX = $(CROSSDEV)g++
|
||||
CPP = $(CROSSDEV)gcc -E -P -x c
|
||||
LD = $(CROSSDEV)gcc
|
||||
LD = $(CROSSDEV)ld
|
||||
STRIP = $(CROSSDEV)strip --strip-unneeded
|
||||
AR = $(CROSSDEV)gcc-ar rcs
|
||||
NM = $(CROSSDEV)gcc-nm
|
||||
|
||||
@@ -130,7 +130,7 @@ int up_cpu_paused(int cpu)
|
||||
|
||||
arm_savestate(tcb->xcp.regs);
|
||||
|
||||
/* Release the g_cpu_puased spinlock to synchronize with the
|
||||
/* Release the g_cpu_paused spinlock to synchronize with the
|
||||
* requesting CPU.
|
||||
*/
|
||||
|
||||
|
||||
@@ -123,14 +123,14 @@ int arm_start_handler(int irq, FAR void *context, FAR void *arg)
|
||||
* Name: up_cpu_start
|
||||
*
|
||||
* Description:
|
||||
* In an SMP configution, only one CPU is initially active (CPU 0). System
|
||||
* initialization occurs on that single thread. At the completion of the
|
||||
* initialization of the OS, just before beginning normal multitasking,
|
||||
* In an SMP configuration, only one CPU is initially active (CPU 0).
|
||||
* System initialization occurs on that single thread. At the completion of
|
||||
* the initialization of the OS, just before beginning normal multitasking,
|
||||
* the additional CPUs would be started by calling this function.
|
||||
*
|
||||
* Each CPU is provided the entry point to is IDLE task when started. A
|
||||
* Each CPU is provided the entry point to its IDLE task when started. A
|
||||
* TCB for each CPU's IDLE task has been initialized and placed in the
|
||||
* CPU's g_assignedtasks[cpu] list. Not stack has been allocated or
|
||||
* CPU's g_assignedtasks[cpu] list. No stack has been allocated or
|
||||
* initialized.
|
||||
*
|
||||
* The OS initialization logic calls this function repeatedly until each
|
||||
@@ -138,8 +138,8 @@ int arm_start_handler(int irq, FAR void *context, FAR void *arg)
|
||||
*
|
||||
* Input Parameters:
|
||||
* cpu - The index of the CPU being started. This will be a numeric
|
||||
* value in the range of from one to (CONFIG_SMP_NCPUS-1). (CPU
|
||||
* 0 is already active)
|
||||
* value in the range of one to (CONFIG_SMP_NCPUS-1).
|
||||
* (CPU 0 is already active)
|
||||
*
|
||||
* Returned Value:
|
||||
* Zero on success; a negated errno value on failure.
|
||||
|
||||
@@ -51,8 +51,7 @@
|
||||
* 1) The priority of the currently running task drops and the next
|
||||
* task in the ready to run list has priority.
|
||||
* 2) An idle, ready to run task's priority has been raised above the
|
||||
* the priority of the current, running task and it now has the
|
||||
* priority.
|
||||
* priority of the current, running task and it now has the priority.
|
||||
*
|
||||
* Input Parameters:
|
||||
* tcb: The TCB of the task that has been reprioritized
|
||||
@@ -110,7 +109,6 @@ void up_reprioritize_rtr(struct tcb_s *tcb, uint8_t priority)
|
||||
{
|
||||
/* If we are going to do a context switch, then now is the right
|
||||
* time to add any pending tasks back into the ready-to-run list.
|
||||
* task list now
|
||||
*/
|
||||
|
||||
if (g_pendingtasks.head)
|
||||
|
||||
@@ -60,14 +60,14 @@
|
||||
* This function must be provided via the architecture-specific logic.
|
||||
*
|
||||
* Input Parameters:
|
||||
* lock - The address of spinlock object.
|
||||
* lock - A reference to the spinlock object.
|
||||
*
|
||||
* Returned Value:
|
||||
* The spinlock is always locked upon return. The value of previous value
|
||||
* of the spinlock variable is returned, either SP_LOCKED if the spinlock
|
||||
* as previously locked (meaning that the test-and-set operation failed to
|
||||
* The spinlock is always locked upon return. The previous value of the
|
||||
* spinlock variable is returned, either SP_LOCKED if the spinlock was
|
||||
* previously locked (meaning that the test-and-set operation failed to
|
||||
* obtain the lock) or SP_UNLOCKED if the spinlock was previously unlocked
|
||||
* (meaning that we successfully obtained the lock)
|
||||
* (meaning that we successfully obtained the lock).
|
||||
*
|
||||
****************************************************************************/
|
||||
|
||||
|
||||
@@ -63,7 +63,7 @@ config ARMV7M_USEBASEPRI
|
||||
WARNING: If CONFIG_ARCH_HIPRI_INTERRUPT is selected, then you
|
||||
MUST select CONFIG_ARMV7M_USEBASEPRI. The Kconfig dependencies
|
||||
here will permit to select an invalid configuration because it
|
||||
cannot enforce that requirement. If you create this invalild
|
||||
cannot enforce that requirement. If you create this invalid
|
||||
configuration, you will encounter some problems that may be
|
||||
very difficult to debug.
|
||||
|
||||
|
||||
@@ -80,8 +80,6 @@ endif
|
||||
ifeq ($(CONFIG_ARCH_CORTEXM4),y)
|
||||
TOOLCHAIN_ARM7EM := y
|
||||
TOOLCHAIN_MCPU := -mcpu=cortex-m4
|
||||
TOOLCHAIN_MTUNE := -mtune=cortex-m4
|
||||
TOOLCHAIN_MARCH := -march=armv7e-m
|
||||
ifeq ($(CONFIG_ARCH_FPU),y)
|
||||
TOOLCHAIN_MFLOAT := -mfpu=fpv4-sp-d16 -mfloat-abi=hard
|
||||
else
|
||||
@@ -90,8 +88,6 @@ ifeq ($(CONFIG_ARCH_CORTEXM4),y)
|
||||
else ifeq ($(CONFIG_ARCH_CORTEXM7),y)
|
||||
TOOLCHAIN_ARM7EM := y
|
||||
TOOLCHAIN_MCPU := -mcpu=cortex-m7
|
||||
TOOLCHAIN_MTUNE := -mtune=cortex-m7
|
||||
TOOLCHAIN_MARCH := -march=armv7e-m
|
||||
ifeq ($(CONFIG_ARCH_FPU),y)
|
||||
ifeq ($(CONFIG_ARCH_DPFPU),y)
|
||||
TOOLCHAIN_MFLOAT := -mfpu=fpv5-d16 -mfloat-abi=hard
|
||||
@@ -104,8 +100,6 @@ else ifeq ($(CONFIG_ARCH_CORTEXM7),y)
|
||||
else # ifeq ($(CONFIG_ARCH_CORTEXM3),y)
|
||||
TOOLCHAIN_ARM7EM := n
|
||||
TOOLCHAIN_MCPU := -mcpu=cortex-m3
|
||||
TOOLCHAIN_MTUNE := -mtune=cortex-m3
|
||||
TOOLCHAIN_MARCH := -march=armv7-m
|
||||
TOOLCHAIN_MFLOAT := -mfloat-abi=soft
|
||||
endif
|
||||
|
||||
@@ -142,7 +136,7 @@ else
|
||||
CPP = $(CROSSDEV)gcc -E -P -x c
|
||||
endif
|
||||
|
||||
LD = $(CROSSDEV)gcc
|
||||
LD = $(CROSSDEV)ld
|
||||
STRIP = $(CROSSDEV)strip --strip-unneeded
|
||||
AR = $(CROSSDEV)gcc-ar rcs
|
||||
NM = $(CROSSDEV)gcc-nm
|
||||
|
||||
@@ -95,12 +95,12 @@
|
||||
*
|
||||
* REVISIT: Can this alignment requirement vary from core-to-core? Yes, it
|
||||
* depends on the number of vectors supported by the MCU. The safest thing
|
||||
* to do is to put the vector table at the beginning of RAM in order toforce
|
||||
* to do is to put the vector table at the beginning of RAM in order to force
|
||||
* the highest alignment possible.
|
||||
*/
|
||||
|
||||
up_vector_t g_ram_vectors[ARMV7M_VECTAB_SIZE]
|
||||
__attribute__ ((section (".ram_vectors"), aligned (RAMVEC_ALIGN)));
|
||||
locate_data(".ram_vectors") aligned_data(RAMVEC_ALIGN);
|
||||
|
||||
/****************************************************************************
|
||||
* Public Functions
|
||||
|
||||
@@ -50,8 +50,7 @@
|
||||
* 1) The priority of the currently running task drops and the next
|
||||
* task in the ready to run list has priority.
|
||||
* 2) An idle, ready to run task's priority has been raised above the
|
||||
* the priority of the current, running task and it now has the
|
||||
* priority.
|
||||
* priority of the current, running task and it now has the priority.
|
||||
*
|
||||
* Input Parameters:
|
||||
* tcb: The TCB of the task that has been reprioritized
|
||||
@@ -111,7 +110,6 @@ void up_reprioritize_rtr(struct tcb_s *tcb, uint8_t priority)
|
||||
{
|
||||
/* If we are going to do a context switch, then now is the right
|
||||
* time to add any pending tasks back into the ready-to-run list.
|
||||
* task list now
|
||||
*/
|
||||
|
||||
if (g_pendingtasks.head)
|
||||
|
||||
@@ -55,12 +55,9 @@
|
||||
* Private Functions
|
||||
****************************************************************************/
|
||||
|
||||
void __cyg_profile_func_enter(void *func, void *caller)
|
||||
__attribute__((naked, no_instrument_function));
|
||||
void __cyg_profile_func_exit(void *func, void *caller)
|
||||
__attribute__((naked, no_instrument_function));
|
||||
void __stack_overflow_trap(void)
|
||||
__attribute__((naked, no_instrument_function));
|
||||
void __cyg_profile_func_enter(void *func, void *caller) naked_function;
|
||||
void __cyg_profile_func_exit(void *func, void *caller) naked_function;
|
||||
void __stack_overflow_trap(void) naked_function;
|
||||
|
||||
/****************************************************************************
|
||||
* Name: __stack_overflow_trap
|
||||
|
||||
@@ -76,7 +76,7 @@ extern void exception_common(void);
|
||||
* Note that the [ ... ] designated initializer is a GCC extension.
|
||||
*/
|
||||
|
||||
unsigned _vectors[] __attribute__((section(".vectors"))) =
|
||||
unsigned _vectors[] locate_data(".vectors") =
|
||||
{
|
||||
/* Initial stack */
|
||||
|
||||
|
||||
@@ -62,14 +62,14 @@
|
||||
* This function must be provided via the architecture-specific logic.
|
||||
*
|
||||
* Input Parameters:
|
||||
* lock - The address of spinlock object.
|
||||
* lock - A reference to the spinlock object.
|
||||
*
|
||||
* Returned Value:
|
||||
* The spinlock is always locked upon return. The value of previous value
|
||||
* of the spinlock variable is returned, either SP_LOCKED if the spinlock
|
||||
* as previously locked (meaning that the test-and-set operation failed to
|
||||
* The spinlock is always locked upon return. The previous value of the
|
||||
* spinlock variable is returned, either SP_LOCKED if the spinlock was
|
||||
* previously locked (meaning that the test-and-set operation failed to
|
||||
* obtain the lock) or SP_UNLOCKED if the spinlock was previously unlocked
|
||||
* (meaning that we successfully obtained the lock)
|
||||
* (meaning that we successfully obtained the lock).
|
||||
*
|
||||
****************************************************************************/
|
||||
|
||||
|
||||
@@ -62,11 +62,11 @@
|
||||
* lock - The address of spinlock object.
|
||||
*
|
||||
* Returned Value:
|
||||
* The spinlock is always locked upon return. The value of previous value
|
||||
* of the spinlock variable is returned, either SP_LOCKED if the spinlock
|
||||
* as previously locked (meaning that the test-and-set operation failed to
|
||||
* The spinlock is always locked upon return. The previous value of the
|
||||
* spinlock variable is returned, either SP_LOCKED if the spinlock was
|
||||
* previously locked (meaning that the test-and-set operation failed to
|
||||
* obtain the lock) or SP_UNLOCKED if the spinlock was previously unlocked
|
||||
* (meaning that we successfully obtained the lock)
|
||||
* (meaning that we successfully obtained the lock).
|
||||
*
|
||||
****************************************************************************/
|
||||
|
||||
|
||||
@@ -57,12 +57,12 @@
|
||||
*
|
||||
* REVISIT: Can this alignment requirement vary from core-to-core? Yes, it
|
||||
* depends on the number of vectors supported by the MCU. The safest thing
|
||||
* to do is to put the vector table at the beginning of RAM in order toforce
|
||||
* to do is to put the vector table at the beginning of RAM in order to force
|
||||
* the highest alignment possible.
|
||||
*/
|
||||
|
||||
extern up_vector_t g_ram_vectors[ARMV7M_VECTAB_SIZE]
|
||||
__attribute__ ((section (".ram_vectors"), aligned (128)));
|
||||
locate_data(".ram_vectors") aligned_data(128);
|
||||
|
||||
/****************************************************************************
|
||||
* Public Function Prototypes
|
||||
|
||||
@@ -88,7 +88,7 @@ endif
|
||||
CC = $(CROSSDEV)gcc
|
||||
CXX = $(CROSSDEV)g++
|
||||
CPP = $(CROSSDEV)gcc -E -P -x c
|
||||
LD = $(CROSSDEV)gcc
|
||||
LD = $(CROSSDEV)ld
|
||||
STRIP = $(CROSSDEV)strip --strip-unneeded
|
||||
AR = $(CROSSDEV)gcc-ar rcs
|
||||
NM = $(CROSSDEV)gcc-nm
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user