CNZ RAM8H SUB1 not working as expected

[bgriffith]

I'm not using the latest firmware, so it's possible this is old news.  I'm running v03.02.17f.
 
I'm using the bits in RAM82 to signify if a notification email needs to be sent -- one bit for each email.  I'm doing the same with RAM83 for the WEBSETs.  I then have a subroutine that turns on my router, sets a timer, does the EMAIL and/or WEBSET, and clears out RAM8H.
 
    CNZ RAM8H WEBNOTIFY
 
Seems like it should work, but it seemed like WEBSETs were only happening when emails were being sent (when RAM82 != 0).  I copied RAM8H into VAR2 where I could see it.  I can see that a couple bits in RAM83 get set, but they just stay set, and no WEBSET happens (I didn't wait for an email to be requested).
 
I changed the above line to this:
 
    TSTNE RAM8H 0  
    CALLSUB WEBNOTIFY   
 
Now it works as I wanted it to.  WEBSETs and EMAILs go out, and RAM8H (visible in VAR2) never stays at a non-0 value long enough for me to see it. 
 
So should I be able to use CNZ with the upper 16 bits of a RAM location or was that not intended to work?
 
Thanks,
-Ben
 

 

[CAI_Support]

CNZ is not for comparing variable values.  In the user manual. it states " Same as the branch instruction but calls a subroutine instead of branching." Or, it means "Callsub if zerobit is not set."
 
This instruction check against zero flag, Zero flag is an internal Boolean value remembering last tst or math instruction value was zero or not

 

[bgriffith]

This is what I was basing my usage on:

BNZ  |  (a) b  |  If the optional a operand is specified it is tested
for a nonzero value. If a is not specified then the
zero bit is tested for non-zero. If true then program
jumps to label specified in operand b.
...

CNZ | (a) b | Same as the branch instruction but calls a subroutine
instead of branching. See section on program address stack.

 
I specified RAM8H as the "optional a operand".

 

[CAI_Support]

I see what your point is.
The problem is ONLY RAM1 has 32 bits accessible, which starts from RAM1B1 to RAM1B32
RAM83 is RAM8 byte 4. 
When you checked against RAM8H, that is 16bit value including all RAM82 and RAM83.
Are you sure RAM8H is all zero, or not zero in both byte 3 and 4?
 
Do you plan to update to latest firmware?  I would recommend to the latest 8.02.18b3 or 18d3.

 

[bgriffith]

When I set the bits I just do:
 
ORB RAM83 1 RAM83
 
So not being 32 bit accessible isn't a problem. 
By copying RAM8H into VAR2 I confirmed that RAM8H was sitting there with a value of 256, even though this line:
 
    CNZ RAM8H WEBNOTIFY
 
should call the WEBNOTIFY routine, which should do a WEBSET (didn't happen) and as it's last line does SET RAM8H 0.
 
When I replaced the above CNZ line with the following two lines:
 
    TSTNE RAM8H 0  
    CALLSUB WEBNOTIFY  
 
everything worked.  I think those two lines should be equivalent to the CNZ line. 
 
I can update the firmware... I might have time later this weekend.  I recall that it requires running a tftp program in Windows.  Is there something special about that or can I do the same with a tftp server in Linux?  I don't have any Windows machines up and running at the moment. 

 

[CAI_Support]

Could you please do a

SET VARx RAM8H
before your CNZ call, then a long DELAY afterwards,
so that you can see from screen what RAM8H actually contains?
 
There is no change in 17f to latest on the CNZ logic handling.
 
You can use any tftp client to update, as long as it is pure tftp on default port

 

[bgriffith]

I tried running just this small program:
 

START    
    SET VAR1 0  
    SET VAR2 0  
    SET VAR3 0  
    SET VAR4 0  
    SET VAR5 0  
    SET VAR6 0  
    SET VAR7 0  
    SET VAR8 0  
RUNLOOP:
    SET RAM8H 256  
    SET VAR2 RAM8H  
    DELAY 10000   
    CNZ RAM8H SUB1  
    GOTO RUNLOOP   
    END    

SUB1:
    SET VAR6 256  
    SET VAR7 256  
    SET VAR8 RAM8H  
    RET    


When I look at the status page, VAR2 is 256 and all the other VARs are 0.  VAR6,7,8 should all be 256.
 
So I replaced the CNZ line with:

TSTNE RAM8H 0
CALLSUB SUB1

Now I see the correct behavior where VAR2,6,7,8 are all 256 and the others are 0. 
 
Then I put the CNZ line back, but used RAM83 there instead of RAM8H.  That worked correctly... the last three VARs were set to 256.
Next I put RAM8H back but changed the setting of it to 128 instead of 256.  That also worked correctly... the last three VARs were 256, 256, 128.
Next I set RAM8H to 0xff00 and that didn't work.
Finally I changed all occurrences of RAM8H to RAM8L and verified that the same problem exists with the lower half. 
I poked around some more and verified that CZ, BZ, and BNZ behave in the same incorrect manner.
 
I didn't get a chance to update the firmware so this is all still with v03.02.17f with build date Sep 20 2013, 08:45:11.
 
-Ben

 

[CAI_Support]

bgriffth,
 
Thanks for your good example code, we have located the problem on that.
We will publish download link soon, for both 18bx and 18dx firmware,
We appreciate your work with us patiently on this.  This will help others, too.