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

treewide: replace remaining occurrences of tests/pkg_*

This commit is contained in:
Alexandre Abadie 2023-05-06 07:48:58 +02:00
parent a347879f71
commit 07d2e1c228
No known key found for this signature in database
GPG Key ID: 1C919A403CAE1405
20 changed files with 38 additions and 38 deletions

View File

@ -165,12 +165,12 @@ u8g2_SetI2CAddress(&u8g2, SSD1306_I2C_ADDR);
u8g2_InitDisplay(&u8g2); u8g2_InitDisplay(&u8g2);
u8g2_SetPowerSave(&u8g2, 0); u8g2_SetPowerSave(&u8g2, 0);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The `tests/pkg_u8g2` test application is a good example of how to use the The `tests/pkg/u8g2` test application is a good example of how to use the
`pkg/u8g2` package. It can be compiled for the board with the following command: `pkg/u8g2` package. It can be compiled for the board with the following command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TEST_OUTPUT=4 TEST_I2C=0 TEST_ADDR=0x3c TEST_PIN_RESET=GPIO16 \ TEST_OUTPUT=4 TEST_I2C=0 TEST_ADDR=0x3c TEST_PIN_RESET=GPIO16 \
TEST_DISPLAY=u8g2_Setup_ssd1306_i2c_128x64_noname_f \ TEST_DISPLAY=u8g2_Setup_ssd1306_i2c_128x64_noname_f \
BOARD=esp32-heltec-lora32-v2 make -C tests/pkg_u8g2/ flash BOARD=esp32-heltec-lora32-v2 make -C tests/pkg/u8g2/ flash
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Back to table of contents](#esp32_heltec_lora32_v2_toc) [Back to table of contents](#esp32_heltec_lora32_v2_toc)

View File

@ -50,7 +50,7 @@ _RATIOS = [
DEFAULT_APPS = [ 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/shell",
"tests/saul" "tests/saul"

View File

@ -88,7 +88,7 @@ implementations:
[nanocoap library](https://github.com/kaspar030/sock/tree/master/nanocoap) [nanocoap library](https://github.com/kaspar030/sock/tree/master/nanocoap)
implementation implementation
* [Microcoap](../../tests/pkg_microcoap): another lightweight CoAP server based * [Microcoap](../../tests/pkg/microcoap): another lightweight CoAP server based
on the [microcoap library](https://github.com/1248/microcoap) implementation on the [microcoap library](https://github.com/1248/microcoap) implementation

View File

@ -19,7 +19,7 @@
* The use of the library itself [is described in the libcose * The use of the library itself [is described in the libcose
* documentation](https://bergzand.github.io/libcose/), and some example code * documentation](https://bergzand.github.io/libcose/), and some example code
* can be found in * can be found in
* [`tests/pkg_libcose/`](https://github.com/RIOT-OS/RIOT/tree/master/tests/pkg_libcose). * [`tests/pkg/libcose/`](https://github.com/RIOT-OS/RIOT/tree/master/tests/pkg/libcose).
* *
* Backends * Backends
* -------- * --------

View File

@ -23,7 +23,7 @@ LVGL_TASK_THREAD_PRIO cannot be configured via Kconfig.
Example of command line for changing the max activity period to 5s: Example of command line for changing the max activity period to 5s:
``` ```
CFLAGS=-DCONFIG_LVGL_ACTIVITY_PERIOD=5000 make -C tests/pkg_lvgl CFLAGS=-DCONFIG_LVGL_ACTIVITY_PERIOD=5000 make -C tests/pkg/lvgl
``` ```
### SDL Usage ### SDL Usage

View File

@ -93,7 +93,7 @@
* *
* # Testing * # Testing
* Many Mbed TLS implementations provide self tests within the boundaries of * Many Mbed TLS implementations provide self tests within the boundaries of
* a module and the [test folder](../../tests/pkg_mbedtls) acts as a place to execute * a module and the [test folder](../../tests/pkg/mbedtls) acts as a place to execute
* these tests in RIOT context. It is noteworthy, that built-in Mbed TLS entropy source tests * these tests in RIOT context. It is noteworthy, that built-in Mbed TLS entropy source tests
* only execute on the source that is implemented in `mbedtls_hardware_poll`. * only execute on the source that is implemented in `mbedtls_hardware_poll`.
* The additional sources that were added using `mbedtls_entropy_add_source` are ignored in the test. * The additional sources that were added using `mbedtls_entropy_add_source` are ignored in the test.

View File

@ -322,7 +322,7 @@
- The provided test application provides a UDP client and server. If the UDP - The provided test application provides a UDP client and server. If the UDP
server is able to receive packets, the mechanism is considered to work correctly. server is able to receive packets, the mechanism is considered to work correctly.
You should also be able to ping the device from your host. See You should also be able to ping the device from your host. See
`tests/pkg_openwsn/README.md` for more details. `tests/pkg/openwsn/README.md` for more details.
- To speed up synchronization and make sniffing easier you can disable channel - To speed up synchronization and make sniffing easier you can disable channel
hopping by setting (`CFLAGS=-DIEEE802154E_SINGLE_CHANNEL=26`). hopping by setting (`CFLAGS=-DIEEE802154E_SINGLE_CHANNEL=26`).
@ -343,7 +343,7 @@
the IoT-LAB testbed. the IoT-LAB testbed.
- To test Openserial on a given platform the target `make openv-serial` can - To test Openserial on a given platform the target `make openv-serial` can
be used on a BOARD flashed with `tests/pkg_openwsn` (`USEMODULE=openwsn_serial`) be used on a BOARD flashed with `tests/pkg/openwsn` (`USEMODULE=openwsn_serial`)
must be included as well. The following output should appear: must be included as well. The following output should appear:
``` ```

View File

@ -127,7 +127,7 @@
* *
* to make the device to be a composite keyboard/mouse device. * to make the device to be a composite keyboard/mouse device.
* *
* Please refer `$RIOTBASE/tests/pkg_tinyusb_cdc_msc` and the * Please refer `$RIOTBASE/tests/pkg/tinyusb_cdc_msc` and the
* [tinyUSB documentation](https://docs.tinyusb.org/en/latest/reference/getting_started.html) * [tinyUSB documentation](https://docs.tinyusb.org/en/latest/reference/getting_started.html)
* for details. * for details.
*/ */

View File

@ -18,7 +18,7 @@ The program will loop forever. In every loop it:
This is an example, with the Arduino Mega2560 board and the Decagon CTD-10 This is an example, with the Arduino Mega2560 board and the Decagon CTD-10
sensor: sensor:
$ BOARD=arduino-mega2560 make -C tests/pkg_arduino_sdi_12 all flash term $ BOARD=arduino-mega2560 make -C tests/pkg/arduino_sdi_12 all flash term
[...] [...]
2021-09-28 12:14:57,492 # main(): This is RIOT! (Version: 2021.10-devel-776-gc7af21-sdi12) 2021-09-28 12:14:57,492 # main(): This is RIOT! (Version: 2021.10-devel-776-gc7af21-sdi12)
2021-09-28 12:14:57,496 # Testing the Arduino-SDI-12 package 2021-09-28 12:14:57,496 # Testing the Arduino-SDI-12 package

View File

@ -256,8 +256,8 @@ sudo dist/tools/tapsetup/tapsetup -c 2
- bootstrap the `BOARD`s and specify the tap interface to use for each - bootstrap the `BOARD`s and specify the tap interface to use for each
``` ```
PORT=tap0 make -C tests/pkg_edhoc_c all term PORT=tap0 make -C tests/pkg/edhoc_c all term
PORT=tap1 make -C tests/pkg_edhoc_c all term PORT=tap1 make -C tests/pkg/edhoc_c all term
``` ```
#### physical `BOARD`s #### physical `BOARD`s
@ -268,7 +268,7 @@ through which they will be able to communicate.
- bootstrap the `BOARD`s - bootstrap the `BOARD`s
``` ```
make -C tests/pkg_edhoc_c flash term make -C tests/pkg/edhoc_c flash term
``` ```
### Perform the handshake ### Perform the handshake
@ -414,5 +414,5 @@ OSCORE salt:
As long as a BOARD with a netdev interface is used is as simple as: As long as a BOARD with a netdev interface is used is as simple as:
``` ```
$ make -C tests/pkg_edhoc_c flash test-with-config $ make -C tests/pkg/edhoc_c flash test-with-config
``` ```

View File

@ -15,7 +15,7 @@ Usage
Simply flash and run the application on the board of your choice using: Simply flash and run the application on the board of your choice using:
make BOARD=<board of your choice> -C tests/pkg_flatbuffers flash term make BOARD=<board of your choice> -C tests/pkg/flatbuffers flash term
Expected result Expected result
--------------- ---------------

View File

@ -11,7 +11,7 @@ The application works without modification on the stm32f429i-disc1 board. To
build, flash and run the application for this board, just use: build, flash and run the application for this board, just use:
``` ```
make BOARD=stm32f429i-disc1 -C tests/pkg_lvgl flash make BOARD=stm32f429i-disc1 -C tests/pkg/lvgl flash
``` ```
### Expected result ### Expected result

View File

@ -9,7 +9,7 @@ The application works without modification on the stm32f429i-disc1 board. To
build, flash and run the application for this board, just use: build, flash and run the application for this board, just use:
``` ```
make BOARD=stm32f429i-disc1 -C tests/pkg_lvgl_touch flash make BOARD=stm32f429i-disc1 -C tests/pkg/lvgl_touch flash
``` ```
### Expected result ### Expected result

View File

@ -140,22 +140,22 @@ to be specified for every node, `IOTLAB_NODE=m3-%.saclay.iot-lab.info`
2. flash the root node 2. flash the root node
$ IOTLAB_NODE=${ROOT_IOTLAB_NODE} USEMODULE=openwsn_serial \ $ IOTLAB_NODE=${ROOT_IOTLAB_NODE} USEMODULE=openwsn_serial \
BOARD=iotlab-m3 make -C tests/pkg_openwsn flash BOARD=iotlab-m3 make -C tests/pkg/openwsn flash
3. open a shell to the leaf nodes so in two shell windows, do (one in each): 3. open a shell to the leaf nodes so in two shell windows, do (one in each):
$ BOARD=iotlab-m3 make -C tests/pkg_openwsn all -j4 $ BOARD=iotlab-m3 make -C tests/pkg/openwsn all -j4
$ BOARD=iotlab-m3 IOTLAB_NODE=${LEAF_IOTLAB_NODE0} make -C tests/pkg_openwsn flash-only $ BOARD=iotlab-m3 IOTLAB_NODE=${LEAF_IOTLAB_NODE0} make -C tests/pkg/openwsn flash-only
$ BOARD=iotlab-m3 IOTLAB_NODE=${LEAF_IOTLAB_NODE1} make -C tests/pkg_openwsn flash-only $ BOARD=iotlab-m3 IOTLAB_NODE=${LEAF_IOTLAB_NODE1} make -C tests/pkg/openwsn flash-only
4. open a shell to the leaf nodes 4. open a shell to the leaf nodes
so in two shell windows, do (one in each): so in two shell windows, do (one in each):
$ BOARD=iotlab-m3 IOTLAB_NODE=${LEAF_IOTLAB_NODE0} make -C tests/pkg_openwsn term $ BOARD=iotlab-m3 IOTLAB_NODE=${LEAF_IOTLAB_NODE0} make -C tests/pkg/openwsn term
$ BOARD=iotlab-m3 IOTLAB_NODE=${LEAF_IOTLAB_NODE1} make -C tests/pkg_openwsn term $ BOARD=iotlab-m3 IOTLAB_NODE=${LEAF_IOTLAB_NODE1} make -C tests/pkg/openwsn term
5. in a third shell, launch openvisualizer: 5. in a third shell, launch openvisualizer:
$ BOARD=iotlab-m3 IOTLAB_NODE=${ROOT_IOTLAB_NODE} make -C tests/pkg_openwsn openv-termroot $ BOARD=iotlab-m3 IOTLAB_NODE=${ROOT_IOTLAB_NODE} make -C tests/pkg/openwsn openv-termroot
### Network Setup ### Network Setup
@ -280,11 +280,11 @@ follows:
on iotlab: on iotlab:
$ IOTLAB_NODE=${ROOT_IOTLAB_NODE} BOARD=iotlab-m3 \ $ IOTLAB_NODE=${ROOT_IOTLAB_NODE} BOARD=iotlab-m3 \
make -C tests/pkg_openwsn openv-termtun make -C tests/pkg/openwsn openv-termtun
on local boards: on local boards:
$ PORT=<USB-serial-port, e.g., /dev/ttyUSB0> BOARD=samr21-xpro \ $ PORT=<USB-serial-port, e.g., /dev/ttyUSB0> BOARD=samr21-xpro \
make -C tests/pkg_openwsn openv-termtun make -C tests/pkg/openwsn openv-termtun
Once DAOs are received you can ping nodes in the network from your host: Once DAOs are received you can ping nodes in the network from your host:

View File

@ -51,7 +51,7 @@ board.
Depending on the type of radio device, set the `LORA_DRIVER` variable accordingly: Depending on the type of radio device, set the `LORA_DRIVER` variable accordingly:
For example: For example:
LORA_DRIVER=sx1272 make BOARD=nucleo-f411re -C tests/pkg_semtech-loramac flash term LORA_DRIVER=sx1272 make BOARD=nucleo-f411re -C tests/pkg/semtech-loramac flash term
will build the application for a nucleo-f411re with an SX1272 based mbed LoRa shield. will build the application for a nucleo-f411re with an SX1272 based mbed LoRa shield.
@ -60,7 +60,7 @@ The SX1276 is the default value.
The other parameter that has to be set at build time is the geographic region: The other parameter that has to be set at build time is the geographic region:
`EU868`, `US915`, etc. See LoRaWAN regional parameters for more information. `EU868`, `US915`, etc. See LoRaWAN regional parameters for more information.
LORA_REGION=US915 LORA_DRIVER=sx1272 make BOARD=nucleo-f411re -C tests/pkg_semtech-loramac flash term LORA_REGION=US915 LORA_DRIVER=sx1272 make BOARD=nucleo-f411re -C tests/pkg/semtech-loramac flash term
will build the application for a nucleo-f411re with an SX1272 based mbed LoRa shield will build the application for a nucleo-f411re with an SX1272 based mbed LoRa shield
for US915 region. for US915 region.
@ -247,17 +247,17 @@ for ABP. The test assumes that both devices have the same Application EUI.
1. flash device with appropriate keys and test 1. flash device with appropriate keys and test
$ DEVEUI_OTA=<...> DEVEUI_ABP=<...> APPEUI=<...> APPKEY=<...> DEVADDR=<...> NWKSKEY=<...> APPSKEY=<...> RX2_DR=<...> make BOARD=b-l072z-lrwan1 -C tests/pkg_semtech-loramac test $ DEVEUI_OTA=<...> DEVEUI_ABP=<...> APPEUI=<...> APPKEY=<...> DEVADDR=<...> NWKSKEY=<...> APPSKEY=<...> RX2_DR=<...> make BOARD=b-l072z-lrwan1 -C tests/pkg/semtech-loramac test
#### With iotlab #### With iotlab
1. setup the iotlab experiment: 1. setup the iotlab experiment:
$ make -C tests/pkg_semtech-loramac iotlab-exp $ make -C tests/pkg/semtech-loramac iotlab-exp
2. flash device with the appropriate keys and test 2. flash device with the appropriate keys and test
$ DEVEUI=<...> APPEUI=<...> APPKEY=<...> DEVADDR=<...> NWKSKEY=<...> APPSKEY=<...> RX2_DR=<...> IOTLAB_NODE=auto make -C tests/pkg_semtech-loramac flash test $ DEVEUI=<...> APPEUI=<...> APPKEY=<...> DEVADDR=<...> NWKSKEY=<...> APPSKEY=<...> RX2_DR=<...> IOTLAB_NODE=auto make -C tests/pkg/semtech-loramac flash test
3. stop the iotlab experiment: 3. stop the iotlab experiment:

View File

@ -18,7 +18,7 @@ To get started with TensorFlow Lite on microcontrollers, please refer to
Simply run the application on the board of your choice using: Simply run the application on the board of your choice using:
make BOARD=<board of your choice> -C tests/pkg_tensorflow-lite flash term make BOARD=<board of your choice> -C tests/pkg/tensorflow-lite flash term
Set `EXAMPLE=hello_world` from the command line to try the upstream hello_world Set `EXAMPLE=hello_world` from the command line to try the upstream hello_world
example. example.

View File

@ -16,7 +16,7 @@ variables `USB_VID` and `USB_PID` in the makefile or at the command line,
for example for example
``` ```
USB_VID=1234 USB_PID=5678 BOARD=... make -C tests/pkg_tinyusb_cdc_msc USB_VID=1234 USB_PID=5678 BOARD=... make -C tests/pkg/tinyusb_cdc_msc
``` ```
## Usage ## Usage

View File

@ -20,14 +20,14 @@ The test application use the protocol defined by the CLASS variable, which
defaults to the RNDIS protocol (`tinyusb_class_net_rndis`). This can be defaults to the RNDIS protocol (`tinyusb_class_net_rndis`). This can be
changed by setting this variable in the make command line, for example: changed by setting this variable in the make command line, for example:
``` ```
CLASS=tinyusb_class_net_cdc_ecm BOARD=... make -C tests/pkg_tinyusb_netdev flash CLASS=tinyusb_class_net_cdc_ecm BOARD=... make -C tests/pkg/tinyusb_netdev flash
``` ```
The CDC ECM protocol (`tinyusb_class_net_cdc_ecm`) and the RNDIS protocol The CDC ECM protocol (`tinyusb_class_net_cdc_ecm`) and the RNDIS protocol
(`tinyusb_class_net_rndis`) can be used simultaneously to support all operating (`tinyusb_class_net_rndis`) can be used simultaneously to support all operating
systems, for example : systems, for example :
``` ```
CLASS='tinyusb_class_net_rndis tinyusb_class_net_cdc_ecm' \ CLASS='tinyusb_class_net_rndis tinyusb_class_net_cdc_ecm' \
BOARD=... make -C tests/pkg_tinyusb_netdev flash BOARD=... make -C tests/pkg/tinyusb_netdev flash
``` ```
In this case, the CDC ECM protocol is the default protocol and the RNDIS In this case, the CDC ECM protocol is the default protocol and the RNDIS
protocol the alternative protocol defined as second device configuration. protocol the alternative protocol defined as second device configuration.

View File

@ -77,6 +77,6 @@ Here are the steps required to train a new model and update the C++ files in the
4. Generate the C++ model files that will be included later in the RIOT build: 4. Generate the C++ model files that will be included later in the RIOT build:
``` ```
cd $RIOTBASE/tests/pkg_utensor cd $RIOTBASE/tests/pkg/utensor
utensor-cli convert /tmp/utensor-mnist-demo/mnist_model/deep_mlp.pb --target utensor --output-nodes=y_pred utensor-cli convert /tmp/utensor-mnist-demo/mnist_model/deep_mlp.pb --target utensor --output-nodes=y_pred
``` ```

View File

@ -16,7 +16,7 @@ variables `USB_VID` and `USB_PID` in the makefile or at the command line,
for example for example
``` ```
USB_VID=1234 USB_PID=5678 BOARD=... make -C tests/pkg_tinyusb_cdc_msc USB_VID=1234 USB_PID=5678 BOARD=... make -C tests/pkg/tinyusb_cdc_msc
``` ```
## Usage ## Usage