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

Merge remote-tracking branch 'remotes/mirtos/dev-nuttx-10.1-20210927' into dev

Browse Source 
Signed-off-by: liuhaitao <liuhaitao@xiaomi.com>
Change-Id: If5a0166dbc7c9a595db9b7758cbacaf6af278d5d
This commit is contained in:
liuhaitao
2021-10-18 22:12:06 +08:00
parent 5e47a24aba 5498fbef58
commit 8637e2a550
1970 changed files with 59096 additions and 31178 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/actions/ci-container/action.yaml
+1 -1
View File
@@ -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"
.github/workflows/build.yml
+2 -2
View File
@@ -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
.github/workflows/docker_linux.yml
+2 -2
View File
@@ -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: |
AUTHORS
+10
View File
@@ -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:
Documentation/faq/index.rst
+47
View File
@@ -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
=======
Documentation/guides/image/interface.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 79 KiB

Documentation/guides/image/menu.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

Documentation/guides/image/template.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

Documentation/guides/index.rst
+1
View File
@@ -11,3 +11,4 @@ Guides
drivers.rst
tasktrace.rst
cpp_cmake.rst
pysimcoder.rst
Documentation/guides/pysimcoder.rst
+158
View File
@@ -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
Documentation/index.rst
+1 -1
View File
@@ -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
Documentation/platforms/arm/imxrt/boards/teensy-4.x/index.rst
+14
View File
@@ -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
-------
Documentation/platforms/arm/imxrt/index.rst
+15
View File
@@ -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
==================
Documentation/platforms/risc-v/bl602/index.rst
+208 -6
View File
@@ -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
========== ======= =====
Documentation/platforms/risc-v/esp32c3/index.rst
+8 -8
View File
@@ -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
========== ======= =====
Documentation/platforms/risc-v/mpfs/index.rst
+3 -3
View File
@@ -59,13 +59,13 @@ GPIO Yes
MMUART Yes Uart mode only
SPI Yes
I2C Yes
Timers No
eMMC SD/SDIO Yes eMMC not fully tested
Timers No
Watchdog No
RTC No
CAN No
eNVM No
USB No
eMMC SD/SDIO No
USB No
============ ======= =====
Documentation/platforms/sim/index.rst
+11
View File
@@ -0,0 +1,11 @@
==========
Simulators
==========
The following Simulator/Emulators are supported:
.. toctree::
:maxdepth: 2
:glob:
*/*
Documentation/platforms/sim/sim/index.rst
+56
View File
@@ -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>
Documentation/platforms/xtensa/esp32/boards/esp32-devkitc/index.rst
+46 -9
View File
@@ -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.
Documentation/platforms/xtensa/esp32/boards/esp32-wrover-kit/index.rst
+1 -1
View File
@@ -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.
Documentation/platforms/xtensa/esp32/index.rst
+31 -374
View File
@@ -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
================
Documentation/quickstart/install.rst
+5 -5
View File
@@ -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
Kconfig
+72 -5
View File
@@ -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.
LICENSE
+316
View File
@@ -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.
README.md
+2
View File
@@ -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/
arch/Kconfig
+4
View File
@@ -356,6 +356,10 @@ config ARCH_HAVE_BACKTRACE
bool
default n
config ARCH_HAVE_BOOTLOADER
bool
default n
config ARCH_FPU
bool "FPU support"
default y
arch/arm/include/cxd56xx/cisif.h
+1 -53
View File
@@ -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)
arch/arm/src/Makefile
+6 -8
View File
@@ -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
arch/arm/src/arm/Toolchain.defs
+1 -1
View File
@@ -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
arch/arm/src/arm/arm_reprioritizertr.c
+1 -3
View File
@@ -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)
arch/arm/src/armv6-m/Toolchain.defs
+1 -1
View File
@@ -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
arch/arm/src/armv6-m/arm_ramvec_initialize.c
+1 -1
View File
@@ -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
arch/arm/src/armv6-m/arm_reprioritizertr.c
+1 -3
View File
@@ -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)
arch/arm/src/armv6-m/arm_vectors.c
+1 -1
View File
@@ -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 */
arch/arm/src/armv6-m/ram_vectors.h
+1 -1
View File
@@ -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
arch/arm/src/armv7-a/Toolchain.defs
+1 -1
View File
@@ -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
arch/arm/src/armv7-a/arm_cpupause.c
+1 -1
View File
@@ -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.
*/
arch/arm/src/armv7-a/arm_cpustart.c
+7 -7
View File
@@ -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.
arch/arm/src/armv7-a/arm_reprioritizertr.c
+1 -3
View File
@@ -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)
arch/arm/src/armv7-a/arm_testset.S
+5 -5
View File
@@ -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).
*
****************************************************************************/
arch/arm/src/armv7-a/svcall.h
+8
View File
@@ -29,6 +29,14 @@
#include <syscall.h>
/* SYS call 2:
*
* void arm_switchcontext(uint32_t *saveregs, uint32_t *restoreregs);
*/
#define SYS_switch_context (2)
#ifdef CONFIG_LIB_SYSCALL
/****************************************************************************
arch/arm/src/armv7-m/Kconfig
+1 -1
View File
@@ -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.
arch/arm/src/armv7-m/Toolchain.defs
+1 -1
View File
@@ -136,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
arch/arm/src/armv7-m/arm_ramvec_initialize.c
+2 -2
View File
@@ -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
arch/arm/src/armv7-m/arm_reprioritizertr.c
+1 -3
View File
@@ -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)
arch/arm/src/armv7-m/arm_stackcheck.c
+3 -6
View File
@@ -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
arch/arm/src/armv7-m/arm_vectors.c
+1 -1
View File
@@ -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 */
arch/arm/src/armv7-m/gnu/arm_testset.S
+5 -5
View File
@@ -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).
*
****************************************************************************/
arch/arm/src/armv7-m/iar/arm_testset.S
+4 -4
View File
@@ -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).
*
****************************************************************************/
arch/arm/src/armv7-m/ram_vectors.h
+2 -2
View File
@@ -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

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