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
