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.
vsnprintf is a common string function that could be used in many places.
Using both vsnprintf in libc and vsnprintf in the RTT could make a
bigger image. Moreover, if newlib is not enabled when compiling with
GCC, referencing vsnprintf will lead to link error:
.../arm-none-eabi/lib/armv7-ar/thumb/softfp/libc.a(lib_a-sbrkr.o):
In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
collect2: error: ld returned 1 exit status
Using rt_vsnprintf could avoid such problem.
Because the device could still remain opened when closed by finsh, the
old rx_indicate is useless for finsh. Some buggy driver will still
generate rx_indicate even after the device has been closed. So FinSh
should unregister the rx_indicate when releasing the old device.
Building is only the first step. Correctness is what we need. There are
already many GCC builds for other bsp so GCC building for simulator is
not important. So I use clang-analyze to check all the source codes in
simulator project. Hope it will help us.
Bsps can use the clang analyzer as a tool:
env = Environment(toolpath=[os.path.join(RTT_ROOT, 'tools',
'tools')], tools = ['clang-analyze'])
When building the project, the static analyzer will be called to check
all the C code. The warnings are print to stderr.
Grissiom
Bernard Xiong
prife
joyhope
aozima