1
0
mirror of https://github.com/RIOT-OS/RIOT.git synced 2024-12-29 04:50:03 +01:00

treewide: fix path to shell related tests in doc

This commit is contained in:
Alexandre Abadie 2023-05-13 18:23:57 +02:00
parent c449bc0e87
commit 3989cd79ff
No known key found for this signature in database
GPG Key ID: 1C919A403CAE1405
8 changed files with 28 additions and 28 deletions

View File

@ -576,11 +576,11 @@ command, for example:
- RIOT Docker build image installation - RIOT Docker build image installation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ BUILD_IN_DOCKER=1 DOCKER="sudo docker" \ $ BUILD_IN_DOCKER=1 DOCKER="sudo docker" \
make flash BOARD=esp32-wroom-32 -C tests/shell [Compile Options] make flash BOARD=esp32-wroom-32 -C tests/sys/shell/ [Compile Options]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Local toolchain installation - Local toolchain installation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ make flash BOARD=esp32-wroom-32 -C tests/shell [Compile Options] $ make flash BOARD=esp32-wroom-32 -C tests/sys/shell/ [Compile Options]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The `BOARD` variable in the example specifies the generic ESP32 board that uses The `BOARD` variable in the example specifies the generic ESP32 board that uses
@ -2051,12 +2051,12 @@ installed.
To use QEMU for ESP32, an application has to be built with `esp_qemu` module To use QEMU for ESP32, an application has to be built with `esp_qemu` module
enabled, for example with local toolchain installation enabled, for example with local toolchain installation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/shell $ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/sys/shell/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
or with RIOT Docker build image or with RIOT Docker build image
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ BUILD_IN_DOCKER=1 DOCKER="sudo docker" \ $ BUILD_IN_DOCKER=1 DOCKER="sudo docker" \
USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/shell USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/sys/shell/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Instead of flashing the image to the target hardware, a binary image named Instead of flashing the image to the target hardware, a binary image named
@ -2070,7 +2070,7 @@ QEMU for ESP32 can then be started with command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ qemu-system-xtensa \ $ qemu-system-xtensa \
-s -machine esp32 \ -s -machine esp32 \
-drive file=tests/shell/bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \ -drive file=tests/sys/shell//bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
-serial tcp::5555,server,nowait -serial tcp::5555,server,nowait
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -2099,12 +2099,12 @@ start_test starts a test
To debug the application in QEMU for ESP32, another terminal is required: To debug the application in QEMU for ESP32, another terminal is required:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ xtensa-esp32-elf-gdb tests/shell/bin/esp32-wroom-32/tests_shell.elf $ xtensa-esp32-elf-gdb tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf
GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10 GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10
Copyright (C) 2015 Free Software Foundation, Inc. Copyright (C) 2015 Free Software Foundation, Inc.
... ...
Reading symbols from tests/shell/bin/esp32-wroom-32/tests_shell.elf...done. Reading symbols from tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf...done.
(gdb) target remote :1234 (gdb) target remote :1234
Remote debugging using :1234 Remote debugging using :1234
@ -2117,10 +2117,10 @@ QEMU for ESP32 can also be used in RIOT Docker build image. For that purpose
QEMU has to be started in the Docker container. QEMU has to be started in the Docker container.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ sudo docker run --rm -i -t -u $UID -v $(pwd):/data/riotbuild riot/riotbuild $ sudo docker run --rm -i -t -u $UID -v $(pwd):/data/riotbuild riot/riotbuild
riotbuild@container-id:~$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/shell riotbuild@container-id:~$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/sys/shell/
riotbuild@container-id:~$ qemu-system-xtensa \ riotbuild@container-id:~$ qemu-system-xtensa \
-s -machine esp32 \ -s -machine esp32 \
-drive file=tests/shell/bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \ -drive file=tests/sys/shell//bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
-serial tcp::5555,server,nowait -serial tcp::5555,server,nowait
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -2144,12 +2144,12 @@ test_shell.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ sudo docker docker exec -it <container-id> bash $ sudo docker docker exec -it <container-id> bash
riotbuild@container-id:~$ xtensa-esp32-elf-gdb tests/shell/bin/esp32-wroom-32/tests_shell.elf riotbuild@container-id:~$ xtensa-esp32-elf-gdb tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf
GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10 GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10
Copyright (C) 2015 Free Software Foundation, Inc. Copyright (C) 2015 Free Software Foundation, Inc.
... ...
Reading symbols from tests/shell/bin/esp32-wroom-32/tests_shell.elf...done. Reading symbols from tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf...done.
(gdb) target remote :1234 (gdb) target remote :1234
Remote debugging using :1234 Remote debugging using :1234

View File

@ -59,7 +59,7 @@ To build a RIOT application, simply use the `make` command and specify an
existing ESP8266 board, for example: existing ESP8266 board, for example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make flash BOARD=esp8266-esp-12x -C tests/shell ... make flash BOARD=esp8266-esp-12x -C tests/sys/shell/ ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For more information about the `make` command variables and specific compile For more information about the `make` command variables and specific compile
@ -283,7 +283,7 @@ directory, a RIOT application can be compiled inside RIOT Docker using the
make command as usual, for example: make command as usual, for example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make BOARD=esp8266-esp-12x -C tests/shell ... make BOARD=esp8266-esp-12x -C tests/sys/shell/ ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This will generate a RIOT binary in ELF format. This will generate a RIOT binary in ELF format.
@ -295,7 +295,7 @@ of the compilations is also accessible on the host system. On the host system,
the `flash-only` target can then be used to flash the binary. the `flash-only` target can then be used to flash the binary.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make flash-only BOARD=esp8266-esp-12x -C tests/shell make flash-only BOARD=esp8266-esp-12x -C tests/sys/shell/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@note Both steps can also be performed with a single command on the host @note Both steps can also be performed with a single command on the host
@ -1126,7 +1126,7 @@ For debugging purposes, the application should be compiled with debugging
information. This can either be done by using the `esp_gdb` module, for example: information. This can either be done by using the `esp_gdb` module, for example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
USEMODULE=esp_gdb make flash BOARD=esp8266-esp-12x -C tests/shell USEMODULE=esp_gdb make flash BOARD=esp8266-esp-12x -C tests/sys/shell/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Back to table of contents](#esp8266_toc) [Back to table of contents](#esp8266_toc)
@ -1162,7 +1162,7 @@ term1> $QEMU/bin/qemu-system-xtensa -M esp8266 -nographic -serial stdio -monitor
where `/path/to/build/dir` is the path to the application build directory where `/path/to/build/dir` is the path to the application build directory
`$(BINDIR)` where `$ELFFILE.bin` is generated by the `make` command, for example `$(BINDIR)` where `$ELFFILE.bin` is generated by the `make` command, for example
`$(RIOTBASE)/tests/shell/bin/esp8266-esp-12x`. After that you can `$(RIOTBASE)/tests/sys/shell//bin/esp8266-esp-12x`. After that you can
start `GDB` in second terminal window using command: start `GDB` in second terminal window using command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -1203,7 +1203,7 @@ To start debugging, the application has to be compiled using
module `esp_gdbstub`, for example: module `esp_gdbstub`, for example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
USEMODULE=esp_gdbstub make flash BOARD=esp8266-esp-12x -C tests/shell USEMODULE=esp_gdbstub make flash BOARD=esp8266-esp-12x -C tests/sys/shell/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Once, the application is flashed to ESP82666, debugging can be started as Once, the application is flashed to ESP82666, debugging can be started as
@ -1223,7 +1223,7 @@ term2> xtensa-esp8266-elf-gdb /path/to/the/build/dir/image.elf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
where `/path/to/build/dir` is the path to the application build directory where `/path/to/build/dir` is the path to the application build directory
`$(BINDIR)` where `$ELFFILE.bin` is generated by the `make` command, for example `$(BINDIR)` where `$ELFFILE.bin` is generated by the `make` command, for example
`$(RIOTBASE)/tests/shell/bin/esp8266-esp-12x`. `$(RIOTBASE)/tests/sys/shell//bin/esp8266-esp-12x`.
3. Connect from `GDB` to the ESP8266 module with command: 3. Connect from `GDB` to the ESP8266 module with command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -1250,7 +1250,7 @@ the application stepwise or just continue the execution using the `continue`
command. Please note the limitations below. Once you have started the execution command. Please note the limitations below. Once you have started the execution
in `GDB`, you can use `Ctrl-C` in `GDB` or the console window to break it anytime. in `GDB`, you can use `Ctrl-C` in `GDB` or the console window to break it anytime.
If your application uses console inputs (stdio), such as the `tests/shell` If your application uses console inputs (stdio), such as the `tests/sys/shell/`
application, you can type characters in the console window that gdbstub will application, you can type characters in the console window that gdbstub will
forward to the application. However, the echo of these inputs occur in `GDB`. forward to the application. However, the echo of these inputs occur in `GDB`.

View File

@ -41,7 +41,7 @@ TEST_INTERACTIVE_DELAY = int(os.environ.get('TEST_INTERACTIVE_DELAY') or 1)
TESTRUNNER_RESET_AFTER_TERM = int(os.environ.get('TESTRUNNER_RESET_AFTER_TERM') TESTRUNNER_RESET_AFTER_TERM = int(os.environ.get('TESTRUNNER_RESET_AFTER_TERM')
or 0) or 0)
# When running e.g. tests/shell_ble we don't want to reset the board, because # When running e.g. tests/sys/shell/_ble we don't want to reset the board, because
# then ble-serial would terminate and the created virtual serial port would get # then ble-serial would terminate and the created virtual serial port would get
# lost. By default the board is reset before the test starts. # lost. By default the board is reset before the test starts.
TESTRUNNER_RESET_BOARD_ON_STARTUP = \ TESTRUNNER_RESET_BOARD_ON_STARTUP = \

View File

@ -52,7 +52,7 @@ DEFAULT_APPS = [
"examples/hello-world", "examples/hello-world",
"tests/pkg/tinyusb_cdc_msc", "tests/pkg/tinyusb_cdc_msc",
"tests/mtd_mapper", "tests/mtd_mapper",
"tests/shell", "tests/sys/shell/",
"tests/saul" "tests/saul"
] ]

View File

@ -38,7 +38,7 @@ function call_with_defaults {
function call_with_specific_board_app { function call_with_specific_board_app {
${COMPILE_TEST_DIR}/compile_like_murdock.py \ ${COMPILE_TEST_DIR}/compile_like_murdock.py \
--boards native \ --boards native \
--apps tests/shell \ --apps tests/sys/shell/ \
--dry-run --dry-run
} }

View File

@ -31,8 +31,8 @@ See the general vagrant [README.md](../README.md) for more commands.
Once logged in to the VM you can run compile and run tests e.g. Once logged in to the VM you can run compile and run tests e.g.
```sh ```sh
make -C tests/shell all -j make -C tests/sys/shell/ all -j
make -C tests/shell test make -C tests/sys/shell/ test
``` ```
Even applications requiring network interface access should be able to work: Even applications requiring network interface access should be able to work:

View File

@ -41,7 +41,7 @@ Otherwise the device will appear as "*RIOT OS device*".
## Instructions to connect to the bluetooth shell via ble-serial ## Instructions to connect to the bluetooth shell via ble-serial
- Configure and compile shell app for nrf52840dongle target in `tests/shell`.\ - Configure and compile shell app for nrf52840dongle target in `tests/sys/shell`.\
Add following to Makefile: Add following to Makefile:
``` ```
@ -50,11 +50,11 @@ USEMODULE += nimble_autoadv
USEMODULE += stdio_nimble USEMODULE += stdio_nimble
``` ```
**NOTE:** You can also have a look at `tests/shell_ble`. **NOTE:** You can also have a look at `tests/sys/shell_ble`.
- Flash - Flash
`$ make -C tests/shell -j clean all flash` `$ make -C tests/sys/shell -j clean all flash`
- Install the ble-serial tool - Install the ble-serial tool

View File

@ -8,7 +8,7 @@ USEMODULE += ps
USEMODULE += stdio_nimble stdio_nimble_debug USEMODULE += stdio_nimble stdio_nimble_debug
USEMODULE += nimble_autoadv USEMODULE += nimble_autoadv
CFLAGS += -DCONFIG_NIMBLE_AUTOADV_DEVICE_NAME='"tests/shell_ble"' CFLAGS += -DCONFIG_NIMBLE_AUTOADV_DEVICE_NAME='"tests/sys/shell/_ble"'
TESTRUNNER_SHELL_SKIP_REBOOT = 1 TESTRUNNER_SHELL_SKIP_REBOOT = 1
TESTRUNNER_RESET_BOARD_ON_STARTUP = 0 TESTRUNNER_RESET_BOARD_ON_STARTUP = 0