Multiple POLLED programs not executing

sparky01 · 2010-09-29 16:00

I have a program which should jump to a another program in slot 1 or 2 depending upon which of 2 infrared sensors(pana4602) receives an ir signal.
The jumped prog.'s each lite a different color led depending on which program jumped to.

The program in slot 0 appears to have correct directive and program executes but incorrectly.

The top setup is:

pollin 12, 0
pollrun 1
pollmode 3

and then the same for other pin.

after that is a looping program waiting for the event.
after the paragraph, the first line is:

get 127, pgmslot(pgmslot is var byte)

after ir is sent either one or other led will light and sometimes both!?!?!?:mad:
often is wrong led, corresponding to other irr pin!

Each of polled programs in slots 1 and 2 have:
"RUN 0" at end so returns to prog 0 after they lite led.

Is the setup correct?
HELP !!!!!!!!!!!!!!

If need more clarification on program, please let me know)

TIA

Tracy Allen · 2010-09-29 16:55

I think you may have an unrealistic expectation, if you think that a separate target slot can be associated with each pin. There can only be one target slot at a time for a POLLRUN, and that will be activated by any of the pins going into their target POLLIN state.

You will probably need to post your program if you want a more nuanced answer, and also please explain what you want to accomplish or learn.

sparky01 · 2010-09-29 17:40

Thanks Tracy!

Getting late here-east coast, so have to go.

will attempt to cut and paste prog. tomorrow.

sparky01 · 2010-09-30 06:15

ATTEMPT TO ATTACH PROGRAM:

http://www.nytimes.com/2010/09/30/us/30military.html?_r=1&scp=1&sq=GATES%20FEARS%20WIDER%20GAP&st=cse

sparky01 · 2010-09-30 06:17

sparky01 wrote: »

ATTEMPT TO ATTACH PROGRAM:

http://www.nytimes.com/2010/09/30/us/30military.html?_r=1&scp=1&sq=GATES%20FEARS%20WIDER%20GAP&st=cse

SORRY, WRONG ATTACHMENT !!!!!!!!!!!!:smhair:

sparky01 · 2010-09-30 06:46

AM HAVING DIFFICULTY LOADING THE BS2P PROGRAM AS ATTACHMENT

Therefore attempt to type programs:

ex of program in slot 0:

'{$STAMP BS2P, PROGRAM B, PROGRAM C}

'PROGRAM A

PGMSLOT VAR BYTE

EVENTINA VAR IN12
EVENTPIN CON 12

EVENTINB VAR IN15
EVENTPIN CON 15

SETUP"

POLLIN 12, 0
POLLRUN 1
POLLMODE 3

POLLIN 15, 0
POLLRUN 2
POLLMODE 3

THELOOP
GET 127, PGMSLOT
DEBUG "LOOPING...", CR
PAUSE 200
GOTO THELOOP

ex. PROGRAM B(in slot 1):

'{$STAMP BS2P}

'PROGRAM B

PGMSLOT VAR BYTE

MAIN
GET 127, PGMSLOT
HIGH 1 'lites led
PAUSE 1000
LOW 1
RUN 0 'return to Program A

The PROGRAM A in slot 0 will loop until an event occurs.
When an event occurs that makes pin 12 or 15 low, it is supposed to make PROGRAM B OR C load and run. These programs each lite a different colored led to show which pin the event occurred on. Program B or C is then supposed to return to program in slot 0(PROGRAM A). These "POLL" programs are not working. I SUSPECT it is in the SETUP!?!?

Tracy Allen · 2010-09-30 09:31

POLLIN 12, 0
POLLRUN 1 
POLLMODE 3

POLLIN 15, 0
POLLRUN 2
POLLMODE 3

What that code is not going to do as you are expecting. It ends up with both pins p12 and p15 as active polling inputs, looking for a low in each case, and with slot 2 as the RUN target. There is a brief period between the first POLLMODE 3 and the second one that only pin p12 is active and targeted to slot 1. You see, only one slot at a time can be the RUN target, and all pins that are set for POLLing will have the same effect. It is not as versatile as you might expect.

Depending on where you are headed with this, start with simple polling and don't use the POLLing commands.

IF in12=0 THEN RUN 1
IF in15=0 THEN RUN 2

There are some effective ways to use POLLing commands to latch pin events while your program is off busy doing other things. Are you doing this with a particular goal, or out of curiosity?

It is not hard to do attachments. If you hit the full REPLY button, there is a large box under your reply window, "Additional Options", and in that window there is a "Manage Attachments" button.

sparky01 · 2010-09-30 14:54

Tracy,

I wish to break away from a running program(ex. program in slot 0) and go to another (program 1) AT ANY TIME when a pin turns low ex pin 12. (ALSO OTHER PINS AND PROGRAMS... ex. PIN15 FOR PROGRAM 2 ect.)

I believe your suggestion that I put "if in12 = 0 then run 1" at start will not accomplish this because it is only at start of the running program and not at anytime.

Are there no polling instructions that will monitor several pins to see if one goes low at ANYTIME( while running a program ex. program 0) and run another program depending upon which pin goes low?

Thankyou for your support!:idea:

Mike Green · 2010-09-30 15:40

No, there are no instructions that will monitor several I/O pins at once and run a specific program depending on which pin goes low. POLLRUN is the closest thing and that will only monitor one I/O pin and execute one program. If you specify a new POLL action, that replaces any previous one.

sparky01 · 2010-09-30 15:49

That solves the situation but not my problem!
Your post makes me realize that what I am attempting is impossible

Thankyou for your asistance, Mike.

Probably the closest I can come to what I want to do would be Tracy's suggestion to place "if in12......." at start (and several other waypoints in program).

Tracy Allen · 2010-09-30 15:54

The pin tests would go inside your main loop, tested over and over, each time around:

theLoop:
  IF in12=0 THEN RUN 1
  IF in15=0 THEN RUN 2
  ' do other stuff
GOTO theLoop

As it stands, your main loop isn't doing anything except waiting for a keypress, so the response to a key press would be fast. However, if you write a long program, it might take some time to get back to the tests. The tests can be executed at multiple points in the program.

On the other hand, you can use the POLLRUN command to break out of your main program at any point between commands, but pin-dependent branching will have to be coded into the target slot:

POLLMODE 0
POLLIN 12,0
POLLIN 15,0
POLLRUN 1
POLLMODE 11   ' mode 11 is latched version of pollrun
TheLoop:
DO
  ' do various short tasks
  ' any one of which can be broken into by RUN 1
LOOP

Once in slot 1, the program there can determine which pin caused the branch, either by reading the pins directly, or by reading the polling status bytes in the scratchpad ram...

' in slot 1
GET 129, whobyte   ' latched polling status byte for mainio 8-15
IF whobyte.bit4 THEN   ' polling was activated by p12
  HIGH 1  ' this will blink the LED
  PAUSE 1000
  LOW 1
ENDIF
IF whobyte.bit7 THEN RUN 2  ' activated by p15
     ' this blinks an LED using slot 2 code
RUN 0

sparky01 · 2010-09-30 16:27

Tracy,

This looks like it shall work for me.
I shall attempt tomorrow or this weekend.

Thankyou for your recomendations!:smilewinkgrin:

sparky01 · 2010-10-01 10:13

Tracy,

Regarding your "POLLMODE 11" instruction.

I have been to "the Basic Stamp syntax and reference manual(online)".
Checked the index, POLLMODE p. 319--> and POLLRUN p.331--> and I can not
find out what a "latched version of pollrun" means. How is pollmode 11 different from pollmode 3 which I would normally probably use?
What does the "latched" mean?
Does it mean that pins 12 and 15 can not change state even if it changes?
Does it mean that program in slot 1 must run until done and not change to another program(or until changed by new poll instruction in that program)?

Tracy Allen · 2010-10-01 21:30

In normal POLLOUT modes, the response to a POLLed INput pin is that the output pin follows the input pin as it goes high and low. However, in latched modes, if an input goes to its target state (set by the POLLIN pin,targetstate), then the output (set by POLLOUT pin,targetstate) will go to its target state and stay there, latched. It does not go back and follow the input. It remembers that the input went to the target state.

That is not just for POLLOUT. Have you looked at table 5.77 in the Stamp manual? The four read-only bytes from 128–131 in scratchpad RAM reflect the state of the pins that are set for POLLing. A bit corresponding to each of those pins will in normal mode simply follow the state of the pin. But in latched modes, if the corresponding input pin goes into its target state, then the bit in scratchpad will go to 1 and stick there. That allows those bits to catch and remember short events, like someone quickly pressing and releasing a key. And it gives a way for your program to inspect those bits to see which pins went active. The bits are reset when the program executes another POLLMODE command.

"Latched" modes are not well documented. You see them mentioned at the bottom of table 5.77. All it means for your program is that you can read bits 4 and 7 in the byte that comes from,
GET 129, whobyte
Those bits show which pin caused the POLLRUN. If you use the normal POLLMODE 3, those bits will show the pins that are currently active, and that might be none at all if the button was quickly released. If you do POLLMODE 11, there is no problem with quickly released buttons, because the bits remember the events.

sparky01 · 2010-10-02 10:18

This clarifys "LATCHED" much better!

Also, your code sent on 9-30 is working for me.

PROBLEM SOLVED !

Tracy, Thankyou for your support.

Multiple POLLED programs not executing

Comments