Hello, I'm writing a C extension for cygwin python to access a vendor supplied DLL that allows one to set the general purpose IO (gpio) pins of the Silicon Labs' cp2103 USB/serial chip. We communicate to the device using the vendor's virtual com port driver, but the gpio pins allow us access to other functions, like resetting the device and initiating a firmware download. The DLL provides a function, CP210xRT_WriteLatch which sets the gpio pins. It accepts the HANDLE of the open device's com port, a bit mask, and a bit data field to perform its task.
Note: I load the DLL dynamically within the extension's init function. Even though the DLL functions are C, apparently the vendor did not use "extern C {", as the functions have C++-like decorations (seen via 'nm' on the .lib file) and cygwin's gcc linker generates symbol not found errors when linking to the provided .lib. Dynamically loading the library works. FWIW, the DLL is said to be compiled via VC++ 6.0. Also using the vendor supplied .h file. The extension code, python test program, stackdump output and program run output are included in the attached tgz file for reference. Th extension accepts a file descriptor to an open serial port, uses the cygwin get_osfhandle() function to get the corresponding HANDLE, calls the DLL function, then returns. When run, python core dumps somewhere between the return statement in the extension function and the python program statement following the call to the extension function. The gpio bits are set correctly. If I comment out the call to the DLL function within the extension, no core dump. Obviously, the gpio bits are not set in this case. If I do not open the com port in the python program, but instead call CreateFile/CloseFile within the extension itself and using the HANDLE provided by CreateFile to call the DLL function, the gpio bits are set and no core dump. I could live with this approach if Python could have the com port open when it calls the extension. When I try this, the extension's call to CreateFile to open the com port always fails, presumably because the serial module opens it in some manner that doesn't allow sharing...? Being relatively new to Python, I'm hoping someone can see an obvious mistake, or suggest some strategies to troubleshoot this problem. Thank you for your time, Steve
cp210x_rt.tgz
Description: application/tgz
-- http://mail.python.org/mailman/listinfo/python-list