TODO

  Description: There is no mechanism in place to handle EP0 OUT data transfers.
               There are two aspects to this problem, neither are easy to fix
               (only because of the number of drivers that would be impacted):

               1. The class drivers only send EP0 write requests and these are
                  only queued on EP0 IN by this drivers.  There is never a read
                  request queued on EP0 OUT.
               2. But EP0 OUT data could be buffered in a buffer in the driver
                  data structure.  However, there is no method currently
                  defined in the USB device interface to obtain the EP0 data.

               Updates:  (1) The USB device-to-class interface as been extended so
               that EP0 OUT data can accompany the SETUP request sent to the
               class drivers. (2) The logic in the STM32 F4 OTG FS device driver
               has been extended to provide this data.  Updates are still needed
               to other drivers.

               Here is an overview of the required changes:
               New two buffers in driver structure:

               1. The existing EP0 setup request buffer (ctrlreq, 8 bytes)
               2. A new EP0 data buffer to driver state structure (ep0data,
                  max packetsize)

               Add a new state:

               3. Waiting for EP0 setup OUT data (EP0STATE_SETUP_OUT)

               General logic flow:

               1. When an EP0 SETUP packet is received:
                  - Read the request into EP0 setup request buffer (ctrlreq,
                    8 bytes)
                  - If this is an OUT request with data length, set the EP0
                    state to EP0STATE_SETUP_OUT and wait to receive data on
                    EP0.
                  - Otherwise, the SETUP request may be processed now (or,
                    in the case of the F4 driver, at the conclusion of the
                    SETUP phase).
               2. When EP0 the EP0 OUT DATA packet is received:
                  - Verify state is EP0STATE_SETUP_OUT
                  - Read the request into the EP0 data buffer (ep0data, max
                    packet size)
                  - Now process the previously buffered SETUP request along
                    with the OUT data.
               3. When the setup packet is dispatched to the class driver,
                  the OUT data must be passed as the final parameter in the
                  call.

               Update 2013-9-2:  The new USB device-side driver for the SAMA5D3
               correctly supports OUT SETUP data following the same design as
               per above.

               Update 2013-11-7: David Sidrane has fixed with issue with the
               STM32 F1 USB device driver.  Still a few more to go before this
               can be closed out.

  Status:      Open
  Priority:    High for class drivers that need EP0 data.  For example, the
               CDC/ACM serial driver might need the line coding data (that
               data is not used currently, but it might be).

  Title:       USB HUB SUPPORT
  Description: Add support for USB hubs
  Status:      Open
  Priority:    Low/Unknown.  This is a feature enhancement.

o Libraries (libc/)
  ^^^^^^^^^^^^^^^^^

  Title:       SIGNED time_t
  Description: The NuttX time_t is type uint32_t. I think this is consistent
               with all standards and with normal usage of time_t.  However,
               according to Wikipedia, time_t is usually implemented as a
               signed 32-bit value.
  Status:      Open
  Priority:    Very low unless there is some compelling issue that I do not
               know about.

  Title:       ENVIRON
  Description: The definition of environ in stdlib.h is bogus and will not
               work as it should.  This is because the underlying
               representation of the environment is not an arry of pointers.
  Status:      Open
  Priority:    Medium

  Title:       TERMIOS
  Description: Need some minimal termios support... at a minimum, enough to
               switch between raw and "normal" modes to support behavior like
               that needed for readline().
               UPDATE:  There is growing functionality in libc/termios/ and in the
               ioctl methods of several MCU serial drivers (stm32, lpc43, lpc17,
               pic32).  However, as phrased, this bug cannot yet be closed since
               this "growing functionality" does not address all termios.h
               functionality and not all serial drivers support termios.
  Status:      Open
  Priority:    Low

  Title:       DAYS OF THE WEEK
  Description: strftime() and other timing functions do not handle days of the week.
  Status:      Open
  Priority:    Low

  Title:       RESETTING GETOPT()
  Description: There is an issue with the way that getopt() handles errors that
               return '?'.

               1. Does getopt() reset its global variables after returning '?' so
                  that it can be re-used?  That would be required to support where
                  the caller terminates parsing before reaching the last parameter.
               2. Or is the client expected to continue parsing after getopt()
                  returns '?'  and parse until the final parameter?

               The current getopt() implementation only supports #2.
  Status:      Open
  Priority:    Low

  Title:       CONCURRENT STREAM READ/WRITE
  Description: NuttX only supports a single file pointer so reads and writes
               must be from the same position.  This prohibits implementation
               of behavior like that required for fopen() with the "a+" mode.
               According to the fopen man page:

               "a+ Open for reading and appending (writing at end of file).
                The file is created if it does not exist. The initial file
                position for reading is at the beginning of the file, but
                output is always appended to the end of the file."

               At present, the single NuttX file pointer is positioned to the
               end of the file for both reading and writing.
  Status:      Open
  Priority:    Medium.  This kind of operation is probably not very common in
               deeply embedded systems but is required by standards.

  Title:       DIVIDE BY ZERO
  Description: This is bug 3468949 on the SourceForge website (submitted by
               Philipp Klaus Krause):
               "lib_strtod.c does contain divisions by zero in lines 70 and 96.
                AFAIK, unlike for Java, division by zero is not a reliable way to
                get infinity in C. AFAIK compilers are allowed e.g. give a compile-
                time error, and some, such as sdcc, do. AFAIK, C implementations
                are not even required to support infinity. In C99 the macro isinf()
                could replace the first use of division by zero. Unfortunately, the
                macro INFINITY from math.h probably can't replace the second division
                by zero, since it will result in a compile-time diagnostic, if the
                implementation does not support infinity."
  Status:       Open
  Priority:

  Title:       OLD dtoa NEEDS TO BE UPDATED
  Description: This implementation of dtoa in libc/stdio is old and will not
               work with some newer compilers.  See
               http://patrakov.blogspot.com/2009/03/dont-use-old-dtoac.html
  Status:      Open
  Priority:    ??

  Title:       FLOATING POINT FORMATS
  Description: Only the %f floating point format is supported.  Others are accepted
               but treated like %f.
  Status:      Open
  Priority:    Medium (this might important to someone).

  Title:       FLOATING POINT PRECISION
  Description: A fieldwidth and precision is required with the %f format.  If %f
               is used with no format, than floating numbers will be printed with
               a precision of 0 (effectively presented as integers).
  Status:      Open
  Priority:    Medium (this might important to someone).

  Title:       LIBM INACCURACIES
  Description: "..if you are writing something like robot control or
               inertial navigation system for aircraft, I have found
               that using the toolchain libmath is only safe option.
               I ported some code for converting quaternions to Euler
               angles to NuttX for my project and only got it working
               after switching to newlib math library.

               "NuttX does not fully implement IEC 60559 floating point
               from C99 (sections marked [MX] in OpenGroup specs) so if
               your code assumes that some function, say pow(), actually
               behaves right for all the twenty or so odd corner cases
               that the standards committees have recently specified,
               you might get surprises. I'd expect pow(0.0, 1.0) to
               return 0.0 (as zero raised to any positive power is
               well-defined in mathematics) but I get +Inf.

               "NuttX atan2(-0.0, -1.0) returns +M_PI instead of correct
               -M_PI. If we expect [MX] functionality, then atan2(Inf, Inf)
               should return M_PI/4, instead NuttX gives NaN.

               "asin(2.0) does not set domain error or return NaN. In fact
               it does not return at all as the loop in it does not
               converge, hanging your app.

               "There are likely many other issues like these as the Rhombs
               OS code has not been tested or used that much. Sorry for not
               providing patches, but we found it easier just to switch the
               math library."

               Ref: https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/7805
Status:        Open
Priority:      Low for casual users but clearly high if you need care about
               these incorrect corner case behaviors in the math libraries.

o File system / Generic drivers (fs/, drivers/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  NOTE:  The NXFFS file system has its own TODO list at nuttx/fs/nxffs/README.txt

  Title:       CHMOD() AND TRUNCATE()
  Description: Implement chmod(), truncate().
  Status:      Open
  Priority:    Low

  Title:       CAN POLL SUPPORT
  Description: At present, the CAN driver does not support the poll() method.
               See drivers/can.c
  Status:      Open
  Priority:    Low

  Title:       REMOVING PIPES AND FIFOS
  Description: There is no way to remove a FIFO or PIPE created in the
               pseudo filesystem.  Once created, they persist indefinitely
               and cannot be unlinked.  This is actually a more generic
               issue:  unlink does not work for anything in the pseudo-
               filesystem.
  Status:      Open, but partially resolved: pipe buffer is at least freed
               when there are not open references to the pipe/FIFO.
  Priority:    Medium

  Title:       ROMFS CHECKSUMS
  Description: The ROMFS file system does not verify checksums on either
               volume header on on the individual files.
  Status:      Open
  Priority:    Low.  I have mixed feelings about if NuttX should pay a
               performance penalty for better data integrity.

  Title:       SPI-BASED SD MULTIPLE BLOCK TRANSFERS
  Description: The simple SPI based MMCS/SD driver in fs/mmcsd does not
               yet handle multiple block transfers.
  Status:      Open
  Priority:    Medium-Low

  Title:       SDIO-BASED SD READ-AHEAD/WRITE BUFFERING INCOMPLETE
  Description: The drivers/mmcsd/mmcsd_sdio.c driver has hooks in place to
               support read-ahead buffering and write buffering, but the logic
               is incomplete and untested.
  Status:      Open
  Priority:    Low

  Title:       POLLHUP SUPPORT
  Description: All drivers that support the poll method should also report
               POLLHUP event when the driver is closed.
  Status:      Open
  Priority:    Medium-Low

  Title:       CONFIG_RAMLOG_CONSOLE DOES NOT WORK
  Description: When I enable CONFIG_RAMLOG_CONSOLE, the system does not come up
               properly (using configuration stm3240g-eval/nsh2).  The problem
               may be an assertion that is occurring before we have a console.
  Status:      Open
  Priority:    Medium

  Title:       UNIFIED DESCRIPTOR REPRESENTATION
  Descripton:  There are two separate ranges of descriptors for file and
               socket descriptors: if a descriptor is in one range then it is
               recognized as a file descriptor; if it is in another range
               then it is recognized as a socket descriptor.  These separate
               descriptor ranges can cause problems, for example, they makes
               dup'ing descriptors with dup2() problematic.  The two groups
               of descriptors are really indices into two separate tables:
               On an array of file structures and the other an array of
               socket structures.  There really should be one array that
               is a union of file and socket descriptors.  Then socket and
               file descriptors could lie in the same range.
  Status:      Open
  Priority:    Low

  Title:       DUPLICATE FAT FILE NAMES
  Description: "The NSH and POSIX API interpretations about sensitivity or
               insensitivity to upper/lowercase file names seem to be not
               consistent in our usage - which can result in creating two
               directories with the same name..."

               Example using NSH:

                 nsh> echo "Test1" >/tmp/AtEsT.tXt
                 nsh> echo "Test2" >/tmp/aTeSt.TxT
                 nsh> ls /tmp
                 /tmp:
                  AtEsT.tXt
                  aTeSt.TxT
                 nsh> cat /tmp/aTeSt.TxT
                 Test2
                 nsh> cat /tmp/AtEsT.tXt
                 Test1

  Status:      Open
  Priority:    Low

  Title:       FAT LONG FILENAME COMPATIBILTY
  Description: Recently there have been reports that file with long file
               names created by NuttX don't have long file names when viewed
               on Windows.  The long file name support has been around for a
               long time and I don't ever having seen this before so I am
               suspecting that some evil has crept in.
  Status:      Open
  Priority:    Medium

  Title:       MISSING FILES IN NSH 'LS' OF A DIRECTORY
  Description: I have seen cases where (1) long file names are enabled,
               but (2) a short file name is created like:

                 nsh> echo "This is another thest" >/mnt/sdcard/another.txt

               But then on subsequent 'ls' operations, the file does not appear:

                 nsh> ls -l /mnt/sdcard

               I have determined that the problem is because, for some as-
               of-yet-unkown reason the short file name is treated as a long
               file name.  The name then fails the long filename checksum
               test and is skipped.

               readdir() (and fat_readdir()) is the logic underlying the
               failure and the problem appears to be something unique to the
               fat_readdir() implementation.  Why?  Because the file is
               visible when you put the SD card on a PC and because this
               works fine:

                 nsh> ls -l /mnt/sdcard/another.txt

               The failure does not happen on all short file names.  I do
               not understand the pattern.  But I have not had the opportunity
               to dig into this deeply.
  Status:      Open
  Priority:    Perhaps not a problem???  I have analyzed this problem and
               I am not sure what to do about it.  I am suspected that a
               fat filesystem was used with a version of NuttX that does
               not support long file name entries.  Here is the failure
               scenario:

               1) A file with a long file name is created under Windows.
               2) Then the file is deleted.  I am not sure if Windows or
                  NuttX deleted the file, but the resulting directory
                  content is not compatible with NuttX with long file
                  name support.

                  The file deletion left the full sequence of long
                  file name entries intact but apparently delete only
                  the following short file name entry.  I am thinking
                  that this might have happened because a version of NuttX
                  with only short file name support was used to delete
                  the file.

               3) When a new file with a short file name was created, it
                  re-used the short file name entry that was previously
                  deleted.  This makes the new short file name entry
                  look like a part of the long file name.

               4) When comparing the checksum in the long file name
                  entry with the checksum of the short file name, the
                  checksum fails and the entire directlry sequence is
                  ignored by readder() logic.  This the file does not
                  appear in the 'ls'.

o Graphics subsystem (graphics/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  See also the NxWidgets TODO list file for related issues.

  Title:       UNTESTED GRAPHICS APIS
  Description: Testing of all APIs is not complete.  See
               http://nuttx.sourceforge.net/NXGraphicsSubsystem.html#testcoverage
  Status:      Open
  Priority:    Medium

  Title:       ITALIC FONTS / NEGATIVE FONT OFFSETS
  Description: Font metric structure (in include/nuttx/nx/nxfont.h) should allow
               negative X offsets. Negative x-offsets are necessary for certain
               glyphs (and is very common in italic fonts).
               For example Eth, icircumflex, idieresis, and oslash should have
               offset=1 in the 40x49b font (these missing negative offsets are
               NOTE'ed in the font header files).
  Status:      Open.  The problem is that the x-offset is an unsigned bitfield
               in the current structure.
  Priority:    Low.

  Title:       RAW WINDOW AUTORAISE
  Description: Auto-raise only applies to NXTK windows. Shouldn't it also apply
               to raw windows as well?
  Status:      Open
  Priority:    Low

  Title:       AUTO-RAISE DISABLED
  Description: Auto-raise is currently disabled in NX multi-server mode.  The
               reason is complex:
               - Most touchscreen controls send touch data a high rates
               - In multi-server mode, touch events get queued in a message
                  queue.
               - The logic that receives the messages performs the auto-raise.
                 But it can do stupid things after the first auto-raise as
                 it operates on the stale data in the message queue.
               I am thinking that auto-raise ought to be removed from NuttX
               and moved out into a graphics layer (like NxWM) that knows
               more about the appropriate context to do the autoraise.
  Status:      Open
  Priority:    Medium low

  Title:       IMPROVED NxTERM FONT CACHING
  Description: Now each NxTerm instance has its own private font cache
               whose size is determined by CONFIG_NXTERM_MXCHARS.  If there
               are multiple NxTerm instances using the same font, each will
               have a separate font cache.  This is inefficient and wasteful
               of memory:  Each NxTerm instance should share a common font
               cache.
  Status:      Open
  Priority:    Medium.  Not important for day-to-day testing but would be
               a critical improvement if NxTerm were to be used in a
               product.

  Title:       NxTERM VT100 SUPPORT
  Description: If the NxTerm will be used with the Emacs-like command line
               editor (CLE), then it will need to support VT100 cursor control
               commands.
  Status:      Open
  Priority:    Low, the need has not yet arisen.

  Title:       ANTI-ALIASING
  Description: Needed for proper rendering.  After some analysis, I believe
               this change would only be required in the the trapezoid
               rendering logic.  Essentially, it would need to blend the
               fractional pixels at ends of each run with the underlying
               pixel.

               Hmmm.. graphics are sometimes erased by just redrawing them
               with the background color.  Would this approach leave ghost
               images around where the erase image was?
  Status:      Open
  Priority:    Medium-ish.  This would definitely improve graphics rendering
               and line drawing.

  Title:       LINE JOINS
  Description: Lines are currently draw as rectangles with the width of the
               rectangle being the line width.  So when shapes, like circles,
               are drawn with fat lines, they do not join cleanly from
               segment to segment.

               The fix would be to draw a circle at each endpoint that has a
               radius equal to the width of the line.
  Status:      Open
  Priority:    Medium-ish.  This would definitely improve line drawing.

  Title:       PER-WINDOW FRAMEBUFFERS
  Description: One of the most awkard things to handle in the NX windowing
               system is the re-draw callback.  This is difficult because it
               requires ad hoc, custom logic to be able to do the redrawing
               in most cases.

               One solution would be to provide a per-window framebuffer.
               All rending would be performed into the per-window framebuffer
               and the rended bits would be copied the LCD or framebuffer
               device memory on demand when the redraw is required.

               This would (a) greatly simplify the graphics interface, (b)
               greatly improve redraw performance, and (c) enable a more
               generic use of the windowing.  The downside would be a large
               usage of memory to hold all of the framebuffers, one for each
               window.
  Status:      Open
  Priority:    Low, of mostly strategic value.

o Pascal Add-On (pcode/)
  ^^^^^^^^^^^^^^^^^^^^^^

  Title:       P-CODES IN MEMORY UNTESTED
  Description: Need APIs to verify execution of P-Code from memory buffer.
  Status:      Open
  Priority:    Low

  Title:       SMALLER LOADER AND OBJECT FORMAT
  Description: Loader and object format may be too large for some small
               memory systems.  Consider ways to reduce memory footprint.
  Status:      Open
  Priority:    Medium

  Title:       PDBG
  Description: Move the the pascal p-code debugger into the NuttX apps/ tree
               where it can be used from the NSH command line.
  Status:      Open
  Priority:    Low

o Documentation (Documentation/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       DOCUMENT APIS USABLE FROM INTERRUPT HANDLERS
  Description: Need to document which APIs can be used in interrupt
               handlers (like mq_send and sem_post) and which cannot.
  Status:      Open
  Priority:    Low

o Build system
  ^^^^^^^^^^^^

  Title:       WINDOWS DEPENDENCY GENERATION
  Description: Dependency generation is currently disabled when a Windows native
               toolchain is used in a POSIX-like environment (like Cygwin).  The
               issue is that the Windows tool generates dependencies use Windows
               path formatting and this fails with the dependency file (Make.dep)
               is include).  Perhaps the only issue is that all of the Windows
               dependencies needed to be quoted in the Make.dep files.
  Status:      Open
  Priority:    Low -- unless some dependency-related build issues is discovered.

  Title:       MAKE EXPORT LIMITATIONS
  Description: The top-level Makefile 'export' target that will bundle up all of the
               NuttX libraries, header files, and the startup object into an export-able
               tarball. This target uses the tools/mkexport.sh script.  Issues:

               1. This script assumes the host archiver ar may not be appropriate for
                  non-GCC toolchains
               2. For the kernel build, the user libraries should be built into some
                  libuser.a.  The list of user libraries would have to accepted with
                  some new argument, perhaps -u.
  Status:      Open
  Priority:    Low.

o Linux/Cywgin simulation (arch/sim)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       SIMULATOR NETWORKING SUPPORT
  Description: I never did get networking to work on the sim Linux target.  On Linux,
               it tries to use the tap device (/dev/net/tun) to emulate an Ethernet
               NIC, but I never got it correctly integrated with the NuttX networking.
               NOTE: On Cygwin, the build uses the Cygwin WPCAP library and is, at
               least, partially functional (it has never been rigorously tested).
  Status:      Open
  Priority:    Low (unless you want to test networking features on the simulation).

  Title:       SIMULATOR HAS NO INTERRUPTS (NON-PREMPTIBLE)
  Description: The current simulator implementation is has no interrupts and, hence,
               is non-preemptible.  Also, without simulated interrupt, there can
               be no high-fidelity simulated device drivers.

               Currently, all timing and serial input is simulated in the IDLE loop:
               When nothing is going on in the simulation, the IDLE loop runs and
               fakes timer and UART events.
  Status:      Open
  Priority:    Low, unless there is a need for developing a higher fidelity simulation
               I have been thinking about how to implement simulated interrupts in
               the simulation.  I think a solution would work like this:
               http://www.nuttx.org/doku.php?id=wiki:nxinternal:simulator

  Title:       ROUND-ROBIN SCHEDULING IN THE SIMULATOR
  Description: Since the simulation is not pre-emptible, you can't use round-robin
               scheduling (no time slicing).  Currently, the timer interrupts are
               "faked" during IDLE loop processing and, as a result, there is no
               task pre-emption because there are no asynchronous events.  This could
               probably be fixed if the "timer interrupt" were driver by Linux
               signals. NOTE:  You would also have to implement irqsave() and
               irqrestore() to block and (conditionally) unblock the signal.
  Status:      Open
  Priority:    Low

o ARM (arch/arm/)
  ^^^^^^^^^^^^^^^

  Title:       IMPROVED ARM INTERRUPT HANDLING
  Description: ARM interrupt handling performance could be improved in some
               ways. One easy way is to use a pointer to the context save
               area in current_regs instead of using up_copystate so much.

               This approach is already implemented for the ARM Cortex-M0,
               Cortex-M3, Cortex-M4, and Cortex-A5 families.  But still needs
               to be back-ported to the ARM7 and ARM9 (which are nearly
               identical to the Cortex-A5 in this regard).  The change is
               *very* simple for this architecture, but not implemented.
  Status:      Open.  But complete on all ARM platforms except ARM7 and ARM9.
  Priority:    Low.

  Title:       IMPROVED ARM INTERRUPT HANDLING
  Description: The ARM and Cortex-M3 interrupt handlers restores all registers
               upon return. This could be improved as well:  If there is no
               context switch, then the static registers need not be restored
               because they will not be modified by the called C code.
               (see arch/sh/src/sh1/sh1_vector.S for example)
  Status:      Open
  Priority:    Low

  Title:       CORTEX-M3 STACK OVERFLOW
  Description: There is bit bit logic in up_fullcontextrestore() that executes on
               return from interrupts (and other context switches) that looks like:

                 ldr r1, [r0, #(4*REG_CPSR)] /* Fetch the stored CPSR value */
                 msr cpsr, r1 /* Set the CPSR */

                 /* Now recover r0 and r1 */

                 ldr r0, [sp]
                 ldr r1, [sp, #4]
                 add sp, sp, #(2*4)

                 /* Then return to the address at the stop of the stack,
                  * destroying the stack frame
                  */

                 ldr pc, [sp], #4

               Under conditions of excessively high interrupt conditions, many
               nested interrupts can occur just after the 'msr cpsr' instruction.
               At that time, there are 4 bytes on the stack and, with each
               interrupt, the stack pointer may increment and possibly overflow.

               This can happen only under conditions of continuous interrupts.
               See this email thread: https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/1261
               On suggested change is:

                 ldr  r1, [r0, #(4*REG_CPSR)] /* Fetch the stored CPSR value */
                 msr spsr_cxsf, r1 /* Set the CPSR */
                 ldmia     r0, {r0-r15}^

               But this has not been proven to be a solution.

               UPDATE:  Other ARM architectures have a similer issue.

  Status:      Open
  Priority:    Low.  The conditions of continuous interrupts is really the problem.
               If your design needs continuous interrupts like this, please try
               the above change and, please, submit a patch with the working fix.

  Title:       STACK ALIGNMENT IN INTERRUPT HANDLERS
  Description: The EABI standard requires that the stack always have a 32-byte
               alignment.  There is no guarantee at present that the stack will be
               so aligned in an interrupt handler.  Therefore, I would expect some
               issues if, for example, floating point or perhaps long long operations
               were performed in an interrupt handler.

               This issue exists for ARM7, ARM9, Cortex-M0, Cortex-M3, and
               Cortex-M4 but has been addressed for the Cortex-A5.  The fix
               is really simple can cannot be incorporated without some
               substantial testing.  For ARM, the fix is the following logic
               arround each call into C code from assembly:

                 mov  r4, sp     /* Save the SP in a preserved register */
                 bic  sp, sp, #7 /* Force 8-byte alignment */
                 bl   cfunction  /* Call the C function */
                 mov  sp, r4     /* Restore the possibly unaligned stack pointer */

               This same issue applies to the interrupt stack which is, I think
               improperly aligned in almost all cases (except Cortex-A5).

  Status:      Open
  Priority:    Low for me because I never do floating point operations in
               interrupt handlers.

  Title:       IMPROVED TASK START-UP AND SYSCALL RETURN
  Description: Couldn't up_start_task and up_start_pthread syscalls be
               eliminated.  Wouldn't this work to get us from kernel-
               to user-mode with a system trap:

                 lda r13, #address
                 str rn, [r13]
                 msr spsr_SVC, rm
                 ld r13,{r15}^

               Would also need to set r13_USER and r14_USER. For new SYS_context_switch... couldn't we do he same thing?

               Also... System calls use traps to get from user- to kernel-
               mode to perform OS services.  That is necessary to get from
               user- to kernel-mode.  But then another trap is used to get
               from kernel- back to user-mode.  It seems like this second
               trap should be unnecessary.  We should be able to do the
               same kind of logic to do this.
  Status:      Open
  Priority:    Low-ish, but a good opportunity for performance improvement.

o ARM/C5471 (arch/arm/src/c5471/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       UART RECONFIGURATION
  Description: UART re-configuration is untested and conditionally compiled out.
  Status:      Open
  Priority:    Medium.  ttyS1 is not configured, but not used; ttyS0 is configured
               by the bootloader

o ARM/DM320 (arch/arm/src/dm320/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       DEBUG ISSUES
  Description: config/ntos-dm320: It seems that when a lot of debug statements
               are added, the system no longer boots.  This is suspected to be
               a stack problem: Making the stack bigger or removing arrays on
               the stack seems to fix the problem (might also be the
               bootloader overwriting memory)
  Status:      Open
  Priority:    Medium

  Title:       USB DEVICE DRIVER UNTESTED
  Description: A USB device controller driver was added but has never been tested.
  Status:      Open
  Priority:    Medium

  Title:       FRAMEBUFFER DRIVER UNTESTED
  Description: A framebuffer "driver" was added, however, it remains untested.
  Status:      Open
  Priority:    Medium

  Title:       VIDEO ENCODER DRIVER
  Description: In order to use the framebuffer "driver" additional video encoder
               logic is required to setup composite video output or to interface
               with an LCD.
  Status:      Open
  Priority:    Medium (high if you need to use the framebuffer driver)

o ARM/i.MX (arch/arm/src/imx/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       PORT IS INCOMPLETE
  Description: The basic port of the i.MX1 architecture was never finished.  The port
               is incomplete (as of this writing, is still lacks a timer, interrupt
               decoding, USB, network) and untested.
  Status:      Open
  Priority:    Medium (high if you need i.MX1/L support)

  Title:       SPI METHODS ARE NOT THREAD SAFE
  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
  Status:      Open
  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.

o ARM/LPC17xx (arch/arm/src/lpc17xx/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       USB DMA INCOMPLETE
  Description: USB DMA not fully implemented. Partial logic is in place but it is
               fragmentary and bogus. (Leveraged from the lpc214x)
  Status:      Open
  Priority:    Low

  Title:       SSP DRIVER IMPROVEMENTS
  Description: a) At present the SSP driver is polled.  Should it be interrupt driven?
                  Look at arch/arm/src/imx/imx_spi.c -- that is a good example of an
                  interrupt driven SPI driver.  Should be very easy to part that architecture
                  to the LPC.
               b) See other SSP (SPI) driver issues listed under ARM/LPC214x.  The LPC17xx
                  driver is a port of the LPC214x driver and probably has the same issues.
               b) Other SSP driver improvements: Add support for multiple devices on the
                  SSP bus, use DMA data transfers
  Status:      Open
  Priority:    Medium

  Title:       NOKIA LCD DRIVER NONFUNCTIONAL
  Description: An LCD driver for the Olimex LPC1766STK has been developed.  However, that
               driver is not yet functional on the board:  The backlight comes on, but
               nothing is visible on the display.
  Status:      Open
  Priority:    Medium-Low (unless you need the display on the LPC1766STK!)

o ARM/LPC214x (arch/arm/src/lpc214x/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       VECTOR INTERRUPTS
  Description: Should use Vector Interrupts
  Status:      Open
  Priority:    Low

  Title:       USB DMA INCOMPLETE
  Description: USB DMA not fully implemented. Partial logic is in place but it is
               fragmentary and bogus.
  Status:      Open
  Priority:    Low

  Title:       USB SERIAL DRIVER REPORTS WRONG ERROR
  Description: USB Serial Driver reports wrong error when opened before the
               USB is connected (reports EBADF instead of ENOTCONN)
  Status:      Open
  Priority:    Low

  Title:       SPI DRIVER IMPROVEMENTS
  Description: At present the SPI driver is polled.  Should it be interrupt driven?
               Look at arch/arm/src/imx/imx_spi.c -- that is a good example of an
               interrupt driven SPI driver.  Should be very easy to part that architecture
               to the LPC.
  Status:      Open
  Priority:    Medium

  Title:       SPI METHODS ARE NOT THREAD SAFE
  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
  Status:      Open
  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.

  Title:       SPI DRIVER DELAYS
  Description: At present the SPI driver is polled -AND- there is a rather large, arbitrary,
               delay in one of the block access routines.  The purpose of the delay is to
               avoid a race conditions.  This begs for a re-design -OR- at a minimum, some
               optimization of the delay time.
  Status:      Open
  Priority:    Medium

  Title:       2GB SD CARD ISSUES
  Desription:  I am unable to initialize a 2Gb SanDisk microSD card (in adaptor) on the
               the mcu123 board.  The card fails to accept CMD0.  Doesn't seem like a software
               issue, but if anyone else sees the problem, I'd like to know.
               Related:  Fixes were recently made for the SDIO-based MMC/SD driver to
               support 2Gb cards -- the block size was forced to 512 in all cases.  The SPI-
               based driver may also have this problem (but I don't think this would have
               anything to do with CMD0).
  Status:      Open
  Priority:    Uncertain

  Title:       USB BROKEN?
  Description: I tried to bring up the new configuration at configs/mcu123-214x/composite,
               and Linux failed to enumerate the device.  I don't know if this is
               a problem with the lpc214x USB driver (bit rot), or due to recent
               changed (e.g., -r4359 is suspicious), or an incompatibility between the
               Composite driver and the LPC214x USB driver.  It will take more work
               to find out which -- like checking if the other USB configurations are
               also broken.
  Status:      Open
  Priority:    It would be high if the LPC2148 were a current, main stream architecture.
               I am not aware of anyone using LPC2148 now so I think the priority has
               to be low.

o ARM/LPC31xx (arch/arm/src/lpc31xx/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       PLATFORM-SPECIFIC LOGIC
  Description: arch/arm/src/lpc313x/lpc313x_spi.c contains logic that is specific to the
               Embedded Artist's ea3131 board.  We need to abstract the assignment of SPI
               chip selects and logic SPI functions (like SPIDEV_FLASH).  My thoughts are:
               - Remove lpc313x_spiselect and lpc313x_spistatus from lpc313x_internal.h
               - Remove configs/ea3131/src/up_spi.c
               - Add configurations CONFIG_LPC3131x_CSOUT1DEV, CONFIG_LPC3131x_CSOUT2DEV,
                 and CONFIG_LPC3131x_CSOUT3DEV that maps the lpc313x SPI chip selects to
                 SPIDEV_* values.
               - Change arch/arm/src/lpc313x/lpc313x_spi.c to use those configuration
                 settings.
  Status:      Open
  Priority:    High if you want to use SPI on any board other than the ea3131.

  Title:       SPI DRIVER
  Description: arch/arm/src/lpc313x/lpc313x_spi.c may or may not be functional.  It was
               reported to be working, but I was unable to get it working with the
               Atmel at45dbxx serial FLASH driver.
  Status:      Open
  Priority:    High if you need to use SPI.

o ARM/LPC43x (arch/arm/src/lpc43xx/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  See comments in configs/lpc4330-xplorer/README.txt

o ARM/STR71x (arch/arm/src/str71x/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       UNVERIFIED MMC SUPPORT
  Description: Verify SPI driver and integrate with MMC support. This effort is stalled
               at the moment because the slot on the Olimex board only accepts MMC card;
               I have no MMC cards, only SD cards which won't fit into the slot.
  Status:      Open
  Priority:    Medium

  Title:       SPI METHODS ARE NOT THREAD SAFE
  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
  Status:      Open
  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.

o ARM/LM3S6918 (arch/arm/src/tiva/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       SSI OVERRUNS
  Description: Should terminate SSI/SPI transfer if an Rx FIFO overrun occurs.
               Right now, if an Rx FIFO overrun occurs, the SSI driver hangs.
  Status:      Open
  Priority:    Medium, If the transfer is properly tuned, then there should not
               be any Rx FIFO overruns.

  Title:       THTTPD BUGS
  Description: There are some lingering bugs in THTTPD, possibly race conditions.  This
               is covered above under Network Utilities, but is duplicated here
               to point out that the LM3S suffers from this bug.
  Status:      Open.
               UPDATE: I have found that increasing the size of the CGI program stack
               from 1024 to 2048 (on the LM3S) eliminates the problem.  So the most
               likely cause is probably a stack overflow, not a hard software bug.
  Priority:    Probably Low

o ARM/SAMA5D3 ((arch/arm/src/sama5/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Issues related to the SAMA5D3 port are in configs/sama5d3x-ek/README.txt.

o ARM/STM32 (arch/arm/src/stm32/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       USBSERIAL ISSUES
  Description  A USB device-side driver is in place but not well tested.  At
               present, the apps/examples/usbserial test sometimes fails.  The situation
               that causes the failure is:

               - Host-side of the test started after the target side sends the
                 first serial message.

               The general failure is as follows:

               - The target message pends in the endpoint packet memory
               - When the host-side of the test is stated, it correctly
                 reads this pending data.
               - an EP correct transfer interrupt occurs and the next
                 pending outgoing message is setup
               - But, the host never receives the next message

               If the host-side driver is started before the first target message
               is sent, the driver works fine.
  Status:      Open
  Priority:    Medium-High

  Title:       DMA EXTENSIONS F1/3
  Description: DMA logic needs to be extended.  DMA2, Channel 5, will not work
               because the DMA2 channels 4 & 5 share the same interrupt.
  Status:      Open
  Priority:    Low until someone needs DMA1, Channel 5 (ADC3, UART4_TX, TIM5_CH1, or
               TIM8_CH2).

  Title:       F4 SDIO MULTI-BLOCK TRANSFER FAILURES
  Description: If you use a large I/O buffer to access the file system, then the
               MMCSD driver will perform multiple block SD transfers.  With DMA
               ON, this seems to result in CRC errors detected by the hardware
               during the transfer.  Workaround:  CONFIG_MMCSD_MULTIBLOCK_DISABLE=y.
  Status:      Open
  Priority:    Medium

  Title:       DMA BOUNDARY CROSSING
  Description: I see this statement in the reference manual:  "The burst
               configuration has to be selected in order to respect the AHB protocol,
               where bursts must not cross the 1 KB address boundary because the
               minimum address space that can be allocated to a single slave
               is 1 KB. This means that the 1 KB address boundary should not be crossed
               by a burst block transfer, otherwise an AHB error would be generated,
               that is not reported by the DMA registers."

               The implication is that there may be some unenforced alignment
               requirements for some DMAs.  There is nothing in the DMA driver to
               prevent this now.
  Status:      Open
  Priority:    Low (I am not even sure if this is a problem yet).

  Title:       DMA FROM EXTERNAL, FSMC MEMORY
  Description: I have seen a problem on F1 where all SDIO DMAs work exist for
               write DMAs from FSMC memory (i.e., from FSMC memory to SDIO).
               Read transfers work fine (SDIO to FSMC memory).  The failure is
               a data underrun error with zero bytes of data transferred.  The
               workaround for now is to use DMA buffers allocated from internal
               SRAM.
  Status:      Open
  Priority:    Low

o AVR (arch/avr)
  ^^^^^^^^^^^^^^

  Title:        AMBER WEB SERVER UNTESTED
  Description:  There is a port for the Amber Web Server ATMega128, however this is
                completely untested due to the lack to compatible, functional test
                equipment.
  Status:       Open
  Priority:     The priority might as well be low since there is nothing I can do about
                it anyway.

  Title:        STRINGS IN RAM
  Description:  Many printf-intensive examples (such as the OS test) cannot be executed
                on most AVR platforms.  The reason is because these tests/examples
                generate a lot of string data.  The build system currently places all
                string data in RAM and the string data can easily overflow the tiny
                SRAMs on these parts.  A solution would be to put the string data
                into the more abundant FLASH memory, but this would require modification
                to the printf logic to access the strings from program memory.
  Status:       Open
  Priority:     Low.  The AVR is probably not the architecture that you want to use
                for extensive string operations.

  Title:        SPI AND USB DRIVERS UNTESTED
  Description:  An SPI driver and a USB device driver exist for the AT90USB (as well
                as a USB mass storage example).  However, this configuration is not
                fully debugged as of the NuttX-6.5 release.
                Update 7/11:  (1) The SPI/SD driver has been verified, however, (2) I
                believe that the current teensy/usbmsc configuration uses too
                much SRAM for the system to behave sanely.  A lower memory footprint
                version of the mass storage driver will be required before this can
                be debugged
  Status:       Open
  Priority:     Medium-High.

  Title:        AVR32 PORT IS NOT FULLY TESTED
  Description:  A complete port for the AVR32 is provided and has been partially
                debugged.  There may still be some issues with the serial port
                driver.
  Status:       Open
  Priority:     Medium

o Intel x86 (arch/x86)
  ^^^^^^^^^^^^^^^^^^^^