|author||patacongo <patacongo@7fd9a85b-ad96-42d3-883c-3090e2eb8679>||2012-09-05 13:18:14 +0000|
|committer||patacongo <patacongo@7fd9a85b-ad96-42d3-883c-3090e2eb8679>||2012-09-05 13:18:14 +0000|
Things missing from lib/Kconfig
git-svn-id: https://nuttx.svn.sourceforge.net/svnroot/nuttx/trunk@5093 7fd9a85b-ad96-42d3-883c-3090e2eb8679
1 files changed, 101 insertions, 21 deletions
diff --git a/nuttx/lib/Kconfig b/nuttx/lib/Kconfig
index 1f9bc07df3..e3348f26b6 100644
@@ -82,41 +82,53 @@ config LIBC_PERROR_STDOUT
be defined, however, to provide perror() output that is serialized with
other stdout messages.
- string "perror() to device"
- default "/dev/console"
- depends on !LIBC_PERROR_STDOUT
- Another non-standard option is to provide perror() output to a logging device
- or file. LIBC_PERROR_DEVNAME may be defined to be any write-able,
- character device (or file).
bool "Low-level console output"
- architecture supports low-level, boot time console output
+ architecture supports low-level, boot time console output
int "sendfile() buffer size"
- Size of the I/O buffer to allocate in sendfile(). Default: 512b
+ Size of the I/O buffer to allocate in sendfile(). Default: 512b
+ bool "Support for ROM string access"
+ default n
+ In Harvard architectures, data accesses and instruction accesses
+ occur on different busses, perhaps concurrently. All data accesses
+ are performed on the data bus unless special machine instructions
+ are used to read data from the instruction address space. Also, in
+ the typical MCU, the available SRAM data memory is much smaller that
+ the non-volatile FLASH instruction memory. So if the application
+ requires many constant strings, the only practical solution may be
+ to store those constant strings in FLASH memory where they can only
+ be accessed using architecture-specific machine instructions.
+ If ARCH_ROMGETC is defined, then the architecture logic must export
+ the function up_romgetc(). up_romgetc() will simply read one byte
+ of data from the instruction space.
+ If ARCH_ROMGETC, certain C stdio functions are effected: (1) All
+ format strings in printf, fprintf, sprintf, etc. are assumed to lie
+ in FLASH (string arguments for %s are still assumed to reside in SRAM).
+ And (2), the string argument to puts and fputs is assumed to reside
+ in FLASH. Clearly, these assumptions may have to modified for the
+ particular needs of your environment. There is no "one-size-fits-all"
+ solution for this problem.
bool "Enable arch optimized functions"
- Allow for architecture optimized implementations
- The architecture can provide optimized versions of the
- following to improve system performance
- The architecture may provide custom versions of certain
- standard header files:
- config ARCH_MATH_H, ARCH_STDBOOL_H, ARCH_STDINT_H
+ Allow for architecture optimized implementations of certain library
+ functions. Architecture-specific implementations can improve overall
+ system performance.
@@ -157,3 +169,71 @@ config ARCH_BZERO
+ bool "Customize header files"
+ default n
+ The architecture may provide custom versions of certain
+ standard header files
+ bool "stdbool.h"
+ default n
+ The stdbool.h header file can be found at nuttx/include/stdbool.h.
+ However, that header includes logic to redirect the inclusion of an
+ architecture specific header file like:
+ #ifdef CONFIG_ARCH_STDBOOL_H
+ # include <arch/stdbool.h>
+ Recall that that include path, include/arch, is a symbolic link and
+ will refer to a version of stdbool.h at nuttx/arch/<architecture>/include/stdbool.h.
+ bool "math.h"
+ default n
+ There is also a re-directing version of math.h in the source tree.
+ However, it resides out-of-the-way at include/nuttx/math.h because it
+ conflicts too often with the system math.h. If ARCH_MATH_H=y is
+ defined, however, the top-level makefile will copy the redirecting
+ math.h header file from include/nuttx/math.h to include/math.h. math.h
+ will then include the architecture-specific version of math.h that you
+ must provide at nuttx/arch/>architecture</include/math.h.
+ #ifdef CONFIG_ARCH_MATH_H
+ # include <arch/math.h>
+ So for the architectures that define ARCH_MATH_H=y, include/math.h
+ will be the redirecting math.h header file; for the architectures
+ that don't select ARCH_MATH_H, the redirecting math.h header file
+ will stay out-of-the-way in include/nuttx/.
+ bool "stdarg.h"
+ default n
+ There is also a redirecting version of stdarg.h in the source tree
+ as well. It also resides out-of-the-way at include/nuttx/stdarg.h.
+ This is because you should normally use your toolchain's stdarg.h
+ file. But sometimes, your toolchain's stdarg.h file may have other
+ header file dependencies and so may not be usable in the NuttX build
+ environment. In those cases, you may have to create a architecture-
+ specific stdarg.h header file at nuttx/arch/<architecture>/include/stdarg.h
+ If ARCH_STDARG_H=y is defined, the top-level makefile will copy the
+ re-directing stdarg.h header file from include/nuttx/stdarg.h to
+ include/stdarg.h. So for the architectures that cannot use their
+ toolchain's stdarg.h file, they can use this alternative by defining
+ ARCH_STDARG_H=y and providing. If ARCH_STDARG_H, is not defined, then
+ the stdarg.h header file will stay out-of-the-way in include/nuttx/.