I've enabled the kernel but timer_delay() doesn't change process

You need to enable kernel signals, otherwise timer_delay() is simply a busy wait.

Compilation fails on timer.c. What's going on?

Probably you have disabled "asynchronous timers" (CONFIG_TIMER_EVENTS) but you left enabled "hi-res timer_usleep()" (CONFIG_TIMER_UDELAY). You must disable timer_usleep when disabling asynchronous timers.

How do I change the default stack size?

You need to manually edit your project's linker scripts. Look in the directory bertos/cpu/[your_cpu]/scripts and select the linker script you're using (see the [your_project_name]_wiz.mk to know exactly which script you're linking).

For example, for ARM you would edit the following lines:

FIQ_STACK_SIZE = 0x0400;
IRQ_STACK_SIZE = 0x0400;
ABT_STACK_SIZE = 0x0400;
UND_STACK_SIZE = 0x0400;
SVC_STACK_SIZE = 0x1000;

How do I reduce memory usage when using kprintf()?

The function kprintf() formats %[something] escape sequences to the correct value. For each % sequence, it must allocate a char buffer on the stack which will be used to format the number. You can change the value of CONFIG_FRMWRI_BUFSIZE to save some space, but remember that when formatting no check is done for buffer overflows.

If you're using at most 32-bit ints only, a size of 16 is enough.

When using floats, it's a bit more complicated. Remember that %f is a fixed point notation with 6 decimal digits by default? Yes, when using %f formatter you must have enough chars for representing FLT_MAX (> 1e37), that is: sign + 37 digits + '.' + 6 decimals. So you need 50 chars to be safe. If you're using %e or %g instead, you're rather safe with a value of 20.

Bottom line: when using PRINTF_NOFLOAT, 16 is good. When using PRINTF_FULL and format your floats with %g or %e, 20 should be enough.

If you use %f, you can still use 20, but if your programs generates large numbers, you will have problems. You need to do some tests on your own to find the optimal value.