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 buffer: ('value',
> '\x8b|'). I was probably thrown off by the '|' in the string. Not
> sure why that gets returned. I guess to get a real value out of that
> buffer you have to use the 're' module or something.
>
You need to use your head to figure this out, and thinking of the "re"
module is not using your head.
The only way to pass buffers around in Python 2 is as strings. The
answer is that your ioctl is returning TWO bytes: 8B and 7C. It is not
uncommon practice in FX2 firmware to return an error code in the first
byte, so perhaps the port value is actually the second byte: 7C. You
can tell this for sure by checking the firmware source code.
If you really want to handle the result as hex byte values, you can use
struct or array:
import struct
s = '\x8b|'
t = struct.unpack('BB', s )
print [hex(i) for i in t]
import array
x = array('B')
x.fromstring( s )
t = x.tolist()
print [hex(i) for i in t]
> 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.
Are you getting two bytes here as well? What's the second byte?
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
