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.
With this patch, one could define two alias for the same function like:
FINSH_FUNCTION_EXPORT_ALIAS(rt_hw_cpu_reset, reboot, reboot the cpu);
FINSH_FUNCTION_EXPORT_ALIAS(rt_hw_cpu_reset, __cmd_reboot, reboot the cpu);
Suitable for being used in MSH/Finsh.
When forwarding rx/tx callback from the underlaying device(pipe), the
"dev" argument should be the portal. So the portal callback could think
itself as called.
Portal is a device that connect devices. Currently, you can only connect
pipes in portal. Pipes are unidirectional. But with portal, you can
construct a bidirectional device with two pipes.
Some reader(FinSh again) would like to block on a semaphore which is
released in rx_indicate. So we should invoke rx_indicate in
_rt_pipe_resume_reader.
The previous implementation will always blocks the reader/writer.
However, at least FinSh would expect the device to be nonblocking ---
read should return 0 when there is no data in it.
Bernard Xiong
Grissiom
prife