What memory location(s) would you suggest to monitor in sx60hs?
So far I've seen the value be 0x03 and 0x3c in the camera log. From using rmem before and after running MD, the neighboring values don't don't seem to be affected
It's possible that the corrupted area is located completely elsewhere (for example: your byte variable's source, the propcase area, ...). You could also try disabling all CHDK drawings (use an empty function for draw_pixel_std() ) and do the experiment blindly.
con 1> rmem -i32 0xb910 640x0000b910 2560x0000b910: 0x00000000 0x00000001 0x00000000 0x000000010x0000b920: 0x00000001 0x00000000 0x00000000 0x000000000x0000b930: 0x00000001 0x00000000 0x00000000 0x000000000x0000b940: 0x00000001 0x00000000 0x00000000 0x0002405f0x0000b950: 0x0002aed4 0x0000fffc 0x0000ffc9 0x01d201320x0000b960: 0x01d40134 0x01d60136 0x01d80138 0x000000000x0000b970: 0x00000000 0x0002aed4 0x00000000 0x80008000
con> cconnected: Canon PowerShot SX60 HS, max packet size 512con> rmem -i32 0xb910 640x0000b910 2560x0000b910: 0x00000000 0x00000001 0x00000000 0x000000010x0000b920: 0x00000001 0x00000000 0x00000000 0x000000000x0000b930: 0x00000001 0x00000000 0x00000000 0x000000000x0000b940: 0x00000001 0x00000000 0x00000000 0x0009dce20x0000b950: 0x0009d487 0x0000fffc 0x0000ffc9 0x01d201320x0000b960: 0x01d40134 0x01d60136 0x01d80138 0x000000000x0000b970: 0x00000000 0x0009d487 0x00000000 0x80008000
I've attached a corrected version of motion_detector.c that treats triggering on colors correctly. The previous version may well have triggered on color changes, but the R G B values were not calculated correctly.
!m=require'extras/md' m.init()
!m.print_result(m.do_md({threshold=10,mode='y',timeout=300,wait=true,cell_vals=true}))
cells: 0 time: 0.320values: 179 200 208 200 175 211 146 96 91 206 220 93 14 10 218 224 89 11 10 220 217 233 238 230 211
I haven't started debugging yet, but I don't think the U, V and RGB modes are correct in the new code for pre-digic6 cameras
On the other hand I always thought the calc was suspect pre digic 6 for u v r g b because I didn't think the position/alignment in the row was constrained properly so uyvyyy was used correctly. Sometimes it would hit yyuyv. It gave me a headache;)
I guess the simplest thing to do ( but maybe not most pleasing) is to ensure all changes are enclosed within the #ifdef thumb properly.
regarding the test code, if the test pattern was implemented in chdkptp GUI code, it could almost be automated....