I have this code to send the file size from a Linux device to an 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 leaves here), the programmer (who downloads the firmware to the device via the same serial port) terminates with the bad file descriptor error. It is not possible to restart the device (there is no internal source of energy in it), I need to restart the computer. What is wrong with Python code? How is it possible that poor setup remains even when the device is reused (FT2232)?
Opening the port with cutecom allows you to program the device, but when I close it again, the error will return.
UPDATE 1: Using strace , I found that the first difference is in locks:
open ("// var / lock / LCK..ttyUSB1", O_RDONLY) = 4 at the beginning of a successful download,
open ("// var / lock / LCK..ttyUSB1", O_RDONLY) = -1 ENOENT (No such file or directory) upon failure. The second difference (and the whole error) may be an error in the loader, so I wrote on the toolchain forum (they believe that read() returns 0 to be an error, call perror() , but there was no error, so EBAFD is stored in errno from earlier). But I'm curious to know about castles. I could not find links to cutecom or python scripts (using strace), but the locks were somehow affected. Can this question be ported to Unix and Linux?
UPDATE 2: As I mentioned earlier, the problem is that read() on the serial port returns 0. When I focused on this, I found that read () should block or return EAGAIN in non-blocking mode. Under what circumstances can the read () call return 0?
UPDATE 3: I “resolved” the bootloader issue by accepting a call for the device with a select() call. There is still a problem with PySerial changing something in the port.