diff --git a/nuttx/ChangeLog b/nuttx/ChangeLog
index f179381fb..6e016fc61 100644
--- a/nuttx/ChangeLog
+++ b/nuttx/ChangeLog
@@ -2314,3 +2314,9 @@
logic.
*configs/olimex-lpc1766stk/src/up_buttons.c: Add support form the buttons
on the Olimex LPC1766-STK board.
+ * Makefile: Added 'apps_clean' and 'apps_distclean' target to simplify
+ managing the state of the application directory while in the NuttX directory
+ * Documentation/NuttXGettingStarted.html: Added a "Getting Started" Guide
+ for NuttX. At present, this is just a stub and it refers to the NuttX
+ top-level README.txt file which is the only, real "Getting Started" Guide
+ that exists for the time being.
diff --git a/nuttx/Documentation/NuttX.png b/nuttx/Documentation/NuttX.png
old mode 100755
new mode 100644
diff --git a/nuttx/Documentation/NuttX2-a.png b/nuttx/Documentation/NuttX2-a.png
old mode 100755
new mode 100644
diff --git a/nuttx/Documentation/NuttX2-b.png b/nuttx/Documentation/NuttX2-b.png
old mode 100755
new mode 100644
diff --git a/nuttx/Documentation/NuttX2.png b/nuttx/Documentation/NuttX2.png
old mode 100755
new mode 100644
diff --git a/nuttx/Documentation/NuttX320.png b/nuttx/Documentation/NuttX320.png
old mode 100755
new mode 100644
diff --git a/nuttx/Documentation/NuttXCommercial.html b/nuttx/Documentation/NuttXCommercial.html
old mode 100755
new mode 100644
diff --git a/nuttx/Documentation/NuttXDemandPaging.html b/nuttx/Documentation/NuttXDemandPaging.html
old mode 100755
new mode 100644
diff --git a/nuttx/Documentation/NuttXDocumentation.html b/nuttx/Documentation/NuttXDocumentation.html
old mode 100755
new mode 100644
index 80401a078..0363db955
--- a/nuttx/Documentation/NuttXDocumentation.html
+++ b/nuttx/Documentation/NuttXDocumentation.html
@@ -1,78 +1,79 @@
-
-
- NuttX Links
-
-
-
-
-
+
+
+ NuttX Links
+
+
+
+
+
diff --git a/nuttx/Documentation/NuttXGettingStarted.html b/nuttx/Documentation/NuttXGettingStarted.html
new file mode 100644
index 000000000..8e3cf38ca
--- /dev/null
+++ b/nuttx/Documentation/NuttXGettingStarted.html
@@ -0,0 +1,25 @@
+
+
+NuttX Getting Started
+
+
+
+
+
+
+
+ Getting Started with NuttX
+ Last Updated: December 31, 2011
+ |
+
+
+
+Getting Started.
+ There is no "Getting Started" Guide for NuttX yet.
+ However, most everything that you need to get started with NuttX can be found in the README.txt file located in the top-level NuttX directory.
+ That README.txt can also be read online in the NuttX SVN repository
+ here.
+ Just click on "Links to HEAD: (view)" on that page.
+
+
+
diff --git a/nuttx/Documentation/NuttXLinks.html b/nuttx/Documentation/NuttXLinks.html
old mode 100755
new mode 100644
diff --git a/nuttx/Documentation/NuttXRelated.html b/nuttx/Documentation/NuttXRelated.html
old mode 100755
new mode 100644
diff --git a/nuttx/Documentation/README.html b/nuttx/Documentation/README.html
old mode 100755
new mode 100644
diff --git a/nuttx/Documentation/UsbTrace.html b/nuttx/Documentation/UsbTrace.html
old mode 100755
new mode 100644
index 2f08f9ef2..6a834752f
--- a/nuttx/Documentation/UsbTrace.html
+++ b/nuttx/Documentation/UsbTrace.html
@@ -1,6 +1,6 @@
-README Files
+NuttX USB Trace Capability
diff --git a/nuttx/Documentation/pm.png b/nuttx/Documentation/pm.png
old mode 100755
new mode 100644
diff --git a/nuttx/Documentation/rss.gif b/nuttx/Documentation/rss.gif
old mode 100755
new mode 100644
diff --git a/nuttx/Makefile b/nuttx/Makefile
index 5b622ab40..7bda2b9e0 100644
--- a/nuttx/Makefile
+++ b/nuttx/Makefile
@@ -249,9 +249,11 @@ endif
BIN = nuttx$(EXEEXT)
all: $(BIN)
-.PHONY: context clean_context check_context export subdir_clean clean subdir_distclean distclean
+.PHONY: context clean_context check_context export subdir_clean clean subdir_distclean distclean apps_clean apps_distclean
-# Build the mkconfig tool used to create include/nuttx/config.h
+# Targets used to build include/nuttx/version.h. Creation of version.h is
+# part of the overall NuttX configuration sequency. Notice that the
+# tools/mkversion tool is cuilt and used to create include/nuttx/version.h
tools/mkversion:
@$(MAKE) -C tools -f Makefile.host TOPDIR="$(TOPDIR)" mkversion
@@ -263,21 +265,25 @@ $(TOPDIR)/.version:
chmod 755 .version; \
fi
-# Create the include/nuttx/version.h file
-
include/nuttx/version.h: $(TOPDIR)/.version tools/mkversion
@tools/mkversion $(TOPDIR) > include/nuttx/version.h
-# Build the mkconfig tool used to create include/nuttx/config.h
+# Targets used to build include/nuttx/config.h. Creation of config.h is
+# part of the overall NuttX configuration sequency. Notice that the
+# tools/mkconfig tool is cuilt and used to create include/nuttx/config.h
tools/mkconfig:
@$(MAKE) -C tools -f Makefile.host TOPDIR="$(TOPDIR)" mkconfig
-# Create the include/nuttx/config.h file
-
include/nuttx/config.h: $(TOPDIR)/.config tools/mkconfig
@tools/mkconfig $(TOPDIR) > include/nuttx/config.h
+# dirlinks, and helpers
+#
+# Directories links. Most of establishing the NuttX configuration involves
+# setting up symbolic links with 'generic' directory names to specific,
+# configured directories.
+#
# Link the apps/include directory to include/apps
include/apps: Make.defs
@@ -318,11 +324,23 @@ endif
dirlinks: include/arch include/arch/board include/arch/chip $(ARCH_SRC)/board $(ARCH_SRC)/chip include/apps
+# context
+#
+# The context target is invoked on each target build to assure that NuttX is
+# properly configured. The basic configuration steps include creation of the
+# the config.h and version.h header files in the include/nuttx directory and
+# the establishment of symbolic links to configured directories.
+
context: check_context include/nuttx/config.h include/nuttx/version.h dirlinks
@for dir in $(CONTEXTDIRS) ; do \
$(MAKE) -C $$dir TOPDIR="$(TOPDIR)" context; \
done
+# clean_context
+#
+# This is part of the distclean target. It removes all of the header files
+# and symbolic links created by the context target.
+
clean_context:
@rm -f include/nuttx/config.h
@$(DIRUNLINK) include/arch/board
@@ -332,6 +350,13 @@ clean_context:
@$(DIRUNLINK) $(ARCH_SRC)/chip
@$(DIRUNLINK) include/apps
+# check_context
+#
+# This target checks if NuttX has been configured. NuttX is configured using
+# the script tools/configure.sh. That script will install certain files in
+# the top-level NuttX build directory. This target verifies that those
+# configuration files have been installed and that NuttX is ready to be built.
+
check_context:
@if [ ! -e ${TOPDIR}/.config -o ! -e ${TOPDIR}/Make.defs ]; then \
echo "" ; echo "Nuttx has not been configured:" ; \
@@ -339,6 +364,11 @@ check_context:
exit 1 ; \
fi
+# Archive targets. The target build sequency will first create a series of
+# libraries, one per configured source file directory. The final NuttX
+# execution will then be built from those libraries. The following targets
+# built those libraries.
+#
# Possible kernel-mode builds
lib/libklib$(LIBEXT): context
@@ -390,6 +420,8 @@ syscall/libproxies$(LIBEXT): context
lib/liblib$(LIBEXT): context
@$(MAKE) -C lib TOPDIR="$(TOPDIR)" liblib$(LIBEXT)
+# pass1 and pass2
+#
# If the 2 pass build option is selected, then this pass1 target is
# configured to built before the pass2 target. This pass1 target may, as an
# example, build an extra link object (CONFIG_PASS1_OBJECT) which may be an
@@ -444,20 +476,29 @@ ifeq ($(CONFIG_RAW_BINARY),y)
@$(OBJCOPY) $(OBJCOPYARGS) -O binary $(BIN) $(BIN).bin
endif
-# In the normal case, all pass1 and pass2 dependencies are created then pass1
+# $(BIN)
+#
+# Create the final NuttX executable in a two pass build process. In the
+# normal case, all pass1 and pass2 dependencies are created then pass1
# and pass2 targets are built. However, in some cases, you may need to build
# pass1 depenencies and pass1 first, then build pass2 dependencies and pass2.
# in that case, execute 'make pass1 pass2' from the command line.
$(BIN): pass1deps pass2deps pass1 pass2
-# This is a helper target that will rebuild NuttX and download it to the
-# target system in one step. It will generate an error an error if the
-# DOWNLOAD command is not defined in platform Make.defs file.
+# download
+#
+# This is a helper target that will rebuild NuttX and download it to the target
+# system in one step. The operation of this target depends completely upon
+# implementation of the DOWNLOAD command in the user Make.defs file. It will
+# generate an error an error if the DOWNLOAD command is not defined.
download: $(BIN)
$(call DOWNLOAD, $<)
+# pass1dep: Create pass1 build dependencies
+# pass2dep: Create pass2 build dependencies
+
pass1dep: context
@for dir in $(USERDEPDIRS) ; do \
$(MAKE) -C $$dir TOPDIR="$(TOPDIR)" depend ; \
@@ -468,6 +509,8 @@ pass2dep: context
$(MAKE) -C $$dir TOPDIR="$(TOPDIR)" EXTRADEFINES=$(KDEFINE) depend; \
done
+# export
+#
# The export target will package the NuttX libraries and header files into
# an exportable package. Caveats: (1) These needs some extension for the KERNEL
# build; it needs to receive USERLIBS and create a libuser.a). (2) The logic
@@ -477,7 +520,15 @@ pass2dep: context
export: pass2deps
@tools/mkexport.sh -t "$(TOPDIR)" -l "$(NUTTXLIBS)"
-# Housekeeping targets: dependencies, cleaning, etc.
+# General housekeeping targets: dependencies, cleaning, etc.
+#
+# depend: Create both PASS1 and PASS2 dependencies
+# clean: Removes derived object files, archives, executables, and
+# temporary files, but retains the configuration and context
+# files and directories.
+# distclean: Does 'clean' then also removes all configuration and context
+# files. This essentially restores the directory structure
+# to its original, unconfigured stated.
depend: pass1dep pass2dep
@@ -494,7 +545,7 @@ ifeq ($(CONFIG_BUILD_2PASS),y)
endif
clean: subdir_clean
- @rm -f $(BIN) nuttx.* mm_test *.map *~
+ @rm -f $(BIN) nuttx.* mm_test *.map _SAVED_APPS_config *~
@rm -f nuttx-export*
subdir_distclean:
@@ -510,3 +561,31 @@ ifeq ($(CONFIG_BUILD_2PASS),y)
endif
@rm -f Make.defs setenv.sh .config
+# Application housekeeping targets. The APPDIR variable refers to the user
+# application directory. A sample apps/ directory is included with NuttX,
+# however, this is not treated as part of NuttX and may be replaced with a
+# different application directory. For the most part, the application
+# directory is treated like any other build directory in this script. However,
+# as a convenience, the following targets are included to support housekeeping
+# functions in the user application directory from the NuttX build directory.
+#
+# apps_clean: Perform the clean operation only in the user application
+# directory
+# apps_distclean: Perform the distclean operation only in the user application
+# directory. Note that the apps/.config file is preserved
+# so that this is not a "full" distclean but more of a
+# configuration "reset."
+
+apps_clean:
+ifneq ($(APPDIR),)
+ @$(MAKE) -C "$(TOPDIR)/$(APPDIR)" TOPDIR="$(TOPDIR)" clean
+endif
+
+apps_distclean:
+ifneq ($(APPDIR),)
+ @cp "$(TOPDIR)/$(APPDIR)/.config" _SAVED_APPS_config || \
+ { echo "Copy of $(APPDIR)/.config failed" ; exit 1 ; }
+ @$(MAKE) -C "$(TOPDIR)/$(APPDIR)" TOPDIR="$(TOPDIR)" distclean
+ @mv _SAVED_APPS_config "$(TOPDIR)/$(APPDIR)/.config" || \
+ { echo "Copy of _SAVED_APPS_config failed" ; exit 1 ; }
+endif
diff --git a/nuttx/README.txt b/nuttx/README.txt
index b820590e0..87f870d96 100755
--- a/nuttx/README.txt
+++ b/nuttx/README.txt
@@ -15,6 +15,10 @@ README
o Building NuttX
- Building
- Re-building
+ - Build Targets
+ o Cygwin Build Problems
+ - Strange Path Problems
+ - Window Native Toolchain Issues
o Documentation
INSTALLATION
@@ -269,9 +273,85 @@ Re-building
This 'make' command will remove of the copied directories, re-copy them,
then make NuttX.
+Build Targets
+
+ Below is a summary of the build targets available in the top-level
+ NuttX Makefile:
+
+ all
+
+ The default target builds the NuttX executable in the selected output
+ formats.
+
+ clean
+
+ Removes derived object files, archives, executables, and temporary
+ files, but retains the configuration and context files and directories.
+
+ distclean
+
+ Does 'clean' then also removes all configuration and context files.
+ This essentially restores the directory structure to its original,
+ unconfigured stated.
+
+ Application housekeeping targets. The APPDIR variable refers to the user
+ application directory. A sample apps/ directory is included with NuttX,
+ however, this is not treated as part of NuttX and may be replaced with a
+ different application directory. For the most part, the application
+ directory is treated like any other build directory in the Makefile script.
+ However, as a convenience, the following targets are included to support
+ housekeeping functions in the user application directory from the NuttX
+ build directory.
+
+ apps_clean
+
+ Perform the clean operation only in the user application directory
+
+ apps_distclean
+
+ Perform the distclean operation only in the user application directory.
+ The apps/.config file is preserved so that this is not a "full" distclean
+ but more of a configuration "reset."
+
+ export
+
+ The export target will package the NuttX libraries and header files into
+ an exportable package. Caveats: (1) These needs some extension for the KERNEL
+ build. (2) The logic in tools/mkexport.sh only supports GCC and, for example,
+ explicitly assumes that the archiver is 'ar'
+
+ download
+
+ This is a helper target that will rebuild NuttX and download it to the target
+ system in one step. The operation of this target depends completely upon
+ implementation of the DOWNLOAD command in the user Make.defs file. It will
+ generate an error an error if the DOWNLOAD command is not defined.
+
+ The following targets are used internally by the make logic but can be invoked
+ from the command under certain conditions if necessary.
+
+ depend
+
+ Create build dependencies. (NOTE: There is currently no support for build
+ dependencies under Cygwin using Windows-native toolchains.)
+
+ context
+
+ The context target is invoked on each target build to assure that NuttX is
+ properly configured. The basic configuration steps include creation of the
+ the config.h and version.h header files in the include/nuttx directory and
+ the establishment of symbolic links to configured directories.
+
+ clean_context
+
+ This is part of the distclean target. It removes all of the header files
+ and symbolic links created by the context target.
+
CYGWIN BUILD PROBLEMS
^^^^^^^^^^^^^^^^^^^^^
+Strange Path Problems
+
If you see strange behavior when building under Cygwin then you may have
a problem with your PATH variable. For example, if you see failures to
locate files that are clearly present, that may mean that you are using
@@ -294,6 +374,98 @@ The solution is either:
$ export PATH=/usr/local/bin:/usr/bin:/bin:$PATH
+Window Native Toolchain Issues
+
+ There are many popular Windows native toolchains that may be used with NuttX.
+ Examples include CodeSourcery (for Windows), devkitARM, and several vendor-
+ provied toolchains. There are several limitations with using a and Windows
+ based toolchain in a Cygwin environment. The three biggest are:
+
+ 1. The Windows toolchain cannot follow Cygwin paths. Path conversions are
+ performed automatically in the Cygwin makefiles using the 'cygpath' utility
+ but you might easily find some new path problems. If so, check out 'cygpath -w'
+
+ 2. Windows toolchains cannot follow Cygwin symbolic links. Many symbolic links
+ are used in Nuttx (e.g., include/arch). The make system works around these
+ problems for the Windows tools by copying directories instead of linking them.
+ But this can also cause some confusion for you: For example, you may edit
+ a file in a "linked" directory and find that your changes had no effect.
+ That is because you are building the copy of the file in the "fake" symbolic
+ directory. If you use a Windows toolchain, you should get in the habit of
+ making like this:
+
+ make clean_context all
+
+ An alias in your .bashrc file might make that less painful. The rebuild
+ is not a long as you might think because there is no dependency checking
+ if you are using a native Windows toolchain. That bring us to #3:
+
+ 3. Dependencies are not made when using Windows versions of the GCC. This is
+ because the dependencies are generated using Windows pathes which do not
+ work with the Cygwin make.
+
+ Support has been added for making dependencies with the windows-native toolchains.
+ That support can be enabled by modifying your Make.defs file as follows:
+
+ - MKDEP = $(TOPDIR)/tools/mknulldeps.sh
+ + MKDEP = $(TOPDIR)/tools/mkdeps.sh --winpaths "$(TOPDIR)"
+
+ If you have problems with the dependency build (for example, if you are not
+ building on C:), then you may need to modify tools/mkdeps.sh
+
+General Pre-built Toolchain Issues
+
+ To continue with the list of "Window Native Toolchain Issues" we can add
+ the following. These, however, are really just issues that you will have
+ if you use any pre-built toolchain (vs. building the NuttX toolchain from
+ the NuttX buildroot package):
+
+ There may be incompatibilities with header files, libraries, and compiler
+ built-in functions at detailed below. For the most part, these issues
+ are handled in the existing make logic. But if you are breaking new ground,
+ then you may incounter these:
+
+ 4. Header Files. Most pre-built toolchains will build with a foreign C
+ library (usually newlib, but maybe uClibc or glibc if you are using a
+ Linux toolchain). This means that the header files from the foreign
+ C library will be built into the toolchain. So if you "include ",
+ you will get the stdio.h from the incompatible, foreign C library and
+ not the nuttx stdio.h (at nuttx/include/stdio.h) that you wanted.
+
+ This can cause really confusion in the buildds and you must always be
+ sure the -nostdinc is included in the CFLAGS. That will assure that
+ you take the include files only from
+
+ 5. Libraries. What was said above header files applies to libraries.
+ You do not want to include code from the libraries of any foreign
+ C libraries built into your toolchain. If this happens you will get
+ perplexing errors about undefined sysmbols. To avoid these errors,
+ you will need to add -nostdlib to your CFLAGS flags to assure that
+ you only take code from the NuttX libraries.
+
+ This, however, may causes other issues for libraries in the toolchain
+ that you do want (like libgcc.a or libm.a). These are special-cased
+ in most Makefiles, but you could still run into issues of missing
+ libraries.
+
+ 6. Built-Ins. Some compilers target a particular operating system.
+ Many people would, for example, like to use the same toolchain to
+ develop Linux and NuttX software. Compilers built for other
+ operating systems may generate incompatible built-in logic and,
+ for this reason, -fno-builtin should also be included in your
+ C flags
+
+ And finally you may not be able to use NXFLAT.
+
+ 7. NXFLAT. If you use a pre-built toolchain, you will lose all support
+ for NXFLAT. NXFLAT is a binary format described in
+ Documentation/NuttXNxFlat.html. It may be possible to build
+ standalone versions of the NXFLAT tools; there are a few examples
+ of this in the misc/buildroot/configs directory. However, it
+ is possible that there could be interoperability issues with
+ your toolchain since they will be using different versions of
+ binutials and possibly different ABIs.
+
DOCUMENTATION
^^^^^^^^^^^^^
diff --git a/nuttx/configs/olimex-lpc1766stk/include/board.h b/nuttx/configs/olimex-lpc1766stk/include/board.h
index 2d99fe40a..5a22c0970 100755
--- a/nuttx/configs/olimex-lpc1766stk/include/board.h
+++ b/nuttx/configs/olimex-lpc1766stk/include/board.h
@@ -413,6 +413,9 @@ EXTERN void up_buttoninit(void);
* Name: up_buttons
*
* Description:
+ * up_buttoninit() must be called to initialize button resources. After that,
+ * up_buttons() may be called to collect the current state of all buttons.
+ *
* After up_buttoninit() has been called, up_buttons() may be called to collect
* the state of all buttons. up_buttons() returns an 8-bit bit set with each bit
* associated with a button. See the BOARD_BUTTON_*_BIT and BOARD_JOYSTICK_*_BIT
@@ -427,7 +430,6 @@ EXTERN uint8_t up_buttons(void);
*
* Description:
* up_buttoninit() must be called to initialize button resources. After that,
- * up_buttons() may be called to collect the current state of all buttons or
* up_irqbutton() may be called to register button interrupt handlers.
*
* up_irqbutton() may be called to register an interrupt handler that will be called
@@ -437,6 +439,11 @@ EXTERN uint8_t up_buttons(void);
* The previous interrupt handler address is returned (so that it may restored, if
* so desired).
*
+ * Note that up_irqbutton() also enables button interrupts. Button interrupts
+ * will remain enabled after the interrupt handler is attached. Interrupts may
+ * be disabled (and detached) by calling up_irqbutton with irqhandler equal to
+ * NULL.
+ *
************************************************************************************/
#if defined(CONFIG_ARCH_IRQBUTTONS) && defined(CONFIG_GPIO_IRQ)
diff --git a/nuttx/configs/olimex-lpc1766stk/src/lpc1766stk_internal.h b/nuttx/configs/olimex-lpc1766stk/src/lpc1766stk_internal.h
index 4fa082369..d1c0ebe80 100755
--- a/nuttx/configs/olimex-lpc1766stk/src/lpc1766stk_internal.h
+++ b/nuttx/configs/olimex-lpc1766stk/src/lpc1766stk_internal.h
@@ -129,22 +129,26 @@
* P0[4]/I2SRX_CLK/RD2/CAP2[0] 81 LED2/ACC IRQ
*/
-#define LPC1766STK_LED1 (GPIO_OUTPUT | GPIO_VALUE_ZERO | GPIO_PORT1 | GPIO_PIN25)
-#define LPC1766STK_LED2 (GPIO_OUTPUT | GPIO_VALUE_ZERO | GPIO_PORT0 | GPIO_PIN4)
+#define LPC1766STK_LED1 (GPIO_OUTPUT | GPIO_VALUE_ZERO | GPIO_PORT1 | GPIO_PIN25)
+#define LPC1766STK_LED2 (GPIO_OUTPUT | GPIO_VALUE_ZERO | GPIO_PORT0 | GPIO_PIN4)
/* Buttons GPIO PIN SIGNAL NAME
* -------------------------------- ---- --------------
- * P2[12]/#EINT2/I2STX_WS 51 WAKE-UP
* P0[23]/AD0[0]/I2SRX_CLK/CAP3[0] 9 BUT1
* P2[13]/#EINT3/I2STX_SDA 50 BUT2
+ * P2[12]/#EINT2/I2STX_WS 51 WAKE-UP
*
- * Pull-ups are not required because the pins are already pulled-up by through
- * resistors on the board.
+ * NOTES:
+ * 1. Pull-ups are not required because the pins are already pulled-up by
+ * through resistors on the board.
+ * 2. All buttons are capable of supporting interrupts if up_irqbutton() is
+ * called to attach an interrupt handler. Interrupts are configured to
+ * occur on both edges.
*/
-#define LPC1766STK_BUT1 (GPIO_INPUT | GPIO_FLOAT | GPIO_PORT0 | GPIO_PIN23)
-#define LPC1766STK_BUT2 (GPIO_INPUT | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN13)
-#define LPC1766STK_WAKEUP (GPIO_INPUT | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN12)
+#define LPC1766STK_BUT1 (GPIO_INTBOTH | GPIO_FLOAT | GPIO_PORT0 | GPIO_PIN23)
+#define LPC1766STK_BUT2 (GPIO_INTBOTH | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN13)
+#define LPC1766STK_WAKEUP (GPIO_INTBOTH | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN12)
/* Button IRQ numbers */
@@ -160,15 +164,19 @@
* P2[7]/RD2/RTS1 66 LEFT
* P2[8]/TD2/TXD2 65 RIGHT
*
- * Pull-ups are not required because the pins are already pulled-up by through
- * resistors on the board.
+ * NOTES:
+ * 1. Pull-ups are not required because the pins are already pulled-up by
+ * through resistors on the board.
+ * 2. All buttons are capable of supporting interrupts if up_irqbutton() is
+ * called to attach an interrupt handler. Interrupts are configured to
+ * occur on both edges.
*/
-#define LPC1766STK_CENTER (GPIO_INPUT | GPIO_FLOAT | GPIO_PORT0 | GPIO_PIN5)
-#define LPC1766STK_UP (GPIO_INPUT | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN0)
-#define LPC1766STK_DOWN (GPIO_INPUT | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN1)
-#define LPC1766STK_LEFT (GPIO_INPUT | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN7)
-#define LPC1766STK_RIGHT (GPIO_INPUT | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN8)
+#define LPC1766STK_CENTER (GPIO_INTBOTH | GPIO_FLOAT | GPIO_PORT0 | GPIO_PIN5)
+#define LPC1766STK_UP (GPIO_INTBOTH | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN0)
+#define LPC1766STK_DOWN (GPIO_INTBOTH | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN1)
+#define LPC1766STK_LEFT (GPIO_INTBOTH | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN7)
+#define LPC1766STK_RIGHT (GPIO_INTBOTH | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN8)
/* Joystick IRQ numbers */
@@ -188,10 +196,10 @@
* P3[26]/STCLK/MAT0[1]/PWM1[3] 26 LCD_BL (PWM1)
*/
-#define LPC1766STK_LCD_CS (GPIO_OUTPUT | GPIO_VALUE_ONE | GPIO_PORT1 | GPIO_PIN21)
-#define LPC1766STK_LCD_RST (GPIO_OUTPUT | GPIO_VALUE_ZERO | GPIO_PORT3 | GPIO_PIN25)
-#define LPC1766STK_LCD_BL GPIO_PWM1p3_3
-#define GPIO_PWM1p3 GPIO_PWM1p3_3
+#define LPC1766STK_LCD_CS (GPIO_OUTPUT | GPIO_VALUE_ONE | GPIO_PORT1 | GPIO_PIN21)
+#define LPC1766STK_LCD_RST (GPIO_OUTPUT | GPIO_VALUE_ZERO | GPIO_PORT3 | GPIO_PIN25)
+#define LPC1766STK_LCD_BL GPIO_PWM1p3_3
+#define GPIO_PWM1p3 GPIO_PWM1p3_3
/* SD/MMC GPIO PIN SIGNAL NAME
* -------------------------------- ---- --------------
@@ -202,8 +210,8 @@
* P0[21]/RI1/RD1 57 MMC PWR (active low)
*/
-#define LPC1766STK_MMC_CS (GPIO_OUTPUT | GPIO_VALUE_ONE | GPIO_PORT0 | GPIO_PIN6)
-#define LPC1766STK_MMC_PWR (GPIO_OUTPUT | GPIO_VALUE_ONE | GPIO_PORT0 | GPIO_PIN21)
+#define LPC1766STK_MMC_CS (GPIO_OUTPUT | GPIO_VALUE_ONE | GPIO_PORT0 | GPIO_PIN6)
+#define LPC1766STK_MMC_PWR (GPIO_OUTPUT | GPIO_VALUE_ONE | GPIO_PORT0 | GPIO_PIN21)
/* AD GPIO PIN SIGNAL NAME
* -------------------------------- ---- --------------
@@ -211,8 +219,8 @@
* P0[25]/AD0[2]/I2SRX_SDA/TXD3 7 MIC IN
*/
-#define LPC1766STK_TEMP GPIO_AD0p1
-#define LPC1766STK_MIC_IN GPIO_AD0p2
+#define LPC1766STK_TEMP GPIO_AD0p1
+#define LPC1766STK_MIC_IN GPIO_AD0p2
/* UEXT GPIO PIN SIGNAL NAME
* -------------------------------- ---- --------------
diff --git a/nuttx/configs/olimex-lpc1766stk/src/up_buttons.c b/nuttx/configs/olimex-lpc1766stk/src/up_buttons.c
index 65fe89dfc..611ff5640 100644
--- a/nuttx/configs/olimex-lpc1766stk/src/up_buttons.c
+++ b/nuttx/configs/olimex-lpc1766stk/src/up_buttons.c
@@ -119,6 +119,10 @@ void up_buttoninit(void)
* Name: up_buttons
*
* Description:
+ * up_buttoninit() must be called to initialize button resources. After
+ * that, up_buttons() may be called to collect the current state of all
+ * buttons.
+ *
* up_buttons() may be called at any time to harvest the state of every
* button. The state of the buttons is returned as a bitset with one
* bit corresponding to each button: If the bit is set, then the button
@@ -151,14 +155,12 @@ uint8_t up_buttons(void)
return ret;
}
-/************************************************************************************
+/****************************************************************************
* Button support.
*
* Description:
* up_buttoninit() must be called to initialize button resources. After
- * that, up_buttons() may be called to collect the current state of all
- * buttons or up_irqbutton() may be called to register button interrupt
- * handlers.
+ * that, up_irqbutton() may be called to register button interrupt handlers.
*
* up_irqbutton() may be called to register an interrupt handler that will
* be called when a button is depressed or released. The ID value is a
@@ -167,13 +169,19 @@ uint8_t up_buttons(void)
* of enumeration values. The previous interrupt handler address is returned
* (so that it may restored, if so desired).
*
- ************************************************************************************/
+ * Note that up_irqbutton() also enables button interrupts. Button
+ * interrupts will remain enabled after the interrupt handler is attached.
+ * Interrupts may be disabled (and detached) by calling up_irqbutton with
+ * irqhandler equal to NULL.
+ *
+ ****************************************************************************/
#if defined(CONFIG_ARCH_IRQBUTTONS) && defined(CONFIG_GPIO_IRQ)
xcpt_t up_irqbutton(int id, xcpt_t irqhandler)
{
xcpt_t oldhandler = NULL;
irqstate_t flags;
+ int irq;
/* Verify that the button ID is within range */
@@ -188,10 +196,25 @@ xcpt_t up_irqbutton(int id, xcpt_t irqhandler)
flags = irqsave();
- /* Configure the interrupt */
+ /* Configure the interrupt. Either attach and enable the new
+ * interrupt or disable and detach the old interrupt handler.
+ */
- (void)irq_attach(g_buttonirq[id], irqhandler);
- up_enable_irq(g_buttonirq[id]);
+ irq = g_buttonirq[id];
+ if (irqhandler)
+ {
+ /* Attach then enable the new interrupt handler */
+
+ (void)irq_attach(irq, irqhandler);
+ up_enable_irq(irq);
+ }
+ else
+ {
+ /* Disable then then detach the the old interrupt handler */
+
+ up_disable_irq(irq);
+ (void)irq_detach(irq);
+ }
irqrestore(flags);
}
return oldhandler;
-
- 
- 
-
-