Behaviour when the Pyboard fails.
Opened this issue · 5 comments
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.
- 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. - 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. - 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.
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.
@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.
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.
Cool - I like the keyboard macros idea.