Quote:
Originally posted by Jferrante
do i have to have the serin check everything or can i just have it as:
Serin COMA\COMB, INBAUD, [rc_swA,rc_swB]
|
It's possible to do what you are asking, but you need to be a bit careful, as it is not going to work the way you are thinking right now.
The Serin command isn't "Smart" enough to know that the variable named "rc_swA" should be set to the RC's digital switch values. You could name your variables anything... it is the order in the Serin command that is important.
The Serin command, here, is basically receiving a packet of data, and assigning each byte to a different variable, based on location. Look at your "main" Serin and see how the order matters. The agreement between the P-Basic uP and the Master uP about packet order and contents was established in the "PBASIC - MASTER uP INITIALIZATION ROUTINE", the "DO NOT MOVE, DO NOT CHANGE, UNDER PENALTY OF LAW SECTION"
Depending on your programming experience you may not fully understand this line.... basically it is performing a set of bit-wise shifts to "build" a 5 byte command packet to tell the Master uP what values to send and in what order. This "building" process is controlled, by the "Initialization constants" section where you "turn off" or "turn on" each variable by setting a 1 or 0.
So, to your question, if you use your command above, rc_swA and rc_swB, will be set to the digital values of the OI, not the RC, since the OI bytes are the first two sent. (Assuming you haven't turned them off).
Possible solutions:
1)
Idea:
Define a new command packet for the Master uP and send it to redefine what bytes to receive.
Problem:
You would then have to move the "main" command packet into the do/loop so that your other Serin reads in valid data. This will cause delays and possible other problems, with malformed packets and the like... I'll look into this more when I go into work and see if it is a possible idea.....
2)
Idea:
Since luckily the bytes of input you want are near the front of the data packet, you could have "junk" variables in the first two location to receive the OI data, and rc_swA/B in the next spots to receive the correct data.
Problem:
With only 26 allowed variables, using 2 as junk in this purpose would be wasteful.
3)
Idea:
This just came to me as I was typing, so it is completely untested, I'll verify it later today.... But if the packet assignment order is what I think it is, then you might be able to get away with using your rc_swA/B varibles as the junk variables. Let them get set to the trash you don't want, and then finally set to the correct values.
Problems:
As I said before, I have
never tested this idea, I have just thought of it. PBASIC may not allow such a thing, the internal MUXes may not like it, the data my collade and raise a Basic Init Error, I'm not sure.
Here are a couple ideas to try out and see what will work in your situation. I will test them today, and reply tonight with what worked... Remember just because a variable is set, doesn't mean it is set to the values you think it is, ALWAYS test, DEBUG is your friend. :-)
Also not this is based on the way FIRST has the RC setup with the series processors. When using the programming port for SERIN yields an entirely new set of rules. Which could, in the long run, be easier.