Shop OBEX P1 Docs P2 Docs Learn Events
code question — Parallax Forums

code question

There has to be a structural issue that I am confused about here, but I have been fiddling for the most part of a day and it eludes me.

This code runs in its own cog.

It copies a small region of an image from HUB Ram into LUT Ram. It then copies the LUT Ram contents back to a different region of the image in Hub Ram. Simple and it works fine.

However, when I started to add call subroutines, I ran into an issue.

If you look at the subroutines section(line 51), you'll see a subroutine that is not actually called, does absolutely nothing, but does corrupt the data I am passing from the LUT to the Hub.

If I comment out the subroutine, everything is fine.

How can a subroutine, which does nothing and is never called, have any impact on a program?
dat             org
area_test

              
              mov  at_testpoint, ##32064
              mov  at_testPointaddr, at_testpoint
              add  at_testPointaddr, ##_SCREEN_BUFFER
              mov  at_inc2output,##129_408   'offset from input point output point (640*202)+128
              mov  at_rgnwidth,#21
              mov  at_rgnheight,#21
              mov  at_rgnwm1div2,#10
              mov  at_rgnhm1div2,#10
              mov  at_rgnbase,at_testPointaddr
              sub  at_rgnbase,#at_rgnwm1div2
              mul  at_rgnhm1div2,##640
              sub  at_rgnbase,at_rgnhm1div2
              mov  at_rgnlinept0,at_rgnbase
              mov  at_temp1,at_rgnwidth
              mov  at_lutaddr,#0
              mov  at_temp2,at_rgnheight
'***
at_region2lut 
              mov    at_temp1,at_rgnwidth
              rdfast #0,at_rgnlinept0
              rep    @at_hline,#20
              rfbyte at_pixval
              wrlut  at_pixval,at_lutaddr
              add    at_lutaddr,#1
at_hline
              add  at_rgnlinept0,##640
              djnz at_temp2,#at_region2lut
'***
              mov  at_lutaddr,#0
              mov  at_rgnlinept0,##_SCREEN_BUFFER
              add  at_rgnlinept0,##1040
              mov  at_temp2,#21
at_lut2region
              mov    at_targetpt, at_rgnlinept0 
              mov    at_temp1,#21
              wrfast #0,at_rgnlinept0
              rep    @at_hline2,#20
              rdlut  at_pixval, at_lutaddr
              add    at_lutaddr,#1
              wfbyte at_pixval
at_hline2
              add  at_rgnlinept0,##640
              djnz at_temp2, #at_lut2region
              jmp #area_test             'back to start
'__________________________________________________________________________________________________________              

'**************
'Subroutines
at_neibrhood                                    '<----------------???????
  ret
'*************                            'start address of output picture  (640*202)+128
            
at_bool             res 1
at_lutaddr         res 1   
at_lutpt0           res 1
at_temp1          res 1
at_temp2          res 1
at_pixval           res 1
at_outputLinept   res 1
at_testline         res 1
at_testval          res 1
at_testPoint       res 1
at_testPointaddr  res 1
at_imageBase      res 1
at_imageEnd       res 1
at_outputBase     res 1
at_outputaddr     res 1
at_rgnbase          res 1
at_rgnwidth        res 1
at_rgnheight       res 1
at_rgnwm1div2   res 1 
at_rgnhm1div2   res 1  
at_inc2output     res 1
at_rgnlinept0      res 1 
at_targetpt         res 1
at_testpix           res 1
                                      fit     $1F0

Comments

  • rjo__rjo__ Posts: 2,114
    Thinking that maybe I was running out of room in low hub address below the image, I added to the base address of the image by ##1000. That didn't help.
  • rjo__rjo__ Posts: 2,114
    This illustrates the issue. Initially an image is loaded with titles. Then image capture from two PropCams, historgram, and image processing begins and is overlaid on the original image in the buffer.

    A 21x21 area is being captured from the first camera on the left and displayed
    at the top of the frame toward the right edge.

    Without the inclusion of an uncalled, do nothing subroutine, the image capture
    is fine. But with the inclusion of the do-nothing, uncalled subroutine, the image capture appears to include part of the white frame from the left side of the original under-laid image.

    How can including an uncalled, do-nothing subroutine possibly do anything?
    640 x 480 - 15K
    1280 x 480 - 52K
  • Hi, rjo__

    Have you ever tried to replace the 'ret' instruction with a 'res 1' statement, or even another instruction, such as a 'nop'?

    If the problem has to do with the address of any / all other labels, it will continue to interfere with your code.
    Otherwise, it will magically disappear, and you may start to blame the compiler.
    Another useful test might be to check the $ hex image of the code output to detect any incorrect compiler behavior.

    Hope that helps a bit

    Henrique
  • SeairthSeairth Posts: 2,474
    edited 2016-12-16 17:26
    Do you mean for at_rgnwm1div2 on line 14 to be an immediate value?
  • rjo__rjo__ Posts: 2,114
    I just found that:)... same da*n*ed thing I did before. I can't believe it.

  • Accidentally specifying immediate mode (or not specifying it) is probably the most common mistake I make, especially when refactoring code. And I suspect this is the same for others. What makes this particular bug bad is that it's often hard to spot. It makes me wonder if there is a better syntax for this.
  • RaymanRayman Posts: 13,917
    If we had a list of things to check for when debugging, that should definitely be near the top.
  • kwinnkwinn Posts: 8,697
    Always found assemblers that specified the addressing mode as part of the command easier to work with. Most common mistake I make with the P1 is leaving off the "#".
  • rjo__rjo__ Posts: 2,114
    Rayman wrote: »
    If we had a list of things to check for when debugging, that should definitely be near the top.

    But it is on my list!!!

    I actually looked for it and didn't see it... until the next day after begging for help:)
    It is a short piece of code... how I did not see it is beyond me. I was so busy systematically looking in all the wrong places...for an entire day!!!

    My bigly problem is that I can't help trying to optimize every little task... I write it the slow way to get it working and then play with faster and faster methods.

    I have now decided to completely re-organize my entire demo...
    It might never get done:)

    I love it!!!

    Very addictive.






Sign In or Register to comment.