Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

print a variable without print() function #44

Open
choies1 opened this issue Jun 29, 2019 · 4 comments
Open

print a variable without print() function #44

choies1 opened this issue Jun 29, 2019 · 4 comments

Comments

@choies1
Copy link

choies1 commented Jun 29, 2019

If I use a serial terminal, the following code shows the result (1)

a = 1
a 

However, if I use MicroPython-USB kernel in Jupygter notebook, I have to use the 'print()' function to display the result as follows.

a = 1
print(a) 

There is any method to display variable without print() function like normal serial terminal.

@goatchurchprime
Copy link
Owner

I've always wanted to have this one, but I think it's very difficult.

Here's some more information about how difficult it is, when I posted the request to the adafruit version:
adafruit/jupyter_micropython_kernel#8

The way this kernel works is it enters the raw REPL mode of the MicroPython board so that it can execute and retrieve results without getting stepped on from REPL output (like the >>> prompt, etc.). This is a nifty feature of MicroPython so that it can work with tooling like this notebook, upload tools like ampy, etc. It looks like though the raw REPL mode suppresses the default output of a variable repr result (i.e. just typing a variable name at the REPL is actually calling the variable's repr function internally and printing the result as a convenience). So the fix here would be to change MicroPython's raw REPL mode, but that could have knock on implications for tooling that depends on the current behavior and is outside the scope of this notebook. Stick with printing any state explicitly.

So basically, the serial connection to Micropython enters this raw mode (Control-A) which turns off the echoes and interactive outputs -- other than what is explicitly printed -- so you don't get normal behavior, like giving the final value.

I can't see a work-around. Fortunately it's not stopping any capabilities, other than the need to write "print()" round stuff.

@Carglglz
Copy link

Hi @goatchurchprime,

I have a solution to this (works the same for both SERIAL and WebREPL connections).
I use a library I'm currently developing upydevice which basically deals with sending commands and receiving the output.

The are some limitations like big code blocks or more than a block in a cell (although if they are defined within a function works great)

Another limitation is that for the serial communication I use picocom, which is not supported in windows, but in the future there may be an alternative...

If you are interested let me know ;).

@goatchurchprime
Copy link
Owner

I just tried it, but couldn't get it to work. It said it was connected, but nothing got executed on the board unfortunately. No errors were given. Can it connect to a device which is already running a program? Why the dependence on picocom when you already have the serial library?

You should steal my guessserialport() function so people don't need the hassle of looking it up on the operating system when there is only one ESP32 plugged in:
https://github.com/goatchurchprime/jupyter_micropython_kernel/blob/master/jupyter_micropython_kernel/deviceconnector.py#L11

@Carglglz
Copy link

Carglglz commented Jan 9, 2020

Hi, which class did you test that didn't work?

Can it connect to a device which is already running a program?

W_UPYDEVICE class needs WebREPL to be running/available to connect and sends commands so if a device is running a program/while loop you would need to use '.kbi()' method (Keyboard Interrupt) first to be able to send commands and receive output.

S_UPYDEVICE by default resets the device at initialization so if there is a while loop in main you would need to use '.kbi()' method first to be able to send commands and receive output too.

Why the dependence on Picocom when you already have the serial library?

Back in the day when I started to write the library it was easier for me ( in fact the only way I got it working) to use Picocom to write to its stdin and read from stdout (see Windows support) but now I got it working with just Pyserial, see this

You should steal my guessserialport() function so people don't need the hassle of looking it up on the operating system

Thanks for this!, I will definitely implement it in upydevice. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants