Loadable plugins support
"Sztupák Sz. Zsolt"
Managed to get a simple, dynamically loading plugin support to work.
This means we can now not only write interpreted lua scripts, but also
compiled C code to control ML and Canon.
So, there are now three separate ways to externally script your
Canon/ML: USB, Lua and now loadable plugins. (Wooo. I'm on a roll. :) )
What better test is for this plugin support to actually put major parts
(= the whole interpreter) of the Lua scripting support to a separate
module. This also means that hopefully lua scripting will work for 550D
users too! (Please test!)
About the implementation:
Plugins are compiled as position-independent, and some linker tinkering
is used to put some section information to the first few bytes of the
binary. Now, the "linker" (strong quotes) will know which sections of
the binary will contain the function and data pointers, that need to be
relocated, and will relocate them. Communication from/to the plugin is
done the following way:
The plugin_export.h file contains all the functions that are exported
from ML/DryOs to the plugin. The ML module loader will send this
information to the plugin, who will load the positions from this
structure, and can use all of the exported functions natively.
The plugin on the otherside can signal the compiler that he wants to
create en exportable function using the EXTERN_FUNC macro. The
definitions of these functions will get to a special place inside the
plugin bin (the almost very start), from where the ML Module loader can
load this information.
The advantage of this solution:
- It's more or less simple. Handling of the exported functions is
actually automated by the macros, so it's not that hard to use.
- You only need to compile the plugin once, and it will work on all
cameras, firmware and ML versions. (if they export the functions you use
of course)
The disadvantage:
- All ML/DryOS functions need to be explicitly exported, for them to be
useable inside the plugins.
- The function export list and function pointers inside the plugins take
away memory.
The other possible way would be to auto-generate stubs files from the
compiled ML autoexec.bin-s and DryOs stubs file, and use them inside the
plugins. The advantage would be that no explicit exporting would be
needed, and all ML/DryOs commands would be available for plugin
developers. There would be also no memory used for the export lists (as
there are none). The major drawback is that each plugin would have to be
compiled for all ML and all Camera versions separately. This idea was
soon discarded.
If you have any other idea on how to implement linking easily feel free
to tell :)
How to build plugins:
The plugins directory contains everything that is needed to build
plugins. Just create a new directory, copy the Makefile from lua or the
testplug directory to your directory, edit it (add the .o files), then
run make, and it will compile. There are some linker scripts and helper
functions available inside the base plugins directory, that will be
compiled in every plugin. After compiling to load them you have to use
the plug = load_plugin(filename) function to load it, and func =
get_function(plug, func_id) or func = get_function_str( plug, func_name
) to get the address of the function. After that func can be used as a
regular function. There is no real API yet to actually use modules (lua
module will be loaded when lua scripting is first used, and the testplug
module is loaded using the "Don't touch" button), but if it is okay with
everyone I'll start some structural changes so external modules can work
as any other part of ML (like extending the "configs" API to allow
adding configuration values later, etc.)
Other questions:
1. I saw that the .bss section is not put inside the autoexec.bin files.
I know it only contains a bunch of zeroes, but wouldn't it be safer if
those zeroes would be explicitly loaded too (they take memory away
anyway)? The plugin makefiles do fill in the .bss section inside the
binary, as during dynamic loading no one can guarantee that the memory
will actually be zeroed out.
2. On 60D I set that the module loader will load the modules inside
"malloc" memory. On all other cameras it will load it inside the
"AllocateMemory" memory. What other cameras are there where "malloc"
memory would be more appropriate?
Binary download link for testing: (I only have a 60D. 550D testers are
very welcome!)
https://bitbucket.org/sztupy/magic-lantern/downloads/magiclantern-2012Mar8.usb.lua.plugin.sztupy.zip.zip
SztupY
Dave Thomas
--
http://magiclantern.wikia.com/
To post to this group, send email to ml-d...@googlegroups.com
To unsubscribe from this group, send email to ml-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/ml-devel?hl=en
Daniele Musso
What about performances/startup speed?
Great work !
Inviato da iPhone
Il giorno 08/mar/2012, alle ore 04:01, "Sztupák Sz. Zsolt" <ma...@sztupy.hu> ha scritto:
> SztupY
Redkite Bart
Maybe this can lead to a basic stable ml core with all the common features like zebra, peaking, iso, kelvin, timelapse, audio followed by a few plugin tabs where you can add plugins with additional functionality. Kind of a ML appstore.
Redkite Bart
eggnot
eggnot
i mean it works on 550d. wb_shoot.lua tends to glitch(shoots reapiteadly, trigged with play button for some reason, in M mode not sleeping for 1000, etc), test it more later. it's small bugs i bealive to be eliminated.
Giovanni Di Cello
;)
"Sztupák Sz. Zsolt"
> I can test stuff on my 50D, let me know if you know how to do it.
> ;)
> http://magiclantern.wikia.com/
>
> To post to this group, send email to ml-d...@googlegroups.com
> To unsubscribe from this group, send email to
SztupY
Giovanni Di Cello
Testing in a while :)
Giovanni Di Cello
Lauris Heijdemann
Perhaps now we can program the canon to roll on a dolly, pan, tilt, zoom, focus.
By pulse wide modulating the led or by beeping via monitor audio?