diff options
Diffstat (limited to 'nuttx/TODO')
| -rw-r--r-- | nuttx/TODO | 152 |
1 files changed, 105 insertions, 47 deletions
diff --git a/nuttx/TODO b/nuttx/TODO index 906601192..6c28bfd43 100644 --- a/nuttx/TODO +++ b/nuttx/TODO @@ -1,4 +1,4 @@ -NuttX TODO List (Last updated September 16, 2012) +NuttX TODO List (Last updated November 25, 2012) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This file summarizes known NuttX bugs, limitations, inconsistencies with @@ -14,13 +14,13 @@ nuttx/ (2) C++ Support (6) Binary loaders (binfmt/) (17) Network (net/, drivers/net) - (3) USB (drivers/usbdev, drivers/usbhost) - (11) Libraries (lib/) + (4) USB (drivers/usbdev, drivers/usbhost) + (11) Libraries (libc/, ) (9) File system/Generic drivers (fs/, drivers/) (5) Graphics subystem (graphics/) (1) Pascal add-on (pcode/) (1) Documentation (Documentation/) - (6) Build system / Toolchains + (8) Build system / Toolchains (5) Linux/Cywgin simulation (arch/sim) (6) ARM (arch/arm/) (1) ARM/C5471 (arch/arm/src/c5471/) @@ -32,15 +32,15 @@ nuttx/ (0) ARM/LPC43x (arch/arm/src/lpc43xx/) (3) ARM/STR71x (arch/arm/src/str71x/) (3) ARM/LM3S6918 (arch/arm/src/lm3s/) - (7) ARM/STM32 (arch/arm/src/stm32/) + (4) ARM/STM32 (arch/arm/src/stm32/) (3) AVR (arch/avr) (0) Intel x86 (arch/x86) - (4) 8051 / MCS51 (arch/8051/) + (5) 8051 / MCS51 (arch/8051/) (3) MIPS/PIC32 (arch/mips) (1) Hitachi/Renesas SH-1 (arch/sh/src/sh1) (4) Renesas M16C/26 (arch/sh/src/m16c) (10) z80/z8/ez80 (arch/z80/) - (8) z16 (arch/z16/) + (9) z16 (arch/z16/) (1) mc68hc1x (arch/hc) apps/ @@ -421,7 +421,7 @@ o Binary loaders (binfmt/) .word .LC3-(.LPIC4+4) .word .LC4-(.LPIC5+4) - This is good and bad. This is good because it means that .rodata.str1.1 can not + This is good and bad. This is good because it means that .rodata.str1.1 can now reside in FLASH with .text and can be accessed using PC-relative addressing. That can be accomplished by simply moving the .rodata from the .data section to the .text section in the linker script. (The NXFLAT linker script is located at @@ -629,8 +629,13 @@ o USB (drivers/usbdev, drivers/usbhost) CDC/ACM serial driver might need the line coding data (that data is not used currenly, but it might be). -o Libraries (lib/) - ^^^^^^^^^^^^^^^^ + Title: USB HUB SUPPORT + Description: Add support for USB hubs + Status: Open + Priority: Low/Unknown. This is a feature enhancement. + +o Libraries (libc/) + ^^^^^^^^^^^^^^^^^ Title: ENVIRON Description: The definition of environ in stdlib.h is bogus and will not @@ -643,7 +648,7 @@ o Libraries (lib/) 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 lib/termios/ and in the + 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 @@ -708,7 +713,7 @@ o Libraries (lib/) Priority: Title: OLD dtoa NEEDS TO BE UPDATED - Description: This implementation of dtoa in lib/stdio is old and will not + 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 @@ -716,7 +721,7 @@ o Libraries (lib/) Title: SYSLOG INTEGRATION Description: There are the beginnings of some system logging capabilities (see - drivers/syslog, fs/fs_syslog.c, and lib/stdio/lib_librawprintf.c and + drivers/syslog, fs/fs_syslog.c, and libc/stdio/lib_librawprintf.c and lib_liblowprintf.c. For NuttX, SYSLOG is a concept and includes, extends, and replaces the legacy NuttX debug ouput. Some additional integration is required to formalized this. For example: @@ -890,23 +895,30 @@ o Build system Description: Need a NuttX configuration tool. The number of configuration settings has become quite large and difficult to manage manually. Update: This task is essentially completed. But probably not for - all platforms and all features. When do we know that the the - features is complete and that we can switch to exclusive use of - the tool? + all platforms and all features. When do we know that the feature + is complete and that we can switch to exclusive use of the tool? Status: Open Priority: Medium-low Title: NATIVE WINDOWS BUILD - 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). + Description: This effort is underway using MinGW-GCC and GNUWin32 tools + for (coreutils+make+grep+sed+uname). Current status: + + 1. configs/stm32f4discovery/winbuild - builds okay natively + 2. configs/ez80f910200kitg - Can be reconfigured to build natively. + Requires some manual intervention to get a clean build. + See configs/ez80f910200kitg/README.txt. + Status: Open Priority: Low Title: WINDOWS DEPENDENCY GENERATION 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. + toolchain is used in a POSIX-like enviornment (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. @@ -953,7 +965,7 @@ o Build system 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 + must be moved to libc/nx and those functions must be built into libuser.a to be linked with the user-space code. A similar issue exists in NSH that uses some internal OS interfaces that would not be available in a kernel build @@ -962,6 +974,48 @@ o Build system Priority: Low -- the kernel build configuration is not fully fielded yet. + Title: mconf NOT AVAILABLE IN NATIVE WINDOWS BUILD + Description: NuttX is migrating to the use of the kconfig-frontends mconf + tool for all configurations. In NuttX 6.24, support for native + Windows builds was added. However, the mconf tool does not + build to run natively under Windows. + + Some effort was spent trying to get a clean mconf build under + Windows. This is documented in the message thread beginning + here: http://tech.groups.yahoo.com/group/nuttx/message/2900. + The build was successfully completed using: MinGW-GCC, MSYS, + additional Windows libraries, and additional MSYS libraries + (MSYS is a variant of Cygwin so, presumeably, Cygwin could + have been used as well). However, on final testing, it was + found that there are problems with text and numeric entry: + http://tech.groups.yahoo.com/group/nuttx/message/2953. This + was considered a show stopper and the changs were not checked + in. + + Options: (1) Use conf (not mconf). confis the text-only + configuration tool, (2) fix mconf, (3) write another variant + of the configuration tool for windows, or (4) do all configuration + under Cygwin or MSYS. I am doing (4) now, but this is very + awkward because I have to set the apps path to ../apps (vs + ..\apps) and CONFIG_WINDOWS_NATIVE=n for the 'make menuconfig' + to run error free under windows. Very awkward! + Status: Open, there are some workarounds, but none are good. + Priority: High + + Title: configure.sh NOT AVAILABLE IN NATIVE WINDOWS BUILD + Description: configure.sh is a Bash script and cannot be used from a Windows + CMD.exe window. I started a configure.bat script, but I do + not have the batch file programming skills to duplicate some + of the more complex operations. + + I also considered adding a configure.c file that could be + compiled and then executed by configure.bat (and configure.sh?). + But I have not gone down that path yet. + + The current work-around is to configure under Cygwin. + Status: Open + Priority: High + o Linux/Cywgin simulation (arch/sim) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -1344,11 +1398,6 @@ o ARM/LM3S6918 (arch/arm/src/lm3s/) o ARM/STM32 (arch/arm/src/stm32/) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - Title: NOR FLASH DRIVER - Description: NOR Flash driver with FTL layer to support a file system. - Status: Open - Priority: Low - 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 @@ -1371,11 +1420,6 @@ o ARM/STM32 (arch/arm/src/stm32/) Status: Open Priority: Medium-High - Title: FSMC EXTERNAL MEMORY UNTESTED - Description: FSMC external memory support is untested - Status: Open - Priority: Low - Title: DMA EXTENSIONS Description: DMA logic needs to be extended. DMA2, Channel 5, will not work because the DMA2 channels 4 & 5 share the same interrupt. @@ -1383,12 +1427,6 @@ o ARM/STM32 (arch/arm/src/stm32/) Priority: Low until someone needs DMA1, Channel 5 (ADC3, UART4_TX, TIM5_CH1, or TIM8_CH2). - Title: UNFINISHED DRIVERS - Description: The following drivers are incomplete: DAC. The following drivers - are untested: DMA on the F4, CAN. - Status: Open - Priority: Medium - 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 @@ -1412,13 +1450,15 @@ o ARM/STM32 (arch/arm/src/stm32/) Status: Open Priority: Low (I am not even sure if this is a problem yet). - Status: UNFINISHED STM32 F4 OTG FS HOST DRIVER - Description: A quick-n-dirty leverage of the the LPC17xx host driver was put into - the STM32 source to support development of the STM32 F4 OTG FS host - driver. It is non-functional and still waiting for STM32 F4 logic - to be added. Don't use it! + 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 allocted from internal + SRAM. Status: Open - Priority: Low (unless you need a host driver). + Priority: Low o AVR (arch/avr) ^^^^^^^^^^^^^^ @@ -1507,6 +1547,16 @@ o 8051 / MCS51 (arch/8051/) Status: Open Priority: Low -- only because there as so many other issues with 8051 + Title: 8051 BUILD BROKEN + Description: The last time I tried to build the pjrc-8051 configurtion using + the SDCC 3.2.1 toolchain (for Windows). I got compilation + errors in sched/os_bringup.c. It complained about type + mis-matches. What I gather from Googling, this is a problem + with the --stack-auto option. At any rate, this problem will + need to be fixed if you want to resurrect the 8051 NuttX port. + Status: Open + Priority: Low -- I don't think anyone uses the 8051 port. + o MIPS/PIC32(arch/mips) ^^^^^^^^^^^^^^^^^^^^^ @@ -1835,9 +1885,17 @@ o z16 (arch/z16) Internal Error(0503) On line 2504 of "MMCSD\MMCSD_SDIO.C" File <c3>, 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 + Status: Open. Recommended workaround: remove mmcsd_sdio.c from + drivers/mmcsd/Make.defs. There is no SDIO support for the Z16 anyway + Priority: Low + + Title: NATIVE BUILD PROBLEMS + Description: When last tested (ca.12/12), there were some missing .obj files in + arch/z16/src. A little additional TLC will be needed to get a + reliable Windows native build. As of this writing, the Cygwin + based build has not been re-verified. + Status: Open + Priority: Low -- I don't think anyone uses the Z16 port. o mc68hc1x (arch/hc) ^^^^^^^^^^^^^^^^^^ |