CHDK firmware hack discussion (19)

NHSTUB(Close,0xFFE3B614) ok
NHSTUB(Read, 0xFFE3B6A8) ok
NHSTUB(Write, 0xFFE3B6B4) ok
NHSTUB(Remove, 0xFFE3B634) ok

NHSTUB(Mount_FileSystem, 0xFFE3A938)
NHSTUB(kbd_read_keys_r2, 0xFFDDD0C0)
NHSTUB(DisplayImagePhysicalScreen, 0xFFDD1AE0)

NHSTUB(kbd_pwr_off, 0xFFDDD708) bad autofind, it is found manually
NHSTUB(SetPropertyCase, 0xFFC0BB80) bad autofind, it is found
manually

NHSTUB(free, 0xFFCD1704)
NHSTUB(SetZoomActuatorSpeedPercent, 0xFFDD3094) null stub, used
for S2/S3 only
Thanks for the hints.. but they did not work... the firmware compiles and builds ok, but when I put the ps.fir anb diskboot.bin in the camera and update to the chdk firmware the camera hangs... having to release the batteries.

Anyway, I would like to know the process to obtain the valid function addresses... I am a little bit curious, I guess..... I searched for the addresses in the IDA and they seem to be valid functions address, but they are unknown functions.

Any hint on what to do to make the firmware work?

Thanks for the support
 
Hi ewavr,

I sent an email to you, but quickly:
  • With the address you provided, it compiles and links. But it does not work (using the rossig source code for the A570)
  • With the GrAnd SVN version, it even does not compile.. the functions GetZoomLensCurrentPosition, GetZoomLensCurrentPoint and VbattGet are missing I have to find them in the IDA.
I have read several time the http://tools.assembla.com/chdk/wiki/HDK/Adding%20support%20for%20new%20camera page and there are thing unknown to me... for example:

-------------------------------------------------------------------
void h_usrKernelInit() - fix R0(h_usrRoot) and (IMPORTANT!)
R2 (pMemPoolStart) parameters of kernelInit() call like that:
"LDR R0, =h_usrRoot\n"
"MOV R1, #0x4000\n"

"LDR R2, =0xC0000\n"
"STR R12, [SP]\n"
"STR R4, [SP,#4]\n"
"BL sub_FFEC9DA8\n" kernelInit()

here 0xA0000 is an original value and 0x20000 is MEMISOSIZE.
Now return to makefile.inc and modify MEMISOSTART so it
pointed to original pMemPoolStart i.e. 0xA0000 in this example.
-------------------------------------------------------------------

I haven't modified nothing in this file... since I don't know where to find the 0xA0000 and 0x20000. I just have copied the values from the rossig version (values 0xA6C30 and 0x30000). Of course, the values may be wrong... but as the firm compiles and link, I thought they were ok.

For the other files, I neither have touched them... only the 2.S files, where I put the hand defined functions addresses.

Thanks!
 
Alain (and others)

I did a scan of the behavior of every property from 0-269 before, during, and after a "click shoot_full" (in groups of 4, so I could monitor them with decent time resolution) and only 205 appears to be functioning as an indicator of the "readyness" state of the camera. And it does behave as you would expect it to under these conditions: it stays set (1) longer by about the duration of the shot when doing 1 sec exposures.

In some cases, it remains set for 2.5 sec (when exposure is 1 sec, and presumably its doing a dark frame subtraction)

I will also note this: 205 resets (goes to 0) just before my script slows down significantly: A typical cycle time for my script to call a subroutine, scan 4 properties, grab the msec time, print, return, and do a the loop is 150-160 msec. So each line of 4 samples in my output file is typically spaced that much. However, the 2nd printed line after 205 resets seems to be about 500 msec later than expected, and this is true if the image exposure time is short or long. I'm thinking (but I don't know) that this is when the camera is writing the image to disk (hence, other processes run slower), and so it takes longer to do all the things my script does to do another line of samples. If my hunch is correct, then shooting again after 205 resets means you are able to get another shot off even while the current image is being written.

About 15 other properties also change relatively consistently during the course of a shot, but these others all seem generally to be associated with exposure or focus settings (the values in these properties could be anything, positive or negative, and they change by multiple units), and are not always stable under variable conditions, and they change early in the process (when 205 gets set, or shortly thereafter), and none of them seem to vary in a way that is correlated with the exposure time.

So, whatever 205 is, your experience shows it works, and from what I can see, there is nothing else that is better for this purpose.

Regards,

Divalent
 
Cat,

What build of the CHDK are you using? For special build you may need a new UBASIC.exe if the build have new Ubasic commands.

For parameters there is a limit to use only a - j letters.
 
Hi Divalent,
I did a scan of the behavior of every property from 0-269 before,
during, and after a "click shoot_full" (in groups of 4, so I could
monitor them with decent time resolution) and only 205 appears to be
functioning as an indicator of the "readyness" state of the camera.
And it does behave as you would expect it to under these conditions:
it stays set (1) longer by about the duration of the shot when doing
I did also a test with the camera that may explain the behaviour of 205 and the usage I do in my script. Switch to Tv and select a 2 sec or so exposure, shoot and imediately release the button , shoot again and keep it pressed

==> the camera finishes the first shoot and goes on shooting the second one witout displaying the first one !
So, whatever 205 is, your experience shows it works, and from what I
can see, there is nothing else that is better for this purpose.
We share the same feeling : 205 is not that bad when used with "shoot_half" in P, Av, Tv modes only

bye
Alain
 
I did a scan of the behavior of every property from 0-269 before,
during, and after a "click shoot_full" (in groups of 4, so I could
monitor them with decent time resolution) and only 205 appears to be
functioning as an indicator of the "readyness" state of the camera.
And it does behave as you would expect it to under these conditions:
it stays set (1) longer by about the duration of the shot when doing
I did also a test with the camera that may explain the behaviour of
205 and the usage I do in my script. Switch to Tv and select a 2 sec
or so exposure, shoot and imediately release the button , shoot again
and keep it pressed
==> the camera finishes the first shoot and goes on shooting the
second one witout displaying the first one !
So, whatever 205 is, your experience shows it works, and from what I
can see, there is nothing else that is better for this purpose.
We share the same feeling : 205 is not that bad when used with
"shoot_half" in P, Av, Tv modes only
sorry read "shoot_full" and not half : 205 is not that bad when used with
"shoot_full" in P, Av, Tv modes only
bye
Alain
 
i use
CHDK Fingalo v106
pre14.grand148.md.cln-a710-100a-106

but even simple scripts if i use ubasic_test.exe (size 58 875b) OR ubasic.exe (68 056) don't recognize @default lines
and i don't now why?
****
i modify motion detection script but is correct?

@title motion shoot count

@param j Shoot count
@default j 2

@param a Columns
@default a 2

@param b Rows
@default b 2

@param c Threshold (0-255)
@default c 10

@param d compare Interval (millisecs)
@default d 80

@param e Begin Triggering Delay(secs)
@default e 0

@param f Detect Timeout (seconds)
@default f 0

@param g pix step(speed/accuracy adj)
@default g 8

@param h reg mode(0-no,1-incl,2-excl)
@default h 0

@param i measure mode(1-Y,0-U,2-V)
@default i 1

if j
if a
if b
if c
if g
if f

let f=f*1000
let e=e*1000

for z=0 to 10000

let t=0

md_detect_motion a, b, i, f, d, c, 1, t, h, 2, 2, a-1, b-1, 0, g, e

if t> 0 then goto "1"
next z
end

:1
for n=1 to j
print "Shot", n, "of", j
shoot
next n
end
 

Keyboard shortcuts

Back
Top