Depending on the speed of the loop and the speed of the robot it seems all to easy for the sensors to go from not seeing anything, to seeing something, to not seeing it again within a single cycle where the robot controller wouldn’t see it because it happened between the serout and serin. Is there any way to check the sensors durring a loop without doing a full serin?
you would have to use a custom circuit to do this.
Which, depending on the application, would be a good use for a custom circuit.
is there a way i can add a second serin that just checks the sensors and ignores the operator interface? Would it cause a problem if the program had two serins and only one serout?
*Originally posted by Jferrante *
**is there a way i can add a second serin that just checks the sensors and ignores the operator interface? Would it cause a problem if the program had two serins and only one serout? **
No, that would not cause any problem, as such.
You can use SERIN and SEROUT at any time.
Heh. On a rather unrelated note, I finally actually figured out how you’d go about using the programming port to send information to and from a custom circuit board.
I was wondering how SERIN or SEROUT had access to the SIN and SOUT pins on the BS2sx in the RC, and finally found it.
While looking at the syntax and description of the SERIN command in the Basic Stamp Manual V2.0 (www.parallax.com), I came across this piece of goodness:
Stolen from the Basic Stamp Manual V2.0
SERIN Rpin {\Fpin}, Baudmode, {Plabel,} {Timeout, Tlabel,} InputData ]
Function
Receive asynchronous serial data (e.g., RS-232 data).
Rpin is a variable/constant/expression (0 - 16) that specifies the I/O
pin through which the serial data will be received. This pin will be
set to input mode. On the BS2, BS2e, BS2sx and BS2p, if Rpin is set to
16, the BASIC Stamp uses the dedicated serial-input pin (SIN,
physical pin 2), which is normally used by the Stamp Editor during
the download process.
Likewise, the SEROUT command has the same kind of functionality, but for physical pin 0, which is the SOUT pin on the Stamp. You can use the SIN and SOUT pins on the BS2sx, itself, as the serial input and output pins.
I’m sorry for annoying anyone who already knew this. I just thought I’d post it…
do i have to have the serin check everything or can i just have it as:
Serin COMA\COMB, INBAUD, [rc_swA,rc_swB]
*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] **
I’m almost hesitant to say, because I can’t test it right now, but I would assume that to work perfectly fine.
Assuming that works, you could also use this to receive the analog sensor inputs, as well as the digital inputs:
Serin COMA\COMB, INBAUD, [rc_swA,rc_swB,sensor1,sensor2, sensor3,sensor4,sensor5,sensor6,sensor7,sensor8]
*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…
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.
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.
You will get a Basic Init Error if your constants (c_p1_x, etc) don’t match up with your SERIN. Whether or not you can SHIFTOUT a new set of variables to the processor remains to be seen.
If you want some sample code that talks to the programming port, check out RoboCon at my website. The BSX file in there uses SERIN and SEROUT to communicate directly with a PC. http://www.robbayer.com/software.html.
Originally posted by JoshB *
**
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.*
Yes you would get a Basic Init Error if you don’t have the correct constants for the first init, basic on the way first has it setup… I was suggesting using a second init setup… that aside… I tested my third idea and it works as I thought…
Citing the specific problem of this thread, you can use the following command.
**Serin COMA\COMB, INBAUD, [rc_swA, rc_swA, rc_swA,rc_swB] **
The first two "rc_swA"s will get set to the OI digital data, but due to the assignment order, rc_swA will be set to the correct value, and so would rc_swB, the rest of the packet would be ingored, since no variables were defined for them.
Hope this helps… if it doesn’t make since, post it (of course) and I’ll try to clearify.