Newer
Older
NuttX TODO List (Last updated September 12, 2011)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This file summarizes known NuttX bugs, limitations, inconsistencies with
standards, things that could be improved, and ideas for enhancements.
patacongo
committed
(5) Task/Scheduler (sched/)
(1) Memory Managment (mm/)
(2) USB (drivers/usbdev, drivers/usbhost)
(5) Build system / Toolchains
(2) ARM/i.MX (arch/arm/src/imx/)
(4) ARM/STM32 (arch/arm/src/stm32/)
(2) Hitachi/Renesas SH-1 (arch/sh/src/sh1)
(4) Renesas M16C/26 (arch/sh/src/m16c)
apps/
(5) Network Utilities (apps/netutils/)
(5) NuttShell (NSH) (apps/nshlib)
(5) Other Applications & Tests (apps/examples/)
o Task/Scheduler (sched/)
^^^^^^^^^^^^^^^^^^^^^^^
Description: When a tasks exits, shouldn't all of its child pthreads also be
terminated?
Status: Open
Priority: Medium, required for good emulation of process/pthread model.
Description: atexit() supports registration of only single function called on
exit(). It should support multiple functions registered by atexit()
or onexit() and these should be called in reverse order of
registration when the task exits.
Priority: Low
Description: Implement sys/mman.h and functions
Status: Open
Priority: Low
Description: Implement sys/wait.h and functions. Consider implementing wait,
waitpid, waitid. At present, a parent has no information about
child tasks.
Update: A simple but usable version of waitpid() has been included.
This version is not compliant with all specifications and can be
enabled with CONFIG_SCHED_WAITPID.
Status: Open
Priority: Low
Description: Several APIs do not set errno. Need to review all APIs.
Status: Open
Priority: Medium, required for standard compliance (but makes the
code bigger)
o On-demand paging (sched/)
^^^^^^^^^^^^^^^^^^^^^^^^^
Description: On-demand paging has recently been incorporated into the RTOS.
The design of this feature is described here:
http://www.nuttx.org/NuttXDemandPaging.html.
As of this writing, the basic feature implementation is
complete and much of the logic has been verified. The test
harness for the feature exists only for the NXP LPC3131 (see
configs/ea3131/pgnsh and locked directories). There are
some limitations of this testing so I still cannot say that
the feature is fully functional.
o Other core OS logic
^^^^^^^^^^^^^^^^^^^
Description: get_environ_ptr() (sched/sched_getenvironptr.c) is not implemented.
The representation of the the environment strings selected for
NutX is not compatible with the operation. Some significant
re-design would be required to implement this funcion and that
effort is thought to be not worth the result.
Status: Open
Priority: Low -- There is no plan to implement this.
Description: timer_getoverrun() (sched/timer_getoverrun.c) is not implemented.
Status: Open
Priority: Low -- There is no plan to implement this.
o Memory Managment (mm/)
^^^^^^^^^^^^^^^^^^^^^^
Description: Add an option to free all memory allocated by a task when the
task exits. This is probably not be worth the overhead for a
deeply embedded system.
There would be complexities with this implementation as well
because often one task allocates memory and then passes the
memory to another: The task that "owns" the memory may not
be the same as the task that allocated the memory.
Status: Open
Priority: Medium/Low, a good feature to prevent memory leaks but would
have negative impact on memory usage and code size.
o Signals (sched/, arch/)
^^^^^^^^^^^^^^^^^^^^^^^
Description: 'Standard' signals and signal actions are not supported.
(e.g., SIGINT, SIGCHLD, SIGSEGV, etc).
Status: Open
Priority: Low, required by standards but not so critical for an
embedded system.
Description: sig_notify() logic does not support SIGEV_THREAD; structure
struct sigevent does not provide required members sigev_notify_function
or sigev_notify_attributes.
Status: Low, there are alternative designs. However, these features
are required by the POSIX standard.
Priority: Low for now
o pthreads (sched/)
^^^^^^^^^^^^^^^^^
Description: pthread_cancel(): Should implement cancellation points and
pthread_testcancel()
Status: Open
Priority: Low, probably not that useful
^^^^^^^^^^^
Description: Need to call static constructors
Status: Open
Priority: Low, depends on toolchain. Call to gcc's built-in static
constructor logic will probably have to be performed by
user logic in user_start().
Description: Not all of the NXFLAT test under apps/examples/nxflat are working.
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
Most simply do not compile yet. tests/mutex runs okay but
outputs garbage on completion.
Status: Open
Priority: High
Description: The ARM up_getpicbase() does not seem to work. This means
the some features like wdog's might not work in NXFLAT modules.
Status: Open
Priority: Medium-High
Description: At present, all .rodata must be put into RAM. There is a
tentative design change that might allow .rodata to be placed
in FLASH (see Documentation/NuttXNxFlat.html).
Status: Open
Priority: Medium
Description: If the function pointer to a statically defined function is
taken, then GCC generates a relocation that cannot be handled
by NXFLAT. There is a solution described in Documentataion/NuttXNxFlat.html,
by that would require a compiler change (which we want to avoid).
The simple workaround is to make such functions global in scope.
Status: Open
Priority: Low (probably will not fix)
Description: In the NXFLAT symbol tables... Using a 32-bit hash value instead
of a string to identify a symbol should result in a smaller footprint.
Status: Open
Priority: Low
Description: Windows build issue. Some of the configurations that use NXFLAT have
the linker script specified like this:
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld -no-check-sections
That will not work for windows-based tools because they require Windows
style paths. The solution is to do something like this:
if ($(WINTOOL)y)
NXFLATLDSCRIPT=${cygpath -w $(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld}
else
NXFLATLDSCRIPT=$(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld
endif
Then use
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T"$(NXFLATLDSCRIPT)" -no-check-sections
Status: Open
Priority: There are too many references like the above. They will have
to get fixed as needed for Windows native tool builds.
Description: Should implement SOCK_RAW, SOCK_PACKET
Status: Open
Priority: Low
Description: uIP polling issues / Multiple network interface support:
(1) Current logic will not support multiple ethernet drivers.
Each driver should poll on TCP connections connect on the
network supported by the driver; UDP polling should respond
with TX data only if the UDP packet is intended for the
the network supported by the driver.
(2) If there were multiple drivers, polling would occur at
double the rate. Fix by using bound IP address in TCP
connection (lipaddr) and verifying that it is in the subnet
served by the driver.
Status: Open
Priority: Medium, The feature is not important, but it is important
for NuttX to resolve the architectural issues.
Description: sendto() and multiple network interface support:
When polled, would have to assure that the destination IP
is on the subnet served by the polling driver.
Status: Open
Priority: Medium, The feature is not important, but it is important
for NuttX to resolve the architectural issues.
Description: IPv6 support is incomplete. Adam Dunkels has recently announced
IPv6 support for uIP (currently only as part of Contiki). Those
changes need to be ported to NuttX.
Status: Open
Priority: Medium
Description: Incoming UDP broadcast should only be accepted if listening on
INADDR_ANY(?)
Status: Open
Priority: Low
Description: Read-ahead buffers capture incoming TCP data when no user
thread is recv-ing the data. Should add some driver call to
support throttling; when there is no listener for new data, the
driver should be throttled. Perhaps the driver should disable
RX interrupts when throttled and re-anable on each poll time.
recvfrom would, of course, have to un-throttle.
Status: Open
Priority: Medium
Description: Need to standardize collection of statistics from network
drivers. apps/nshlib ifconfig command should present
Description: At present, there cannot be two concurrent active TCP send
operations in progress using the same socket. This is because
the uIP ACK logic will support only one transfer at a time. The
solution is simple: A mutex will be needed to make sure that each
send that is started is able to be the exclusive sender until all of
the data to be sent has been ACKed.
Status: Open. There is some temporary logic to apps/nshlib that does
this same fix and that temporary logic should be removed when
send() is fixed.
Priority: Medium-Low. This is an important issue for applications that
send on the same TCP socket from multiple threads.
Description: TCP supports read-ahead buffering to handle the receipt of
TCP/IP packets when there is no read() in place. Should such
capability be useful for UDP? PRO: Would reduce packet loss
and enable support for poll()/select(). CON: UDP is inherently
lossy so why waste memory footprint?
Status: Open
Priority: Medium
Description: poll()/select() is not implemented for UDP sockets because they do
do not support read-ahead buffering. Therefore, there is never
a case where you can read from a UDP socket without blocking.
Status: Open, depends on UDP read-ahead support
Priority: Medium
Description: poll()/select() only works for availability of buffered TCP
read data (when read-ahead is enabled). The way writing is
handled in uIP, all sockets must wait when send and cannot
be notifiied when they can send without waiting.
Status: Open, probably will not be fixed.
Priority: Medium... this does effect porting of applications that expect
different behavior from poll()/select()
Description: sockets do not support all modes except for O_NONBLOCK. Sockets
support only (1) TCP/IP non-blocking read operations when read-ahead
buffering is enabled, and (2) TCP/IP accept() operations when TCP/IP
connection backlog is enabled.
Status: Open
Priority: Low.
Description: I started coding a CrystalLan CS89x0 driver (drivers/net/cs89x0.c),
but never finished it.
Status: Open
Priority: Low unless you need it.
Description: So far, I have not come up with a usable hardware platform to
verify the ENC28J60 Ethernet driver (drivers/net/enc28j60.c).
So it is untested.
Status: Open
Priority: Low unless you need it.
Description: Support for client-side IGMPv2 multicast has been added but not yet
tested (because I don't have a proper environment for multicast testing).
There are most likely errors that need to be fixed at least in the
receipt of multicast packets.
In addition, an ethernet driver that needs to work with the IGMP logic
will have to include additional support for multicast MAC address tables.
Status: Open
Priority: Low unless you need it.
Description: The interfaces used to leave/join IGMP multicast groups is non-standard.
RFC3678 (IGMPv3) suggests ioctl() commands to do this (SIOCSIPMSFILTER) but
also status that those APIs are historic. NuttX implements these ioctl
commands, but is non-standard because: (1) It does not support IGMPv3, and
(2) it looks up drivers by their device name (eg., "eth0") vs IP address.
Linux uses setsockopt() to control multicast group membership using the
IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP options. It also looks up drivers
using IP addresses (It would require additional logic in NuttX to look up
drivers by IP address). See http://tldp.org/HOWTO/Multicast-HOWTO-6.html
Status: Open
Priority: Medium. All standards compatibility is important to NuttX. However, most
the mechanism for leaving and joining groups is hidden behind a wrapper
function so that little of this incompatibilities need be exposed.
Description: Many configurations have the MTU (CONFIG_NET_BUFSIZE) set to very small
numbers, less then the minimum MTU size that must be supported -- 576.
This can cause problems in some networks: CONFIG_NET_BUFSIZE should
be set to at least 576 in all defconfig files.
The symptoms of using very small MTU sizes can be very strange. With
Ubuntu 9.x and vsFtpd was that the total packet size did *not match* the
packet size in the IP header. This then caused a TCP checksum failure
and the packet was rejected.
Status: Open
Priority: Low... fix defconfig files as necessary.
o USB (drivers/usbdev, drivers/usbhost)
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.
Status: Open
Priority: Medium
Description: drivers/usbhost/usbhost_rtl8187.c is a work in progress. There is no RTL8187
driver available yet. That is a work in progress.
Status: Open
Priority: Low (Unless you need RTL8187 support).
o Libraries (lib/)
^^^^^^^^^^^^^^^^
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
Description: fgets implementation does not use C-buffered I/O, but rather
talks to serial driver directly via read(). It includes VT-100
specific editting commands. This gets should be renamed readlin()
and a more generic fgets() should be implemented.
Priority: Low (unless you are using mixed C-buffered I/O with fgets and
fgetc, for example).
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().
Status: Open
Priority: Low
Description: strftime() and other timing functions do not handle days of the week.
Status: Open
Priority: Low
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
Description: Not implemented: ferror() and clearerr()
Status: Open
Priority: Low
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.
o File system / Generic drivers (fs/, drivers/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NOTE: The NXFFS file system has its own TODO list at nuttx/fs/nxffs/README.txt
Description: At present, the CAN driver does not support the poll() method.
Status: Open
Priority: Low
Description: There is no way to remove a FIFO or PIPE created in the
psuedo 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 psuedo-
filesystem.
Status: Open, but partially resolved: pipe buffer is at least freed
when there are not open references to the pipe/FIFO.
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.
Description: The simple SPI based MMCS/SD driver in fs/mmcsd does not
yet handle multiple block transfers.
Status: Open
Priority: Medium-Low
Description: Block driver read-ahead buffer and write buffer support is
implemented but not yet tested.
Status: Open
Priority: Low
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
Description: ENC28J60 driver is complete, but untested (I still haven't got
a good ENC28J60 test platform).
Status: Open
Priority: Low
Description: Time stamping is not implemented in the NuttX FAT file system.
See the following functions in fs/fat/fs_fat32util.c:
fat_systime2fattime() and fat_fattime2systime()
Status: Open
Priority: Medium
o Graphics subystem (graphics/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: Testing of all APIs is not complete. See
http://nuttx.sourceforge.net/NXGraphicsSubsystem.html#testcoverage
Status: Open
Priority: Medium
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.
Description: In the kernel build mode (where NuttX is built as a monlithic
kernel and user code must trap into the protected kernel via
syscalls), the single user mode cannot be supported. In this
built configuration, only the multiple user mode can be supported
with the NX server residing inside of the kernel space. In
this case, most of the user end functions in graphics/nxmu
must be moved to lib/nx and those functions must be built into
libuser.a to be linked with the user-space code.
Status: Open
Priority: Low -- the kernel build configuration is not fully fielded
yet.
Description: Need APIs to verify execution of P-Code from memory buffer.
Status: Open
Description: Loader and object format may be too large for some small
memory systems. Consider ways to reduce memory footprint.
o Documentation (Documentation/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
^^^^^^^^^^^^
Description: Dependencies do not work correctly under configs/<board>/src
Priority: Medium (maybe higher for z80 target)
Description: Need a NuttX configuration tool. The number of configuration
settings has become quite large and difficult to manage manually.
Status: Open
Priority: Medium-low
Description: At present, NuttX builds only under Linux or Cygwin.
Investigate the possibility of a native Windows build using
something like the GNUWin32 tools (coreutils+make+grep+sed+uname).
Status: Open
Priority: Low
Description: Logic in most setenv.sh files can create the following problem
on many platforms:
$ . ./setenv.sh
basename: invalid option -- 'b'
Try `basename --help' for more information.
The problem is that $0 is the current running shell which may include
a dash in front:
$ echo $0
-bash
But often is just /bin/bash (and the problem does not occur. The fix
is:
-if [ "$(basename $0)" = "setenv.sh" ]; then
+if [ "$_" = "$0" ] ; then
Status: Open
Priority: Low. Use of setenv.sh is optional and most platforms do not have
this problem. Scripts will be fixed one-at-a-time as is appropropriate.
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)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: The simulated serial driver has some odd behavior. It
will stall for a long time on reads when the C stdio buffers are
being refilled. This only effects the behavior of things like
fgetc(). Workaround: Set CONFIG_STDIO_BUFFER_SIZE=0, suppressing
all C buffered I/O.
Status: Open
Priority: Low (because the simulator is only a test/development platform)
Description: Simulator does not build correctly on 64-bit machines. Two
issues:
1) It saves addresses in 32-bit types and these fail when cast
to pointers on a 64-bit host.
2) up_setjmp.S does not build
Status: Open
Priority: Medium and increasing (as 32-bit hosts gradually disappear). NOTE
is it possible to work-around this limitation by building the sim
target for 32-bit operation on a 64-bit platform. Modify the
Make.defs file in the appropriate places so that -m32 is included
in the CFLAGS and -m32 and -melf_386 are included in the LDFLAGS.
See the patch 0001-Quick-hacks-to-build-sim-nsh-ostest-on-x86_64-as-32-.patch
that can be found at http://tech.groups.yahoo.com/group/nuttx/files.
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).
Description: There is an X11-based framebuffer driver that you can use exercise
the NuttX graphics subsystem on the simulator. But I am not much
of an X11 programmer so I did not use X11 autoconfiguration stuff.
As a result, it builds on old X11 installations, but not on current
versions.
Status: Open
Priority: Low (unless you want to test graphics features on the simulation).
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 asynchrous 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
Descripion: The NSH example has some odd behaviors. Mult-tasking -- for example,
execution of commands in background -- does not work normally. This
is due to the fact that NSH uses the system standard input for the
console. This means that the simulation is actually "frozen" all of
the time when NSH is waiting for input and background commands never
get the chance to run.
Status: Open
Priority: This will not be fixed. This is the normal behavior in the current
design of the simulator. "Real" platforms will behave correctly
because NSH will "sleep" when it waits for console inpu and other
tasks can run freely.
Description: In the NSH example, the host HOST echoes each command so after you
you enter a command, the command is repeated on the next line. This
is an artifact of the simulator only.
Status: Open
Priority: This will not be fixed. This is the normal behavior in the current
design of the simulator. "Real" platforms will behave correctly.
Description: ARM interrupt handling performance could be improved in some
ways. One easy way is to use a pointer to the context save
see handling of 'current_regs" in arch/arm/src/armv7-m/* for
Description: The ARM and Cortex-M3 interrupt handlers restores all regisers
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
Description: The Cortex-M3 user context switch logic uses SVCall instructions.
This user context switching time could be improved by eliminating
the SVCalls and developing assembly language implementations
of the context save and restore logic.
Also, because interrupts are always disabled when the SVCall is
executed, the SVC goes to the hard fault handler where it must
be handled as a special case. I recall seeing some controls
somewhere that will allow to suppress one hard fault. I don't
recall the control, but something like this should be used before
executing the SVCall so that it vectors directly to the SVC
handler.
Status: Open
Priority: Low
Description: The ARM interrupt handling (arch/arm/src/arm/up_vectors.S) returns
using 'ldmia sp, {r0-r15}^' My understanding is that this works
fine because everything is in kernel-mode. In an operating model
where applications run in user mode and interrupts/traps run in
kernel-mode, I think that there is a problem with this. This would
like be a problem, for example, if for a kernel build where NuttX
is built as a monolithic, protected kernel and user mode programs
trap into the kernel.
Priority: Low until I get around to implementng security or kernel mode for
the ARM platform.
o ARM/C5471 (arch/arm/src/c5471/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
Description: A USB device controller driver was added but has never been tested.
Status: Open
Priority: Medium
Description: A framebuffer "driver" was added, however, it remains untested.
Status: Open
Priority: Medium
Description: In order to use the framebuffer "driver" additional video encoder
logic is required to setupt composite video output or to interface
with an LCD.
Status: Open
Priority: Medium (high if you need to use the framebuffer driver)
Description: The basic port of the i.MX1 architecuture was never finished. The port
is incomplete (as of this writing, is still lacks a timer, interrupt
decoding, USB, network) and untested.
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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
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
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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: Should use Vector Interrupts
Status: Open
Priority: Low
Description: USB DMA not fully implemented. Partial logic is in place but it is
fragmentary and bogus.
Description: USB Serial Driver reports wrong error when opened before the
USB is connected (reports EBADF instead of ENOTCONN)
Status: Open
Priority: Low
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.
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.
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
optimiation of the delay time.
Status: Open
Priority: Medium
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 blocksize was forced to 512 in all cases. The SPI-
based driver may also have this problem (but I don't think this would have
andything to do with CMD0).
Description: Possible errors in USB device driver reported "I suspect there's a few
issues in the lpc214x USB driver - in particular it doesn't stall both
in/out endpoints for unsupported setup requests and it doesn't call
CLASS_DISCONNCET on a USB reset - I don't have any access to that hardware
so can't pursue it really."
o ARM/LPC313x (arch/arm/src/lpc313x/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
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/STR71x (arch/arm/src/str71x/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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;
Description: Develop a USB driver and integrate with existing USB serial and storage
class drivers.
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/lm3s/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: Still need to implement I2C
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.
Description: Dependency generation is currently disabled when a Windows native
toolchain is used. I think that 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.
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 sofware bug.
Priority: Probably Low
o ARM/STM32 (arch/arm/src/stm32/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: NOR Flash driver with FTL layer to support a file system.
Status: Open
Priority: Low
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
Description: FSMC external memory support is untested
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).
o AVR (arch/avr)
^^^^^^^^^^^^^^
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.
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.
Priority: Low. The AVR is probably not the architecuture that you want to use
for extensive string operations.
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/usbstorage 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.
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 8051 / MCS51 (arch/8051/)
^^^^^^^^^^^^^^^^^^^^^^^^^
Description: Current status:
- Basic OS task management seems OK
- Fails when interrupts enabled. The stack pointer is around
0x6e before the failure occurs. It looks like some issue
when the stack pointer moves from the directly to indirectly
addressable region (0x80 boundary).
- Work on the 8052 is temporarily on hold
Status: Open
Priority: Low, 8051 is a tough platform because of the tiny stack.
Description: Use timer 0 as system timer. Timer 2 is needed for second UART.
Logic is implemented, but there needs to be a system
configuration to change the ticks-per-second value to match the
timer interrupt rate
Status: Open
Priority: Low
Description: During build, there are several integer overflows reported:
sched/gmtime_r.c aroud lines 184 and 185
sched/clock_initialize.c at line 107