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:
parent
fdb743c108
commit
78ff791618
|
@ -816,7 +816,7 @@
|
||||||
and (2) it requires symbol table arguments.
|
and (2) it requires symbol table arguments.
|
||||||
* lib/: Add fileno()
|
* lib/: Add fileno()
|
||||||
* examples/ostest: Several of the tests used a big, hard-coded stack size
|
* 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
|
be controlled by the .config file or the OSTest won't work on platforms
|
||||||
with memory constraints.
|
with memory constraints.
|
||||||
* netutils/thttpd: An initial port of Jeff Poskanzer's THTTPD HTTP server.
|
* 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
|
out instead. This improves behavior, for example, on the first GET request
|
||||||
from a browser.
|
from a browser.
|
||||||
* arch/arm/src/lpc17xx/lpc17_emacram.h and lpc17_allocateheap.c: The Ethernet
|
* 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
|
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
|
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
|
included in the heap
|
||||||
* arch/arm/src/lpc17xx/lpc17_ssp.c: Fix compilation errors when SSP1 is
|
* arch/arm/src/lpc17xx/lpc17_ssp.c: Fix compilation errors when SSP1 is
|
||||||
selected.
|
selected.
|
||||||
|
@ -1785,7 +1785,7 @@
|
||||||
that support 16-bit addressability have smaller overhead than devices
|
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. However, there are many MCUs
|
||||||
that support 32-bit addressability *but* have internal SRAM of size
|
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-
|
defined so that those MCUs will also benefit from the smaller, 16-
|
||||||
bit-based allocation overhead.
|
bit-based allocation overhead.
|
||||||
* lib/string/lib_strndup.c: Add standard strndup() library function.
|
* 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
|
* arch/sim/src/up_romgetc.c: Used to test the basic logic to access strings
|
||||||
without directly de-referencing a string pointer.
|
without directly de-referencing a string pointer.
|
||||||
* arch/avr/src/avr/up_romget.c: Used to access strings that lie in the first
|
* 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).
|
FLASH without using the PROGMEM attribute).
|
||||||
* configs/teensy/src/up_spi.c: Correct reading of SD CD and WP pins (was reading
|
* 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.
|
the wrong register. AVR SPI now appears to be functional.
|
||||||
|
|
|
@ -8,7 +8,7 @@
|
||||||
<tr align="center" bgcolor="#e4e4e4">
|
<tr align="center" bgcolor="#e4e4e4">
|
||||||
<td>
|
<td>
|
||||||
<h1><big><font color="#3c34ec"><i>NuttShell (NSH)</i></font></big></h1>
|
<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>
|
</td>
|
||||||
</tr>
|
</tr>
|
||||||
</table>
|
</table>
|
||||||
|
@ -1210,7 +1210,7 @@ losetup [-o <offset>] [-r] <dev-path> <file-path>
|
||||||
<p>
|
<p>
|
||||||
<b>Synopsis</b>.
|
<b>Synopsis</b>.
|
||||||
Setup the loop device at <dev-path> to access the file at <file-path> as a block device.
|
Setup the loop device at <dev-path> to access the file at <file-path> 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.
|
used to make the file accessible as a block device.
|
||||||
A FAT file system is created (<code>mkfatfs</code>) and mounted (<code>mount</code>).
|
A FAT file system is created (<code>mkfatfs</code>) and mounted (<code>mount</code>).
|
||||||
Files can then be managed on the loop-mounted file.
|
Files can then be managed on the loop-mounted file.
|
||||||
|
@ -3148,7 +3148,7 @@ endef
|
||||||
</p>
|
</p>
|
||||||
<li>
|
<li>
|
||||||
<p>
|
<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>
|
</p>
|
||||||
<ul><pre>
|
<ul><pre>
|
||||||
APPNAME = hello
|
APPNAME = hello
|
||||||
|
@ -3160,7 +3160,7 @@ STACKSIZE = 2048
|
||||||
<p>
|
<p>
|
||||||
And finally, the <code>Makefile</code> invokes the <code>REGISTER</code> macro to added the <code>hello_main()</code> named application.
|
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.
|
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>
|
</p>
|
||||||
<ul><pre>
|
<ul><pre>
|
||||||
.context:
|
.context:
|
||||||
|
|
|
@ -858,9 +858,9 @@
|
||||||
<p>
|
<p>
|
||||||
Using a variety of technologies, NuttX can scale from the very tiny to
|
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
|
the moderate-size system. I have executed NuttX with some simple applications
|
||||||
in as little as 32Kb <i>total</i> memory (code and data).
|
in as little as 32K <i>total</i> memory (code and data).
|
||||||
On the other hand, typical, richly featured NuttX builds require more like 64Kb
|
On the other hand, typical, richly featured NuttX builds require more like 64K
|
||||||
(and if all of the features are used, this can push 100Kb).
|
(and if all of the features are used, this can push 100K).
|
||||||
</p>
|
</p>
|
||||||
</td>
|
</td>
|
||||||
</tr>
|
</tr>
|
||||||
|
@ -2028,8 +2028,8 @@
|
||||||
<b>Micropendous 3 AT9USB64x</b> and <b>AT9USB6128x</b>.
|
<b>Micropendous 3 AT9USB64x</b> and <b>AT9USB6128x</b>.
|
||||||
This port of NuttX to the Opendous Micropendous 3 board. The Micropendous3 is
|
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
|
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
|
version for testing. This version have very limited memory resources: 64K of
|
||||||
FLASH and 4Kb of SRAM.
|
FLASH and 4K of SRAM.
|
||||||
</p>
|
</p>
|
||||||
<ul>
|
<ul>
|
||||||
<p>
|
<p>
|
||||||
|
@ -2085,7 +2085,7 @@
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Most NuttX test applications are console-oriented with lots of strings used for printf and debug output.
|
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:
|
So, in order for the AVR port to be useful, one of two things would need to be done:
|
||||||
</p>
|
</p>
|
||||||
<ol>
|
<ol>
|
||||||
|
@ -2917,7 +2917,7 @@ if [ -x "$WINELOADER" ]; then exec "$WINELOADER" "$appname" "$@"; fi
|
||||||
</pre>
|
</pre>
|
||||||
<p><b>87C52</b>
|
<p><b>87C52</b>
|
||||||
A reduced functionality OS test for the 8052 target requires only
|
A reduced functionality OS test for the 8052 target requires only
|
||||||
about 18-19Kb:
|
about 18-19K:
|
||||||
</p>
|
</p>
|
||||||
<pre>
|
<pre>
|
||||||
Stack starts at: 0x21 (sp set to 0x20) with 223 bytes available.
|
Stack starts at: 0x21 (sp set to 0x20) with 223 bytes available.
|
||||||
|
|
|
@ -143,7 +143,7 @@
|
||||||
</li>
|
</li>
|
||||||
<li>
|
<li>
|
||||||
The MCU must have a (relatively) small block of fast SRAM from which it can execute code.
|
The MCU must have a (relatively) small block of fast SRAM from which it can execute code.
|
||||||
A size of, say 256Kb (or 192Kb as in the NXP LPC3131) would be sufficient for many applications.
|
A size of, say 256K (or 192K as in the NXP LPC3131) would be sufficient for many applications.
|
||||||
</li>
|
</li>
|
||||||
<li>
|
<li>
|
||||||
The MCU has an MMU (again like the NXP LPC3131).
|
The MCU has an MMU (again like the NXP LPC3131).
|
||||||
|
@ -479,7 +479,7 @@
|
||||||
This memory regions must include:
|
This memory regions must include:
|
||||||
<ul>
|
<ul>
|
||||||
<li>
|
<li>
|
||||||
All logic for all interrupt pathes.
|
All logic for all interrupt paths.
|
||||||
All interrupt logic must be locked in memory because the design present here will not support page faults from interrupt handlers.
|
All interrupt logic must be locked in memory because the design present here will not support page faults from interrupt handlers.
|
||||||
This includes the page fault handling logic and <a href="#PageFaults"><code>pg_miss()</code></a> that is called from the page fault handler.
|
This includes the page fault handling logic and <a href="#PageFaults"><code>pg_miss()</code></a> that is called from the page fault handler.
|
||||||
It also includes the <a href="#FillComplete"><code>pg_callback()</code></a> function that wakes up the page fill worker thread
|
It also includes the <a href="#FillComplete"><code>pg_callback()</code></a> function that wakes up the page fill worker thread
|
||||||
|
@ -572,24 +572,24 @@
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<b>Example</b>.
|
<b>Example</b>.
|
||||||
As an example, suppose that the size of the SRAM is 192Kb (as in the NXP LPC3131). And suppose further that:
|
As an example, suppose that the size of the SRAM is 192K (as in the NXP LPC3131). And suppose further that:
|
||||||
<ul>
|
<ul>
|
||||||
<li>
|
<li>
|
||||||
The size of the locked, memory resident .text area is 32Kb, and
|
The size of the locked, memory resident .text area is 32K, and
|
||||||
</li>
|
</li>
|
||||||
<li>
|
<li>
|
||||||
The size of the DATA area is 64Kb.
|
The size of the DATA area is 64K.
|
||||||
</li>
|
</li>
|
||||||
<li>
|
<li>
|
||||||
The size of one, managed page is 1Kb.
|
The size of one, managed page is 1K.
|
||||||
</li>
|
</li>
|
||||||
<li>
|
<li>
|
||||||
The size of the whole .text image on the non-volatile, mass storage device is 1024Kb.
|
The size of the whole .text image on the non-volatile, mass storage device is 1024K.
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
</ul>
|
||||||
<p>
|
<p>
|
||||||
Then, the size of the locked, memory resident code is 32Kb (<i>m</i>=32 pages).
|
Then, the size of the locked, memory resident code is 32K (<i>m</i>=32 pages).
|
||||||
The size of the physical page region is 96Kb (96 pages), and the
|
The size of the physical page region is 96K (96 pages), and the
|
||||||
size of the data region is 64 pages.
|
size of the data region is 64 pages.
|
||||||
And the size of the virtual paged region must then be greater than or equal to (1024-32) or 992 pages (<i>n</i>).
|
And the size of the virtual paged region must then be greater than or equal to (1024-32) or 992 pages (<i>n</i>).
|
||||||
</p>
|
</p>
|
||||||
|
|
|
@ -3935,7 +3935,7 @@ build
|
||||||
16-bit addressability have smaller overhead than devices that
|
16-bit addressability have smaller overhead than devices that
|
||||||
support 32-bit addressability. However, there are many MCUs
|
support 32-bit addressability. However, there are many MCUs
|
||||||
that support 32-bit addressability <i>but</i> have internal SRAM
|
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
|
can be defined so that those MCUs will also benefit from the
|
||||||
smaller, 16-bit-based allocation overhead.
|
smaller, 16-bit-based allocation overhead.
|
||||||
</li>
|
</li>
|
||||||
|
@ -4740,7 +4740,7 @@ build
|
||||||
<li>
|
<li>
|
||||||
<code>CONFIG_P14201_FRAMEBUFFER</code>:
|
<code>CONFIG_P14201_FRAMEBUFFER</code>:
|
||||||
If defined, accesses will be performed using an in-memory copy of the OLEDs GDDRAM.
|
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 this is defined, then the driver will be fully functional.
|
||||||
If not, then it will have the following limitations:
|
If not, then it will have the following limitations:
|
||||||
<ul>
|
<ul>
|
||||||
|
|
|
@ -33,7 +33,7 @@
|
||||||
<li><b>Small Footprint</b>.
|
<li><b>Small Footprint</b>.
|
||||||
NXWidgets is tailored for use MCUs in embedded applications.
|
NXWidgets is tailored for use MCUs in embedded applications.
|
||||||
It is ideally suited for mid- and upper-range of most MCU families.
|
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>
|
||||||
<li><b>Output Devices</b>.
|
<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.
|
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.
|
||||||
|
|
|
@ -1668,7 +1668,7 @@ Important bugfixes included:
|
||||||
And feature enhancements:
|
And feature enhancements:
|
||||||
|
|
||||||
* The LPC176x Ethernet driver was using all of AHB SRAM Bank0 for
|
* 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
|
the amount of SRAM used for packet buffering and to re-use any
|
||||||
extra Bank0 memory for heap.
|
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)
|
* A PCI-based E1000 Ethernet driver (contributed by Yu Qiang)
|
||||||
* New C library functions: inet_addr() (contributed by Yu Qiang),
|
* New C library functions: inet_addr() (contributed by Yu Qiang),
|
||||||
strndup(), asprintf()
|
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
|
* fdopen() now works with socket descriptors allowing standard
|
||||||
buffered C functions to be used for network communications.
|
buffered C functions to be used for network communications.
|
||||||
* The NSH ifconfig command can now be used to set or change the
|
* 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
|
This port of NuttX to the Amber Web Server from SoC Robotics
|
||||||
(http://www.soc-robotics.com/index.htm). Is only partially in
|
(http://www.soc-robotics.com/index.htm). Is only partially in
|
||||||
place. The Amber Web Server is based on an Atmel ATMega128
|
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
|
STATUS: Work on this port has stalled due to toolchain issues. It
|
||||||
is complete, but untested.
|
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,
|
Micropendous3 may be populated with an AT90USB646, 647, 1286,
|
||||||
or 1287. See http://code.google.com/p/opendous/. I have only
|
or 1287. See http://code.google.com/p/opendous/. I have only
|
||||||
the AT90USB647 version for testing. This version has very
|
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
|
STATUS: The basic port was released in NuttX-6.5. This basic
|
||||||
port consists only of a "Hello, World!!" example that demonstrates
|
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
|
This is a port of NuttX to the PJRC Teensy++ 2.0 board. This
|
||||||
board was developed by PJRC (http://pjrc.com/teensy/). The
|
board was developed by PJRC (http://pjrc.com/teensy/). The
|
||||||
Teensy++ 2.0 is based on an Atmel AT90USB1286 MCU with 128Kb
|
Teensy++ 2.0 is based on an Atmel AT90USB1286 MCU with 128K
|
||||||
of FLASH and 8Kb of SRAM; a little more room to move than the
|
of FLASH and 8K of SRAM; a little more room to move than the
|
||||||
AT90USB647.
|
AT90USB647.
|
||||||
|
|
||||||
STATUS: The basic port was released in NuttX-6.5. This basic
|
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
|
Most NuttX test applications are console-oriented with lots of
|
||||||
strings used for printf and debug output. These strings are all
|
strings used for printf and debug output. These strings are all
|
||||||
stored in SRAM now due to these data accessing issues and even the
|
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
|
memory. So, in order for the AVR port to be useful, one of two
|
||||||
things would need to be done:
|
things would need to be done:
|
||||||
|
|
||||||
|
|
|
@ -1819,7 +1819,7 @@ o mc68hc1x (arch/hc)
|
||||||
Description: There is no script for building in banked mode (more correctly, there
|
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).
|
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
|
It would be necessary to implement banked mode to able to access more
|
||||||
the 48Kb of FLASH.
|
the 48K of FLASH.
|
||||||
Status: Open.
|
Status: Open.
|
||||||
Priority: Medium/Low
|
Priority: Medium/Low
|
||||||
|
|
||||||
|
|
|
@ -69,9 +69,7 @@
|
||||||
#include "up_arch.h"
|
#include "up_arch.h"
|
||||||
#include "up_internal.h"
|
#include "up_internal.h"
|
||||||
|
|
||||||
#include "lpc43_usbotg.h"
|
#include "lpc43_usb0dev.h"
|
||||||
#include "lpc43_evntrtr.h"
|
|
||||||
#include "lpc43_syscreg.h"
|
|
||||||
|
|
||||||
/*******************************************************************************
|
/*******************************************************************************
|
||||||
* Definitions
|
* Definitions
|
||||||
|
|
|
@ -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 */
|
||||||
|
|
Loading…
Reference in New Issue