diff --git a/configs/freedom-kl25z/README.txt b/configs/freedom-kl25z/README.txt index 23390503de..f2cc8e0c02 100644 --- a/configs/freedom-kl25z/README.txt +++ b/configs/freedom-kl25z/README.txt @@ -301,6 +301,86 @@ Where is one of the following: configuration. This configuration has far fewer features than the nsh configuration but is also a fraction of the size. + This minnsh configuration is a "proof-of-concept" and not very usable in + its current state. This configuration was created by disabling + everything possible INCLUDING file system support. Without file system + support, NuttX is pretty much crippled. Here are some of the + consequences of disabling the file system: + + - All features that depend on the file system are lost: device drivers, + mountpoints, message queues, named semaphores. + + - Without device drivers, you cannot interact with the RTOS using POSIX + interfaces. You would have to work with NuttX as with those other + tiny RTOSs: As a scheduler and a callable hardare abstraction layer + (HAL). + + - You cannot use any of the NuttX upper half device drivers since they + depend on the pseudo-file system and device nodes. You can, of + course, continue to use the lower half drivers either directly. Or, + perhaps, you could write some custom minnsh upper half drivers that + do not depend on a file system and expose a HAL interface. + + There is a special version of readline() the NSH uses when there is no + file system. It uses a special up_putc() to write data to the console + and a special function up_getc() to read data from the console. + + - The current up_getc() implementationsa are a kludge. They are + analogous to the up_putc() implementations: They directly poll the + hardware for serial availability, locking up all lower priority tasks + in the entire system while they poll. So a version of NSH that uses + up_getc() essentially blocks the system until a character is received. + + This, of course, could be fixed by creating a special, upper half + implementation of the interrupt-driven serial lower half (like + stm32_serial) that just supports single character console I/O + (perhaps called up_putc and up_getc?). The NSH could wait for serial + input without blocking the system. But then that would increase the + footprint too. + + So although the minnsh configurations are a good starting point for + making things small, they not are really very practical. Why might + you want a NuttX minnsh solution? Perhaps you have software that runs + on a family of chips including some very tiny MCUs. Then perhaps having + the RTOS compatibility would justify the loss of functionality? + + You can re-enable the file system and (true) serial console with + these settings: + + Enable the file system: + CONFIG_NFILE_DESCRIPTORS=5 + CONFIG_NFILE_STREAMS=5 + + Enable the console device: + CONFIG_DEV_CONSOLE=y + + Disable most new NSH commands. Some like 'ls' are really mandatory + with a file system: + CONFIG_NSH_DISABLE_xxx=y + + Enable the upper half serial driver: + CONFIG_SERIAL=y + CONFIG_STANDARD_SERIAL=y + + Enable the USART1 serial driver: + CONFIG_STM32_USART1=y + CONFIG_STM32_USART1_SERIALDRIVER=y + CONFIG_USART1_SERIAL_CONSOLE=y + + CONFIG_USART1_2STOP=0 + CONFIG_USART1_BAUD=115200 + CONFIG_USART1_BITS=8 + CONFIG_USART1_PARITY=0 + CONFIG_USART1_RXBUFSIZE=16 + CONFIG_USART1_TXBUFSIZE=16 + + With these changes, NSH should behave better and we preserve the device + driver interface. But this result in a total size increase of about + 7KB: That is about 5KB of additional OS support for the file system and + serial console PLUS about 2KB for the 'ls' command logic (including OS + support for opendir(), readdir(), closedir(), stat(), and probably other + things). + nsh: --- Configures the NuttShell (nsh) located at apps/examples/nsh. The diff --git a/configs/freedom-kl26z/README.txt b/configs/freedom-kl26z/README.txt index 260ee1b6be..55f593c7d0 100644 --- a/configs/freedom-kl26z/README.txt +++ b/configs/freedom-kl26z/README.txt @@ -279,6 +279,86 @@ Where is one of the following: configuration. This configuration has far fewer features than the nsh configuration but is also a fraction of the size. + This minnsh configuration is a "proof-of-concept" and not very usable in + its current state. This configuration was created by disabling + everything possible INCLUDING file system support. Without file system + support, NuttX is pretty much crippled. Here are some of the + consequences of disabling the file system: + + - All features that depend on the file system are lost: device drivers, + mountpoints, message queues, named semaphores. + + - Without device drivers, you cannot interact with the RTOS using POSIX + interfaces. You would have to work with NuttX as with those other + tiny RTOSs: As a scheduler and a callable hardare abstraction layer + (HAL). + + - You cannot use any of the NuttX upper half device drivers since they + depend on the pseudo-file system and device nodes. You can, of + course, continue to use the lower half drivers either directly. Or, + perhaps, you could write some custom minnsh upper half drivers that + do not depend on a file system and expose a HAL interface. + + There is a special version of readline() the NSH uses when there is no + file system. It uses a special up_putc() to write data to the console + and a special function up_getc() to read data from the console. + + - The current up_getc() implementationsa are a kludge. They are + analogous to the up_putc() implementations: They directly poll the + hardware for serial availability, locking up all lower priority tasks + in the entire system while they poll. So a version of NSH that uses + up_getc() essentially blocks the system until a character is received. + + This, of course, could be fixed by creating a special, upper half + implementation of the interrupt-driven serial lower half (like + stm32_serial) that just supports single character console I/O + (perhaps called up_putc and up_getc?). The NSH could wait for serial + input without blocking the system. But then that would increase the + footprint too. + + So although the minnsh configurations are a good starting point for + making things small, they not are really very practical. Why might + you want a NuttX minnsh solution? Perhaps you have software that runs + on a family of chips including some very tiny MCUs. Then perhaps having + the RTOS compatibility would justify the loss of functionality? + + You can re-enable the file system and (true) serial console with + these settings: + + Enable the file system: + CONFIG_NFILE_DESCRIPTORS=5 + CONFIG_NFILE_STREAMS=5 + + Enable the console device: + CONFIG_DEV_CONSOLE=y + + Disable most new NSH commands. Some like 'ls' are really mandatory + with a file system: + CONFIG_NSH_DISABLE_xxx=y + + Enable the upper half serial driver: + CONFIG_SERIAL=y + CONFIG_STANDARD_SERIAL=y + + Enable the USART1 serial driver: + CONFIG_STM32_USART1=y + CONFIG_STM32_USART1_SERIALDRIVER=y + CONFIG_USART1_SERIAL_CONSOLE=y + + CONFIG_USART1_2STOP=0 + CONFIG_USART1_BAUD=115200 + CONFIG_USART1_BITS=8 + CONFIG_USART1_PARITY=0 + CONFIG_USART1_RXBUFSIZE=16 + CONFIG_USART1_TXBUFSIZE=16 + + With these changes, NSH should behave better and we preserve the device + driver interface. But this result in a total size increase of about + 7KB: That is about 5KB of additional OS support for the file system and + serial console PLUS about 2KB for the 'ls' command logic (including OS + support for opendir(), readdir(), closedir(), stat(), and probably other + things). + nsh: --- Configures the NuttShell (nsh) located at apps/examples/nsh. The diff --git a/configs/lpcxpresso-lpc1115/README.txt b/configs/lpcxpresso-lpc1115/README.txt index 3a0beb1e7f..bfe29dc6d5 100644 --- a/configs/lpcxpresso-lpc1115/README.txt +++ b/configs/lpcxpresso-lpc1115/README.txt @@ -687,6 +687,86 @@ Where is one of the following: configuration. This configuration has far fewer features than the nsh configuration but is also a fraction of the size. + This minnsh configuration is a "proof-of-concept" and not very usable in + its current state. This configuration was created by disabling + everything possible INCLUDING file system support. Without file system + support, NuttX is pretty much crippled. Here are some of the + consequences of disabling the file system: + + - All features that depend on the file system are lost: device drivers, + mountpoints, message queues, named semaphores. + + - Without device drivers, you cannot interact with the RTOS using POSIX + interfaces. You would have to work with NuttX as with those other + tiny RTOSs: As a scheduler and a callable hardare abstraction layer + (HAL). + + - You cannot use any of the NuttX upper half device drivers since they + depend on the pseudo-file system and device nodes. You can, of + course, continue to use the lower half drivers either directly. Or, + perhaps, you could write some custom minnsh upper half drivers that + do not depend on a file system and expose a HAL interface. + + There is a special version of readline() the NSH uses when there is no + file system. It uses a special up_putc() to write data to the console + and a special function up_getc() to read data from the console. + + - The current up_getc() implementationsa are a kludge. They are + analogous to the up_putc() implementations: They directly poll the + hardware for serial availability, locking up all lower priority tasks + in the entire system while they poll. So a version of NSH that uses + up_getc() essentially blocks the system until a character is received. + + This, of course, could be fixed by creating a special, upper half + implementation of the interrupt-driven serial lower half (like + stm32_serial) that just supports single character console I/O + (perhaps called up_putc and up_getc?). The NSH could wait for serial + input without blocking the system. But then that would increase the + footprint too. + + So although the minnsh configurations are a good starting point for + making things small, they not are really very practical. Why might + you want a NuttX minnsh solution? Perhaps you have software that runs + on a family of chips including some very tiny MCUs. Then perhaps having + the RTOS compatibility would justify the loss of functionality? + + You can re-enable the file system and (true) serial console with + these settings: + + Enable the file system: + CONFIG_NFILE_DESCRIPTORS=5 + CONFIG_NFILE_STREAMS=5 + + Enable the console device: + CONFIG_DEV_CONSOLE=y + + Disable most new NSH commands. Some like 'ls' are really mandatory + with a file system: + CONFIG_NSH_DISABLE_xxx=y + + Enable the upper half serial driver: + CONFIG_SERIAL=y + CONFIG_STANDARD_SERIAL=y + + Enable the USART1 serial driver: + CONFIG_STM32_USART1=y + CONFIG_STM32_USART1_SERIALDRIVER=y + CONFIG_USART1_SERIAL_CONSOLE=y + + CONFIG_USART1_2STOP=0 + CONFIG_USART1_BAUD=115200 + CONFIG_USART1_BITS=8 + CONFIG_USART1_PARITY=0 + CONFIG_USART1_RXBUFSIZE=16 + CONFIG_USART1_TXBUFSIZE=16 + + With these changes, NSH should behave better and we preserve the device + driver interface. But this result in a total size increase of about + 7KB: That is about 5KB of additional OS support for the file system and + serial console PLUS about 2KB for the 'ls' command logic (including OS + support for opendir(), readdir(), closedir(), stat(), and probably other + things). + STATUS: 2015-6-10 The nuttx.bin minnsh firmware file size: diff --git a/configs/stm32f103-minimum/README.txt b/configs/stm32f103-minimum/README.txt index 4ddee1fb07..4f8ff5849f 100644 --- a/configs/stm32f103-minimum/README.txt +++ b/configs/stm32f103-minimum/README.txt @@ -492,7 +492,7 @@ Where is one of the following: 2016-06-07: As another experiment, I tried enabling just (1) the file system, (2) the console device, and (3) the upper half serial driver in the minnsh configuration. With these changes, NSH should behave better - nd we preserve the device driver interface. I made the following + and we preserve the device driver interface. I made the following configuration changes: Enable the file system: @@ -525,13 +525,28 @@ Where is one of the following: The resulting code was bigger as expected: $ arm-none-eabi-size nuttx - text data bss dec hex filename - 20093 88 876 21057 5241 nuttx + text data bss dec hex filename + 19853 88 876 20817 5151 nuttx I am sure that other things that could be disabled were also drawn into - the build, so perhaps this could be reduced. But as a ballpark - estimate, it looks like the cost of basic file system and serial console - driver support is around 7+KB. + the build, so perhaps this could be reduced. This amounts to a size + increase of around 7KB. + + One major part of this size increase is due to the addition of the NSH + 'ls' command. Now, if I disable the 'ls' command, I get: + + $ arm-none-eabi-size nuttx + text data bss dec hex filename + 17804 80 864 18748 493c nuttx + + Or an increase of only 5.1 KB. This, of course, not only excludes the + 'ls' command logic, but also the things that were drawn into the link + when 'ls' was enabled: opendir(), readdir(), closedir(), stat(), and + probably other things. + + So I think we can say that the cost of the file system and true serial + console device was about 5 KB (primarily OS support) and the cost of + the NSH 'ls' command (including OS support) is about 2KB. nsh: ---