Main > Linux
Attempting to hack and document GunCon2 for Linux, FreeBSD, and MacOS X.
Numbski:
dewhodewhadehuh??
:laugh2:
Sorry, should explain that I'm not really a programmer, I just pretend to be one. Quick tutorial please? How would endianness throw the values so far off? Quick background on me...I'm a network engineer, and I have a mild amount of coding experience using perl. Please be gentle. :)
(Just look it up on wikipedia: http://en.wikipedia.org/wiki/Endianness ....and figures. byte ordering. Gee, not dealing with byte order here AT ALL. :P Now I need to figure out what order is being used and how. I have NO IDEA how to do that. :dunno )
Numbski:
Crap. I never knew that Little-Endian meant the byte order was FLIPPED. WTF???
Why on earth would you store your bytes backwards?
:soapbox:
(This, my friends, is why I went into MIS and not CS.)
So...yeah, byte order could be reversed to what these guys were seeing. Lovely.
Still doesn't make any sense. Take our trigger example again. This is what the gun returns for me when the trigger is pulled:
FF DF 01 00 05 00
Now, if I have big-endian, and they were small endian, then it would be this:
00 05 00 01 DF FF
The TopGun driver says it's looking for trigger input at 0x20. I'm presuming that 0x20 is a hex number (as 0x notation suggest), meaning each place is actually 16 and not 10, so 20 is really 2x16, or 32 bits in. Still makes no sense at all to me. :\ At some point today I'm giong to try to hack together a perl script that gives me the current value being spit out by /dev/ugen0.1 so that at very least I can identify what values are messed with by x-axis and y-axis.
Numbski:
Just occurred to me to try looking at this as hex octets. Don't know why...
FF FF 01 00 05 00
So...
255 255 1 0 5 0
The last 4 values don't really change doing that.
My tracking example was:
ff ff a6 03 f0 00
255 255 166 240 0
So it looks like octets 1 and 2 are button values, octets 3 and 4 are tracking values, and octet 5 is....padding? Maybe a delimiter? But that means at no time can you track larger than 255 in any given direction? We know that isn't true based on what you say about the Top Gun driver:
X Min = 160
X Max = 672
Y Min = 32
Y Max = 224
672 > 255. Hmm....
2600:
Ok, actually took a second to look at what you are saying. It's not an Endian Issue, not sure why I said that. But hey you learned something new.
I am having trouble of thinking of how to best describe this to you. I'm not sure if you have a grasp on bits, bytes, or hex notation and I don't have time provide a lot of help.
I only glanced at it and could be wrong so double check, but here's the trigger example:
FF FF 01 00 05 00 is your default.
FF DF 01 00 05 00 is when the trigger is pulled.
FF is hex notation for 1111 1111 in binary.
DF is hex notation for 1101 1111 in binary.
Notice only one bit changed when the trigger was pulled. The example code is masking that bit and if that bit is zero then the trigger is pulled.
That's the gist of it, sorry don't have time to help more.
Numbski:
Actually, I'm pretty good with it from doing subnet calculations, so yeah, I should have realized that as soon as I started looking at hex that only individual bits changed. I need to break this out in binary (which I was lazy and trying to avoid doing), and I'm sure a pattern will emerge from that.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version