PDA

View Full Version : Life after 2k w/ 16F648



Acetronics2
- 23rd June 2005, 17:35
Hi,

I face a strange thing : in my program, I have a not nested GOSUB statement ( without any jumps ...) . It is placed at line 890 ( PBP ) of my program ... ( 2520 assembler lines )

When alone everything all right ... normal !

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

The same loop, in a shorter program on a 16F628 runs fine ...

Any ideas ???

16F648 also needs to be erased before re-programming ...

Alain

PS PBP + MPLAB 7.11 Environment ( Win XP )

Dwayne
- 23rd June 2005, 17:57
How is the GoSub returning??

If I remember correctly, you are only allowed 4 levels of "GoSubs"

Thus, my first impression would be a "illegal" return from your GoSub... Something like the following:

Loop:

.....
......
......
if (something happens gosub Loop2)
goto Loop

Loop2:
......
......
......
if (something happens goto Loop) ' This is a NO NO!!!!
.....
.....
return

end


Dwayne

Acetronics2
- 23rd June 2005, 18:12
No, it's much simpler ...

Start:

result = 0

For I = 1 to 16....

GOSUB Thesub
PULSIN input,1, value

IF (value < A) OR ( value > B ) then

error = 1 ( it's a red led ! )
value1 = ...
value2 = ...
GOTO Start

ENDIF

result = result + value

NEXT I

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


.
.
.

the sub:
Low out1
Pulsout out1,value1...
Low out2
Pulsout out2,value2

RETURN

That's all !!!
Alain

Bruce
- 23rd June 2005, 18:57
Is there another GOTO Start that's not enclosed in the IF/THEN block?

If program execution falls-through, lands in TheSub, then hits the RETURN, it will go haywire on you.

Acetronics2
- 23rd June 2005, 19:11
Hi, Bruce

No, nothing else.

Note without the FOR NEXT, it works well , but a further (in the 2 following lines ) " If result = ...THEN" test always passes, even if values should make the test fail ...

another strange thing.

Alain

Bruce
- 23rd June 2005, 19:41
Remove the GOTO Start from the IF/THEN block. Place it after the NEXT.

Dwayne
- 23rd June 2005, 19:44
How about a interupt??

Maybe a wrong return on a interupt (Like a Goto Start), instead of not returning on the GoSub?

I was looking at your code....

What happens if A = Value? and that IF statement fails?

It goes right through 16 times, and then continues to the Subroutine...hits REturn... and...and...<g>

DWayne

Dwayne
- 23rd June 2005, 20:17
Hello Ace,
>>>
Ace
For I = 1 to 16....

GOSUB Thesub
PULSIN input,1, value

IF (value < A) OR ( value > B ) then

error = 1 ( it's a red led ! )
value1 = ...
value2 = ...
GOTO Start

ENDIF

result = result + value

NEXT I

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

REwrite it as the following:; I think this will solve your problem...This is assuming you have a goto start BEFORE your subroutine...like after your
result = result >> 4 ( the mean value ....) statement.


i=1
while(i<17)

GOSUB Thesub
PULSIN input,1, value

IF (value < A) OR ( value > B ) then

error = 1 ( it's a red led ! )
value1 = ...
value2 = ...
i=18
else
result = result + value
endif
I=I+1
endwhile
if I>18 then goto start

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

Acetronics2
- 24th June 2005, 06:08
Hi, Bruce

The "GOTO Start" has to be here to allow a pulsout for each value of I ....

It works very well with no FOR -NEXT loop ...

But there's another problem on the line past "result = result >> 4" :

( with >> 4 neutralised ...of course !!! )

IF ABS ( result - refvalue ) > 100 THEN Start

Whatever the value of result ... test result is YES !!!

So, I begin to think the problem is located on the IF THEN tests ...

Note this works with R/C signals ... 1 to 2 ms pulses @ 40 Hz

Alain

Acetronics2
- 24th June 2005, 07:01
Hi, Dwayne

There are no interrupts in all the programs i've written at this day ...
for these types of programs, all is driven by the incoming ( or not !!! )signals ...hope it will last !!!

I want to tell once more this piece of basic litterature has been running perfectly for years on smaller programs aboard dozens of 16F628s ... with the same names for variables ...and the same working context.

IF value between A and B ... it is simply considered good and taken for the mean value calculation ... with no spare value for pulsout generation, nor calculation reset.

Alain

Bruce
- 24th June 2005, 07:59
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
- 24th June 2005, 08:55
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
- 24th June 2005, 14:36
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
- 24th June 2005, 14:59
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
- 27th June 2005, 15:47
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