WIP: Multitests involving PICO-infra

[hmaerki]

Feature Request

Topic

Remove inappropriate lines below

• testbed_micropython (https://github.com/octoprobe/testbed_micropython)

Feature Description

Allow to involve the PICO-infra into a test.

Test scenario

Preparation: i2c of DUT and PICO-infra are electrically connected.

Setup: PICO-infra: Load software to to act as I2C target returning 42.
Setup: DUT: Initialize I2C controller
Step: DUT: read from I2C target
Expected result: Value 42 was red.

Proposed Solution

Alternatives Considered

Additional Context

[hmaerki]

@dpgeorge: I preparted a propose which I would to discuss with you tomorrow. If you find some time, please have a look at the two links below.

• See: https://github.com/hmaerki/fork_micropython/blob/proposal_multitest_i2c/tests/multi_i2c/

• See: https://github.com/octoprobe/testbed_micropython/blob/multitests-PICO-infra/src/testbed_micropython/testrunspecs/run_multi2c.py

• Required octoprobe dependency: https://github.com/octoprobe/octoprobe/tree/issue48_automatically-update-tentacles

[hmaerki]

@dpgeorge: We discussed the pin assignements for FUT_I2C_EXTERNAL and FUT_I2C_INTERNAL. Please review and comment/agree.

For FUT_I2C_EXTERNAL, I propose these pins: hmaerki/fork_micropython@e436c16
If you agree to this: Could you please resolder your pico tentacle and do a commit to the micropython repo?

For FUT_UART_EXTERNAL: There are no tests yet, you see the proposed pins below.

For FUT_SPI_EXTERNAL: On the tentalcle-PICO-infra, whe have to share pins between spi and i2c/uart. However, I have no solution on how to handle this. I recomment to not support FUT_SPI_EXTERNAL for the time beeing.

We decided to rename FUT_EXTMOD_HARDWARE to FUT_UART_INTERNAL, FUT_GPIO_INTERNAL, FUT_I2C_INTERNAL. However, I changed my mind and prefer to stay with FUT_EXTMOD_HARDWARE :

• There is no advantage in Octoprobe to handle different FUT's if we do not know the relation to the tests. It just brings confusion.
• FUT_EXTMOD_HARDWARE reflects nicly the the folder tests/extmod_hardware.

May we agree on these connections for the tentacle RPI_PICO2_W?

Connections

* Bootmode
  * Board TP6 (Bootsel) <=> Tentacle Relay 1b
  * Tentacle Relay 1a <=> Tentacle GND

* GND
  * Board GND <=> Tentacle GND

* FUT_EXTMOD_HARDWARE (tx/rx,pwm loopback)
  * Board GP0 <=> Board GP1

* FUT_EXTMOD_HARDWARE (I2C loopback)
  * Board GP4 (SDA) <=> Board GP6 (SDA)
  * Board GP5 (SCL) <=> Board GP7 (SCL)
  * Board GP4 (SDA) <=> R4k7 (Pullup) <=> Board 3V3 (pin 36)
  * Board GP5 (SCL) <=> R4k7 (Pullup) <=> Board 3V3 (pin 36)

* FUT_I2C_EXTERNAL (I2C towards PICO-infra)
  * Board GP10 (SDA) <=> Tentacle GPIO10 (SDA)                          # You used GP8
  * Board GP11 (SCL) <=> Tentacle GPIO11 (SCL)                            # You used GP9
  * Board GP10 (SDA) <=> R4k7 (Pullup) <=> Board 3V3 (pin 36)
  * Board GP11 (SCL) <=> R4k7 (Pullup) <=> Board 3V3 (pin 36)

* FUT_UART_EXTERNAL (UART towards PICO-infra)
  * Board GP12 (TX) <=> Tentacle GPIO13 (RX)
  * Board GP13 (RX) <=> Tentacle GPIO12 (TX)

[dpgeorge]

How about using the same pins for both FUT_I2C_EXTERNAL and FUT_UART_EXTERNAL? Namely pins GP12 and GP13. That has UART0 on it, and also I2C0. The UART will work just fine with pull-up resistors (they will actually make the UART RX more stable).

Or is there an advantage to having separate pins for UART and I2C?

Regarding SPI: we could use GP10, GP11, GP12, GP13 for that. Or GP12, GP13, GP14, GP15. Both of those sets have a full set of SPI1 connections. But GP12-GP15 has the advantage that it includes a 4-line UART interface (RX, TX, CTS, RTS).

Basically, if we wire through GP12-GP15 from Pico-infa to Pico-DUT, we have I2C0, I2C1, full UART0 and full SPI1.

[dpgeorge]

My idea doesn't work, because TX/RX must be swapped, and also SPI TX/RX must be swapped!

[hmaerki]

@dpgeorge Question about pin assignements and ESP32.

I try to make this test working machine_i2c_target.py:

elif sys.platform == "esp32":
    args_controller = {"scl": 5, "sda": 6}    <==== Pin 6 under question ====================
    args_target = (0,)  # on pins 9/8 for C3 and S3, 18/19 for others
    kwargs_target = {"scl": 9, "sda": 8}

See: https://docs.espressif.com/projects/esp-idf/en/v4.4/esp32/_images/esp32-devkitC-v4-pinout.png

Here it saids at bottom right: *Pin shared with Flash Memory. CLK cant be used as regular GPIO*

Question: Are the pin assignements for I2C loopback and I2C external correct and did they work?
Or shall I make a proposal? And if yes: Which boards should support I2C loopback and I2C external?

[dpgeorge]

Are the pin assignements for I2C loopback and I2C external correct and did they work?

I'm pretty sure I tested these, but note that I2CTarget does not work on standard ESP32, only ESP32-S2/S3/C3.

Or shall I make a proposal? And if yes: Which boards should support I2C loopback and I2C external?

Feel free to make proposals to adjust the pins. We need to change them anyway. S2/S3/C3 supports this feature.

[hmaerki]

@dpgeorge I Damien - I prepared a proposal for run-multitests.py

Links:

• proposal: run-multitests.py --target-wiring dpgeorge/micropython#20
• https://github.com/octoprobe/testbed_micropython/tree/multitests-PICO-infra

This is how far I got:

run-multitests.py
                --test-instance=port:/dev/ttyACM1,
                --target-wiring=target_wiring/rp2.py,
                --test-instance=port:/dev/ttyACM0,
                --target-wiring=target_wiring/rp2_octoprobe_infra.py,
                multi_extmod/machine_i2c_target_irq.py,
                multi_extmod/machine_i2c_target_memory.py"

Tests run find on DUT-rp2 vs infra-rp2.

I --target-wiring is specified, it has to be the same count as --test-instance. If --target-wiring= so it should detect the board as in detect_target_wiring_script(). However I got stock in applying detect_target_wiring_script().

Now tests/target_wiring/rp2.py includes the i2c-wiring as follows:

uart_loopback_args = (0,)
uart_loopback_kwargs = {"tx": "GPIO0", "rx": "GPIO1"}

i2c_args = (0,)
i2c_kwargs = {"scl": 9, "sda": 8}

The same for tests/target_wiring/rp2_octoprobe_infra.py

# Target wiring for rp2 on octoprobe tentacle.
#

i2c_args = (1,)
i2c_kwargs = {"scl": 11, "sda": 10}

In Octoprobe, I introduced FUT_I2C_EXTERNAL. It is expected that a board supports host and device. If host is not supported, then the test should skip.

run-multitests.py --permutations=1: Octoprobe runs two tests, one for host and one for device. This way we get _results.json for host and device and the summary report is clearer.

[dpgeorge]

I --target-wiring is specified, it has to be the same count as --test-instance

I don't think we need that restriction. If the user doesn't specify enough --target-wiring options, the remaining can be auto-detect.

If --target-wiring= so it should detect the board as in detect_target_wiring_script()

I think it's better to be explicit here and make it so --target-wiring=auto does the auto detection.

However I got stock in applying detect_target_wiring_script().

You'll need to call detect_test_platform() first to get all the relevant info about the board.