Connecting 2 Basic Stamps together
dakota77
Posts: 23
Hello,
I want to connect 1 BS2P (transmitter) and 1 BS2 (receiver) together.
Physically the connection is done : pin 15 of BS2P is connected to pin 0 of BS2.
Is the code below correct ?
On BS2P transmitter:
SEROUT 15, 16780, [noparse][[/noparse]"A"]····
On BS2 receiver:
x VAR Byte
loop:
··· SERIN 0, 16780, [noparse][[/noparse]x]
··· IF x ="A" THEN DBG
GOTO loop
DBG:
··· DEBUG "ok it works"
GOTO loop
The message "ok it works" never appears when the "A" is sent.
I don't understand what is wrong.
Do you have any idea - suggestion·?
Thanks for your help.
I want to connect 1 BS2P (transmitter) and 1 BS2 (receiver) together.
Physically the connection is done : pin 15 of BS2P is connected to pin 0 of BS2.
Is the code below correct ?
On BS2P transmitter:
SEROUT 15, 16780, [noparse][[/noparse]"A"]····
On BS2 receiver:
x VAR Byte
loop:
··· SERIN 0, 16780, [noparse][[/noparse]x]
··· IF x ="A" THEN DBG
GOTO loop
DBG:
··· DEBUG "ok it works"
GOTO loop
The message "ok it works" never appears when the "A" is sent.
I don't understand what is wrong.
Do you have any idea - suggestion·?
Thanks for your help.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Do you have a Stamp Tester yet?
http://hometown.aol.com/newzed/index.html
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
I have checked the 2 BS : they seem to work properly. The connections are OK.
I there something wrong in the code below ? Thanks for your time.
On BS2P transmitter:
SEROUT 15, 17405, [noparse][[/noparse]"A"]
On BS2 receiver:
x VAR Byte
loop:
SERIN 0, 16780, [noparse][[/noparse]x]
IF x ="A" THEN DBG
GOTO loop
DBG:
DEBUG "ok it works"
GOTO loop
Baud··· CON··· Inverted + T9600
-- do this for both sides to make sure they match.· In addition to the serial line, you must also have a common ground (Vss) connection.· Now on the transmitter side, use a loop with a pad:
Main:
· SEROUT Sio, Baud, [noparse][[/noparse]"A"]
· PAUSE 100
· GOTO Main
On the receiver you can use the WAIT modifier to help sync the two sides:
Main:
· SERIN Sio, Baud, [noparse][[/noparse]WAIT("A")]
· DEBUG "Have sync", CR
· GOTO Main
BTW... in your program you're using the word "loop" as a label -- we recommend that you change this as LOOP is a PBASIC 2.5 keyword, and if you want to take advantage of PBASIC 2.5 features (e.g., IF-THEN-ELSE, SELECT-CASE, etc.) then your current code would cause an illegal label name error.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Thanks a lot for your help. It works now. The baud rate was incorrect and the VSS connection on the BS2 was not good.
I have another question :
When a button is pushed, the BS2P sends a string to the BS2 (receiver) through pin 8. Then the BS2P scans pin 9 for a response from the BS2 which will come after a few seconds. It also scans pin 10 for a string coming from an Ipaq Pocket Pc.
The problem is that when I use the BUTTON instruction alone it works: the string is transmitted to BS2.
But when I put BUTTON instruction and SERIN instructions in the loop, nothing happens.
Thanks for your time.
This is the code for the BS2P:
main:
BUTTON 2,0,0,0,BtnWrk,1,p01
SERIN 9, 17405, [noparse][[/noparse]x]
IF x = "B" THEN relay1
SERIN 10, 17405, [noparse][[/noparse]y]
goto main
p01:
SEROUT 8, 17405, [noparse][[/noparse]"A"]
goto main
You can get around this by sampling the button's data line every so often, and spending most of your time in a SERIN command.
This code below works :
main:
··· IF n > 500 THEN but
··· n = n + 1
goto main
This code doesn't work :
main:
··· IF n > 500 THEN but
··· serin· 9, 17405, [noparse][[/noparse]x]
··· n = n + 1
goto main
but:
· DEBUG "Check button",CR
· n=0
··BUTTON 2,0,0,0,BtnWrk,1,p01···
goto main
As soon as the SERIN instruction is active, nothing happens any more.
Thanks for your help.
What is your overall intent? You code at this point is just fragments and yet organized -- my fear is that it will grow to a point where this style gets in your way. PBASIC 2.5 is quite flexible, and if we know what your goal is we can point you in the right direction. I rarely use the BUTTON instruction, and even then it's just to demo -- it's easier to handle inputs directly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
I want to use these 2 BStamps to do aerial vertical photography.
In the aircraft I have an Ipaq Hx4700 (pocket pc) connected to a Bluetooth gps and displaying a moving map.
This computer calculates a time depending of aircraft ground speed and altitude. This time, for example 3 seconds, is sent to BS2P.
The final target is to fire the camera every 3 seconds. But of course this time will vary·(aircraft speed, wind, altitude...).
To the· BS2P are connected :
1) a push button: to start and stop the photos
2) the Ipaq which gives the time between the photos
3) a relay which fires the digital camera
4) a second Stamp BS2 to have a time reference.
The sequence is :
- the button is activated
- BS2P has detected the button and activates the relay
- BS2P sends a string to BS2 containing the time in milliseconds for example : 3000
- BS2 enters in a pause of 3000 milliseconds. (The BS2 is used as a timer)
- When BS2 has finished his pause, he sends a string back to BS2P.
- The BS2P activates the relay for the next photo.
- The BS2P has also to scan the button which can be pressed to stop the photos but has also to scan the pin connected to the Ipaq which can send another recalculated time.
I have spent a lot of time but I can not make work BUTTON and SERIN together in a loop.
Thanks a lot for your help.
Mario
I'm not exactly sure what you mean by "As soon as the SERIN instruction is active, nothing happens any more", but read on and see if the following helps, and/or makes any sense in your situation. "Nothing happens any more" can mean many things, depending on how you interpret it.
Perhaps the following will make some better sense to you. NOTHING will INDEED happen on a PBASIC Stamp while it is performing a SERIN statement, unless one of two things occurs:
1. The SERIN is "satisfied" (read: completed) by having the appropriate asynchronous serial data appear on the indicated pin port, and that expected data appears in a timely and apppropriate manner.
2a. The data DOES NOT appear, or appears incorrectly, and a timeout and/or parity error routine IS specified. In this case, the timeout or parity error routine will get control, after the specified time, if so provided.
2b. The data DOES NOT appear, or appears incorrectly, and a timeout and/or parity error routine is NOT specified. The Stamp will appear to "hang" waiting for the data for some default period of time. Sorry, but I don't remember the exact time off the top of my head.
When this time period expires, the next sequential instruction will be given control, without any further indication that any error has occurred. In other words, BOTH the data is lost, as well as the indication of an error!
Note: Since there (unfortunately) IS a way for a PIC processor, using a software UART (as the PBASIC Stamp uses) to get "hung" indefinitely in a SERIN (without a timeout specified) under a certain set of Rx line conditions, I can only believe that it is possible for that to happen with a Stamp as well. I'll have to dig into my archives to find out the exact set of conditions when this can occur. The conditions (as I remember) are unusual, but by NO MEANS RARE.
There is no way of telling if this is occuring in your case, unless you add a timeout parameter to the SERIN statements. If the "hang" disappears WITH the timeout in place, it is likely that something like that is occuring.
I hope that is of some help.
Regards,
Bruce Bates
1) Why use an external Stamp for the delay when the master has to sit on a SERIN waiting for the input?· Do the PAUSE locally.
2) How are you getting the time from the iPaq?
I'm packing for my move now, but on a break I'll whip up a little program that should get you going.· Since the button thing is just to start the sequence (I'm sure it's more of a Go/No-Go switch), you start to construct your program like this:
TakePics··· PIN··· 2
Yes········ CON··· 1
No········· CON··· 0
Main:
· DO : LOOP UNTIL (TakePics = Yes)
· GOSUB Take_Photo
· GOSUB Get_Timing
· PAUSE picDelay
· GOTO Main
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
I started with a simpler solution: 1 button, 1 relay and only one BS.
The button starts and stops the process. It works perfectly.
The timing is get·from the lenght of the FOR NEXT statement: 12 seconds·= 30000 steps.
The next step will be with the SERIN statement.
start:
·· BUTTON 2,0,255,0,Btn1,1,p01
GOTO start
p01:
· DEBUG "PHOTOS STARTED",CR
· GOSUB relay
· PAUSE 50
· DEBUG "WAITING BUTTON",CR
· FOR y = 1 TO 7500
··· BUTTON 2,0,0,0,Btn2,1,p02
· NEXT
GOTO p01
relay:
· HIGH 0
· PAUSE 100
· LOW 0
RETURN
p02:
··· DEBUG "STOP BUTTON PUSHED",CR
GOTO start
Like Jon, I am no big fan of the BUTTON command although I suppose it may have its purposes. Personally, I would much rather simply scan a pre-conditioned pin port for an input signal, as I may see fit, than to rely on an instruction with so many caveats, requirements, and possibly time delays. That is more opinion than fact, but that's fine for my purposes. YMMV!
Unlike Jon, who usually does his input "switch" de-bouncing with the program, as I remember·(which is fine!), I would much prefer to do as much·with external hardware,·so long as·it's not cost intensive and doesn't take up a lot of real estate.
I'm sure someone will correct me if I'm wrong here, but as I remember 2 TTL OR logic gates,·or possibly a Schmitt trigger will give me a clean, one-shot (bounce removed) input signal to scan for·in my program, and I suspect with the addition of a capacitor, I could even s-t-r-e-t-c-h that signal, if I needed to. What, $3.00 worth of mostly junk box parts?
However, if you feel compelled to use the BUTTON command, you would be well advised to study it closely and completely. Below is the entire BUTTON section (less the diagrams) from the PBASIC Help File. I have BOLDED certain items which you need to review NOW. Here is that mostly verbatim copy:
quote
Syntax: BUTTON Pin, DownState, Delay, Rate, Workspace, TargetState, Address
Function
Debounce button input, perform auto-repeat, and branch to address if button is in target state. Button circuits may be active-low or active-high.
IMPORTANT:
Explanation
When you press a button or flip a switch, the contacts make or break a connection. A brief (1 to 20 ms) burst of noise occurs as the contacts scrape and bounce against each other. BUTTON's debounce feature prevents this noise from being interpreted as more than one switch action.
BUTTON also lets PBASIC react to a button press the way your computer keyboard does to a key press. When you press a key, a character immediately appears on the screen. If you hold the key down, there's a delay, then a rapid-fire stream of characters appears on the screen. BUTTON's auto-repeat function can be set up to work much the same way.
BUTTON is designed for use inside a program loop. Each time through the loop, BUTTON checks the state of the specified pin. When it first matches DownState, BUTTON debounces the switch. Then, in accordance with TargetState, it either branches to address (TargetState = 1) or doesn't (TargetState = 0).
If the switch stays in DownState, BUTTON counts the number of program loops that execute. When this count equals Delay, BUTTON once again triggers the action specified by TargetState and address. Hereafter, if the switch remains in DownState, BUTTON waits Rate number of cycles between actions. The Workspace variable is used by BUTTON to keep track of how many cycles have occurred since the pin switched to TargetState or since the last auto-repeat.
BUTTON does not stop program execution. In order for its delay and auto repeat functions to work properly, BUTTON must be executed from within a program loop.
end quote
·At least in the case of the second BUTTON command the Btn2 workspace has NOT been cleared as indicated above (second time through issue). Also, since the second BUTTON command is in a "time" (actually iteration) limited loop, that may cause the instruction to cease scanning; ergo the loop is not infinitely waiting for an input. This may be fine for your specific purposes, but·the limitation·must be kept in mind. Additionally, the length of time that loop will take IS dependent on whether the chosen BUTTON state is achieved. Again, whether that matters or not is beyond my scope or knowledge.
Regards,
Bruce Bates