-
Notifications
You must be signed in to change notification settings - Fork 11
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
Comments
Thanks for the feedback. I think I know how to deal with this under linux. I've previously written this program: 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. |
@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. |
I just pushed some changes which add some improvements. See adae08d It still doesn't deal cleanly with the serial disappearing while its running. |
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.
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.
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.
The text was updated successfully, but these errors were encountered: