diff options
Diffstat (limited to 'nuttx/Documentation/NuttxPortingGuide.html')
-rw-r--r-- | nuttx/Documentation/NuttxPortingGuide.html | 59 |
1 files changed, 45 insertions, 14 deletions
diff --git a/nuttx/Documentation/NuttxPortingGuide.html b/nuttx/Documentation/NuttxPortingGuide.html index 0e169d60d..f2c89dcbe 100644 --- a/nuttx/Documentation/NuttxPortingGuide.html +++ b/nuttx/Documentation/NuttxPortingGuide.html @@ -3907,22 +3907,9 @@ build </li> </ul> -<h2>General OS setup</h2> +<h2>Memory Management</h2> <ul> <li> - <code>CONFIG_ARCH_LOWPUTC</code>: architecture supports low-level, boot - time console output - </li> - <li> - <code>CONFIG_NUTTX_KERNEL</code>: - With most MCUs, NuttX is built as a flat, single executable image - containing the NuttX RTOS along with all application code. - The RTOS code and the application run in the same address space and at the same kernel-mode privileges. - If this option is selected, NuttX will be built separately as a monolithic, kernel-mode module and the applications - can be added as a separately built, user-mode module. - In this a system call layer will be built to support the user- to kernel-mode interface to the RTOS. - </li> - <li> <code>CONFIG_MM_REGIONS</code>: If the architecture includes multiple regions of memory to allocate from, this specifies the number of memory regions that the memory manager must @@ -3940,6 +3927,50 @@ build smaller, 16-bit-based allocation overhead. </li> <li> + <code>CONFIG_HEAP2_BASE</code> and <code>CONFIG_HEAP2_SIZE</code>: + Some architectures use these settings to specify the size of + a second heap region. + <li> + </li> + <code>CONFIG_GRAN</code>: + Enable granual allocator support. Allocations will be aligned to the + granule size; allocations will be in units of the granule size. + Larger granules will give better performance and less overhead but + more losses of memory due to alignment and quantization waste. + NOTE: The current implementation also restricts the maximum + allocation size to 32 granaules. That restriction could be + eliminated with some additional coding effort. + <li> + </li> + <code>CONFIG_GRAN_SINGLE</code>: + Select if there is only one instance of the granule allocator (i.e., + gran_initialize will be called only once. In this case, (1) there + are a few optimizations that can can be done and (2) the GRAN_HANDLE + is not needed. + </li> + <li> + <code>CONFIG_DEBUG_GRAM</code>: + Just like <code>CONFIG_DEBUG_MM</code>, but only generates ouput from the gran + allocation logic. + </li> +</ul> + +<h2>General OS setup</h2> +<ul> + <li> + <code>CONFIG_ARCH_LOWPUTC</code>: architecture supports low-level, boot + time console output + </li> + <li> + <code>CONFIG_NUTTX_KERNEL</code>: + With most MCUs, NuttX is built as a flat, single executable image + containing the NuttX RTOS along with all application code. + The RTOS code and the application run in the same address space and at the same kernel-mode privileges. + If this option is selected, NuttX will be built separately as a monolithic, kernel-mode module and the applications + can be added as a separately built, user-mode module. + In this a system call layer will be built to support the user- to kernel-mode interface to the RTOS. + </li> + <li> <code>CONFIG_MSEC_PER_TICK</code>: The default system timer is 100Hz or <code>MSEC_PER_TICK</code>=10. This setting may be defined to inform NuttX that the processor hardware is providing system timer interrupts at some interrupt |