IF-THEN what?

[Ioannis]

Well, I am embarrased to have this asked, but maybe my coffee is not strong enough.

Isn't these two totally equivalent?

IF w1>A THEN
    IF w1<B THEN
        DO SOMETHING
    ENDIF
ENDIF

 
IF w1>A AND w1<B THEN DO SOMETHING

They do not respond as expected. I mean as the second snipet.

Ioannis

[dhouston]

Both work here.

A=5:B=10:w1=7

If w1>A And w1<B 
   Debug "w1>A And w1<B"
EndIf

If w1>A 
  If w1<B 
    Debug "w1>A And w1<B" 
   EndIf
EndIf

[HenrikOlsson]

Hi,
I tried it here as well and they both seem to do the same thing... I tried with W1 less than A, bigger than B and within the range, both routines responded in the same way, what are you getting?

[Ioannis]

Thanks for the replies. Well, I was testing a code for decoding RF remotes based on the MM53200/UM3750 or HT12 transmission protocol.

The code with the AND in the IF-THEN statements works fine.

The other with the nested IF-THENs does not.

Mystery...

Me too think that both codes are equivalent.

Ioannis

[mister_e]

It reminds me some weird stuff I already experimented in the past, memory leak or whatsoever, run CCLeaner, and reboot. this should do the trick.

Out of curiosity, are you using MCSP or MPLAB?

[Ioannis]

Thanks Steve. I am using MCSP and Pickit2 with Stand Alone Driver.

You are right about the weird things. I had some in the past for un-explained reasons.

Will see.

Ioannis

[Ioannis]

OK. I think Steve was right.

I have this test code on a Dropbox folder in order to work on different PCs. On a freshly boot PC, guess what. Works OK!

How can a reboot make a program running as expected (or not...) ?

Ioannis

P.S. Maybe it is a tough one for Darrel

[mister_e]

I would believe it's more a MCSP behaviour than PBP compiler, but ya never know.

This said, it happen on other compiler and programming environement too. Visual Studio, etc etc name it. Rebooting once in a while never hurt...

[flotulopex]

Ioannis,

Depending on the PIC used, you might want to be careful in what syntax you are going tu use.

This first code costs you i.e. 11 WORDs (PIC16F628) and 13 WORDs (PIC16F690)

w1 var byte
A  var byte
B  var byte

IF w1>A THEN
    IF w1<B THEN
    ...
    ENDIF
ENDIF

This second code will cost you 60 WORDs (PIC16F628) and 64 WORDs (PIC16F690)

w1 var byte
A  var byte
B  var byte

IF w1>A AND w1<B THEN
    ...
ENDIF

[Bruce]

How can a reboot make a program running as expected (or not...) ?

in short - it cant. The compiler is going to produce the same .HEX file no matter what.

If you had a problem with your PC that caused the compiler to generate a bad .HEX file at compile time, I suspect you would be having a great deal more problems than just compiling a PBP program.

My guess would be you had something loaded in memory, from an old file, that wasn't being updated by your programmer at program time.

Re-booting or not re-booting your PC should have zero affect on the compiled .HEX file that PBP produced at compile time.

For example, you compile a program, then you re-boot your PC. How would re-booting your PC alter your previously compiled .HEX file? If it does - you have major issues with your PC..;o)

If your device programmer is not reloading the new version .HEX file into memory after each compile, prior to progamming the device, that would be an issue.

[Ioannis]

@Roger: That was my concern, the produced size of the code. I knew that inline AND command needs more code space.

@Bruce: Well, I never meant or implied that a reboot would alter my .hex file. It just "seems" that after the reboot the compiler produced a correct hex file. I have to say that I use a lot the Sleep or Hibernate state on my Laptop. Maybe there lies the problem.

The project files are stored in a Dropbox folder and when a new hex is produced I see the blue rolling arrows that show a sync is taking place, so I am pretty sure the files are updated.

Now all seems fine after a complete reboot. Both codes work the same as expected.

Ioannis