On 2013-08-12 14:44, Karel Gardas wrote:
Hello Sebastian, thanks for your note, I've already disabled POSIX and changed ticker Init.c configuration with information taken from minimal sample to: #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER #define CONFIGURE_MAXIMUM_TASKS 4 #define CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM #define CONFIGURE_RTEMS_INIT_TASKS_TABLE #define CONFIGURE_UNIFIED_WORK_AREAS #define CONFIGURE_DISABLE_CLASSIC_API_NOTEPADS #define CONFIGURE_MINIMUM_TASK_STACK_SIZE 512
This a very low stack size. You can use the stack checker to see the actual stack usage.
You can also use #define CONFIGURE_DISABLE_NEWLIB_REENTRANCY #define CONFIGURE_UNIFIED_WORK_AREAS #define CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION as additional options.
#define CONFIGURE_MAXIMUM_PRIORITY 15 #define CONFIGURE_INIT but still this is no picnic. RTEMS now fails with: (gdb) bt #0 0x0000cb04 in _Internal_error_Occurred (the_source=RTEMS_FATAL_SOURCE_EXCEPTION, is_internal=false, the_error=536875124) at /export/home/karel/vcs/rtems/c/src/../../cpukit/score/src/interr.c:43 #1 0x0000aa2a in rtems_fatal (source=RTEMS_FATAL_SOURCE_EXCEPTION, error=536875124) at /export/home/karel/vcs/rtems/c/src/../../cpukit/sapi/src/fatal2.c:34 #2 0x00014c6c in _ARM_Exception_default (frame=0x20001074) at /export/home/karel/vcs/rtems/c/src/../../cpukit/score/cpu/arm/arm-exception-default.c:24 #3 <signal handler called> #4 __swrite (ptr=0x65e7ae8b, cookie=0xd <bsp_start_vector_table_begin+13>, buf=0x20003370 "xa", n=1709682315) at /tmp/archive/gcc-4.7.2/newlib/libc/stdio/stdio.c:81
Be careful if you want to use printf() etc. with such a low stack size.
#5 0x20003088 in bsp_section_work_begin () #6 0x20003088 in bsp_section_work_begin () Backtrace stopped: previous frame identical to this frame (corrupt stack?) at the second ticker task initialization. Looks like I'm really scratching the limits of RAM and RTEMS here. Honestly speaking for the project itself I really need just UART driver and some application code. The project involves some bluetooth security so the application code is either using pure UART or application specific bluetooth stack (HCI) in case I'm going to use just HCI-enabled bluetooth module... Anyway, it's quite hard to judge amount of memory needed. Is there any way how to instruct RTEMS to trace RAM allocation and at the end of application print minimal amount of remaining RAM or maximal consumed RAM (or better is this value saved somewhere so I can print it from debugger)? If so, then I may switch to STM32F4 which is also supported by RTEMS and provides more RAM to see my project application RAM limits...
32KiB is enough for simple C applications on RTEMS if you are careful. Its not something that works out of the box.
-- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
