Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Hi Pete and anyone else that can help,

I've had a thought today whilst at work and just wondered if someone could confirm if this is possible or not, I understand that offsets 66c0 -> 66FF can be used for personal use.

I currently use a payware aircraft that does not have any output offsets that I know about - I've decoded all the VC buttons to LVAR values and have written a .lua script to handle the buttons that I am programming through my BU0863X card so for example...

if ipcPARAM == 1 then
	 ipc.writeLVARS("example_lvar", 1);
end

So I configure my button on my joystick (or in this case connected to the BU0863X card) and choose the action from the drop-down menu in FSUIPC and then specify the parameter as '1' as I want to set the above LVAR as to mimic pushing a button in the cockpit and this works great for 'inputs' but I want to also have some LED's in my cockpit too :)

Am I right in assume that if I was to add for example ipc.writeSB() like so:-

-- Turn ON my example button

if ipcPARAM == 1 then
	 ipc.writeLVARS("example_lvar", 1); // The switch in the aircraft is now turned ON!
	 ipc.writeSB("66C0", 1); // The 'output' LED is now turned ON!
end

That I could then use my OpenCockpits USBOutputs card to 'READ' the value of the 66C0 offset and it would read '1' or when turned off like in my next example (below) would read '0'....

-- Turn OFF my example button
if ipcPARAM == 2 then
	 ipc.writeLVARS("example_lvar", 0); // The switch in the aircraft is now turned OFF!
	 ipc.writeSB("66C0", 0); // The 'output' LED is now turned OFF!
end

I hope this makes sense and even better, if it is possible to both read and write to these offsets that would be amazing!! - I only hope that I haven't misunderstood the 66C0 -> 66FF offset range's purpose :S

Many thanks in advance,

Bobby

Posted

I've had a thought today whilst at work and just wondered if someone could confirm if this is possible or not, I understand that offsets 66c0 -> 66FF can be used for personal use.

Yes, they are 'reserved' for general use by anyone.

Am I right in assume that if I was to add for example ipc.writeSB() like so:-

-- Turn ON my example button

if ipcPARAM == 1 then
	 ipc.writeLVARS("example_lvar", 1); // The switch in the aircraft is now turned ON!
	 ipc.writeSB("66C0", 1); // The 'output' LED is now turned ON!
end

That I could then use my OpenCockpits USBOutputs card to 'READ' the value of the 66C0 offset and it would read '1' or when turned off like in my next example (below) would read '0'....

I don't know the OpenCockpits software, but if it is capable or reading specified offsets and operating indicators according to the values it reads then, yes, that will work.

If you are going to have a lot of indicators driven in this way, and if the OC software can handle bits not just bytes, then you might want to consider using the ipc.setbitsUB and ipc.clearbitsUB functions instead. You'd get 8 switches per byte then.

Regards

Pete

Posted
I don't know the OpenCockpits software, but if it is capable or reading specified offsets and operating indicators according to the values it reads then, yes, that will work.

Excellent and as far as I know it does work :) - I'll have a play when I get home later this evening and fingers crossed it will work great :smile: as that would be great! :smile:

If you are going to have a lot of indicators driven in this way, and if the OC software can handle bits not just bytes, then you might want to consider using the

I will have several yes and I will of-course take your advice and use the setbits and clearbits method if I can :)

I therefore assume that each of the following are valid....

ipc.setbitsUB("66C0" , 1) -- Switch One On (1st bit in the first offset now equal to '1')
ipc.setbitsUB("66C0" , 2) -- Switch Two On (2nd bit in the first offset, now equal to '1')
-----
ipc.setbitsUB("66C0", 8) -- Switch Eight On (8th and last bit in the first offset, now equal to '1')


ipc.setbitsUB("66C1", 1) -- Switch On (1st bit in the second usable offset), now equal to '1'.)
ipc.clearbitsUB("66C1", 1) -- Turn off the last switch (bit) as above, now equal to '0')
----

^ I just want to make sure that I fully understand what you are saying Pete? :)

... Uber excited that in theory I could create all my own outputs for my switches!! :smile:

Posted

I therefore assume that each of the following are valid....

ipc.setbitsUB("66C0" , 1) -- Switch One On (1st bit in the first offset now equal to '1')
ipc.setbitsUB("66C0" , 2) -- Switch Two On (2nd bit in the first offset, now equal to '1')
-----
ipc.setbitsUB("66C0", 8) -- Switch Eight On (8th and last bit in the first offset, now equal to '1')

No. The first two are correct, but evidently not for the reasons you think. The setbits and clearbits functions deal with multiple bits -- you can set and clear any of the bits in one call. so the values are not bit numbers (if they were you'd be wrong on all three, because bit numbers are always counted from 0 -- the power of 2 represented, 2^0 = 1, 2^1 = 2 etc).

So, bit 0 is represented by 1, bit 1 by 2, bit 2 by 4 (2^2), and so on, up to bit 7 by 128 (2^7). In binary each next bit doubles the value, same as in decimal each next digit multiplies by 10.

If you had 8 indicators in one BYTE, you could set them all by "setbits" with 255, and clear them all with "clearbits" with 255, because 255 = 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1.

Regards

Pete

Posted

Ahh ok, I think I understand fully now then, so...

ipc.setbits("66C0", 65) --Turn on both bits 1 and 7
ipc.clearbits("66C0", 65) -- Turn off both bits 1 and 7 (leaving the rest in their current state)
ipc.setbits("66C0", 128) -- Turn ON bit 8 (leaving the rest in their current state? - Or would this just turn off all others and just turn on the 8th?)
ipc.clearbits("66C0", 255) -- Turns off ALL bits in the offset regardless!

If my third example is in fact just turning ON the 8th and resetting the rest, I'll need to do some maths with a LUA function I suppose to read the current value and then add on the additional 128 (to turn on the 8th bit as well as the current ones that are already 'on'). - I hope that I have now fully understood :)

Pete - Thanks for your help - You are amazing and truly dedicated to supporting this great software :smile:

Posted

I actually see from reading your post a second time that my third example above, that is would only turn on bit 8 whilst resetting the others so I guess I'll have to devise a LUA function to add or subtract bit values from the current state of an offset.

I'll read up again on your FSUIPC LUA documentation and I guess I will find something like:

ipc.readbits("66C0");

to which I can then do something like:-

if ipcPARAM == 1 then  -- turn on the 7th bit leaving the rest intact!
   bitval = ipc.readbits("66C0")
   newbitval = (bitval+64)
   ipc.setbits("66C0", newbitval)
end

if ipcPARAM == 2 then   -- turn off the 7th bit leaving the rest intact!
   bitval = ipc.readbits("66C0")
   newbitval = (bitval-64)
   ipc.setbits("66C0", newbitval)
end

Posted

Actually I see a problem with using the 'setbits' in my project, most of the buttons are mapped to Mouse macros that I cannot get the value of so I suppose if I was to press a toggle switch (which runs a mouse macro) I wouldn't easily be able to get the value of the bit for that toggle switch (eg if that 'bit' within the byte was previously on or off) unless I could check the status of a bit within the byte and not just return the offset value as a whole.

... I should probably just stop wasting your time and just read the documentation again! - If all else fails I will just use the offsets with writeUB instead of setbits.

Thanks Pete - you are a gentleman!

Posted

Just a quick note that might help you Bobby. I use those user-defined offsets in my control configuration setup and one thing

I find very usefull is the ability to display up to 4 offsets through the FSUIPC4 Logging facility.

I use offset ox66C0 to control the "mode" my controls operate in and I have that offset value "permanently" displayed

in the title bar so that I can see at a glance what "mode" I am in (I change modes by incrementing/decrementing 0x66Co

with 2 of my momentary switches). I also use several other offsets in that range to trigger Lua functions.

When debugging/testing any changes using other offsets, I just change the logging settings to display those offset values.

Makes it a lot easier to actually "see" what you are doing...or not :)

Paul

Posted

Ahh ok, I think I understand fully now then, so...

ipc.setbits("66C0", 65) --Turn on both bits 1 and 7
ipc.clearbits("66C0", 65) -- Turn off both bits 1 and 7 (leaving the rest in their current state)
ipc.setbits("66C0", 128) -- Turn ON bit 8 (leaving the rest in their current state? - Or would this just turn off all others and just turn on the 8th?)
ipc.clearbits("66C0", 255) -- Turns off ALL bits in the offset regardless!

Well, apart from you calling bits 0-7 "1-8", yes, essentially that is correct. You only affect the bits in the value you provide.

Please see the FAQ about numbers, in the FAQ subforum. You should think of these numbers in BINARY, then you'll se what is going on. 65 in a binary 8-bit byte is 0 1 0 0 0 0 0 1, reading from high to low (as you do in decimal numbers of course). So your "bit 1" is the last bit, your bit 8 is the first. But really they should be numbered from 0 -- because then their numeric value corresponds to the power of two, as I already explained but you missed (?): bit 0 = 2^0 = 1, bit 1 = 2^1 = 2, bit 2 = 2^2 = 2x2 = 4, bit 3 = 2^3 = 2 x 2 x 2 = 8, and so on.

If my third example is in fact just turning ON the 8th and resetting the rest.

No it isn't. That would happen with "ipc.writeUB". The whole point of the "setbits" and "clearbits" functions is to only set and clear the bits you specify!

I suppose to read the current value and then add on the additional 128 (to turn on the 8th bit as well as the current ones that are already 'on')

That's exactly what "setbits" does, and what it is for.

I actually see from reading your post a second time that my third example above, that is would only turn on bit 8 whilst resetting the others

How on Earth did you derive that from what I said? My English must be atrocious! :sad:


bitval = ipc.readbits("66C0")
newbitval = (bitval+64)
ipc.setbits("66C0", newbitval)

[/CODE]

Oh dear. What's the point of me providing "setbits" and "clearbits" to handle bits for you if you treat them as if they are straight "read" and ""write"? Because that's what you appear to be assuming, somehow. :sad:

In any case, even with read and write that code wouldn't work. You should not ADD 64 -- if the 64 bit was already set that would amount to 128! You'd have to OR the bit in, using the l[b]ogic.Or[/b] function! To remove bits you'd have to use [b]logic.And[/b]. The setbits and clearbits functions replace three separate function calls.

I should probably just stop wasting your time and just read the documentation again!

The documentation doesn't teach you basic things about numbers, bits and bytes, which is clearly where you are fundamentally misunderstanding things. Please check that FAQ I mentioned, to start with, and please read what I've actually written in my replies -- don't make assumptions and skip over things so much!

I really can't understand how you've ended up where you have from what I've said. I think I might give up trying to explain simple things. I am obviously not very good at it.

:sad:

Pete

Posted

Sorry Pete, It was my mistake - I had been working all day and was extremely tired and I should have realised a few things which at the time but they just passed me by... firstly the fact that 'setbits' and 'clearbits' - the words alone state the usage of the methods/functions. - I am actually a software developer myself so I should have known better!

And your correct where I was addressing the bits incorrectly, I mean't my 'switches' which I named 1 - 8 and I completely understand the 0 - 7 are the 'true' way to address the bits due to the fact that its binary.

I feel completely stupid now Pete and extremely sorry that I seemed to annoy you so much last night!

Posted

I feel completely stupid now Pete and extremely sorry that I seemed to annoy you so much last night!

Oh, I'm sorry if i came out "annoyed". That really was not the case. And please do not feel stupid. It happens to everyone, that things in front of you don't register. Please do not be concerned and i apologise if my words came over as so critical.

I get annoyed more at myself when i think I am not explaining things properly!

Regards

Pete

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.