Update README, LPC1766-STK button improvements, new Make targets, new Getting Started document
git-svn-id: https://nuttx.svn.sourceforge.net/svnroot/nuttx/trunk@4244 7fd9a85b-ad96-42d3-883c-3090e2eb8679
|
@ -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.
|
||||
|
|
Before Width: | Height: | Size: 4.8 KiB After Width: | Height: | Size: 4.8 KiB |
Before Width: | Height: | Size: 1.5 KiB After Width: | Height: | Size: 1.5 KiB |
Before Width: | Height: | Size: 1.5 KiB After Width: | Height: | Size: 1.5 KiB |
Before Width: | Height: | Size: 3.4 KiB After Width: | Height: | Size: 3.4 KiB |
Before Width: | Height: | Size: 4.1 KiB After Width: | Height: | Size: 4.1 KiB |
|
@ -28,6 +28,7 @@
|
|||
<tr>
|
||||
<td> </td>
|
||||
<td>
|
||||
<li><a href="NuttxGettingStarted.html" target="main">Getting Started</a></li>
|
||||
<li><a href="NuttxUserGuide.html" target="main">User Guide</a></li>
|
||||
<li><a href="NuttxPortingGuide.html" target="main">Porting Guide</a></li>
|
||||
<li><a href="NuttShell.html" target="main">NuttShell (NSH)</a></li>
|
||||
|
|
|
@ -0,0 +1,25 @@
|
|||
<html>
|
||||
<head>
|
||||
<title>NuttX Getting Started</title>
|
||||
</head>
|
||||
|
||||
<body background="backgd.gif">
|
||||
<hr><hr>
|
||||
<table width ="100%">
|
||||
<tr align="center" bgcolor="#e4e4e4">
|
||||
<td>
|
||||
<h1><big><font color="#3c34ec"><i>Getting Started with NuttX</i></font></big></h1>
|
||||
<p>Last Updated: December 31, 2011</p>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr><hr>
|
||||
<p><b>Getting Started</b>.
|
||||
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 <code>README.txt</code> file located in the top-level NuttX directory.
|
||||
That <code>README.txt</code> can also be read online in the NuttX SVN repository
|
||||
<a href="http://nuttx.svn.sourceforge.net/viewvc/nuttx/trunk/nuttx/README.txt?view=log">here</a>.
|
||||
Just click on "Links to HEAD: (view)" on that page.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
|
@ -1,6 +1,6 @@
|
|||
<html>
|
||||
<head>
|
||||
<title>README Files</title>
|
||||
<title>NuttX USB Trace Capability</title>
|
||||
</head>
|
||||
|
||||
<body background="backgd.gif">
|
||||
|
|
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 451 B After Width: | Height: | Size: 451 B |
105
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
|
||||
|
|
172
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 <stdio.h>",
|
||||
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
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -134,17 +134,21 @@
|
|||
|
||||
/* 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 */
|
||||
|
||||
|
|
|
@ -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;
|
||||
|
|