external interrupt

Special_K · 2006-06-12 01:01

This may be a stupid question. But, I was reading the new Nuts and Volts and they had an article on external interrupts...
Does the BS2 or any parallax chip have this function?
I looked in the manual and I did not see it mentioned.

Bruce Bates · 2006-06-12 05:00

Special_K -

No PBASIC Stamp has external interrupt capability, but polling can come awfully close when used with the BS2p series Stamps.See PollWait, PollRun, etc.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

LoopyByteloose · 2006-06-12 06:20

I believe that the RTC pin or Port B of the SXes can be used as external interrupts. Much depends on how you want to program such.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········

···················· Tropical regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Gadgetman · 2006-06-12 13:29

And the Propeller chip can easily dedicate a COG to wait for an external event....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Special_K · 2006-06-12 13:48

I thought about the Propeller but I am a little afraid of learning a new language I am still trying to get really good with PBasic.

Bean · 2006-06-12 14:58

What you you doing that requires external interrupts ?
I find that many times people THINK they need interrupts, but usually it can be accomplished using a simple latch or something.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com

"I reject your reality, and substitute my own." Mythbusters
·

Zoot · 2006-06-12 16:32

My first micro programming project was building and programming the old HERO-1 by Heathkit. The Motorola chip had plenty of interrupt capability, interrupt masking, etc. But you know what? I agree with Bean -- I discarded interrupts on every app I developed. As often as not they got in the way (masking and returning from interrupts can be as much of a chore, and sometimes more annoying than programming good state machines that handle such events).

My own feeling is that true interrupts are only necessary when the possible speed of your main state-machine loop prevents handling an "interrupt" event quickly enough, or because the hardware of your platform dictates such an approach. In the case of the former, on a Stamp, presuming you have a slot free to handle the POLL code, you'd probably be OK. In the case of the latter, you may need a chip with true interrupt capability.

The POLL commands allow for you to check the state of an I/O pin "between" every program instruction, and then your code jumps to a pre-defined slot. You may want to see some of Tracy Allen's write-ups on multi-slot task management if you take this approach -- it can make it easier to simulate a "return from interrupt" after your POLL slot has run. emesystems.com/BS2SX.htm#Crossbank

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

Tracy Allen · 2006-06-12 17:30

There is more "advanced" info on the POLLing commands at this URL
www.emesystems.com/BS2poll.htm

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Special_K · 2006-06-12 20:09

Here is the code I am using.
_________________code snipet____________________
DO
IF IN0=0 THEN
GOSUB bumped
ENDIF
mainloop:
GOSUB GET_sonar
SELECT cm
CASE > 25
GOTO TOir
CASE < 15
GOSUB Ping_Around
CASE < 10
GOSUB Backward
GOSUB Ping_Around
'CASE 16 TO 25
' GOSUB Forward
ENDSELECT
_________________code snipet_ end___________________

the program then goes to a subroutine if the BOEbot is stuck.

_________________code snipet____________________
bumped: 'start bumper subroutine
LFT = 750 'set lft value to stop
RHT = 750 'set rht value to stop
SEROUT Sdat,baud+$8000,[noparse][[/noparse]"!SC", 01, 0, LFT.LOWBYTE, LFT.HIGHBYTE, CR] 'apply stop values
SEROUT Sdat,baud+$8000,[noparse][[/noparse]"!SC", 00, 0, RHT.LOWBYTE, RHT.HIGHBYTE, CR] 'apply stop values
FREQOUT sound, 200, 2000
PAUSE 100
FREQOUT sound, 50, 3400
GOTO mainloop
RETURN
_________________code snipet__ end__________________

This subroutine has to back the BOEbot up enough to get it out of its jam. However sometimes the BOEbot backs up into things. I modified two limit switches from the VEX systems and the act as bumpers. The problem is that since the value is being sent to a PSC it just backs up even if the switch is hit. The PSC will keep going backward. I thought that the interrupt would help. Any ideas?

Zoot · 2006-06-12 20:50

OK, first of all, you have an error or something I don't understand in your Bumped sub, because you GOTO the main loop before the actual return. So you don't actually return from the SUB, even though this code works because the return spot is the same as the Main: label. Regardless, I think this is a case where writing your state-machine well is the best (and simplest) solution. You didn't include code for your "backward" routine, but that is the place to put in something like this:

Backward: 'start backup subroutine
LFT = 650  'or whatever your speed is
RHT = 850 'ditto
SEROUT Sdat,baud+$8000,[noparse][[/noparse]"!SC", 01, 0, LFT.LOWBYTE, LFT.HIGHBYTE, CR] 'apply backup values
SEROUT Sdat,baud+$8000,[noparse][[/noparse]"!SC", 00, 0, RHT.LOWBYTE, RHT.HIGHBYTE, CR] 'apply backup values

'now here is where you loop within the routine WHILE backing up to see if you hit anything while backing up
'if you do, jump back to your "bumped" routine again to "stop" your bot (or whatever you want to do at that point)
'note that in this case I use a counter to "time" the backup, you could also do something like use your PING
' to check the distance in front and actually verify the distance you've backed up

Counter = 200   'or however many counts gives you enough backup time

Check_backup:
   Counter = Counter - 1                    'decrement timer
   IF IN1 = 0 THEN                             'check if you backed into anything -- not sure what your other pin assignment is
      GOSUB Bumped                           'stop and make a beep sound
      RETURN                                     'if you hit something in back, you're done here and can prob. go back to the main loop
   ENDIF
   IF ( Counter > 0 ) THEN Check_backup                 'if you didn't hit anything, keep backing up till time is expired
   RETURN

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

Zoot · 2006-06-12 20:53

Oh, one other thing. My above example will NOT work unless you take the "GOTO MainLoop" statement out of your "Bumped" sub -- otherwise, when you call the Bumped sub, you will not return to your Backward routine, you'll go straight to the main loop and will keep backing up until other code tells your PSC to do something else.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

Special_K · 2006-06-12 21:05

yep I forgot to include the backup code.Here is the whole thing.
it is I guess a combination of fast IR using Sony IR units, sonar and a bumper switch. The sonar is on a turret with two servos later I will have it sweep and then raise and sweep again (it keeps getting stuck unter the couch).

Post Edited (Special_K) : 6/12/2006 9:35:35 PM GMT

Zoot · 2006-06-12 21:19

OK, I didn't compile this, so I don't how much variable space you have, but what I suggested above should work nicely. Mostly you would need to decide how and where the routine should goto if it detects a bump while going backwards.

The PAUSE in your original backward routine will burn you btw, because during the PAUSE, the Stamp will be doing nothing, parsing no input, while the pause is in effect. Your PSC, though, will keep your bot rolling backwards.

Like I said above, you could use a counter to time your backup, or you could use your PING (a more elegant solution) to actually check the distance in front of you and see if you've backed away from the obstacle enough. The problem with that, of course, is that if your bumpers triggered the backup and NOT the PING, then you don't have good way to tell.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

Special_K · 2006-06-12 21:43

Maybe I can have the bumper run another subroutine that will check the see if the Ping distance is long enough. If not it can perform a turn in place.
Thanks for the ideas.

Zoot · 2006-06-12 22:01

Sure thing. BTW, I *love* your Blog.

Oh, one other thing I saw in a casual persual of your code..... where you have

READ_IRLFT:
LOW CLLFT    ' turn on detector for reading
rl:
IF IN11 = 0 THEN rl  ' wait for input high
SHIFTIN DLLFT, CLLFT, MSBPOST, [noparse][[/noparse]IRLFT]
HIGH CLLFT    ' turn detector off
'PAUSE 1    ' let detector reset
RETURN

READ_IRRHT:
LOW CLRHT    ' turn on detector for reading
r2:
IF IN9 = 0 THEN r2  ' wait for input high
SHIFTIN DLRHT, CLRHT, MSBPOST, [noparse][[/noparse]IRRHT]
HIGH CLRHT    ' turn detector off
'PAUSE 1    ' let detector reset
RETURN

READ_IRBOTH:
LOW CLLFT    ' turn on detector for reading
bl:
IF IN11 = 0 THEN bl  ' wait for input high
SHIFTIN DLLFT, CLLFT, MSBPOST, [noparse][[/noparse]IRLFT]
HIGH CLLFT    ' turn detector off
'PAUSE 1    ' let detector reset

'--------------------------------------------------------

LOW CLRHT    ' turn on detector for reading
c2:
IF IN9 = 0 THEN c2  ' wait for input high
SHIFTIN DLRHT, CLRHT, MSBPOST, [noparse][[/noparse]IRRHT]
HIGH CLRHT    ' turn detector off
'PAUSE 1    ' let detector reset
RETURN

You could combine the "both" part like this:

READ_IRLFT:
LOW CLLFT    ' turn on detector for reading
rl:
IF IN11 = 0 THEN rl  ' wait for input high
SHIFTIN DLLFT, CLLFT, MSBPOST, [noparse][[/noparse]IRLFT]
HIGH CLLFT    ' turn detector off
'PAUSE 1    ' let detector reset
RETURN

READ_IRRHT:
LOW CLRHT    ' turn on detector for reading
r2:
IF IN9 = 0 THEN r2  ' wait for input high
SHIFTIN DLRHT, CLRHT, MSBPOST, [noparse][[/noparse]IRRHT]
HIGH CLRHT    ' turn detector off
'PAUSE 1    ' let detector reset
RETURN

READ_IRBOTH:
GOSUB READ_IRLFT
GOSUB READ_IRRHT
RETURN

Also, though I haven't tested this, you could probably save an I/O pin by using one line to read data from both IR detectors, and use separate clock lines. Only one detector will be sending out data so you can use just the one pin to read from either one, depending on which one is enabled.

Lastly, I saw that you are using a discrete pin to send out pulses to your PING servo. You could hook that servo up to your PSC, saving another pin. The trick there of course, is timing your program so it reads the PING only after the servo has gotten to the proper place. On my bots, I "read" the actual position of the servo from the PSC to verify that it's gotten where I want it go before going further. Refer to the PSC documentation for info about reading actual servo positions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

Special_K · 2006-06-13 02:24

the READ_IRLFT: and READ_IRRHT: is a holdover from the original code from acroname http://www.acroname.com/robotics/parts/R19-IR02.html
I tried to make the code a little tighter but I never got it smaller. the READ_IRBOTH: is just the two bits mashed together.

Special_K · 2006-06-14 01:20

I used the backup bumper loop. it worked great.
thanks.

Zoot · 2006-06-14 02:07

Cool.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

external interrupt

Comments