Add a USB0 device header file for LPC43

git-svn-id: https://nuttx.svn.sourceforge.net/svnroot/nuttx/trunk@5016 7fd9a85b-ad96-42d3-883c-3090e2eb8679
This commit is contained in:
patacongo 2012-08-07 23:51:47 +00:00
parent ed303232fa
commit 62cfd38241
10 changed files with 801 additions and 705 deletions

View File

@ -816,7 +816,7 @@
and (2) it requires symbol table arguments.
* lib/: Add fileno()
* examples/ostest: Several of the tests used a big, hard-coded stack size
when creating test threads (16Kb stacksize). The stack size should
when creating test threads (16K stacksize). The stack size should
be controlled by the .config file or the OSTest won't work on platforms
with memory constraints.
* netutils/thttpd: An initial port of Jeff Poskanzer's THTTPD HTTP server.
@ -1369,10 +1369,10 @@
out instead. This improves behavior, for example, on the first GET request
from a browser.
* arch/arm/src/lpc17xx/lpc17_emacram.h and lpc17_allocateheap.c: The Ethernet
logic was using all of AHB SRAM Bank0 for Ethernet packet buffers (16Kb). An
logic was using all of AHB SRAM Bank0 for Ethernet packet buffers (16K). An
option was added to limit the amount of SRAM used for packet buffering and to
re-use any extra Bank0 memory for heap. configs/olimex-lpc1766stk/nettest
now uses only 8Kb at the beginning of Bank0; the 8Kb at the end of Bank0 is
now uses only 8K at the beginning of Bank0; the 8K at the end of Bank0 is
included in the heap
* arch/arm/src/lpc17xx/lpc17_ssp.c: Fix compilation errors when SSP1 is
selected.
@ -1785,7 +1785,7 @@
that support 16-bit addressability have smaller overhead than devices
that support 32-bit addressability. However, there are many MCUs
that support 32-bit addressability *but* have internal SRAM of size
less than or equal to 64Kb. In this case, CONFIG_MM_SMALL can be
less than or equal to 64K. In this case, CONFIG_MM_SMALL can be
defined so that those MCUs will also benefit from the smaller, 16-
bit-based allocation overhead.
* lib/string/lib_strndup.c: Add standard strndup() library function.
@ -1846,7 +1846,7 @@
* arch/sim/src/up_romgetc.c: Used to test the basic logic to access strings
without directly de-referencing a string pointer.
* arch/avr/src/avr/up_romget.c: Used to access strings that lie in the first
64Kb of FLASH (But I still haven't figured out how to get strings to reside in
64K of FLASH (But I still haven't figured out how to get strings to reside in
FLASH without using the PROGMEM attribute).
* configs/teensy/src/up_spi.c: Correct reading of SD CD and WP pins (was reading
the wrong register. AVR SPI now appears to be functional.

View File

@ -8,7 +8,7 @@
<tr align="center" bgcolor="#e4e4e4">
<td>
<h1><big><font color="#3c34ec"><i>NuttShell (NSH)</i></font></big></h1>
<p>Last Updated: August 3, 2012</p>
<p>Last Updated: August 7, 2012</p>
</td>
</tr>
</table>
@ -1210,7 +1210,7 @@ losetup [-o <offset>] [-r] &lt;dev-path&gt; &lt;file-path&gt;
<p>
<b>Synopsis</b>.
Setup the loop device at &lt;dev-path&gt; to access the file at &lt;file-path&gt; as a block device.
In the following example a 256Kb file is created (<code>dd</code>) and <code>losetup</code> is
In the following example a 256K file is created (<code>dd</code>) and <code>losetup</code> is
used to make the file accessible as a block device.
A FAT file system is created (<code>mkfatfs</code>) and mounted (<code>mount</code>).
Files can then be managed on the loop-mounted file.
@ -3148,7 +3148,7 @@ endef
</p>
<li>
<p>
The make file then defines the application name (<code>hello</code>), the task priority (default), and the stack size that will be allocated in the task runs (2Kb).
The make file then defines the application name (<code>hello</code>), the task priority (default), and the stack size that will be allocated in the task runs (2K).
</p>
<ul><pre>
APPNAME = hello
@ -3160,7 +3160,7 @@ STACKSIZE = 2048
<p>
And finally, the <code>Makefile</code> invokes the <code>REGISTER</code> macro to added the <code>hello_main()</code> named application.
Then, when the system build completes, the <code>hello</code> command can be executed from the NSH command line.
When the <code>hello</code> command is executed, it will start the task with entry point <code>hello_main()</code> with the default priority and with a stack size of 2Kb.
When the <code>hello</code> command is executed, it will start the task with entry point <code>hello_main()</code> with the default priority and with a stack size of 2K.
</p>
<ul><pre>
.context:

View File

@ -858,9 +858,9 @@
<p>
Using a variety of technologies, NuttX can scale from the very tiny to
the moderate-size system. I have executed NuttX with some simple applications
in as little as 32Kb <i>total</i> memory (code and data).
On the other hand, typical, richly featured NuttX builds require more like 64Kb
(and if all of the features are used, this can push 100Kb).
in as little as 32K <i>total</i> memory (code and data).
On the other hand, typical, richly featured NuttX builds require more like 64K
(and if all of the features are used, this can push 100K).
</p>
</td>
</tr>
@ -2028,8 +2028,8 @@
<b>Micropendous 3 AT9USB64x</b> and <b>AT9USB6128x</b>.
This port of NuttX to the Opendous Micropendous 3 board. The Micropendous3 is
may be populated with an AT90USB646, 647, 1286, or 1287. I have only the AT90USB647
version for testing. This version have very limited memory resources: 64Kb of
FLASH and 4Kb of SRAM.
version for testing. This version have very limited memory resources: 64K of
FLASH and 4K of SRAM.
</p>
<ul>
<p>
@ -2085,7 +2085,7 @@
</p>
<p>
Most NuttX test applications are console-oriented with lots of strings used for printf and debug output.
These strings are all stored in SRAM now due to these data accessing issues and even the smallest console-oriented applications can quickly fill a 4-8Kb memory.
These strings are all stored in SRAM now due to these data accessing issues and even the smallest console-oriented applications can quickly fill a 4-8K memory.
So, in order for the AVR port to be useful, one of two things would need to be done:
</p>
<ol>
@ -2917,7 +2917,7 @@ if [ -x "$WINELOADER" ]; then exec "$WINELOADER" "$appname" "$@"; fi
</pre>
<p><b>87C52</b>
A reduced functionality OS test for the 8052 target requires only
about 18-19Kb:
about 18-19K:
</p>
<pre>
Stack starts at: 0x21 (sp set to 0x20) with 223 bytes available.

File diff suppressed because it is too large Load Diff

View File

@ -3935,7 +3935,7 @@ build
16-bit addressability have smaller overhead than devices that
support 32-bit addressability. However, there are many MCUs
that support 32-bit addressability <i>but</i> have internal SRAM
of size less than or equal to 64Kb. In this case, CONFIG_MM_SMALL
of size less than or equal to 64K. In this case, CONFIG_MM_SMALL
can be defined so that those MCUs will also benefit from the
smaller, 16-bit-based allocation overhead.
</li>
@ -4740,7 +4740,7 @@ build
<li>
<code>CONFIG_P14201_FRAMEBUFFER</code>:
If defined, accesses will be performed using an in-memory copy of the OLEDs GDDRAM.
This cost of this buffer is 128 * 96 / 2 = 6Kb.
This cost of this buffer is 128 * 96 / 2 = 6K.
If this is defined, then the driver will be fully functional.
If not, then it will have the following limitations:
<ul>

View File

@ -33,7 +33,7 @@
<li><b>Small Footprint</b>.
NXWidgets is tailored for use MCUs in embedded applications.
It is ideally suited for mid- and upper-range of most MCU families.
A complete NXWidgets is possible in as little as 40Kb of FLASH and maybe 4Kb of SRAM.
A complete NXWidgets is possible in as little as 40K of FLASH and maybe 4K of SRAM.
</li>
<li><b>Output Devices</b>.
NXWidgets will work on the high-end frame buffer devices as well as on LCDs connected via serial or parallel ports to a small MCU.

View File

@ -1668,7 +1668,7 @@ Important bugfixes included:
And feature enhancements:
* The LPC176x Ethernet driver was using all of AHB SRAM Bank0 for
Ethernet packet buffers (16Kb). An option was added to limit
Ethernet packet buffers (16K). An option was added to limit
the amount of SRAM used for packet buffering and to re-use any
extra Bank0 memory for heap.
@ -2022,7 +2022,7 @@ and is available for download from the SourceForge website. The
* A PCI-based E1000 Ethernet driver (contributed by Yu Qiang)
* New C library functions: inet_addr() (contributed by Yu Qiang),
strndup(), asprintf()
* Reduced memory allocation overhead for MCUs with small heaps (<64Kb).
* Reduced memory allocation overhead for MCUs with small heaps (<64K).
* fdopen() now works with socket descriptors allowing standard
buffered C functions to be used for network communications.
* The NSH ifconfig command can now be used to set or change the
@ -2062,7 +2062,7 @@ they are, ordered from the least to the most complete:
This port of NuttX to the Amber Web Server from SoC Robotics
(http://www.soc-robotics.com/index.htm). Is only partially in
place. The Amber Web Server is based on an Atmel ATMega128
(128Kb FLASH but only 4Kb of SRAM).
(128K FLASH but only 4K of SRAM).
STATUS: Work on this port has stalled due to toolchain issues. It
is complete, but untested.
@ -2073,7 +2073,7 @@ they are, ordered from the least to the most complete:
Micropendous3 may be populated with an AT90USB646, 647, 1286,
or 1287. See http://code.google.com/p/opendous/. I have only
the AT90USB647 version for testing. This version has very
limited memory resources: 64Kb of FLASH and 4Kb of SRAM.
limited memory resources: 64K of FLASH and 4K of SRAM.
STATUS: The basic port was released in NuttX-6.5. This basic
port consists only of a "Hello, World!!" example that demonstrates
@ -2085,8 +2085,8 @@ they are, ordered from the least to the most complete:
This is a port of NuttX to the PJRC Teensy++ 2.0 board. This
board was developed by PJRC (http://pjrc.com/teensy/). The
Teensy++ 2.0 is based on an Atmel AT90USB1286 MCU with 128Kb
of FLASH and 8Kb of SRAM; a little more room to move than the
Teensy++ 2.0 is based on an Atmel AT90USB1286 MCU with 128K
of FLASH and 8K of SRAM; a little more room to move than the
AT90USB647.
STATUS: The basic port was released in NuttX-6.5. This basic
@ -2109,7 +2109,7 @@ integrated into the normal, general purpose OS.
Most NuttX test applications are console-oriented with lots of
strings used for printf and debug output. These strings are all
stored in SRAM now due to these data accessing issues and even the
smallest console-oriented applications can quickly fill a 4-8Kb
smallest console-oriented applications can quickly fill a 4-8K
memory. So, in order for the AVR port to be useful, one of two
things would need to be done:

View File

@ -1819,7 +1819,7 @@ o mc68hc1x (arch/hc)
Description: There is no script for building in banked mode (more correctly, there
is a script, but logic inside the script has not yet been implemented).
It would be necessary to implement banked mode to able to access more
the 48Kb of FLASH.
the 48K of FLASH.
Status: Open.
Priority: Medium/Low

View File

@ -69,9 +69,7 @@
#include "up_arch.h"
#include "up_internal.h"
#include "lpc43_usbotg.h"
#include "lpc43_evntrtr.h"
#include "lpc43_syscreg.h"
#include "lpc43_usb0dev.h"
/*******************************************************************************
* Definitions

View File

@ -0,0 +1,98 @@
/************************************************************************************
* arch/arm/src/lpc43xx/lpc43_usbdev.h
*
* Copyright (C) 2009, 2011 Gregory Nutt. All rights reserved.
* Author: Gregory Nutt <spudmonkey@racsa.co.cr>
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
* 3. Neither the name NuttX nor the names of its contributors may be
* used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
* AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*
************************************************************************************/
#ifndef __ARCH_ARM_SRC_LPC43XX_LPC32_USB0DEV_H
#define __ARCH_ARM_SRC_LPC43XX_LPC32_USB0DEV_H
/************************************************************************************
* Included Files
************************************************************************************/
#include <nuttx/config.h>
#include <nuttx/usb/usbdev.h>
#include <stdint.h>
#include "chip.h"
#include "chip/lpc43_usb0.h"
/************************************************************************************
* Public Functions
************************************************************************************/
#ifndef __ASSEMBLY__
#undef EXTERN
#if defined(__cplusplus)
#define EXTERN extern "C"
extern "C" {
#else
#define EXTERN extern
#endif
/************************************************************************************
* Name: lpc43_usbpullup
*
* Description:
* If USB is supported and the board supports a pullup via GPIO (for USB software
* connect and disconnect), then the board software must provide lpc43_pullup.
* See include/nuttx/usb/usbdev.h for additional description of this method.
* Alternatively, if no pull-up GPIO the following EXTERN can be redefined to be
* NULL.
*
************************************************************************************/
EXTERN int lpc43_usbpullup(FAR struct usbdev_s *dev, bool enable);
/************************************************************************************
* Name: lpc43_usbsuspend
*
* Description:
* Board logic must provide the lpc43_usbsuspend logic if the USBDEV driver is
* used. This function is called whenever the USB enters or leaves suspend mode.
* This is an opportunity for the board logic to shutdown clocks, power, etc.
* while the USB is suspended.
*
************************************************************************************/
EXTERN void lpc43_usbsuspend(FAR struct usbdev_s *dev, bool resume);
#undef EXTERN
#if defined(__cplusplus)
}
#endif
#endif /* __ASSEMBLY__ */
#endif /* __ARCH_ARM_SRC_LPC43XX_LPC32_USB0DEV_H */