NuttX TODO List (Last updated April 2 2011) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ nuttx/ (5) Task/Scheduler (sched/) (1) On-demand paging (sched/) (2) Memory Managment (mm/) (1) Signals (sched/, arch/) (1) pthreads (sched/) (1) C++ Support (5) Binary loaders (binfmt/) (15) Network (net/, drivers/net) (2) USB (drivers/usbdev, drivers/usbhost) (5) Libraries (lib/) (13) File system/Generic drivers (fs/, drivers/) (2) Graphics subystem (graphics/) (1) Pascal add-on (pcode/) (1) Documentation (Documentation/) (5) Build system / Toolchains (7) Linux/Cywgin simulation (arch/sim) (4) ARM (arch/arm/) (1) ARM/C5471 (arch/arm/src/c5471/) (3) ARM/DM320 (arch/arm/src/dm320/) (2) ARM/i.MX (arch/arm/src/imx/) (4) ARM/LPC17xx (arch/arm/src/lpc17xx/) (7) ARM/LPC214x (arch/arm/src/lpc214x/) (2) ARM/LPC313x (arch/arm/src/lpc313x/) (3) ARM/STR71x (arch/arm/src/str71x/) (4) ARM/LM3S6918 (arch/arm/src/lm3s/) (4) ARM/STM32 (arch/arm/src/stm32/) (0) Intel x86 (arch/x86) (4) 8051 / MCS51 (arch/8051/) (2) Hitachi/Renesas SH-1 (arch/sh/src/sh1) (4) Renesas M16C/26 (arch/sh/src/m16c) (8) z80/z8/ez80 (arch/z80/) (8) z16 (arch/z16/) (1) mc68hc1x (arch/hc) apps/ (5) Network Utilities (apps/netutils/) (4) NuttShell (NSH) (apps/nshlib) (3) 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 one function called on exit(). Should task_delete() also cause atexit() function to be called? Status: Open Priority: Low, task_delete() is non-standard and its behavior is unspecified. 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. 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. Status: Open Priority: Medium-Low 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. Description: Current logic adapts size_t for 16-bit address machines vs. 32-bit address machines. But a small memory option should also be provided so that the small offset option can be used with 32-bit machines that have small RAM memories (like the lpc2148) Status: Open Priority: High, a good feature enhancement. 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. o pthreads (sched/) ^^^^^^^^^^^^^^^^^ Description: pthread_cancel(): Should implement cancellation points and pthread_testcancel() Status: Open Priority: Low, probably not that useful o C++ Support ^^^^^^^^^^^ 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(). o Binary loaders (binfmt/) ^^^^^^^^^^^^^^^^^^^^^^^^ Description: Not all of the NXFLAT test under apps/examples/nxflat are working. 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 o Network (net/, drivers/net) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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: Sendoto() 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 statistics. Status: Open Priority: Low 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 commnands, 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. 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 Priority: Medium 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. Status: Open 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 o File system / Generic drivers (fs/, drivers/) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Description: Implement chmod(), truncate(). Status: Open Priority: Low Description: FAT: long file names Status: Open Priority: Medium Description: The CAN driver is untested. Add a test for the CAN driver. Status: Open Priority: Medium 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. Priority: Medium 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: At present, mmap() only works with file descriptors associated with a ROMFS file system. Generalize this logic so that if mmap is not supported by the file system or block driver, it will allocate memory and copy the file into RAM. This would need some centralized logic so that the memory region would be shared on later mmap()'s on the same inode. Reference counting would be required so that the multiply mmap()'ed region persists until the last munmap(). Status: Open Priority: 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 no implemented in the NuttX FA 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: If CONFIG_NX is enabled, the build fails the first time saying that there is "No rule to make target..." for one of the auto-generated graphics files. This is a nuisance, but if you simply build again (with the source files already auto-generated) the problem does not reoccur. Status: Open Priority: Low, the work-around is simple Description: Testing of all APIs is not complete. See http://nuttx.sourceforge.net/NXGraphicsSubsystem.html#testcoverage Status: Open Priority: Medium Description: The apps/examples/nx test using lcd/p14201.c and the configs/lm3s6965-ek configuration shows two single pixel-wide anomalies. One along column zero is clearly caused by the NX windowing logic. It is not certain if these are consequences of the 4bpp logic or if these are anomalies that have always been in NX, but are only visible now at the low resolution of the p14201 LCD (128x96). Status: Open Priority: Low (unless you need the p13201 then it is certainly higher). o Pascal Add-On (pcode/) ^^^^^^^^^^^^^^^^^^^^^^ Description: Need APIs to verify execution of P-Code from memory buffer. Status: Open Priority: Low Description: Loader and object format may be too large for some small memory systems. Consider ways to reduce memory footprint. Status: Open Priority: Medium 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 o Build system ^^^^^^^^^^^^ Description: configs/pjrc-8051 should be configs/pjrc-87c52 Status: Open Priority: Low Description: Dependencies do not work correctly under configs//src (same as arch//src/board). Status: Open 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 Decription: Build of NX fails with gcc-4.2.2. When generating C files using arm-elf-gcc -E, the CPP fails when using -isystem. Works fine with older compilers. My work around for now is to use an older compiler for the CPP definition in the configuration Make.defs file, do make context, restore the original Make.defs, and then make. Status: Open. This may not be a real issue. I have not seen this happen lately so it may have nothing to do with GCC. Priority: High if you are using NX and a newer compiler. Description: It has been reported to me that in some environments, the int8_t type is unsigned (0-255). The uint8_t type is based on type char and char may or may not be treated as a signed value by your compiler. Two options: (1) in arch//include//types.h, try typedef'ing int8_t as 'signed char', (2) for GCC, you should be able to add the compiler option -fsigned-char to your CFLAGS in Make.defs. Status: Open Priority: Medium 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. o ARM (arch/arm/) ^^^^^^^^^^^^^^^ 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. see handling of 'current_regs" in arch/arm/src/cortexm3/* for examples of how this might be done. Status: Open Priority: Low 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. 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. Status: Open Priority: Low until I get around to implement security 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 Priority: Medium 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) o ARM/i.MX (arch/arm/src/imx/) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Description: The basic port of the i.MX1 architecuture is underway. The port is incomplete (as of this writing, is still lacks a timer, interrupt decoding, USB, network) and untested. Status: Open (and in work) Priority: Medium (high if you need i.MX1/L support) 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!) Description: SLIP (Configuration olimex-lpc1766stk/slip-httpd) only works with VERBOSE debug disabled. For some reason, certain debug statements hang(?). Also, this example does not use UART1's hardware flow control. UART1 hardware flow control is partially implemented but does not behave as expected. Hardware flow control needs a little more work. Status: Open Priority: Low 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. Status: Open Priority: Low 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. Status: Open Priority: Medium 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). Status: Open Priority: Uncertain 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." Status: Open Priority: Medium 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; I have no MMC cards, only SD cards which won't fit into the slot. Status: Open Priority: Medium Description: Develop a USB driver and integrate with existing USB serial and storage class drivers. Status: Open Priority: Medium 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 Status: Open Priority: Low 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 Status: Open Priority: Low 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 Intel x86 (arch/x86) ^^^^^^^^^^^^^^^^^^^^ 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 sched/pthread_create.c at 330 apps/examples/ostest/barrier.c around lines 53 and 74 apps/examples/ostest/sighand.c at 225 and 244 driver/serial.c in usleep calls around 347 and 354 Status: Open. Update: These were reviewed during the hcs12 port. The hcs12 also has 16-bit integer types (if -mshort is in the CFLAGS). I believe that the warnings in most of the above have been fixed but this has not been verified on this platform). Priority: Medium Description Global data is not being initialized. Logic like that of SDCCs crt0*.s needs to be incorporated into the system boot logic Status: Open Priority: Low -- only because there as so many other issues with 8051 o Hitachi/Renesas SH-1 (arch/sh/src/sh1) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Description: There are instabilities that make the SH-1 port un-usable. The nature of these is not understood; the behavior is that certain SH-1 instructions stop working as advertised. I have seen the following examples: 412b jmp @r1 - Set a return address in PR, i.e., it behaved like 410b jsr @r1. Normally 412b works correctly, but in the failure condition, it reliably set the PR. 69F6 mov.l @r15+,r9 - wrote the value of R1 to @r15+. This behavior does not correspond to any known SH-1 instruction This could be a silicon problem, some pipeline issue that is not handled properly by the gcc 3.4.5 toolchain (which has very limit SH-1 support to begin with), or perhaps with the CMON debugger. At any rate, I have exhausted all of the energy that I am willing to put into this cool old processor for the time being. Status: Open Priority: Low -- because the SH-1, SH7032, is very old and only of historical interest. Description: arch/sh has been restructured to support M16C. Need to verify that SH-1 still builds. Status: Open Priority: Low Description: The M16C target cannot be built. The GNU m16c-elf-ld link fails with the following message: m32c-elf-ld: BFD (GNU Binutils) 2.19 assertion fail /home/Owner/projects/nuttx/buildroot/toolchain_build_m32c/binutils-2.19/bfd/elf32-m32c.c:482 Where the reference line is: /* If the symbol is out of range for a 16-bit address, we must have allocated a plt entry. */ BFD_ASSERT (*plt_offset != (bfd_vma) -1); No workaround is known at this time. Status: Open Priority: High -- this is a show stopper for M16C. o Renesas M16C/26 (arch/sh/src/m16c) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Description: Coding of the initial port is complete, but is untested. Status: Open Priority: Low Description: Serial drivers were developed for the M16C, however, the SKP16C26 StarterKit has no serial connectors. Status: Open Priority: Low Description: Should implement SPI, I2C, Virual EEPROM, FLASH, RTC drivers Status: Open Priority: Medium o z80/z8/ez80 (arch/z80) ^^^^^^^^^^^^^^^^^^^^^^^ Description: The SDCC version the same problems with integer overflow during compilation as described for pjrc-8051. At typical cause is code like usleep(500*1000) which exceeds the range of a 16-bit integer. Status: See pjrc-8051. These have probably been fixed but have not yet been verified on these platforms. Priority: See pjrc-8051 Description: The simulated Z80 serial console (configs/z80sim/src/z80_serial.c + driver/serial.c) does not work. This is because there are no interrupts in the simulation so there is never any serial traffic. Status: Open Priority: Low -- the simulated console is not critical path and the designs to solve the problem are complex. Description: ZDS-II Librarian complains that the source for the .obj file is not in the library. Status: Open Priority: Low, thought to be cosmetic. I think this is a consequence of replacing vs. inserting the library. Description: The ZDS-II compiler (version 4.10.1) fails with an internal error while compiler mm/mm_initialize. This has been reported as incident 81509. I have found the following workaround that I use to build for the time being: --- mm/mm_initialize.c.SAVE 2008-02-13 08:06:46.833857700 -0600 +++ mm/mm_initialize.c 2008-02-13 08:07:26.367608900 -0600 @@ -94,8 +94,11 @@ { int i; +#if 0 /* DO NOT CHECK IN */ CHECK_ALLOCNODE_SIZE; CHECK_FREENODE_SIZE; +#endif /* Set up global variables */ Status: Open Priority: High Description: Add support for prioritized ez8 interrupts. Currently logic supports only nominal interrupt priority. Status: Open Priority: Low Description: The z8Encore! port has only been verified on the ZDS-II instruction set simulator. Status: Open Priority: Medium Description: Upgrade to the ZDS-II Z8Encore! 4.11.0 toolchain Status: Open Priority: Low Description: The XTRS target (configs/xtrs) has a clean problem. The clean rule removes .asm files. This works because there are no .asm files except in sub-directories that are provided from 'make clean' -- except for XTRS: It has a .asm file in its src/ directory that gets removed everytime clean is performd. Status: Open Priority: High if you happen to be working with XTRS. Description: A "generic" SPI and I2C drivers have been coded for the eZ80Acclaim! However, these remains untested since I have no SPI or I2C devices for the board (yet). Status: Open Priority: Med 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: A "generic" I2C driver has been coded for the eZ8Encore! However, this remains untested since I have no I2C devices for the board (yet). Status: Open Priority: Med o z16 (arch/z16) ^^^^^^^^^^^^^^^^ Description: ZDS-II Librarian complains that the source for the .obj file is not in the library. Status: Open Priority: Low, thought to be cosmetic. I think this is a consequence of replacing vs. inserting the library. Description: When the interrupt-driven serial driver is used, the system hangs. This is because of TX ready (TRDE) interrupts that get lost while interrupts are disabled. The existing serial driver appears to be limited to hardware with a latching, level-sensitive TX ready interrupt. Status: Open Priority: Medium. A polled, write-only serial driver is used in the interim for system testing. Description: The system delays do not appear to be correct with the apps/examples/ostest/timedmqueue.c test. Status: Open Priority: Medium-High Description: At present, the z16f port does not run properly when CONFIG_DEBUG is disabled: The obvious symptom is that there is no printf() output. I have isolated with problem to errors in optimization. With -reduceopt on the command line, I can get the printf output. However, there are still errors in the compiled code -- specifically in sched/timer_create.c. I have submitted a bug report to ZiLOG for this (support incident 81400). You can see the status of the bug report (and lots more technical detail) here: http://support.zilog.com/support/incident/incident_support.asp?iIncidentId=81400&iSiteId=1&chLanguageCode=ENG Summary of ZiLOG analysis: "This is a ZNEO compiler problem. ... [a] workaround is to replace: if ( !timerid || (clockid != 0) ) By: if ((clockid != 0) || !timerid)" Status: Open Priority: Medium-High Description: The pascal add-on does not work with the z16f (that is configuration z16f2800100zcog/pashello). This appears to be another ZDS-II error: when executing the instruction SYSIO 0, WRITESTR a large case statement is executed. This involves a call into the ZiLOG runtime library to __uwcase(). __uwcase is passed a pointer to a structure containing jump information. The cause of the failure appears to be that the referenced switch data is bad. This is submited as ZiLOG support incident 81459. Summary of ZiLOG analysis: "This is a ZNEO run time library problem. One workaround is to replace the line 58 in uwcase.asm From: ADD R9,#4 ; Skip handler To: ADD R9,#2 ; Skip handler And add uwcase.asm to the project. If the customer does not want to modify uwcase.asm then the other workaround is to add a dummy case and make it same as default: case 0x8000: default: This will make sure that uwcase is not called but ulcase is called." Status: Open. Due to licensing issues, I cannot include the modified uwcase in the NuttX code base. Priority: Medium Description: Add support to maintain SPOV in context switching. This improvement will provide protection against stack overflow and make a safer system solution. Status: Open Priority: Low Description: Add support for prioritized interrupts. Currently logic supports only nominal interrupt priority. Status: Open Priority: Low Description: The file drivers/mmcsd/mmcsd_sdio.c generates an internal compiler error like: mmcsd\mmcsd_sdio.c Internal Error(0503) On line 2504 of "MMCSD\MMCSD_SDIO.C" File , Args(562,46) Status: Open. Recommended workaround: remove mmcsd_sdio.c from drivers/mmcsd/Make.defs. There is no SDIO support for the Z16 anyway Priority: Low o mc68hc1x (arch/hc) ^^^^^^^^^^^^^^^^^^ Description: There is no script for building in banked mode (more correctly, there is a script, but logic inside the script has not yet been implemented). It would be necessary to implement banked mode to able to access more the 48Kb of FLASH. Status: Open. Priority: Medium/Low o Network Utilities (apps/netutils/) Description: One critical part of netutils/ apps is untested: The uIP resolver in netutils/resolv. The webclient code has been tested on host using gethosbyname(), but still depends on the untested resolve logic. Status: Open Priority: Medium, Important but not core NuttX functionality Description: Port PPP support from http://contiki.cvs.sourceforge.net/contiki/contiki-2.x/backyard/core/net/ppp/ Status: Open Priority: Low Description: Not all THTTPD features/options have been verified. In particular, there is no test case of a CGI program receiving POST input. Only the configuration of apps/examples/thttpd has been tested. Status: Open Priority: Medium Description: The first GET received by THTTPD is not responded to. Refreshing the page from the browser solves the problem and THTTPD works fine after thatg. I believe that this is the duplicate of another bug: "Outgoing [uIP] packets are dropped and overwritten by ARP packets if the destination IP has not been mapped to a MAC." Status: Open Priority: Medium Description: If the network is enabled, but THTTPD is not configured, it spews out lots of pointless warnings. This is kind of annoying and unprofessional; needs to be fixed someday. Status: Open. An annoyance, but not a real problem. Priority: Low o NuttShell (NSH) (apps/nshlib) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Description: When the telnetd front end is received, each TCP packet received causes a prompt (nsh >) to be presented. The prompt should only be presented when the user enters a carriage return. Status: Open Priority: Low Description: The wget command has been incorporated into NSH, however it is still untested as of this writing (only because I have not had the correct network setup for the testing yet). Since wget depends on the also untest uIP resolv/ logic, it is like non-functional. Status: Open Priority: Med-High Description: Add support to NSH to run NXFLAT programs from a ROMFS file system Status: Open Priority: Low (enhancement) Description: Add an ARP command so that we can see the contents of the ARP table. Status: Open Priority: Low (enhancement) o Other Applications & Tests (apps/examples/) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Description: The redirection test (part of examples/pipe) terminates incorrectly on the Cywgin-based simulation platform (but works fine on the Linux-based simulation platform). Status: Open Priority: Low Description: examples/wget is untested on the target (it has been tested on the host, but not in the target using the uIP resolv logic). Status: Open Priority: Med Description: examples/sendmail is untested on the target (it has been tested on the host, but not on the target. Status: Open Priority: Med