开发者

Pyserial persistent configuration

I have this code for sending file size from linux machine to embedded device:

#send length
device_port = s开发者_开发知识库erial.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.


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.


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.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜