rshell - Remote Shell
Re: rshell - Remote Shell
dhylands, would you consider publishing rshell on PyPI?
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/
Re: rshell - Remote Shell
pfalcon yeah - let me figure out what I need to do to make that happen, and I'll start publishing that way.
I've started by putting rshell in its own repo. I'll get some accounts setup and figure out what else I need to do.
I've started by putting rshell in its own repo. I'll get some accounts setup and figure out what else I need to do.
Re: rshell - Remote Shell
rshell (version 0.0.1) is now in PyPI: https://pypi.python.org/pypi?:action=di ... sion=0.0.1 (This is my very first PyPi package).
You can install it using: If you're using a virtualenv, then you can drop the sudo.
The repo can be found here: https://github.com/dhylands/rshell
Once its installed, the installer will add rshell into your PATH (previously you would invoke it using rshell.py).
You can install it using:
Code: Select all
sudo pip3 install rshell
The repo can be found here: https://github.com/dhylands/rshell
Once its installed, the installer will add rshell into your PATH (previously you would invoke it using rshell.py).
Re: rshell - Remote Shell
Dave,
Looking at using rshell to communicate with pyboard via wireless serial connection.
Do you know how critical timing is for serial connection/communication?
More particularly with timing when transferring files, there can be all sorts of time delays involved?
Is there any error detection/correction/retries used when transferring files through serial port?
Regards
John
Looking at using rshell to communicate with pyboard via wireless serial connection.
Do you know how critical timing is for serial connection/communication?
More particularly with timing when transferring files, there can be all sorts of time delays involved?
Is there any error detection/correction/retries used when transferring files through serial port?
Regards
John
Re: rshell - Remote Shell
It really depends on the serial protocols that are used. Some serial protocols are quite robust. The protocol that rshell uses is fairly fragile.EasyRider wrote:Dave,
Looking at using rshell to communicate with pyboard via wireless serial connection.
Do you know how critical timing is for serial connection/communication?
I'm not sure exactly what you mean. I don't think that rshell has delays built in. pyboard.py (which rshell is based on) may have some.More particularly with timing when transferring files, there can be all sorts of time delays involved?
rshell doesn't use any.Is there any error detection/correction/retries used when transferring files through serial port?
One of the things I've discovered with rshell is that having it work properly depends quite heavily on the buffer sizes. When using USB serial there are some rather large buffers in play, and rshell's default buffer size of 512 bytes seems to work well. Howver, when ransferring files over a real serial interface, there is typically only a 64 byte buffer on the UART. So as long as rshell's buffer size is smaller than this then file transfer seem to work. rshell has a --buffer-size argument fo control how much data it buffers before sending an ACK during file transfers.
One of the pluses with rshell is that it doesn't require you to install any special software on the pyboard to use it, which in turn means that it doesn't get to use a very robust transfer mechanism. I've been thinking about ways to improve on this.
Re: rshell - Remote Shell
In a noisy wireless environment I need a more robust serial protocol for file transfer, with more flexible timing, CRC, ACK and retries.
Have come across Python XModem and will see if it can be ported/modified for pyboard.
https://pythonhosted.org/xmodem/xmodem.html
https://github.com/tehmaze/xmodem
On the PC host side, terminals like Tera_Term already support Xmodem file transfer.
Need to check if wireless Xbees support 128 byte packets.
Have come across Python XModem and will see if it can be ported/modified for pyboard.
https://pythonhosted.org/xmodem/xmodem.html
https://github.com/tehmaze/xmodem
On the PC host side, terminals like Tera_Term already support Xmodem file transfer.
Need to check if wireless Xbees support 128 byte packets.
Re: rshell - Remote Shell
Direct download link for xmodem 0.4.2, includes 2.7 and 3.4 Python versions.
https://pypi.python.org/pypi/xmodem#downloads
https://pypi.python.org/pypi/xmodem#downloads
Re: rshell - Remote Shell
X/Y/ZMODEM (or perhaps some minor variant which would allow even smaller packets) is one of the candidates that I've been looking at using for a more robust rshell transfer (not just for files, but for all of the information going back and forth).
Re: rshell - Remote Shell
I was trying to get rshell to work with the Adafruit Huzzah ESP8266 and the doit ESP8266 DevKit V2 . . . I modified the code in main.py to check for and validate the relevant USB\VID for these boards in addition to the pyBoard and it then found and connected to them.
[code]
def is_micropython_usb_device(port):
"""Checks a USB device to see if it looks like a MicroPython device.
"""
if type(port).__name__ == 'Device':
# Assume its a pyudev.device.Device
if ('ID_BUS' not in port or port['ID_BUS'] != 'usb' or
'SUBSYSTEM' not in port or port['SUBSYSTEM'] != 'tty'):
return False
usb_id = 'usb vid:pid={}:{}'.format(port['ID_VENDOR_ID'], port['ID_MODEL_ID'])
else:
# Assume its a port from serial.tools.list_ports.comports()
usb_id = port[2].lower()
# We don't check the last digit of the PID since there are 3 possible
# values.
if usb_id.startswith('usb vid:pid=f055:980'):
return True;
elif usb_id.startswith('usb vid:pid=1a86:752'):
return True;
elif usb_id.startswith('usb vid:pid=10c4:ea6'):
return True;
return False
[/code]
Whilst it then listed files that are on the board in response to a "boards" command, it cvrashed when I tried to "cat" the files or take any other action . . . any help on this would be appreciated?
[code]
def is_micropython_usb_device(port):
"""Checks a USB device to see if it looks like a MicroPython device.
"""
if type(port).__name__ == 'Device':
# Assume its a pyudev.device.Device
if ('ID_BUS' not in port or port['ID_BUS'] != 'usb' or
'SUBSYSTEM' not in port or port['SUBSYSTEM'] != 'tty'):
return False
usb_id = 'usb vid:pid={}:{}'.format(port['ID_VENDOR_ID'], port['ID_MODEL_ID'])
else:
# Assume its a port from serial.tools.list_ports.comports()
usb_id = port[2].lower()
# We don't check the last digit of the PID since there are 3 possible
# values.
if usb_id.startswith('usb vid:pid=f055:980'):
return True;
elif usb_id.startswith('usb vid:pid=1a86:752'):
return True;
elif usb_id.startswith('usb vid:pid=10c4:ea6'):
return True;
return False
[/code]
Whilst it then listed files that are on the board in response to a "boards" command, it cvrashed when I tried to "cat" the files or take any other action . . . any help on this would be appreciated?
Re: rshell - Remote Shell
Hi,
Sorry - I've been totally swamped for the past month or so and have had to curtail my MicroPython development, so rshell has been negelected.
I haven't even had time to flash my esp board.
The ESP doesn't have native USB support, so the USB IDs that you're providing are for USB-to-serial converters which are not unique to the esp. For example 1064:EA60 is also used by the Aeotech Z-Stick S2 Z Wave dongle (it probably uses the same USB-to-serial chip internally).
Before I got swamped, I was investigating issues with rshell over UART (on the STM32F401). One of the issues is lack of flow control. Currently the rshell buffers are sized for native USB links. On the stmhal, the default UART buffer is 64 bytes, and I had some success using --buffer-size=32 when running with rshell. I expect you'll need to do something similar with the ESP chips.
Sorry - I've been totally swamped for the past month or so and have had to curtail my MicroPython development, so rshell has been negelected.
I haven't even had time to flash my esp board.
The ESP doesn't have native USB support, so the USB IDs that you're providing are for USB-to-serial converters which are not unique to the esp. For example 1064:EA60 is also used by the Aeotech Z-Stick S2 Z Wave dongle (it probably uses the same USB-to-serial chip internally).
Before I got swamped, I was investigating issues with rshell over UART (on the STM32F401). One of the issues is lack of flow control. Currently the rshell buffers are sized for native USB links. On the stmhal, the default UART buffer is 64 bytes, and I had some success using --buffer-size=32 when running with rshell. I expect you'll need to do something similar with the ESP chips.