mirror of
https://gitee.com/mirrors_PX4/PX4-Autopilot.git
synced 2026-10-29 06:43:34 +08:00
Documentation update
git-svn-id: https://nuttx.svn.sourceforge.net/svnroot/nuttx/trunk@4511 7fd9a85b-ad96-42d3-883c-3090e2eb8679
This commit is contained in:
@@ -8,7 +8,7 @@
|
|||||||
<tr align="center" bgcolor="#e4e4e4">
|
<tr align="center" bgcolor="#e4e4e4">
|
||||||
<td>
|
<td>
|
||||||
<h1><big><font color="#3c34ec"><i>NuttX RTOS</i></font></big></h1>
|
<h1><big><font color="#3c34ec"><i>NuttX RTOS</i></font></big></h1>
|
||||||
<p>Last Updated: March 22, 2012</p>
|
<p>Last Updated: March 24, 2012</p>
|
||||||
</td>
|
</td>
|
||||||
</tr>
|
</tr>
|
||||||
</table>
|
</table>
|
||||||
@@ -708,6 +708,15 @@
|
|||||||
<li>Font management sub-system.</li>
|
<li>Font management sub-system.</li>
|
||||||
</p>
|
</p>
|
||||||
</tr>
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td><br></td>
|
||||||
|
<td>
|
||||||
|
<p>
|
||||||
|
<li>
|
||||||
|
<a href="NxWidgets.html">NxWidgets</a>: NXWidgets is library of graphic objects, or "widgets," (labels, buttons, text boxes, images, sliders, progress bars, etc.). NXWidgets is written in C++ and integrates seamlessly with the NuttX NX graphics and font management subsystems.
|
||||||
|
</li>
|
||||||
|
</p>
|
||||||
|
</tr>
|
||||||
|
|
||||||
<tr>
|
<tr>
|
||||||
<td valign="top" width="22"><img height="20" width="20" src="favicon.ico"></td>
|
<td valign="top" width="22"><img height="20" width="20" src="favicon.ico"></td>
|
||||||
|
|||||||
@@ -8,7 +8,7 @@
|
|||||||
<tr align="center" bgcolor="#e4e4e4">
|
<tr align="center" bgcolor="#e4e4e4">
|
||||||
<td>
|
<td>
|
||||||
<h1><big><font color="#3c34ec"><i>NxWidgets</i></font></big></h1>
|
<h1><big><font color="#3c34ec"><i>NxWidgets</i></font></big></h1>
|
||||||
<p>Last Updated: March 22, 2012</p>
|
<p>Last Updated: March 24, 2012</p>
|
||||||
</td>
|
</td>
|
||||||
</tr>
|
</tr>
|
||||||
</table>
|
</table>
|
||||||
@@ -46,6 +46,9 @@
|
|||||||
<li><b>Many Graphic Objects</b>.
|
<li><b>Many Graphic Objects</b>.
|
||||||
Some of the graphic objects supported by NXWidgets include labels, buttons, text boxes, button arrays, check boxes, cycle buttons, images, sliders, scrollable list boxes, progress bars, and more.
|
Some of the graphic objects supported by NXWidgets include labels, buttons, text boxes, button arrays, check boxes, cycle buttons, images, sliders, scrollable list boxes, progress bars, and more.
|
||||||
</li>
|
</li>
|
||||||
|
<li><b>DOxygen Documentation</ba>
|
||||||
|
DOxygen documentation is available.
|
||||||
|
</li>
|
||||||
</ul>
|
</ul>
|
||||||
<p>
|
<p>
|
||||||
Note: Many of the fundamental classed in NxWidgets derive from the Antony
|
Note: Many of the fundamental classed in NxWidgets derive from the Antony
|
||||||
|
|||||||
+51
-5
@@ -84,6 +84,8 @@ o Task/Scheduler (sched/)
|
|||||||
|
|
||||||
Title: MISSING ERRNO SETTINGS
|
Title: MISSING ERRNO SETTINGS
|
||||||
Description: Several APIs do not set errno. Need to review all APIs.
|
Description: Several APIs do not set errno. Need to review all APIs.
|
||||||
|
Update: These are being fixed as they are encountered. There is
|
||||||
|
no accounting of how many interfaces have this problem.
|
||||||
Status: Open
|
Status: Open
|
||||||
Priority: Medium, required for standard compliance (but makes the
|
Priority: Medium, required for standard compliance (but makes the
|
||||||
code bigger)
|
code bigger)
|
||||||
@@ -208,7 +210,45 @@ o pthreads (sched/)
|
|||||||
being moved to the tail of the scheduling queue at its priority in the
|
being moved to the tail of the scheduling queue at its priority in the
|
||||||
event that its original priority is changed."
|
event that its original priority is changed."
|
||||||
Status: Open
|
Status: Open
|
||||||
Priority: Low, probably not that useful
|
Priority: Low -- about zero, probably not that useful. Priority inheritance is
|
||||||
|
already supported and is a much better solution. And it turns out
|
||||||
|
that priority protection is just about as complex as priority inheritance.
|
||||||
|
Exerpted from my post in a Linked-In discussion:
|
||||||
|
|
||||||
|
"I started to implement this HLS/"PCP" semaphore in an RTOS that I
|
||||||
|
work with (http://www.nuttx.org) and I discovered after doing the
|
||||||
|
analysis and basic code framework that a complete solution for the
|
||||||
|
case of a counting semaphore is still quite complex -- essentially
|
||||||
|
as complex as is priority inheritance.
|
||||||
|
|
||||||
|
"For example, suppose that a thread takes 3 different HLS semaphores
|
||||||
|
A, B, and C. Suppose that they are prioritized in that order with
|
||||||
|
A the lowest and C the highest. Suppose the thread takes 5 counts
|
||||||
|
from A, 3 counts from B, and 2 counts from C. What priority should
|
||||||
|
it run at? It would have to run at the priority of the highest
|
||||||
|
priority semaphore C. This means that the RTOS must maintain
|
||||||
|
internal information of the priority of every semaphore held by
|
||||||
|
the thread.
|
||||||
|
|
||||||
|
"Now suppose it releases one count on semaphore B. How does the
|
||||||
|
RTOS know that it still holds 2 counts on B? With some complex
|
||||||
|
internal data structure. The RTOS would have to maintain internal
|
||||||
|
information about how many counts from each semaphore are held
|
||||||
|
by each thread.
|
||||||
|
|
||||||
|
"How does the RTOS know that it should not decrement the priority
|
||||||
|
from the priority of C? Again, only with internal complexity. It
|
||||||
|
would have to know the priority of every semaphore held by
|
||||||
|
every thread.
|
||||||
|
|
||||||
|
"Providing the HLS capability on a simple phread mutex would not
|
||||||
|
be such quite such a complex job if you allow only one mutex per
|
||||||
|
thread. However, the more general case seems almost as complex
|
||||||
|
as priority inheritance. I decided that the implementation does
|
||||||
|
not have value to me. I only wanted it for its reduced
|
||||||
|
complexity; in all other ways I believe that it is the inferior
|
||||||
|
solution. So I discarded a few hours of programming. Not a
|
||||||
|
big loss from the experience I gained."
|
||||||
|
|
||||||
o C++ Support
|
o C++ Support
|
||||||
^^^^^^^^^^^
|
^^^^^^^^^^^
|
||||||
@@ -231,6 +271,13 @@ o C++ Support
|
|||||||
|
|
||||||
Title: STATIC CONSTRUCTORS
|
Title: STATIC CONSTRUCTORS
|
||||||
Description: Need to call static constructors
|
Description: Need to call static constructors
|
||||||
|
Update: Static constructors are implemented for the STM32 F4 and
|
||||||
|
this will provide the model for all solutions. Basically, if
|
||||||
|
CONFIG_HAVE_CXXINITIALIZE=y is defined in the configuration, then
|
||||||
|
board-specific code must provide the interface up_cxxinitialize().
|
||||||
|
up_cxxinitialize() is called from user_start() to initialize
|
||||||
|
all static class instances. This TODO item probably has to stay
|
||||||
|
open because this solution is only available on STM32 F4.
|
||||||
Status: Open
|
Status: Open
|
||||||
Priority: Low, depends on toolchain. Call to gcc's built-in static
|
Priority: Low, depends on toolchain. Call to gcc's built-in static
|
||||||
constructor logic will probably have to be performed by
|
constructor logic will probably have to be performed by
|
||||||
@@ -462,7 +509,8 @@ o USB (drivers/usbdev, drivers/usbhost)
|
|||||||
|
|
||||||
Title: USB STORAGE DRIVER DELAYS
|
Title: USB STORAGE DRIVER DELAYS
|
||||||
Description: There is a workaround for a bug in drivers/usbdev/usbdev_storage.c.
|
Description: There is a workaround for a bug in drivers/usbdev/usbdev_storage.c.
|
||||||
that involves delays. This needs to be redesigned to eliminate these delays.
|
that involves delays. This needs to be redesigned to eliminate these
|
||||||
|
delays. See logic conditioned on CONFIG_USBMSC_RACEWAR.
|
||||||
Status: Open
|
Status: Open
|
||||||
Priority: Medium
|
Priority: Medium
|
||||||
|
|
||||||
@@ -565,6 +613,7 @@ o File system / Generic drivers (fs/, drivers/)
|
|||||||
|
|
||||||
Title: CAN POLL SUPPORT
|
Title: CAN POLL SUPPORT
|
||||||
Description: At present, the CAN driver does not support the poll() method.
|
Description: At present, the CAN driver does not support the poll() method.
|
||||||
|
See drivers/can.c
|
||||||
Status: Open
|
Status: Open
|
||||||
Priority: Low
|
Priority: Low
|
||||||
|
|
||||||
@@ -1302,9 +1351,6 @@ o MIPS/PIC32(arch/mips)
|
|||||||
Status: Open
|
Status: Open
|
||||||
Priority: High
|
Priority: High
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
o Hitachi/Renesas SH-1 (arch/sh/src/sh1)
|
o Hitachi/Renesas SH-1 (arch/sh/src/sh1)
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user