REPL over BLE

[ghost]

The import multiterminal is not available.

I'd like to use it for repl over BLE (using the BLE uart class).

[dhalbert]

multiterminal only ever worked on the ESP8266 port, which is now discontinued. We would like a BLE REPL, and it's in our long-term plans.

[ghost]

Would you be interested in a PR where the terminal compatible with UART, etc:

class myterminal:
    def write(text: bytes) -> None:
        pass
    def read() -> bytes:
        pass
    def in_waiting() -> int:
        pass

These functions would be called from supervisor/shared/serial.c, with the api in shared-modules/multiterminal.

[tannewt]

@iot49 My preference would be to finish the proper CircuitPython BLE support that uses nordic uart for REPL and a custom service for file transfers. We have an old issue for it here: #1010 and I'd love to chat with you about next steps if you have cycles to work on it.

Basically, I want it to be core to CircuitPython, not just a hook from the VM, because it can work outside the VM then too.

[ghost]

@tannewt Your plans are much further reaching.

I believe both are needed. multiterminal is more generic, e.g. also works for sockets, and can be abused to capture stdout.

My specific need is to control a robot wirelessly (for obvious reasons). I program via jupyter (https://github.com/iot49/iot-kernel) and manage file upload/download over the repl. A dedicated solution (with microcontroller support) would be faster, but I have not found this to be a limitation in my experience.

Not sure what "because it can work outside the VM then too" (I know little about the VM and even less about anything that's running outside it) refers to.

In any case, my need is for multiterminal with pretty much the present api. A more nuanced policy between access of the flash via usb and from circuitpython would be helpful but not required.

[tannewt]

What I mean by "outside the VM" is the code that runs after a crash or code.py completes. If you use multiterminal to update files, then you risk locking yourself out by an error. How are you handling that currently?

[ghost]

The REPL connection library (https://github.com/iot49/iot-device) I have is very reliable. Plug, unplug, press reset, whatever - the devices come reliably online on go off. Very reliable; I never got locked out (try if you like :).

However I once corrupted the flash when editing directly on it. Now I edit my sources on the host, and update with rsync (my implementation, runs over the REPL, however it is connected, soon by BLE). This way I also always have a backup (on the host).

[ghost]

Thinking of it,

This certainly would be a bad idea - code.py:

while True: pass

I protect in boot.py against this in boot.py:

try:
    # CircuitPython specific
    import board
    import digitalio
    import storage

    with digitalio.DigitalInOut(board.D0) as mode:
        # mount CIRCUITPY if D0 pulled low ...
        mode.pull = digitalio.Pull.UP
        storage.remount("/", readonly=not mode.value)
except ImportError:
    pass

But I agree, that's definitely better handled with your solution.

[tannewt]

This was added in #4957