sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Add a USB0 device header file for LPC43

Browse Source 
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@5016 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
patacongo 2012-08-07 23:51:47 +00:00
parent 2501514152
commit 0a65a1d67b
5 changed files with 689 additions and 689 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
Documentation/NuttShell.html
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:

14
Documentation/NuttX.html
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.

1350
Documentation/NuttXDemandPaging.html
View File

File diff suppressed because it is too large Load Diff

4
Documentation/NuttxPortingGuide.html
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>

2
Documentation/NxWidgets.html
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.