Trouble with DLL and file (com port) IO
R. Steve McKown
rsmckown@yahoo.com
Wed Dec 6 17:02:00 GMT 2006
Hello,
We have developed a USB-connected device that uses the Silicon Laboratories
cp2103 USB/serial chip. Communication from the host (PC) to the device is
done predominantly through the vendor's virtual com port, which works just
fine in cygwin (v1.5.12). We provide additional functionality through the
use of the cp2103's gpio pins, which are host controllable via a vendor
supplied DLL (compiled with VC++ 6.0, they provide the dll, .lib and .h
files). For example, initiating a firmware download to the device requires
manipulation of the cp2103 gpio bits.
We use the python programmer software provided by the TinyOS project to
program the device via USB. This works in Linux already (we extended the
linux driver to emulate the gpio capbilities of the vendor DLL). We're now
working to get gpio manipulation working in cygwin on windows xp.
FWIW, I'm using dlopen()/dlsym() to link to the DLL. 'nm' on the
provided .lib file shows decorations on the function names, even though they
are C. Perhaps the vendor didn't use "extern C {"? When linking with
the .lib I get symbol not found errors. Dynamically loading the DLL solves
this problem.
The DLL function uses an open HANDLE through to the com port to target the
device. A standalone C program and a simple python extension in C both
worked, performing these basic steps:
- dlopen()/dlsym() to load the DLL (on init)
- HANDLE = CreateFile("\\\\.\\COM10", ...)
- cp210xrt_WriteLatch(HANDLE, mask, bits)
- CloseFile(HANDLE)
However, the 'real' extension code accepts a file descriptor from Python,
since the python code already has the com port open. 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 next python program
statement after 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...?
I am new to cygwin, especially in terms of dll usage and other non-posix
realities. I'm hoping someone can see an obvious mistake, or suggest some
strategies to troubleshoot this problem.
Thank you for your time,
Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cp210x_rt.tgz
Type: application/x-tgz
Size: 222790 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20061206/58a58d73/attachment.bin>
-------------- next part --------------
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
More information about the Cygwin
mailing list