From 99a0f819cdda7a8414d38672c10f24a89e40ba3d Mon Sep 17 00:00:00 2001 From: patacongo Date: Thu, 3 Mar 2011 23:15:50 +0000 Subject: [PATCH] typos git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@3333 42af7a65-404d-4744-a932-0658087f49c3 --- Documentation/NuttxPortingGuide.html | 4 ++-- configs/olimex-lpc1766stk/README.txt | 29 +++++++++++++++++++++++++++- configs/sim/README.txt | 12 ++++++------ 3 files changed, 36 insertions(+), 9 deletions(-) diff --git a/Documentation/NuttxPortingGuide.html b/Documentation/NuttxPortingGuide.html index 5358f6797b..a3ffa2122b 100644 --- a/Documentation/NuttxPortingGuide.html +++ b/Documentation/NuttxPortingGuide.html @@ -12,7 +12,7 @@

NuttX RTOS Porting Guide

-

Last Updated: February 25, 2011

+

Last Updated: March 3, 2011

@@ -970,7 +970,7 @@ tools/ This could be done manually as follows:

diff --git a/configs/olimex-lpc1766stk/README.txt b/configs/olimex-lpc1766stk/README.txt index 98b0bb1353..6db1ec793b 100755 --- a/configs/olimex-lpc1766stk/README.txt +++ b/configs/olimex-lpc1766stk/README.txt @@ -368,9 +368,36 @@ LEDs Glowing Glowing This is also a normal healthy state: The OS successfully initialized, is running in reduced power mode, but taking interrupts. The glow is very faint and you may have to dim the lights to see that LEDs are - active at all! + active at all! See note below. ON Flashing Ooops! We crashed sometime after initialization. + NOTE: In glowing/glowing case, you get some good subjective information about the + behavior of your system by looking at the level of the LED glow (or better, by + connecting O-Scope and calculating the actual duty): + + 1. The intensity of the glow is determined by the duty of LED on/off toggle -- + as the ON period becomes larger with respect the OFF period, the LED will + glow more brightly. + 2. LED2 is turned ON when entering an interrupt and turned OFF when returning from + the interrupt. A brighter LED2 means that the system is spending more time in + interrupt handling. + 3. LED1 is turned OFF just before the processor goes to sleep. The processor + sleeps until awakened by an interrupt. LED1 is turned back ON after the + processor is re-awakened -- actually after returning from the interrupt that + cause the processor to re-awaken (LED1 will be off during the execution of + that interrupt). So a brighter LED1 means that the processor is spending + less time sleeping. + + When my STM32 sits IDLE -- doing absolutely nothing but processing timer interrupts -- + I see the following: + + 1. LED1 glows dimly due to the timer interrupts. + 2. But LED2 is even more dim! The LED ON time excludes the time processing the + interrupt that re-awakens the processing. So this tells me that the STM32 is + spending more time processing timer interrupts than doing any other kind of + processing. That, of course, makes sense if the system is truly idle and only + processing timer interrupts. + Using OpenOCD and GDB with an FT2232 JTAG emulator ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/configs/sim/README.txt b/configs/sim/README.txt index b4ec61055f..aa12da3369 100644 --- a/configs/sim/README.txt +++ b/configs/sim/README.txt @@ -81,7 +81,7 @@ mount selected as follows: cd /tools - ./Configure.sh sim/mount + ./configure.sh sim/mount nettest @@ -90,7 +90,7 @@ nettest be selected via: cd /tools - ./Configure.sh sim/nettest + ./configure.sh sim/nettest NOTES: - The NuttX network is not, however, functional on the Linux TAP @@ -112,14 +112,14 @@ nsh may be selected as follows: cd /tools - ./Configure.sh sim/nsh + ./configure.sh sim/nsh nx Configures to use examples/nx. This configuration may be selected as follows: cd /tools - ./Configure.sh sim/nx + ./configure.sh sim/nx Special simulated framebuffer configuration options: @@ -155,7 +155,7 @@ ostest configuration may be selected as follows: cd /tools - ./Configure.sh sim/ostest + ./configure.sh sim/ostest pashello @@ -163,4 +163,4 @@ pashello by selected as follows: cd /tools - ./Configure.sh sim/pashello + ./configure.sh sim/pashello