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