Am 12.11.2013 um 08:58 schrieb Frank Tkalcevic <[email protected]>:
> >>> warning: the frame size of 117088 bytes is larger than 2560 bytes >>> [-Wframe-larger-than=] >> >> it's from src/Makefile: >> Makefile:EXTRA_CFLAGS += $(call cc-option,-Wframe-larger-than=2560) >> $(call cc-option,-Wno-declaration-after-statement) >> >> this limitation comes from the limited kernel stack size and applies to > kernel >> threads only. It does not apply to userland RT threads builds (rt-preempt, >> xenomai) using this: http://static.mah.priv.at/public/UnifiedBuild.html > (even >> though the warning might be generated when building userland RT modules; >> this probably should be removed or rather replaced by a sensible limit >> derived from the specific thread system used). >> >> I dont see an easy way around this limitation short of using statics or > some >> form of dynamic memory allocation for such blobs > > Are the kinematics modules userland RT threads? 2.5/master/rt build: kernel modules only ubc3: it depends on the flavor the ubc3 branch is built for (by default, it supports any thread flavor supported by any of the kernels found automatically, so in the most general case the build creates userland RT as well as kernel RT modules) on startup, autodetection decides which flavor to use, which might result in kernel modules loaded (RTAI, xenomai-kernel) or userland threads modules (xenomai, rt-preempt, posix aka sim) > Statics make the code non-thread safe, which I might not be a problem for > the kinematics module, and it would be better not to do memory allocation in > a realtime thread. as it stands now, the kins modules are singletons *) kins methods are currently called from two thread functions: motion-command-handler and motion-controller, which are always pegged to the same thread and execute in turn, so right now it would be safe to allocate memory in rtapi_app_main(), or use statics I never found any use for allocating memory except during rtapi_app_main() and rtapi_app_exit(); in-RT-thread memory allocation is not used anywhere in the current codebase. > But it would be nice to use the ikfast motion planner to > route the robot arm movement. I guess two instances of the iksolver. yes, that would be a great addition! -m *) IMO this is a supboptimal solution - multiple switchable kins (a 'real' one and a 'trivkins' one for joint jogging) would get rid of much bloat like separate planners > > Frank > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
