bs2p40 DIRS
Archiver
Posts: 46,084
>Hello...
>I'm having a bit of trouble initially setting the DIRS
>of all 32 I/O pins. If I start my program with
>DIRS = %1111111111111111
>It only does the MAINIO set. If I change it to
>MAINIO
>DIRS = %1111111111111111
>AUXIO
>DIRS = %1111111111111111
>Then the program just gets into a wierd neverending
>loop. Any ideas?
There is no reason there to put it into a loop.
Maybe setting one of those auxio pins to output is turning on some
external device that causes a glitch on the power supply that causes
it to reset. Put a
debug "top"
statement at the top of the program.
What kind of weird loop?
>I'm having a bit of trouble initially setting the DIRS
>of all 32 I/O pins. If I start my program with
>DIRS = %1111111111111111
>It only does the MAINIO set. If I change it to
>MAINIO
>DIRS = %1111111111111111
>AUXIO
>DIRS = %1111111111111111
>Then the program just gets into a wierd neverending
>loop. Any ideas?
There is no reason there to put it into a loop.
Maybe setting one of those auxio pins to output is turning on some
external device that causes a glitch on the power supply that causes
it to reset. Put a
debug "top"
statement at the top of the program.
What kind of weird loop?
Comments
>I set the entire pin register to output on both IO's.
>
>Init:
> Debug "Initializing...", CR
> MAINIO
> DIRS = $FFFF ' or whatever
> AUXIO
> DIRS = $FFFF
>
>Any other value less than 65535 will not cause this to happen. It's
>hard to see what exactly is happening because I can't really debug
>what's going on. The program just keeps looping thru Init and strange
>characters are spit out in between the debug.
>
>hmm....?
Is that the entire program, the six lines above? What is the BS2p40
connected to, in terms of a power supply and the i/o pins? There is
something funny going on! The debugging process here will certainly
take a process of elimination. Have you actually eliminated all
values less than 65535 simultaneously on mainio and auxio, or could
there be other combinations you haven't tried yet?
-- Tracy
due to a high output load probably coming from the Opto relays. They draw
about 3 to 10 ma on the input side per relay. That means the stamp have to
output
as much as 150 ma which could cause a power reduction and reset condition. I
ran your code without relays and it works fine. Hope this help.
Chuck
'{$STAMP BS2p}
'{$PBASIC 2.5}
x VAR Bit
Init:
DEBUG "init", CR
x = 0
MAINIO
DIRS = $FFFF
auxio
DIRS = $FFFF
Main:
OUTS = $FFFF
DEBUG "OUTS: ", BIN16 OUTS, CR
PAUSE 500
OUTS = $0000
DEBUG "OUTS: ", BIN16 OUTS, CR
PAUSE 500
x = ~x
debug ? x
IOTERM x
GOTO main
module at 5 volts, and when all 16 modules are being driven at once,
the current limit of the Stamp is exceeded. The BS2p specs 30 ma per
pin, but, 60 ma total per each group of 8 pins.
Maybe it works, barely, to drive 15. Why the weird debug? Maybe the
Stamp takes a fraction of a second to "realize" that it is
overloaded, and then it resets, and tries again. Or the power supply
filter capacitor for the Stamp is part of the time delay.
The spec for the OPTO22 G4 series is 12 ma at 5 volts--the input
circuit of the module is simply a 220 ohm resistor in series with the
visible indicator led and the IR isolation led.
For better results, maybe use an emitter follower or buffer on each
Stamp pin, or use one of the 32-output Allegro shift register/power
drivers. Or don't drive more than about 3 modules at a time from
each group of 8 on the Stamp.
-- Tracy
> > Is that the entire program, the six lines above? What is the
>BS2p40
> > connected to, in terms of a power supply and the i/o pins? There
>is
> > something funny going on! The debugging process here will
>certainly
> > take a process of elimination. Have you actually eliminated all
> > values less than 65535 simultaneously on mainio and auxio, or could
> > there be other combinations you haven't tried yet?
> >
> > -- Tracy
>
>I have the stamp connected to an OPTO22 32-module I/O rack. Each pin
>is controlling the logic for a separate module. At the moment, the
>modules are not actually switching anything on or off, but since they
>are optically isolated it really doesn't matter much. I've just been
>testing via the LEDs on the backs of the I/O modules.
>
>I have verified there are no shorts, and the module rack is grounded
>properly. Much more sophisticated programs (based on the Toddler
>state program) have worked without a hitch, and actually this problem
>forced me to rethink my program structure - resulting in a much better
>flow.
>
>The program I initially tested on was ultra-simple:
>
>' ***********************
>'{$STAMP BS2p}
>'{$PBASIC 2.5}
>
>x VAR Bit
>
>
>Init:
>
> DEBUG "init", CR
> x = 0
>
> MAINIO
> DIRS = $FFFF
> auxio
> DIRS = $FFFF
>
>
>Main:
>
> OUTS = $FFFF
> DEBUG "OUTS: ", BIN OUTS, CR
> PAUSE 500
>
> OUTS = $0000
> DEBUG "OUTS: ", BIN OUTS, CR
> PAUSE 500
>
> x = ~x
> IOTERM x
>
> GOTO main
>
>' ***********************
>
>DEBUG looks like this:
>
>init
>OUTS: 1111111111111111
>OUinit
>OUTS: 1111111111111111
>OUinit
>OUTS: 1111111111111111
>OUTS: init
>OUTS: 1111111111111111
>OUTinit
>OUTS: 1111111111111111
>OUþinit
>.
>.
>.
>
>any ideas ?
>
>
>To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
>from the same email address that you subscribed. Text in the
>Subject and Body of the message will be ignored.
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/