8000 tools: Add locking to pyboard.py serial port for linux and OSX by dhylands · Pull Request #2256 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

tools: Add locking to pyboard.py serial port for linux and OSX #2256

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

tools: Add locking to pyboard.py serial port for linux and OSX #2256

wants to merge 1 commit into from

Conversation

dhylands
Copy link
Contributor
@dhylands dhylands commented Jul 23, 2016 •
edited
Loading

This adds proper locking for the serial port on linux and OSX.

If a program like picocom or minicom has the serial port open and you try to run pyboard, you'll now get an error message.

@dhylands dhylands changed the title tools: Add locking to serial port for linux and OSX tools: Add locking to pyboard.py serial port for linux and OSX Jul 23, 2016
@pfalcon
Copy link
Contributor
pfalcon commented Jul 30, 2016

This adds whole bunch of code. Is it really that needed?

@dhylands
Copy link
Contributor Author

Well, it adds a bunch of code on the PC side of things (which personally I'm perfectly happy with). I know I've run into the problem myself numerous times having rshell (which derives from pyboard.py) fail to connect to the pyboard becuase I had some other terminal program running in the background.

If this isn't accepted here, I'll just add it to rshell, but logically the functionality belongs here. Logically, it probably belongs in a separate file, but I know in the past @dpgeorge has preferred to
keep pyboard.py as a single file and not add additional dependencies.

Every terminal program (piccom, minicom, screen, etc) has similar code.

So to summarize, it's not absolutely needed, but without it you get failures trying to run tests if you happen to have the repl open someplace else.

@pfalcon
Copy link
Contributor
pfalcon commented Jul 30, 2016

a bunch of code on the PC side of things

Yes, which may have bugs, or not work as expected for someone, etc.

I'm +0.5 on this, but let @dpgeorge decide on the merge.

@dhylands dhylands force-pushed the pyboard-lock branch 2 times, most recently from feaee5d to f580c22 Compare January 28, 2017 23:18
@dhylands
Copy link
Contributor Author

I fixed a couple minor issues and tested under Python2 & 3 on Windows, Linux, and OSX.

@dpgeorge
Copy link
Member

Running on Arch Linux I get the following error:

Traceback (most recent call last):
  File "./tools/pyboard.py", line 442, in <module>
    main()
  File "./tools/pyboard.py", line 382, in main
    pyb = Pyboard(args.device, args.baudrate, args.user, args.password, args.wait)
  File "./tools/pyboard.py", line 213, in __init__
    self.file_lock.lock()
  File "./tools/pyboard.py", line 162, in lock
    with open(self._lockname, 'w') as file:
PermissionError: [Errno 13] Permission denied: '/var/lock/LCK..ttyACM0'

Also, running picocom on the same device I don't see the LCK file... I assume that it's supposed to be a standard name that all programs create if they lock the device.

@dhylands
Copy link
Contributor Author

Hmm. I'll have to install Arch in a VM and try it out. I actually got the filename from the picocom source files, but picocom supports several different methods of locking. It's possible that Arch decided to implement something different.

tannewt pushed a commit to tannewt/circuitpython that referenced this pull request Nov 1, 2019
@brentru
Merge pull request micropython#2256 from brentru/master
08d1019 
Switch PyPortal Titano to 8-bit Mode
@dpgeorge
Copy link
Member

This is a useful feature but I think it's better suited to integrate as part of #6375, and to only cover the case of multiple pyboard.py's trying to open the same port (ie don't also try to protect against minicom/picocom/etc).

@dpgeorge dpgeorge closed this Apr 20, 2021
@davehylands
Copy link
Contributor

It looks like pyserial 3.3 added an exclusive argument to the init method.

@dpgeorge dpgeorge mentioned this pull request Apr 21, 2021
Merged
3 tasks
@dpgeorge
Copy link
Member

It looks like pyserial 3.3 added an exclusive argument to the init method.

Very nice! See #7141.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@dpgeorge dpgeorge

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@dhylands @pfalcon @dpgeorge @davehylands
0