Shop OBEX P1 Docs P2 Docs Learn Events
Getting NAP to work — Parallax Forums

Getting NAP to work

mphmph Posts: 13
edited 2010-07-30 06:36 in BASIC Stamp
I am using the BS2px, and I have a 2x16 LCD as well as a 4x5 keypad (via a 74C923N decoder) hooked up to P0 through P7. Displaying data on the LCD and accepting inputs from the keypad are working just fine and very stably.

I was now trying to implement a STANDBY function into my program to save power. The idea is that when I press a specific key on the keypad (I call it #72, the STANDBY key) the program would GOSUB to the NapRoutine shown below:


NapRoutine:
NapLoop:
NAP 6
DIRL=%00000000 ' make PINs 0-7 inputs for keypad reading
BUTTON 2,1,255,255,Buttn,0,NapLoop ' Check if keypad button was pressed (data ready)
Char = INL & %11111000 ' read PINs 0-7, only consider high 5 bits (74C923 outputs)
' bitmap of the 4Wx5H keypad from top left key to bottom right key
LOOKDOWN Char,[noparse][[/noparse]%11000000,%01000000,%10000000,%00000000,
%11100000,%01100000,%10100000,%00100000,
%11010000,%01010000,%10010000,%00010000,
%11110000,%01110000,%10110000,%00110000,
%11001000,%01001000,%10001000,%00001000],Char
'assign values to the respective keys
LOOKUP Char,[noparse][[/noparse]65,66,67,68,55,56,57,69,52,53,54,70,49,50,51,71,48,46,13,72],Char
IF Char<>72 THEN GOTO NapLoop
RETURN


This is a modified version of my well-tested routine I use to read keys from the keypad. The main difference is that there is a NAP command in the loop. The BS2px goes NAP for 6 units, then uses the BUTTON command to check if a key was pressed on the keypad, and if not it NAPs again. If a key was pressed it figures out which one, and unless key #72 was pressed it goes NAP again, otherwise it considers itself to be awake again and returns to the program.

The above sub-routine works perfectly for short times (less than 1 minute or so). The BS2px goes NAP and only wakes up if I press the #72 key on the keypad; then it wakes up again. However, if I let the program loop in this routine for a longer time (a minute or more or so) without pressing a key or doing anything to it, the program crashes and becomes completely unresponsive. It looks like it gets hung up in the NAP loop somehow.

Does anyone see what might be going on?? Thanks!
mph

Comments

  • Tracy AllenTracy Allen Posts: 6,664
    edited 2010-07-27 18:23
    If you think it is getting hung up in the NAP loop, test that hypothesis by inserting a DEBUG "z" or toggle an LED. Also put a DEBUG "X" after the BUTTON command. I don't see offhand any reason for it to lock up.

    Another way to implement that on the BS2px is to use the POLLWAIT command:

    POLLIN 2,1    ' look for a 1 on pin p2
POLLMODE 2    ' enable polling
POLLWAIT 5     ' NAP at 0.5 second intervals until pin p2 goes high
POLLMODE 0    ' disable polling



    The napping is more efficient with POLLWAIT, because the pin check is fast within the interpreter microcode instead of your program loop. That code does not debounce the pin, but could be added.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • mphmph Posts: 13
    edited 2010-07-28 03:54
    Thanks a lot Tracy! The code you provided above works much better than by code with the BUTTON command. I am staying in the low-power mode much longer.

    However, after some 10-15 minutes or so, the program still somehow jumps out of the routine without any obvious external input and without ever getting past the POLLMODE 0 command! In fact, it does not even jump back to the line after the calling GOSUB command, but rather it just goes back to Main routine of the program.

    I do not understand that. Any thoughts?
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2010-07-28 16:29
    It sounds like an external glitch might be resetting the Stamp. Does it always happen at about the same time? A DEBUG "top" at the beginning of your program might sort that out. Is the system near any machinery? Programming cable hanging loose? A programming error can cause an out-of-the-blue reset, say, if the call stack gradually builds up without matched RETURNs.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • mphmph Posts: 13
    edited 2010-07-29 03:56
    I checked for any unmatched RETURNs. The time it takes for the glitch to occur is not the same every time. It ranges from less than a minute to ~10 minutes. I tested for any intermittent contacts - all looks fine. I am not near machinery. However, my 74C923N decoder circuit for the keypad is currently only breadboarded and a rather ugly cable mess. It is possible that I am picking something up that causes the glitch. The odd thing is however that the glitch never happens when I am in the regular keypad reading routine (which is similar to the code shown at the beginning of this post) - the program can wait forever for a keypad entry without glitching. In any case it is probably best to clean up the keypad circuit and put it on a PCB.

    Any other thoughts or suggestions are welcome. Thanks!
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2010-07-29 05:23
    When you insert a DEBUG "top" at the start of your program before your main loop, does it print "top" when this glitch occurs? Any indicator using an LED or whatever would help to distinguish a reset from the top from other offbeat routes back into your Main routine.

    You said, "However, after some 10-15 minutes or so, the program still somehow jumps out of the routine without any obvious external input and without ever getting past the POLLMODE 0 command! In fact, it does not even jump back to the line after the calling GOSUB command, but rather it just goes back to Main routine of the program."

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

    Post Edited (Tracy Allen) : 7/29/2010 5:28:03 AM GMT
  • mphmph Posts: 13
    edited 2010-07-29 14:04
    OK, I see what you mean. I inserted a DEBUG "top" *before* the Main loop (it was after the Main statement earlier). Indeed, twice in a row when the glitch occurred I received a "top" on my debug screen, indicating that the glitch actually resets the processor. I thought that can only happen when I either download a new program or press the reset button on my Stamp board.

    Any ideas what else could cause the BS2px to just reset?
  • FranklinFranklin Posts: 4,747
    edited 2010-07-29 15:35
    Bad power or overwriting code segments would do that.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    - Stephen
  • mphmph Posts: 13
    edited 2010-07-29 18:59
    - Power: I am using the power adapter that came with the Stamp board plugged into a regular outlet

    - "overwriting code segments": what is that exactly, and how would I get that when I do all my programming from the Stamp editor?
  • mphmph Posts: 13
    edited 2010-07-30 01:41
    I can positively confirm that the power is not the cause of the reset. I see the same glitch when I use a fresh 9-Volt battery.

    So what else can cause the processor to reset apparently "all by itself":
    - overwriting code segments
    - ??
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2010-07-30 06:36
    Does the program use the WRITE command? If so, it might overwrite itself and crash.

    One way for a program to reset itself, maybe the most common glitch, is a GOTO where there really should be a GOSUB. When the subroutine hits a RETURN, the call stack is empty and the program starts from the top. Another way happen if CALLs are nested more than 4 deep. The Stamp only allows nesting to 4 levels, and having one more will instigate a RETURN to the top. It differs a bit from a hardware reset in that (I think) the variables are not initialized to zeros. So you can test this scenario with a DEBUG ? myBit at the top, followed by myBit=1. If it prints myBit=1, that means there has been a software reset, but myBit=0 means there was a hardware reset. An external power glitch seems unlikely given your observations.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
Sign In or Register to comment.