This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Trouble with DLL and file (com port) IO


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

Attachment: cp210x_rt.tgz
Description: application/tgz

--
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/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]