"What''s a Microcontroller" Chapter 4 project 1
Archiver
Posts: 46,084
Gary,
That makes perfect sense and I appreciate the help and advice.
I am going to play around with the code as you suggested and see
what I can accomplish.
Look forward to hearing from you tomorrow and thanks for taking the
time to help a newby out. I know sometimes it may be trivial to you
but it means alot to us just getting started.
Lu Kwan
--- In basicstamps@yahoogroups.com, "Gary W. Sims" <simsgw@c...>
wrote:
> Lu Kwan:
>
> I haven't time just now to read your code in detail, but let me
give you a
> quick suggestion. Tomorrow I'll look it over more carefully to see
if I can
> add anything. For now:
>
> The requirement that the Stamp wake up refusing commands defines
an initial
> state, but this condition also arises during execution. You have
one mode of
> operation (refusing commands), but more than one way to reach that
mode.
> That's a sign you should use a subroutine. That way, if you change
the
> behavior you only need to change the code in one place to affect
all the
> ways you can initiate that behavior. (Sorry if that's not clear.
It's late
> and I have to hurry.)
>
> So open your program with a statement that calls the subroutine:
>
> GOSUB WaitForStartButton
>
> Then write a subroutine:
>
> WaitForStartButton:
> [noparse][[/noparse]...]
> RETURN
>
> Now the subroutine must satisfy the requirements of the mode it
services. If
> I remember what you said in my quick reading, you must display a
message on
> the debug terminal screen and then wait for the start key.
Something like
> what you wrote:
>
> > DO WHILE IN0 = 0
> > DEBUG "Press Start switch to start the machinery",CR, CRSRUP
> > LOOP
>
> will probably work. (I'd have to check what you said about how the
switch is
> connected to see if de-bouncing is necessary. I doubt it, so this
is
> probably fine to detect the switch.) However, the technique is
what we might
> call "inelegant" -- not to be prissy, but because it does
unnecessary work
> by sending those characters to the debug screen over and over.
Even worse, I
> suspect it will annoy the user by making the display flicker as
you write
> that message repeatedly.
>
> Try this order of commands instead:
>
> > DEBUG "Press Start switch to start the machinery",CR, CRSRUP
> > DO WHILE IN0 = 0
> > LOOP
>
> Now we have:
>
> WaitForStartButton:
> DEBUG "Press Start switch to start the machinery",CR, CRSRUP
> DO WHILE IN0 = 0
> LOOP
> RETURN
>
> Elsewhere in the code, you detect a "kill" switch. I don't
remember how you
> said that was detected, so bear with my "meta code" below. That's
how we
> speak of a step we haven't bothered to code yet, or that may
change in
> different circumstances. It is "meta code" instead of detailed
code.
>
> At that point, you would break off execution of commands like this:
>
> IF <Kill switch pressed> THEN GOTO WaitForStartButton
>
> Good luck for now. As I say, I'll take another look tomorrow if I
get any
> time at all.
>
> Gary
That makes perfect sense and I appreciate the help and advice.
I am going to play around with the code as you suggested and see
what I can accomplish.
Look forward to hearing from you tomorrow and thanks for taking the
time to help a newby out. I know sometimes it may be trivial to you
but it means alot to us just getting started.
Lu Kwan
--- In basicstamps@yahoogroups.com, "Gary W. Sims" <simsgw@c...>
wrote:
> Lu Kwan:
>
> I haven't time just now to read your code in detail, but let me
give you a
> quick suggestion. Tomorrow I'll look it over more carefully to see
if I can
> add anything. For now:
>
> The requirement that the Stamp wake up refusing commands defines
an initial
> state, but this condition also arises during execution. You have
one mode of
> operation (refusing commands), but more than one way to reach that
mode.
> That's a sign you should use a subroutine. That way, if you change
the
> behavior you only need to change the code in one place to affect
all the
> ways you can initiate that behavior. (Sorry if that's not clear.
It's late
> and I have to hurry.)
>
> So open your program with a statement that calls the subroutine:
>
> GOSUB WaitForStartButton
>
> Then write a subroutine:
>
> WaitForStartButton:
> [noparse][[/noparse]...]
> RETURN
>
> Now the subroutine must satisfy the requirements of the mode it
services. If
> I remember what you said in my quick reading, you must display a
message on
> the debug terminal screen and then wait for the start key.
Something like
> what you wrote:
>
> > DO WHILE IN0 = 0
> > DEBUG "Press Start switch to start the machinery",CR, CRSRUP
> > LOOP
>
> will probably work. (I'd have to check what you said about how the
switch is
> connected to see if de-bouncing is necessary. I doubt it, so this
is
> probably fine to detect the switch.) However, the technique is
what we might
> call "inelegant" -- not to be prissy, but because it does
unnecessary work
> by sending those characters to the debug screen over and over.
Even worse, I
> suspect it will annoy the user by making the display flicker as
you write
> that message repeatedly.
>
> Try this order of commands instead:
>
> > DEBUG "Press Start switch to start the machinery",CR, CRSRUP
> > DO WHILE IN0 = 0
> > LOOP
>
> Now we have:
>
> WaitForStartButton:
> DEBUG "Press Start switch to start the machinery",CR, CRSRUP
> DO WHILE IN0 = 0
> LOOP
> RETURN
>
> Elsewhere in the code, you detect a "kill" switch. I don't
remember how you
> said that was detected, so bear with my "meta code" below. That's
how we
> speak of a step we haven't bothered to code yet, or that may
change in
> different circumstances. It is "meta code" instead of detailed
code.
>
> At that point, you would break off execution of commands like this:
>
> IF <Kill switch pressed> THEN GOTO WaitForStartButton
>
> Good luck for now. As I say, I'll take another look tomorrow if I
get any
> time at all.
>
> Gary