Re: [python-win32] kernal32.DeviceIoControl Operation Aborted

2008-12-19 Thread Tim Roberts
Red Rackham wrote: > Mystery solved. The value on the port had changed from 0x09 to 0x76 > from the time I used the c-based program to the time I came along and > red it in Python. Went back and used the c-based program and found > the port was indeed 0x76. > > I used your "array" example: >

Re: [python-win32] kernal32.DeviceIoControl Operation Aborted

2008-12-19 Thread Red Rackham
Mystery solved.  The value on the port had changed from 0x09 to 0x76 from the time I used the c-based program to the time I came along and red it in Python.  Went back and used the c-based program and found the port was indeed 0x76.   I used your "array" example:     x = array.array('B')     x.f

Re: [python-win32] kernal32.DeviceIoControl Operation Aborted

2008-12-19 Thread Red Rackham
Eureka!  After the function returned I did a print on getmembers(buffer) and I found the data (except for the pipe character).   If the function had returned all port values I would expect it to return: OEA, IOA, OEB, IOB, OEC, IOC, OED, IOD, OEE, IOE which I expected to look like: 0x8B, 0x09, 0x00

Re: [python-win32] kernal32.DeviceIoControl Operation Aborted

2008-12-19 Thread Tim Roberts
Red Rackham wrote: > > I think I have finally figured it out. Thanks for the suggestion, I > ran the executable (compiled C code) and it worked, and it returned 0x8B. > > Previously I saw this value and thought was bunkum. I thought it was > incorrect because of the way ctypes encodes a string

Re: [python-win32] kernal32.DeviceIoControl Operation Aborted

2008-12-19 Thread Red Rackham
Except that now I'm trying to read PORTD which is also returning the same value (0x8B) but I'm expecting a different value.  So either it's just a coincidence that I read 0x8B, or I have my data aligned wrong and it's getting a '0' in the field where it's expecting a 7 for PORTD.   ___

Re: [python-win32] kernal32.DeviceIoControl Operation Aborted

2008-12-19 Thread Red Rackham
I think I have finally figured it out.  Thanks for the suggestion, I ran the executable (compiled C code) and it worked, and it returned 0x8B.   Previously I saw this value and thought was bunkum.  I thought it was incorrect because of the way ctypes encodes a string buffer: ('value', '\x8b|').