After `log_trace_init()`, call `memlog_init`. It then turn the logtrace
into a "in-memory" logger which will buffer all the log in memory. It
also set a hook in idle to flush all the log into console. One may
create an other thread to flush the logs but idle might be the simplest
place to go.
With new timer algorithm, timer should be initialized during startup. So
add them to the bsps. Use these commands to get which bsp is missing
calling the function:
% git grep rt_system_timer_init bsp|sed -n 's|bsp/\([^/]*\).*|\1|p' | sort | uniq > have_tm_init
% ls -1 bsp |sed -n 's|\([^/]*\).*|\1|p' | sort > all_bsp
% comm -3 all_bsp have_tm_init
beaglebone
lpc176x
lpc178x
ls1bdev
mb9bf506r
stm32f10x
xplorer4330
We split the history handling form the key handling. So we could handle
the direction key even if the history is disabled. As a "side effect", I
also remove the unnecessary "use_history" bit.
Mutex has the idea of ownership, only the thread which owns the mutex
can release it. So rt_mutex_release could only be called in thread
context. Add a debug guard to it.
Skip list is a "random" data structure that in high possibilities it
would get O(log(N)) time complexity in inserting while the old list get
O(N). Forthermore, when set RT_TIMER_SKIP_LIST_LEVEL to 1, it will just
the same as the old double linked list, both in time and space
complexity.
Benchmarks shows that when RT_TIMER_SKIP_LIST_LEVEL is 3, the average
time of random insertion of new timer is about 2 times faster than the
old timer when there are 100 timers and 3 times faster when there are
200 timers.
However, it restores the deprecated funcion rt_system_timer_init. BSPs
must invoke it upon system startup.
In thread context means: 1) the scheduler has been started; 2) not in
interrupt context. It is more stronger than RT_DEBUG_NOT_IN_INTERRUPT.
With this commit, you will catch the error on situations like taking
mutex before scheduling instead of crashing on NULL pointer reference.
Real-YModem implemented a flexible YModem support. It use callback-based
structure to let the user application to deal with the data. It contains
3 examples:
1. echo.c: write the data recieved on YModem to an other device
2. null.c: discard the YModem data
3. tofile.c: write the data to the file system
Currently, it does not support batch file transmission.