Overview[]
Properties are variables in DryOS to exchange information between tasks. In fact, those are some kind of broadcasted events (one task can change a value, and other parts of code can get notified when that value changes). You can setup callback functions to receive notifications for any property; they are easy to use, thanks to Trammell's PROP_HANDLER macros.
The properties usually take integer or string values. Each property has a "len" parameter, which specifies the amount of bytes used for the value (e.g. for an integer property, len=4).
Properties are used for lots of stuff (e.g. ISO, shutter speed, aperture, focus, white balance, remaining shots / recording time etc). Many (but not all) properties are similar between 5D2 and 550D.
There are also other kind of events, unrelated to properties, for example, GUI events. See GUI Events, GUI Events/550D and CHDK. There are also persistent parameters (remembered when camera is turned off); for those, see the Params page at CHDK wiki.
Reading / writing properties[]
- To be notified via a callback when another task modifies a property, use the PROP_HANDLER macro:
PROP_HANDLER(PROP_SHOOTING_TYPE) { int shooting_type = buf[0]; // uint32_t* buf contains the property value // you also have a variable "unsigned len", which contains the length of the data. // do something with it return prop_cleanup( token, property ); // always return this } Low level stuff: you can also use prop_register_slave() to be notified via a callback.
- To modify a property, use prop_request_change(property, addr, len).
See Magic_Lantern_API and lens.c for usage of the property-related functions. See property.h for a list of properties used in Magic Lantern code, and add new ones in this file.
Discovering properties[]
thumb|300px|right|Draw-prop example: discovering flash-related properties
We can see all PROP_* related outputs with:
- the draw_prop option in the Debug menu.
- the dumpf command: dumpf; Debugging Magic Lantern
Properties can also be found by static analysis of the code:
- tracing the calls to prop_request_change
- decompiling the ARM code backwards, from debug strings
- a rough automatic analysis of properties can be done with GPL Tools/ARM console.
Other useful links:
- See also on CHDK wiki Property_list (May 2009)
- See Lens info properties events in DryOS
- See also CAMSET00.DAT file.
Describing properties[]
Properties/550D[]
Properties/600D[]
Properties functions[]
prop_register_slave()[]
here is what I believe to be the way to register a function to be called if a list of properties is changed.
- first the list (of 9 properties, each of 4 bytes) is copied into other piece of memory.
- then prop_register_slave() is called with r0 = properties_list, r1=num_properties, r2=function_called, r3=0, [SP]=function_that_does_update
- thus it seems prop_register_slave(void* properties_list, int num_properties, void* function_called, int arg_maybe, void *update_func )
ROM:FF19D6E8 LDR R1, =properties_list_9items ; src ROM:FF19D6EC ADD R0, SP, #0x30+dest ; dest ROM:FF19D6F0 MOV R2, #0x24 ; '$' ; size ROM:FF19D6F4 BL memcpy ROM:FF19D6F8 ADR R3, mac_update_and_give_sem ROM:FF19D6FC STR R3, [SP] ROM:FF19D700 MOV R3, #0 ROM:FF19D704 ADR R2, mac_prop_handler ROM:FF19D708 MOV R1, #9 ROM:FF19D70C ADD R0, SP, #0x30+dest ROM:FF19D710 BL prop_register_slave ... ROM:FF0574A0 prop_register_slave() ... ROM:FF4C3DEC properties_list_9items DCD 0x1000006 ; DATA XREF: mac_register_properties+8 ROM:FF4C3DEC ; ROM:off_FF19D938 ROM:FF4C3DF0 DCD 0x1060001 ROM:FF4C3DF4 DCD 0x1060002 ROM:FF4C3DF8 DCD 0x1060003 ROM:FF4C3DFC DCD 0x1060005 ROM:FF4C3E00 DCD 0x1060004 ROM:FF4C3E04 DCD 0x1060000 ROM:FF4C3E08 DCD 0x100000B ROM:FF4C3E0C DCD 0x1000008
prop_request_change()[]
See here [1] and in property.h.
this is the function to update a property value.
R0 is the property "name", r1 is supposed to be where the property value is stored (a pointer), and R2 is the sizeof the new value (in bytes).
ROM:FF2028E8 ADR R2, aProp_requestProp_compression_lD ; "PROP_Request PROP_COMPRESSION_L (%d)" ROM:FF2028EC BL DebugMsg ROM:FF2028F0 LDR R1, =unk_14D44 ROM:FF2028F4 LDR R0, =0x2020001 ROM:FF2028F8 MOV R2, #4 ROM:FF2028FC BL prop_request_change
ROM:FF20292C ADR R2, aProp_requestProp_compression_m1D ; "PROP_Request PROP_COMPRESSION_M1 (%d)" ROM:FF202930 BL DebugMsg ROM:FF202934 LDR R1, =unk_14D48 ROM:FF202938 LDR R0, =0x2020002 ROM:FF20293C MOV R2, #4 ROM:FF202940 BL prop_request_change
See http://magiclantern.wikia.com/wiki/Properties/prop_request_change
Internals[]
You can see what code calls the property slaves by examining the call stack.
property slave 0xff1b6514 prop_delivery_maybe 0xff1b712c AJ_AnalyzeMpuReceiveData 0xff1d852c AJ_StateObj (state probably around ff544b59) 0xff1d84f4 AJ_StateObject_stuff => FUNC(arg0->off_0xC)(arg0, arg1, arg2, arg3) 0xff056c84 EventDispatch 0xff1d8a3c AJ_UserLevel_task 0xff0771c0 FUNC((*(arg0))->off_0xC)((*(arg0))->off_0x10, (*(arg0))->off_0xC, arg2, arg3) // somewhere near task trampoline functions
Functions called from prop_delivery_maybe:
0xff1b6358 get_property_list_of_slaves_maybe => calls 0xff1b62f8 get_property_group_maybe 0xff0575c0 prop_cleanup [why called from here?!]