Documentation: Fix typos
I used codespell to find typos in the documentation. Signed-off-by: Alan C. Assis <acassis@gmail.com>
This commit is contained in:
Alan Carvalho de Assis
Xiang Xiao
parent
3fd3612e4c
commit
468e9fcde5
@ -8,7 +8,7 @@
|
||||
Description
|
||||
~~~~~~~~~~~
|
||||
|
||||
MCUboot Swap Image is an application to demostrate firmware upgrade using
|
||||
MCUboot Swap Image is an application to demonstrate firmware upgrade using
|
||||
internal flash memory. It simulate MCUboot API steps to switch between two
|
||||
valid images.
|
||||
|
||||
@ -19,7 +19,7 @@ signed. Consult your board documentation page to get instructions how to do it.
|
||||
How to build and flash
|
||||
......................
|
||||
|
||||
First step is build your board configuraton using ``mcuboot-loader`` as target.
|
||||
First step is build your board configuration using ``mcuboot-loader`` as target.
|
||||
That create the bootloader itself. The ``nuttx.bin`` must be flash as usual.
|
||||
|
||||
After that, clean up environment and set ``mcuboot-swap-test`` as target. The
|
||||
@ -73,7 +73,7 @@ step that must be executed if you ran ``imgtool.py`` without optional parameter
|
||||
Application Image successfully confirmed!
|
||||
nsh>
|
||||
|
||||
Third step (let's reboot and see whats happen)::
|
||||
Third step (let's reboot and see what's happen)::
|
||||
|
||||
nsh> reboot
|
||||
*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
|
||||
@ -92,7 +92,7 @@ Fourth step (let's switch image)::
|
||||
Image version 2.0.0.0
|
||||
nsh>
|
||||
|
||||
Now, we switched from image version 1.0.0 to image 2.0.0. However, we intentionaly
|
||||
Now, we switched from image version 1.0.0 to image 2.0.0. However, we intentionally
|
||||
will not run ``mcuboot_confirm`` app::
|
||||
|
||||
nsh> reboot
|
||||
|
||||
@ -20,7 +20,7 @@ How do I use this?
|
||||
|
||||
In order to test tcp_ipc_client & tcp_ipc_server together, there are two ways to proceed:
|
||||
|
||||
- Init server manually (command: SERVER &), and after successfull server init, also init client manually (CLIENT 127.0.0.1)
|
||||
- Init server manually (command: SERVER &), and after successful server init, also init client manually (CLIENT 127.0.0.1)
|
||||
- init server automatically after boot using NuttShell start up scripts (check: https://nuttx.apache.org/docs/latest/applications/nsh/installation.html#nuttshell-start-up-scripts )
|
||||
|
||||
Additional info
|
||||
|
||||
@ -22,7 +22,7 @@ How do I use this?
|
||||
|
||||
In order to test client_tcp & server_tcp together, there are two ways to proceed:
|
||||
|
||||
- Init server manually (command: SERVER &), and after successfull server init, also init client manually (CLIENT 127.0.0.1)
|
||||
- Init server manually (command: SERVER &), and after successful server init, also init client manually (CLIENT 127.0.0.1)
|
||||
- init server automatically after boot using NuttShell start up scripts (check: https://nuttx.apache.org/docs/latest/applications/nsh/installation.html#nuttshell-start-up-scripts )
|
||||
|
||||
Additional info
|
||||
|
||||
@ -8,7 +8,7 @@ Crush. It is a 6x6 matrix with blocks (cells) with different colors.
|
||||
Your goal is to move the blocks of the board to unite three or
|
||||
more with the same color.
|
||||
|
||||
Everytime that three of more blocks with the same color match that block
|
||||
Every time that three of more blocks with the same color match that block
|
||||
will blink and it will be removed from the board, leaving more space
|
||||
for movements.
|
||||
|
||||
|
||||
@ -1,3 +1,3 @@
|
||||
============================
|
||||
``iptables`` iptables libary
|
||||
============================
|
||||
=============================
|
||||
``iptables`` iptables library
|
||||
=============================
|
||||
|
||||
@ -64,7 +64,7 @@ notation. In that case, the netmask need not be provided.
|
||||
|
||||
::
|
||||
|
||||
nsh> addroute addroute 11.0.0.0 255.255.255.0 10.0.0.2
|
||||
nsh> addroute 11.0.0.0 255.255.255.0 10.0.0.2
|
||||
|
||||
which is equivalent to
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
Most features of libuv are supported by current port, except SIGPROF relative function (loop_configure).
|
||||
|
||||
Nearly full libuv's test suite avaliable on NuttX, but some known case can't run on sim:
|
||||
Nearly full libuv's test suite available on NuttX, but some known case can't run on sim:
|
||||
|
||||
* ``loop_update_time``
|
||||
* ``idle_starvation``
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
``ymodem`` YMODEM
|
||||
=================
|
||||
|
||||
This is `ymodem protocal <http://pauillac.inria.fr/~doligez/zmodem/ymodem.txt>`_.
|
||||
This is `ymodem protocol <http://pauillac.inria.fr/~doligez/zmodem/ymodem.txt>`_.
|
||||
According to it, the sb rb application is realized, which is used to send files and receive files respectively
|
||||
|
||||
Usage
|
||||
@ -25,8 +25,7 @@ and you need ``sbrb.py`` -k to set the same length as the board. According to my
|
||||
when using -k 32, it can reach 93% of the baud rate,
|
||||
and is fully compatible with the original ymodem protocol.
|
||||
First, you need to add a soft link to sbrb.py, for example ``sudo ln -s /home/<name>/.../<nuttxwork>/apps/system/ymodem/sbrb.py /usr/bin``
|
||||
and then sbrb.py can be configured into minicom.``<Ctrl + a> z o`` then chose ``File transfer protocols`` and
|
||||
crate two option cmd is 'sbrb.py -k 32'. like this
|
||||
and then sbrb.py can be configured into minicom.``<Ctrl + a> z o`` then chose ``File transfer protocols`` and create two option cmd is 'sbrb.py -k 32'. like this
|
||||
|
||||
=========== ============= ==== === ======= ======= =====
|
||||
Name Program Name U/D FullScr IO-Red. Multi
|
||||
|
||||
@ -185,7 +185,7 @@ Subdirectories of ``nuttx/drivers``
|
||||
|
||||
* ``power/`` :doc:`special/power/index`
|
||||
|
||||
Various drivers related to power managament.
|
||||
Various drivers related to power management.
|
||||
|
||||
* ``rc/`` :doc:`character/rc`
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ TXTABLE - A text based partition table stored in last eraseblock
|
||||
#. The 2nd and remaining lines are partition entries(min: one)
|
||||
in format: "%s %zx %zx"(means name, size and offset (byte)(in hex)).
|
||||
#. Size or offset can be default zero(means zero(for 1st entry) or
|
||||
caculate(for others)), and will be caculated by the parser refs to previous
|
||||
calculated(for others)), and will be calculated by the parser refs to previous
|
||||
and next entries.
|
||||
#. The last eraseblock will be registered as pseudo partition named "txtable".
|
||||
If the last eraseblock included by the last real partition, it will be
|
||||
@ -26,7 +26,7 @@ partition table maybe out of sync.
|
||||
And it's easier:
|
||||
|
||||
1. Text format with simple rules(name + size + offset).
|
||||
#. Size or offset can be default(caculated refs to previous
|
||||
#. Size or offset can be default(calculated refs to previous
|
||||
and next entries).
|
||||
#. Support backup table(eg. /etc/txtable.txt in ROMFS)
|
||||
|
||||
@ -99,7 +99,7 @@ More than one not set size or offset
|
||||
|
||||
* Parsed
|
||||
|
||||
| Size of partition[2,3,4,6] and data are caculated, and gap between
|
||||
| Size of partition[2,3,4,6] and data are calculated, and gap between
|
||||
partition7 and data is kept.
|
||||
|
||||
::
|
||||
|
||||
@ -29,7 +29,7 @@ Enable Kconfig
|
||||
CONFIG_BOARD_COREDUMP_COMPRESSION=y /* Default y, enable Coredump compression to
|
||||
reduce the size of the original core image */
|
||||
|
||||
CONFIG_BOARD_COREDUMP_FULL=y /* Default y, save all task informations */
|
||||
CONFIG_BOARD_COREDUMP_FULL=y /* Default y, save all task information */
|
||||
|
||||
2. Run Coredump on nsh (CONFIG_SYSTEM_COREDUMP=y)
|
||||
|
||||
|
||||
@ -23,5 +23,5 @@ How to write a GDB python script
|
||||
Here is an article to introduce, read it to understand the most basic principles of python,
|
||||
`Automate Debugging with GDB Python API <https://interrupt.memfault.com/blog/automate-debugging-with-gdb-python-api>`_.
|
||||
|
||||
For more documentation on gdb pyhton, please refer to the official documentation of gdb
|
||||
`GDB with pyhton <https://interrupt.memfault.com/blog/automate-debugging-with-gdb-python-api>`_.
|
||||
For more documentation on gdb python, please refer to the official documentation of gdb
|
||||
`GDB with python <https://interrupt.memfault.com/blog/automate-debugging-with-gdb-python-api>`_.
|
||||
|
||||
@ -78,7 +78,7 @@ nested interrupt handling. Here is one technical approach to do that:
|
||||
atomic in any case.
|
||||
|
||||
**NOTE 1**: The ARMv7-M could also be configured to use separate MSP and
|
||||
PSP stacks with the interupt processing using the MSP stack and the
|
||||
PSP stacks with the interrupt processing using the MSP stack and the
|
||||
tasks all using the PSP stacks. This is not compatible with certain
|
||||
parts of the existing design and would be more effort, but could result
|
||||
in a better solution.
|
||||
@ -140,7 +140,7 @@ assume that interrupts are enabled.
|
||||
|
||||
/* Current regs non-zero indicates that we are processing an interrupt;
|
||||
* regs holds the state of the interrupted logic; current_regs holds the
|
||||
* state of the interrupted user task. current_regs should, therefor,
|
||||
* state of the interrupted user task. current_regs should, therefore,
|
||||
* only be modified for outermost interrupt handler (when g_nestlevel == 0)
|
||||
*/
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ CONFIGURATION
|
||||
```CONFIG_DISABLE_IDLE_LOOP`` is used to disable the idle loop in NuttX.
|
||||
```CONFIG_SYSTEM_OFLOADER``` is used to enable the Open Flash Loader.
|
||||
```CONFIG_SYSTEM_OFLOADER_TABLE``` is used to configure the flash device
|
||||
frist parameter is the device name, second parameter is the start address.
|
||||
first parameter is the device name, second parameter is the start address.
|
||||
|
||||
The reference configuration "stm32f429i-disco:ofloader" is designed
|
||||
to be used with the STM32F429I-DISCO board in NuttX,
|
||||
|
||||
@ -105,7 +105,7 @@ Setup RNDIS in your computer
|
||||
|
||||
Click on "Apply"
|
||||
|
||||
Disconect and connect the USB cable to force it to get IP.
|
||||
Disconnect and connect the USB cable to force it to get IP.
|
||||
|
||||
#. Identify what IP address your board got:
|
||||
|
||||
|
||||
@ -87,9 +87,9 @@ ADC
|
||||
ADC driver with the successive approximation analog/digital converter. The lower-half of
|
||||
this driver is initialize by calling :c:func:`imxrt_adcinitialize`.
|
||||
|
||||
ADC module can use either continous trigger (next conversion is started as soon as the
|
||||
ADC module can use either continuous trigger (next conversion is started as soon as the
|
||||
previous is finished) or hardware trigger. This option is selected by IMXRT_ADCx_ETC
|
||||
(x = 1, 2) config option. If IMXRT_ADCx_ETC = -1 then continous trigger is used. If
|
||||
(x = 1, 2) config option. If IMXRT_ADCx_ETC = -1 then continuous trigger is used. If
|
||||
corresponding XBAR number is put in IMXRT_ADCx_ETC then that signal is used to trigger
|
||||
the ADC conversion (for example PWM signal can be used as a source). For PWM XBAR options
|
||||
please refer to PWM chapter of this documentation.
|
||||
|
||||
@ -83,7 +83,7 @@ NuttShell configuration with support for CDC/ACM with RNDIS composite driver.
|
||||
highpri
|
||||
-------
|
||||
|
||||
This application demonstrates high priorty interrupt feature of the NuttX.
|
||||
This application demonstrates high priority interrupt feature of the NuttX.
|
||||
|
||||
nsh
|
||||
----
|
||||
|
||||
@ -3,7 +3,7 @@ nRF52840-dongle
|
||||
===============
|
||||
|
||||
The `nRF52840-dongle (PCA10059) <https://www.nordicsemi.com/Products/Development-hardware/nrf52840-dongle>`_
|
||||
is a a small, low-cost USB dongle based on nRF52840 fron Nordic.
|
||||
is a a small, low-cost USB dongle based on nRF52840 from Nordic.
|
||||
|
||||
Serial Console
|
||||
==============
|
||||
@ -59,5 +59,5 @@ Basic NuttShell configuration (CDCACM console enabled in USB Port, at 115200 bps
|
||||
Flash & Debug
|
||||
=============
|
||||
|
||||
Both flashing and debuing is possible only with an external debug proble.
|
||||
Both flashing and debuing is possible only with an external debug probe.
|
||||
|
||||
|
||||
@ -68,4 +68,4 @@ Basic NuttShell configuration (console enabled on Segger RTT channel).
|
||||
Flash & Debug
|
||||
=============
|
||||
|
||||
Both flashing and debuing is possible only with an external debug proble.
|
||||
Both flashing and debuing is possible only with an external debug probe.
|
||||
|
||||
@ -79,4 +79,4 @@ exposed via J-Link VCOM1, at 115200 bps).
|
||||
Flash & Debug
|
||||
=============
|
||||
|
||||
Both flashing and debuing is possible only with an external debug proble.
|
||||
Both flashing and debuing is possible only with an external debug probe.
|
||||
|
||||
@ -42,4 +42,4 @@ TODO
|
||||
Flash & Debug
|
||||
=============
|
||||
|
||||
Both flashing and debuing is possible only with an external debug proble.
|
||||
Both flashing and debuing is possible only with an external debug probe.
|
||||
|
||||
@ -47,7 +47,7 @@ connected LiPo cell.
|
||||
There is a BOOT button which if held down when power is first
|
||||
applied or the RESET button is pressed will cause the RP2040 to
|
||||
boot into program mode and appear as a storage device to
|
||||
a USB connecte . Saving a .UF2 file to this device will
|
||||
a USB connector. Saving a .UF2 file to this device will
|
||||
replace the Flash ROM contents on the RP2040.
|
||||
|
||||
A RESET button that allows rebooting the board without disconnecting
|
||||
|
||||
@ -40,7 +40,7 @@ Buttons and LEDs
|
||||
There is a BOOT button which if held down when power is first
|
||||
applied or the RESET button is pressed will cause the RP2040 to
|
||||
boot into program mode and appear as a storage device to
|
||||
a USB connecte . Saving a .UF2 file to this device will
|
||||
a USB connector. Saving a .UF2 file to this device will
|
||||
replace the Flash ROM contents on the RP2040.
|
||||
|
||||
A RESET button that allows rebooting the board without disconnecting
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
NXP RDDRONE-BMS772
|
||||
==================
|
||||
|
||||
`NXP RDDRONE-BMS772 <https://www.nxp.com/design/designs/smart-battery-management-for-mobile-robotics:RDDRONE-BMS772>`_ is a Battery Management System (BMS) reference design for mobile robotics, such as drones and rovers. Design files are available on the NXP website and may be used to develop your own BMS. RDDRONE-BMS772 is configurable and supports batteries of 3 to 6 cells, which it can monitor individually. The board features the `NXP S32K144 <https://www.nxp.com/products/processors-and-microcontrollers/s32-automotive-platform/s32k-general-purpose-mcus/s32k1-microcontrollers-for-general-purpose:S32K1>`_ MCU, which can monitor the `NXP MC33772B <https://www.nxp.com/products/power-management/battery-management/battery-cell-controllers/6-channel-li-ion-battery-cell-controller-ic:MC33772B>`_ Battery Cell Controller (BCC) and may commmunicates with the Vehicle Management Unit (VMU). When faults are detected the battery output can be disconnected to prevent further damage. Status information may be communicated over I2C/SMBus, CAN or NFC.
|
||||
`NXP RDDRONE-BMS772 <https://www.nxp.com/design/designs/smart-battery-management-for-mobile-robotics:RDDRONE-BMS772>`_ is a Battery Management System (BMS) reference design for mobile robotics, such as drones and rovers. Design files are available on the NXP website and may be used to develop your own BMS. RDDRONE-BMS772 is configurable and supports batteries of 3 to 6 cells, which it can monitor individually. The board features the `NXP S32K144 <https://www.nxp.com/products/processors-and-microcontrollers/s32-automotive-platform/s32k-general-purpose-mcus/s32k1-microcontrollers-for-general-purpose:S32K1>`_ MCU, which can monitor the `NXP MC33772B <https://www.nxp.com/products/power-management/battery-management/battery-cell-controllers/6-channel-li-ion-battery-cell-controller-ic:MC33772B>`_ Battery Cell Controller (BCC) and may communicates with the Vehicle Management Unit (VMU). When faults are detected the battery output can be disconnected to prevent further damage. Status information may be communicated over I2C/SMBus, CAN or NFC.
|
||||
|
||||
NuttX contains basic board support RDDRONE-BMS772, which allows the S32K144 MCU to be initialized. A NuttX-compatible smart battery application for RDDRONE-BMS772 is also available. It contains additional drivers and example software to use most features of the battery management system. This application is currently published in a `separate repository <https://github.com/NXPHoverGames/RDDRONE-BMS772>`_, but (parts) may eventually be upstreamed to Apache NuttX.
|
||||
|
||||
|
||||
@ -36,7 +36,7 @@ Peripheral Support Comments
|
||||
ADC No
|
||||
CMP No
|
||||
eDMA No
|
||||
EEEPROM Yes EEPROM emulated by FlexRAM
|
||||
EEPROM Yes EEPROM emulated by FlexRAM
|
||||
ENET Yes
|
||||
FlexCAN Yes SocketCAN-compatible
|
||||
FlexIO No
|
||||
@ -66,7 +66,7 @@ eDMA
|
||||
|
||||
Enhanced Direct Memory Access module. There is a driver that was copied from the i.MX RT port, but this was not tested on S32K1XX.
|
||||
|
||||
EEEPROM
|
||||
EEPROM
|
||||
-------
|
||||
|
||||
Emulated EEPROM (implemented by FlexRAM module). A basic block driver is available to read and write data.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
NXP S32K3XX
|
||||
===========
|
||||
|
||||
The `S32K3XX series <https://www.nxp.com/products/processors-and-microcontrollers/s32-automotive-platform/s32k-general-purpose-mcus/s32k3-microcontrollers-for-general-purpose:S32K3>`_ is a family of automotive-grade general-purpose microcontrollers from NXP Semiconductors. The chips are based around single, dual (lock-step) or tripple Arm Cortex-M7 cores, running at clockspeeds up to 240 MHz.
|
||||
The `S32K3XX series <https://www.nxp.com/products/processors-and-microcontrollers/s32-automotive-platform/s32k-general-purpose-mcus/s32k3-microcontrollers-for-general-purpose:S32K3>`_ is a family of automotive-grade general-purpose microcontrollers from NXP Semiconductors. The chips are based around single, dual (lock-step) or triple Arm Cortex-M7 cores, running at clockspeeds up to 240 MHz.
|
||||
|
||||
Supported MCUs
|
||||
==============
|
||||
|
||||
@ -10,7 +10,7 @@ ET-STM32 Stamp board from Futurlec (https://www.futurlec.com/ET-STM32_Stamp.shtm
|
||||
- I/O Pins Out: 48
|
||||
- ADCs: 16 (at 12-bit resolution)
|
||||
- DACs: 2 (at 12-bit resolution)
|
||||
- Peripherals: RTC, 4 timers, 2 I2Cs, 3 SPI ports, 1 on-board UART (upto 5 channels)
|
||||
- Peripherals: RTC, 4 timers, 2 I2Cs, 3 SPI ports, 1 on-board UART (up to 5 channels)
|
||||
- Other: Sleep, stop, and standby modes; serial wire debug and JTAG interfaces
|
||||
|
||||
Please see link below for board specific details:
|
||||
|
||||
@ -1164,7 +1164,7 @@ hciuart
|
||||
|
||||
This configuration was used for test the HCI UART driver. The HCI UART
|
||||
is enabled on USART3 as well as the test application at
|
||||
apps/wireless/bluetoot/btsak.
|
||||
apps/wireless/bluetooth/btsak.
|
||||
|
||||
NOTES:
|
||||
|
||||
@ -2177,6 +2177,6 @@ NOTES:
|
||||
The MSYS tools are probably also a option but are likely lower performance
|
||||
since they are based on Cygwin 1.3.
|
||||
|
||||
Host Compiler: I use the MingGW compiler which can be downloaded from
|
||||
Host Compiler: I use the MingW compiler which can be downloaded from
|
||||
http://www.mingw.org/. If you are using GNUWin32, then it is recommended
|
||||
the you not install the optional MSYS components as there may be conflicts.
|
||||
|
||||
@ -27,7 +27,7 @@ SERIAL_RX PD9
|
||||
SERIAL_TX PD8
|
||||
================= ===
|
||||
|
||||
Access to the Cortex-M4 core can be acheived using an additional UART port
|
||||
Access to the Cortex-M4 core can be achieved using an additional UART port
|
||||
or via RPMSG UART by setting ``CONFIG_RPMSG_UART_CONSOLE=y`` in CM4 configuration.
|
||||
|
||||
If the RPMSG UART console is enabled, we can connect to it from CM7 using ``cu``::
|
||||
|
||||
@ -120,7 +120,7 @@ Interprocessor communication between cores is realized with the NuttX RPTUN
|
||||
device based on the OpenAMP framework. ``HSEM`` is used for synchronization and
|
||||
notification between cores.
|
||||
|
||||
32kB of the SRAM3 is reseved for shared memory and this is the only available
|
||||
32kB of the SRAM3 is reserved for shared memory and this is the only available
|
||||
option at the moment.
|
||||
|
||||
Supported Boards
|
||||
|
||||
@ -140,7 +140,7 @@ though. Thus, this change::
|
||||
return TFM_PLAT_ERR_SUCCESS;
|
||||
}
|
||||
|
||||
The third chage is required, since current NuttX does not support lazy FPU
|
||||
The third change is required, since current NuttX does not support lazy FPU
|
||||
register stacking any longer. Thus, this must be disabled for the TF-M secure
|
||||
code as well::
|
||||
|
||||
|
||||
@ -179,8 +179,8 @@ the ``/dev/crypto`` device file.
|
||||
cxx
|
||||
---
|
||||
|
||||
Development enviroment ready for C++ applications. You can check if the setup
|
||||
was successfull by running ``cxxtest``::
|
||||
Development environment ready for C++ applications. You can check if the setup
|
||||
was successful by running ``cxxtest``::
|
||||
|
||||
nsh> cxxtest
|
||||
Test ofstream ================================
|
||||
|
||||
@ -1635,7 +1635,7 @@ This is a configuration with sim usbdev support.
|
||||
|
||||
Make Raw Gadget:
|
||||
Run make in the raw_gadget and dummy_hcd directory. If raw_gadget build
|
||||
fail, you need to check which register interface meets your kenel version,
|
||||
fail, you need to check which register interface meets your kernel version,
|
||||
usb_gadget_probe_driver or usb_gadget_register_driver.
|
||||
|
||||
Install Raw Gadget:
|
||||
|
||||
@ -130,7 +130,7 @@ to bypass the audio subsystem and write directly to the I2S peripheral.
|
||||
-> ESP32 Peripheral Selection
|
||||
-> I2S
|
||||
-> I2S0/1
|
||||
-> Bit Witdh
|
||||
-> Bit Width
|
||||
|
||||
And make sure the data stream buffer being written to the I2S peripheral is
|
||||
aligned to the next boundary i.e. 16 bits for the 8 and 16-bit-widths and
|
||||
@ -307,8 +307,8 @@ disables the NuttShell to get the best possible score.
|
||||
cxx
|
||||
---
|
||||
|
||||
Development enviroment ready for C++ applications. You can check if the setup
|
||||
was successfull by running ``cxxtest``::
|
||||
Development environment ready for C++ applications. You can check if the setup
|
||||
was successful by running ``cxxtest``::
|
||||
|
||||
nsh> cxxtest
|
||||
Test ofstream ================================
|
||||
@ -375,7 +375,7 @@ After successfully built and flashed, run on the boards's terminal::
|
||||
|
||||
i2schar -p /dev/i2schar[0-1]
|
||||
|
||||
The corresponding output should show related debug informations.
|
||||
The corresponding output should show related debug information.
|
||||
|
||||
knsh
|
||||
----
|
||||
|
||||
@ -60,7 +60,7 @@ The ESP32-S2-Kaluga-1 board has connectors for boards with:
|
||||
|
||||
- Extension header (ESP-LyraT-8311A, ESP-LyraP-LCD32)
|
||||
- Camera header (ESP-LyraP-CAM)
|
||||
- Touch FPC coneector (ESP-LyraP-TouchA)
|
||||
- Touch FPC connector (ESP-LyraP-TouchA)
|
||||
- LCD FPC connector (no official extension boards yet)
|
||||
- I2C FPC connector (no official extension boards yet)
|
||||
|
||||
@ -74,7 +74,7 @@ The ESP32-S2-Kaluga-1 board has connectors for boards with:
|
||||
|
||||
ESP32-S2-Kaluga-1 (click to enlarge)
|
||||
|
||||
All the four extension boards are specially desgined to support the following
|
||||
All the four extension boards are specially designed to support the following
|
||||
features:
|
||||
|
||||
* Touch panel control
|
||||
|
||||
@ -80,7 +80,7 @@ to bypass the audio subsystem and write directly to the I2S peripheral.
|
||||
-> System Type
|
||||
-> ESP32-S2 Peripheral Selection
|
||||
-> I2S
|
||||
-> Bit Witdh
|
||||
-> Bit Width
|
||||
|
||||
The following configurations use the I2S peripheral::
|
||||
* :ref:`platforms/xtensa/esp32s2/boards/esp32s2-saola-1/index:audio`
|
||||
@ -169,8 +169,8 @@ disables the NuttShell to get the best possible score.
|
||||
cxx
|
||||
---
|
||||
|
||||
Development enviroment ready for C++ applications. You can check if the setup
|
||||
was successfull by running ``cxxtest``::
|
||||
Development environment ready for C++ applications. You can check if the setup
|
||||
was successful by running ``cxxtest``::
|
||||
|
||||
nsh> cxxtest
|
||||
Test ofstream ================================
|
||||
|
||||
@ -151,8 +151,8 @@ disables the NuttShell to get the best possible score.
|
||||
cxx
|
||||
---
|
||||
|
||||
Development enviroment ready for C++ applications. You can check if the setup
|
||||
was successfull by running ``cxxtest``::
|
||||
Development environment ready for C++ applications. You can check if the setup
|
||||
was successful by running ``cxxtest``::
|
||||
|
||||
nsh> cxxtest
|
||||
Test ofstream ================================
|
||||
|
||||
@ -25,7 +25,7 @@ To choose a configuration you pass the ``<board name>:<board configuration>`` su
|
||||
$ cd nuttx
|
||||
$ cmake -B build -DBOARD_CONFIG=stm32f4discovery:nsh -GNinja
|
||||
|
||||
The ``-B build`` tells what is the build direcotry.
|
||||
The ``-B build`` tells what is the build directory.
|
||||
|
||||
You can then customize this configuration by using the menu based
|
||||
configuration system with:
|
||||
|
||||
@ -108,7 +108,7 @@ Api description
|
||||
:param mutex: mutex descriptor.
|
||||
|
||||
:return:
|
||||
if mutex is locked will return `ture`. if not will reutrn `false`
|
||||
if mutex is locked will return `ture`. if not will return `false`
|
||||
|
||||
.. c:function:: void nxmutex_unlock(FAR mutex_t *mutex)
|
||||
|
||||
|
||||
@ -265,7 +265,7 @@ Tickless Configuration Options
|
||||
bool "Simulation"
|
||||
select ARCH_HAVE_TICKLESS
|
||||
---help---
|
||||
Linux/Cywgin user-mode simulation.
|
||||
Linux/Cygwin user-mode simulation.
|
||||
|
||||
When the simulation platform is selected,
|
||||
``ARCH_HAVE_TICKLESS`` is automatically selected, informing the
|
||||
|
||||
Loading…
Reference in New Issue
Block a user