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

Behaviour when the Pyboard fails. #5

Open
peterhinch opened this issue May 27, 2015 · 5 comments
Open

Behaviour when the Pyboard fails. #5

peterhinch opened this issue May 27, 2015 · 5 comments

Comments

@peterhinch
Copy link

There are three closely related rshell issues here. While to an experienced user these are easily resolved, they could be confusing to beginners and fixing them would give this excellent utility a more professional look.

  1. If you run rshell too soon after plugging in the Pyboard you get
    Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 275, in open
    self.fd = os.open(self.portstr, os.O_RDWR|os.O_NOCTTY|os.O_NONBLOCK)
    OSError: [Errno 16] Device or resource busy: '/dev/ttyACM0'
    plus further trace information.
    It would be good if it issued a message and waited for the board to become ready - perhaps with a timeout or an option to abandon.
  2. Its behaviour could be improved when the Pyboard crashes, is reset or is unplugged.
    If the Pyboard is temporarily removed in regular command mode the code gives no indication, but in the background Linux has re-instantiated the board as /dev/ttyACM1. Issuing repl will cause the code to fail with trace information. The user won't be able to restart it because the board is still on /dev/ttyACM1. It would be better if, in regular command mode, it detected the absence of the Pyboard and returned you to the Linux terminal with a suitable message.
  3. At the repl, disappearance of the Pyboard leads to a lot of trace information. It only returns to the Linux terminal when you type a character, by which time the returned Pyboard is again on /dev/ttyACM1. If it could gracefully return to the terminal before the Pyboard has a chance to re-appear, Linux would instantiate it on /dev/ttyACM0 allowing the program to be run again.
@dhylands
Copy link
Owner

Thanks for the feedback.

I think I know how to deal with this under linux. I've previously written this program:
https://github.com/dhylands/usb-ser-mon/blob/master/usb-ser-mon.py

which, under linux, deals quite gracefully with the serial port coming and going. With rshell, ny initial goal was to make something that worked cross platform.

I think I'll need to come up with different ways of reading the serial port for different platforms.

rshell currently relies on pyboard.py for all of the serial I/O when not using the "repl" command, and does its own I/O when using the repl command.

So I hear where you're coming from, and I definitely want this to be robust as possible.

I need to do some experiments to see if I can make it robust without having to resort to using udev (which is what usb-ser-mon does). And I'll also have to experiment on the other platforms as well.
Aside: I've also been working on a mechanism where if an exception is raised by the remote (say disk full or other error) then these will wind up getting rippled back to rshell.

@dhylands
Copy link
Owner

@peterhinch Just thought I'd let you know that I've been actively working on this.

I've written my own readline (similar functionality to the micropython one) all in python.

This will allow me to detect the serial port disappearing, even while sitting at the prompt and not interacting with the board. I'll still have a bunch of cleanup to deal with failures which occur during actual reads and writes, but I thought you'd like to know that progress is being made.

@peterhinch
Copy link
Author

Sounds good. I had a fairly slick way of working with aliases, keyboard shortcuts and a version of miniterm hacked to provide keyboard macros but I ditched it in favour of rshell. It's quick and avoids the need to mount the sd card. Once the serial port thing is fixed I think it should go in the docs as a recommended approach for beginners.

You might like to consider keyboard macros as a possible future enhancement. The Pyboard REPL has limited command history - and that history is erased by a D reset. To avoid repetitive typing I hacked miniterm to read a text file defining macros which could be replayed into the Pyboard, edited if required, and executed.

@dhylands
Copy link
Owner

Cool - I like the keyboard macros idea.

@dhylands
Copy link
Owner

dhylands commented Jun 3, 2015

I just pushed some changes which add some improvements. See adae08d

It still doesn't deal cleanly with the serial disappearing while its running.

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

2 participants