Strange happenings PBP and 12F683

[RussMartin]

I'm hollering "Uncle!" on this right now.

Attached are two segments from a larger program that, as of right now, works perfectly. It records keypresses (TRIGR) at 8 frames per second and plays them back. This is running on a 12F683 and uses Darrel's interrupts for timing.

What I've been trying is to add (somewhere) a test: If the key is stuck or still held down, I want further execution to stop until the key is released.

And that's where the trouble begins. Sounds silly, simple, and should be straightforward, right? But I've tried an amazing number of combinations of IF . . . ENDIF, WHILE . . . WEND, GOTOs, and GOSUBs. Nothing works quite right. Obviously, I'm not seeing something.

The most common result is that the test "sticks" on odd-numbered attempts and won't release back to the program when the key is released until the key is pressed again. (I've even used ALED as a blinky/status indicator.)

Did I fry one too many brain cells back in the 1960s?

[Darrel Taylor]

Hi Russ,

I don't see any way out of PLOOP.

Since it doesn't increment FRAME, it'll never make it to 240 or find a $FF in EEPROM.
<br>

[Charles Linquis]

Untested, but something like this will probably work. Designed to be called from a timer interrupt.

Gosub ReadKey

If Key = Pressed THEN
   IF KeyPressedFlag = 0 THEN 
     KeyCounter = KeyCounter + 1
     IF KeyCounter > DebouncePeriod THEN
     KeyCounter = 0
     KeyPressedFlag = 1
     GOSUB Routine_for_KeyPressed
   ENDIF
   KeyDownCounter = KeyDownCounter + 1
   IF KeyDownCounter > ToleranceLimit then 
      HSEROUT ["Dummy, Get off the key!"]
   ENDIF
ELSE
   KeyCounter = 0
   KeyPressedFlag = 0
   KeyDownCounter = 0
   GOSUB Routine_for_KeyReleased
ENDIF

[RussMartin]

Hi Russ,

I don't see any way out of PLOOP.

Since it doesn't increment FRAME, it'll never make it to 240 or find a $FF in EEPROM.
<br>

FRAME is incremented in the interrupt handler for both the PLAY and RECORD subroutines.

Remember, these are just the fragments where I tried trapping the "continued key-on" condition; the whole program works just fine as-is.

[RussMartin]

Here's an example of one of many different attempts.

When the flag is 1, it works just fine.

When the flag is 0, it works fine when there is no data present (the first byte read is $FF). As long as the switch is held down, it flashes the LED one way; when it is released, the LED goes back to its "idle" condition.

For any other data present, it sometimes seems to go directly to PLEXIT; other times, it works as it should.

In fact, I'm playing with it now. On one attempt (with data present), it seems to jump directly to PLEXIT; on the next, it plays back the data. Then the cycle starts over again: One wrong response, one correct one. Time after time.

[Archangel]

Hi Russ,
I remember back in the early nineties making a 3 wire timer the 3 wires being hot ground and load. When you activated the timer by momentarily switching power to the load the timer would activate and hold power on the load for 15 seconds. The circuit used a transistor and a capacitor to feed the base and a 555 timer and another transistor to carry the load. My point is maybe you could use a capacitor on your inputs, when it charges up it drops the load and requires you to release the switch to reactivate.

[Acetronics2]

Hi, Russ

I remember having had similar issues some years ago whith a 16F628 ...

IF THEN tests didn't work at all ... whether the condition result.

Was for a R/C failsafe sequence ... rather annoying, indeed.


I just got out of that by re-organizing my subs ( that were called by goto's ...) a bit more "rationnaly" ...

May be posts are not fallen into Archives yet ... ( I'll dig somewhat ... )

Alain

PS: Got it ... but hurry up !!! I Won't be able to post a lot until it passes the limit ... lol
http://www.picbasic.co.uk/forum/showthread.php?t=1952

[RussMartin]

Joe, the switch drives an optoisolator which in turn drives the PIC input (GPIO.3 configured as input, not MCLR). (I've looked at the switch and the output from the opto on the scope; there's not much bounce.)

Alain, my general arrangement of the program is:

PROGRAM (things done at power-up only)

MAIN LOOP (you've seen it)

SUBROUTINES (you've seen the one that is the problem)

INTERRUPT HANDLER

END

I'll try moving some things around, but I continue mystified and frustrated.