The 6d & 60d are low on memory, it'd be nice if there'd be a compiler switch to turn off the audio and video (recording, not live view) features for people who never do video (i.e. me :-)) and want more ram. I'm posting this as a feature request since I guess a seasoned dev can identify the source code to wrap in a switch in no time, while it'd take me a long time to find it. I don't know how much memory would be saved tough & thus if it'd be worth the hassle.
6D is able to boot the 2nd pool now. only binary size is limited.
60D I think is stuck with what its got.
Quote from: 1% on February 08, 2013, 12:56:07 AM
60D I think is stuck with what its got.
Doh, I've got a 60d :-p ... so your call if it's reasonable or too much a hassle.
comment out things in features.h in the platform directory
Quote from: 1% on February 08, 2013, 02:00:54 AM
comment out things in features.h in the platform directory
Yes, I did, and that's what I'm talking about ... my 60d has 39k+1239k free memory - is this enough for picoc?
If not another feature macro for a/v would be nice so I could "#undef COMPILE_AV_STUFF" to save further ram because I expect the whole video recording/bitrate/... code should take quite a lot of space.
pico C is mainly about binary size. add it and see if your camera boots.
Quote from: 1% on February 08, 2013, 02:18:43 AM
pico C is mainly about binary size. add it and see if your camera boots.
Ok, didn't know that - so I enabled "CONFIG_CONSOLE = y" and "CONFIG_PICOC = y" and it boots ... I'll look trough the thread http://www.magiclantern.fm/forum/index.php?topic=4362.msg25677#msg25677 and hope I'll figure it out :-o
You can #undef every single feature, look in features.h and all_features.h.
Quote from: a1ex on February 08, 2013, 10:46:24 AM
You can #undef every single feature, look in features.h and all_features.h.
Doh, I had no idea there already is such a fine-grained structure since I never had a look at all_features.h - great work, thanks!
One other request though - would it be possible to #include some (empty) user_features.h after the platform features.h so I don't have to modify the features.h, causing potential merge collision when updating? No problem if I'm the only one potentially using it :-) but I recently had such a merge collision with features.h
Quote from: Marsu42 on February 09, 2013, 12:33:29 PM
Doh, I had no idea there already is such a fine-grained structure since I never had a look at all_features.h - great work, thanks!
One other request though - would it be possible to #include some (empty) user_features.h after the platform features.h so I don't have to modify the features.h, causing potential merge collision when updating? No problem if I'm the only one potentially using it :-) but I recently had such a merge collision with features.h
I know that is possible to use makefile.user to define features, maybe there is a way to undef them too from there, but I don't know it.
Since we define a function with -DFUNCTION maybe -UFUNCTION undef it?
This is a problem for any ml customization. you have to work it out with repo changes. I don't think there is an easier way to do it. features.h isn't too bad to resolve.
Quote from: scrax on February 09, 2013, 04:24:59 PM
I know that is possible to use makefile.user to define features, maybe there is a way to undef them too from there, but I don't know it.
Since we define a function with -DFUNCTION maybe -UFUNCTION undef it?
Yes and no - there is a gcc -U function, but it fails if the macro is #define'd in the source code. So the only solutions are either to #include a user_features.h from features.h (my suggestion, by far the easiest) or wrap all #define statements in features.h/all_features.h into another macro, for example:
#ifndef SKIP_FEATURE_SNAP_SIM
#define FEATURE_SNAP_SIM
#endif