Pyserial持久化配置
我有这段代码用于将文件大小从 Linux 机器发送到嵌入式设备:
#send length
device_port = serial.Serial("/dev/ttyUSB1", 115200, timeout=3)
device_port.write(program_length_str)
#get response
answer = device_port.readline()
if answer != "OK":
print "Size transmit failed:"
print `answer`
device_port.close()
quit()
问题是,当我运行此代码时(它总是在此处退出),程序员(通过同一串行端口将固件加载到设备)以 错误的文件描述符
错误。重新插入设备(其中没有内部能源)没有帮助,我必须重新启动计算机。 Python 代码有什么问题?即使我重新插入设备(FT2232),错误的设置怎么可能仍然存在?
使用 Cutecom 打开端口可以对设备进行编程,但是当我再次关闭它时,错误又回来了。
更新 1:使用 strace
我发现第一个区别在于锁:
open("//var/lock/LCK..ttyUSB1", O_RDONLY) = 4in the beginning of successfull load,
open("//var/lock/LCK..ttyUSB1", O_RDONLY) = -1 ENOENT (No such file or directory)
失败时。第二个区别(以及整个错误)可能是加载程序中的错误,所以我在 工具链论坛(他们认为 read()
返回 0 是一个错误,调用 perror()
,但没有错误,因此 EBAFD 存储在之前的 errno 中)。但我对锁很好奇。我在 Cutecom 或 python 脚本(使用 strace)中找不到任何参考,但锁受到了某种影响。是否可以将这个问题迁移到 Unix & Linux 站点?
更新 2:正如我之前提到的,问题是串行端口上的 read()
返回 0。当我关注这一点时,我发现 read() 应该在非 - 中阻塞或返回 EAGAIN阻塞模式。在什么情况下 read() 调用可以返回 0?
更新 3:我通过使用 select()
调用等待设备来“解决”了加载器的问题。 PySerial 更改端口中的某些内容仍然存在问题。
I have this code for sending file size from linux machine to embedded device:
#send length
device_port = serial.Serial("/dev/ttyUSB1", 115200, timeout=3)
device_port.write(program_length_str)
#get response
answer = device_port.readline()
if answer != "OK":
print "Size transmit failed:"
print `answer`
device_port.close()
quit()
The problem is that when I run this code (it always quits here) the programmer (which loads firmware to the device over the same serial port) quits with the bad file descriptor
error. Replugging the device (no internal energy source in it) doesn't help, I have to reboot my computer. What is wrong with the Python code? How is it possible that the bad setting stays even when I replug the device (FT2232)?
Opening the port with cutecom enables programming the device, but when I close it again, the error is back.
UPDATE 1: Using strace
I found out that first difference is in locks:
open("//var/lock/LCK..ttyUSB1", O_RDONLY) = 4
in the beginning of successfull load,
open("//var/lock/LCK..ttyUSB1", O_RDONLY) = -1 ENOENT (No such file or directory)
on failure. The second difference (and the whole error) may be bug in the loader, so I wrote on the toolchain forum (they consider read()
returning 0 to be an error, call perror()
, but there was no error, so EBAFD is stored in errno from earlier). But I am curious about the the locks. I couldn't find any reference in cutecom or python scripts (using strace), but the locks are affected somehow. Would it be possible to migrate this question to the Unix & Linux site?
UPDATE 2: As I mentioned before, the problem is that read()
on the serial port returns 0. When I focused on this, I found out that read() should block or return EAGAIN in non-blocking mode. Under what circumstances the read() call can return 0?
UPDATE 3: I "resolved" the problem with the loader by wating for the device with the select()
call. There is still the problem with PySerial changing something in the port.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我不认为你的问题与Python有任何关系。
我在使用 Ubuntu 对 Arduino 进行编程时遇到了同样的问题 - 有时,在插入和拔出几次之后,Ubuntu 将不再识别我的设备。然后它就没有出现在
/dev/
中。我想这也是你问题的根源。
坏文件描述符
很可能告诉您您指定的路径实际上并不存在。您检查过/dev/ttyUSB0
吗?如果这不起作用,我建议将您的安装升级到可用的最新版本。I don't think your problem has anything to do with Python.
I faced the same problem when programming my Arduino using Ubuntu - sometimes, after a few times of plugging it in and unplugging it again, Ubuntu wouldn't recognize my device anymore. It then simply didn't show up in
/dev/
.I guess that's also the source of your problems.
bad file descriptor
most like tells you that the path you specified doesn't actually exist. Have you checked/dev/ttyUSB0
? If that doesn't work, I suggest to upgrade your installation to the newest one available.我在 python 串行和 ubuntu 上工作了很多,问题是 ubuntu 如何“安装”串行端口,有时会失败,并且......
你能发布你的 dmesg 输出吗?这可能有助于仔细检查问题的根源。
I worked quite a lot with python serial and ubuntu, and the problem is about how ubuntu 'mount' serial ports, sometimes fails, and ...
could you post your dmesg output? this may help to double check the root of the problem.