s2m
s2m copied to clipboard
Can't detect device in Windows 7
I followed the user guide, but can't detect device either by autodetecting or specifying serial port. After modifying serial port detecting part in s2m.py, I can detect device either by autodetecting or specifying serial port now.
Original code:
# if no com port was specified, try doing auto discover.
if com_port is None:
print('Autodetecting serial port. Please wait...')
if sys.platform.startswith('darwin'):
locations = glob.glob('/dev/tty.[usb*]*')
locations = glob.glob('/dev/tty.[wchusb*]*') + locations
locations.append('end')
# for everyone else, here is a list of possible ports
else:
locations = ['dev/ttyACM0', '/dev/ttyACM0', '/dev/ttyACM1',
'/dev/ttyACM2', '/dev/ttyACM3', '/dev/ttyACM4',
'/dev/ttyACM5', '/dev/ttyUSB0', '/dev/ttyUSB1',
'/dev/ttyUSB2', '/dev/ttyUSB3', '/dev/ttyUSB4',
'/dev/ttyUSB5', '/dev/ttyUSB6', '/dev/ttyUSB7',
'/dev/ttyUSB8', '/dev/ttyUSB9',
'/dev/ttyUSB10',
'/dev/ttyS0', '/dev/ttyS1', '/dev/ttyS2',
'/dev/tty.usbserial', '/dev/tty.usbmodem', 'com2',
'com3', 'com4', 'com5', 'com6', 'com7', 'com8',
'com9', 'com10', 'com11', 'com12', 'com13',
'com14', 'com15', 'com16', 'com17', 'com18',
'com19', 'com20', 'com21', 'com22', 'com23', 'com24',
'com25', 'com26', 'com27', 'com28', 'com29', 'com30',
'com31', 'com32', 'com33', 'com34', 'com35', 'com36',
'com1', 'end'
]
detected = None
for device in locations:
try:
self.micro_bit_serial = serial.Serial(port=device, baudrate=115200,
timeout=.1)
detected = device
break
except serial.SerialException:
if device == 'end':
print('Unable to find Serial Port, Please plug in '
'cable or check cable connections.')
detected = None
exit()
except OSError:
pass
self.com_port = detected
Modified:
# if no com port was specified, try doing auto discover.
if com_port is None:
print('Autodetecting serial port. Please wait...')
# listing all serial ports and checking if there is a micro:bit board
import re
from serial.tools.list_ports import comports
for port, desc, opts in comports():
if 'VID:PID=' in opts:
vid, pid = re.search('VID:PID=(\w+):(\w+)', opts).groups()
vid, pid = int(vid, 16), int(pid, 16)
if vid == 0x0D28 and pid == 0x0204:
self.com_port = port
break
if self.com_port is None:
print('Unable to detect Serial Port, Please plug in '
'cable or check cable connections.')
sys.exit(0)
F.Y.I. ref: ntoll/microrepl
Some questions: 1.What port are you using. 2. What version of pyserial do you have installed? 3. What version of python are you using?
- I'm using COM4 now.
- pyserial: 3.4
- python: 3.6.4
2 more questions:
- Are you running in a virtual environment?
- What program are you using to flash the micro:bit? If it is Mu, would you know approximately when you installed it?
- No
- Mu, after scratch and python are installed.
I will try to reproduce what you are seeing later today and will let you know the outcome.
I was able to reproduce the issue you had with manually setting the com port and that has been repaired in version 2.0. I cannot reproduce the auto detect issue. I do not have Windows 7, but doubt if that is the cause of your problem. I tested on Windows 10.
I had tried the same code you provided for auto-detection earlier in the development stages but had issues with it working across all platforms. In addition, it requires a driver to be installed for Windows usage, and many schools are very reluctant to have any drivers installed on their machines. Therefore, I will be keeping the auto-detection as-is.
Please try version 2.0 and manually specifying the com port with the -p command line option.
I will be closing this issue, but if you are still having problems, please leave a comment here, and I will reopen it if necessary.
Thanks.
I tried version 2.0 and -p command works, but I need autodetecting in class indeed...
I tried to find out the problem and found that the program will just use first (not micro:bit device) in [locations].
Below is the outcome:
I am not sure I understand. Is there a device plugged into COM2 and that is why it is stopping there?
I think COM2 is used by Intel Chipset which is part of motherboard.
I will look at this to see if I can come up with a fix.
I tried implementing a fix, but because pyserial has changed its API from 2.7 to 3.0, I will need to add a lot of complicated code to do board detection within the auto detection loop. I need to support pyserial 2.7 through 3.4 so that current users do not need to update pyserial to a specific release.
Because the problem is specific to your motherboard, and it is unlikely that I will be making any additional changes to s2m for Scratch 2.0 in the future, I suggest that you clone the code and add the code that solves the problem for you.
Therefore, I am marking this issue as an enhancement for when Scratch 3.0 is released.
Please feel free to leave any additional comments or questions here.
Thanks for your hard work, this project is very helpful in class!
@MrYsLab Pyserial allows you to iterate over all available ports and query their VID and PID (http://pyserial.readthedocs.io/en/latest/tools.html#serial.tools.list_ports.ListPortInfo.vid) if they are available for the specific port (not all COM ports will have it, as these are USB IDs). You can use that feature to identify connected micro:bits: https://support.microbit.org/support/solutions/articles/19000035697-what-are-the-usb-vid-pid-numbers-for-micro-bit
@carlosperate Unfortunately, this does not work with pyserial 2.7 and Linux (and perhaps Windows and Mac as well - I can't remember). Because I don't want to publish a breaking change release at this time, and because Scratch 2.0 is unlikely to be supported once Scratch 3.0 is released, I will wait to address this until Scratch 3.0 comes out. Scratch 2.0 and 3.0 extensions are likely to be incompatible and will need to be rewritten.
That's fair enough.
Out of curiosity, where does the PySerial 2.7 requirement come from? Is that the default version installed in some systems? If needed be, you could bundle your own copy of PySerial, I believe it's a pure Python package, and the latest version is compatible with both Python 2 and 3 out of the box (older versions did some code conversion when the package was installed in Python3 environments).
I normally don't like to bundle other libraries with mine, since it means I may need to provide updates as fixes come available for the external package. I guess if it is working I can ignore any future changes. I will do some experimenting and if bundling works, I will create a new version and close this issue.
I am having problems with bundling working across python 2, python 3, windows and linux, so I am going to leave things as they are.
No worries, thanks for looking into it.