Life after 2k w/ 16F648

[Bruce]

If you look hard at the logic, you'll see what's happening. It can never get
through the FOR/NEXT loop any time your IF/THEN block evaluates as TRUE.

When this happens, as you mentioned previously;

If result = ...THEN" test always passes

That is exactly what causes this;

placed in a FOR NEXT loop ... program hangs up !!!

Because GOTO Start is inside your loop, inside the IF/THEN block that always
evaluates as TRUE.

Start:

  result = 0

For I = 1 to 16....
  GOSUB Thesub
  PULSIN input,1, value

  ' If this next part "always" evaluates TRUE, then you'll never make it
  ' past FOR I = "1". You keep jumping back to Start & restarting
  ' the FOR/NEXT loop

   IF (value < A) OR ( value > B ) then
     error = 1 ( it's a red led ! )
     value1 = ...
     value2 = ...
     GOTO Start  ' <-- restarts FOR/NEXT loop over & over & over, etc,,
   ENDIF           ' while IF/THEN evaluates as TRUE
   result = result + value
NEXT I

   result = result >> 4 ( the mean value ....)

TheSub:
   Low out1
   Pulsout out1,value1
   Low out2
   Pulsout out2,value2
   RETURN

Now let's assume the statement IF (value < A) OR ( value > B ) then
never ends up being TRUE. You go through the FOR/NEXT loop until it expires,
fall-through into TheSub, land on the RETURN, and you now have another big
problem.

RETURN pops the return address from the stack. Where is your program going
to return to if the address is invalid...?

[Acetronics2]

Hi, Bruce

You'll laugh ... that's exactly what I'd like the program to do !!!

let's see closer :

if value is between A and B ... test fails and program computes the mean value. That runs well.

if value is out from A to B , it means signal is out of limits ( Wrong signal ) or no signal at all ( pulsin returns 0 - note pulsin_max defined 12500 @ 20 Mhz).
Then, loop is supposed to be endless and generating spare signals to outputs until a correct input signal is found.

I had a closer look lighting a led as a "pass flag": Even with no incoming signal at all, test for value never comes true ... led do not light up when High led is placed
right after "value2 = ..."
But the Pulsin statement is run well.

Note between the end of this bit of program and the sub, there's a goto to the "good incoming pulse section" ...

If you want the full prog. ( source is ~ 500 lines ...) to have a better view, it will be without any other than the copyright limitations.

The most confusing thing is those lines ( they are Copied and pasted from other program ... with same variables !!! ) work perfectly on shorter programs aboard 16F628s.

As I told Dwayne, an IF THEN statement placed after those lines also always returns YES. ...
EVEN values must return NO ...

I seriously think the problem is located in the IF THEN tests ( all the tests... )as Pulsin returns the correct value for the incoming pulse !!!

Alain

[Dwayne]

Hello Ace,

Did you try that While and endwhile code I gave you???

What that code is doing, is ridding you of a "Burp" jump out of a "IF" statement.

Take a look at that while /endwhile code I posted.

Dwayne

[Acetronics2]

Hi, Dwayne

Thanks

I'll try that this week-End ... on the Breadboard, Electronics is not my job !!!

What feds me up is that ALL the IF THEN tests I place after this part of code( wich crosses the 2K limit ...) have a YES answer ... whatever the test does.

I'll try to confirm with a " IF 1 = 0 THEN ..." ... we'll see then.

I'll also try to move my subs at the real END of the program ( I have a GOTO - GOTO part added after the subs ) REMEMBER it runs like that on a 16F628 ....
AND everything has END separators not to punch through.

IF you want the source ... it's the R/C magic box !!! ( parallelling and trimming center and half travel for two servos driven by one channel )

Alain

[Acetronics2]

Hi, Folks ...

The problem is solved ... but that doesn't give me the explanation !!!

I Only placed better the GOTO - GOTO part BEFORE THE SUBs ... Then everything works well !!!
So, I note Subs MUST be placed before or after any program ...

But the return pile should not have been affected by a GOTO-GOTO section ...

Some compiler secrets are still alive ....

Alain