Newer
Older
Status: Open. Many of the required changes are in place but, unfortunately, not enough
go be fully functional. I think all of the I-Space-to-I-Space fixes are in place.
However, the generated code also includes PC-relative references to .bss which
just cannot be done.
Priority: Medium. The workaround for now is to use the older, 4.3.3 OABI compiler.
Title: LISTENING FOR UDP BROADCASTS
Description: Incoming UDP broadcast should only be accepted if listening on
INADDR_ANY(?)
Status: Open
Priority: Low
Title: CONCURRENT TCP SEND OPERATIONS
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.
Title: POLL/SELECT ON TCP/UDP SOCKETS NEEDS READ-AHEAD
Description: poll()/select() only works for availability of buffered TCP/UDP
read data (when read-ahead is enabled). The way writing is
handled in the network layer, all sockets must wait when send and
cannot be notified 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()
Title: SOCKETS DO NOT ALWAYS SUPPORT O_NONBLOCK
Description: sockets do not support all modes for O_NONBLOCK. Sockets
support nonblocking operations only (1) for TCP/IP non-
blocking read operations when read-ahead buffering is
enabled, (2) TCP/IP accept() operations when TCP/IP
connection backlog is enabled, (2) UDP/IP read() operations
when UDP read-ahead is enabled, and (3) non-blocking
operations on Unix domain sockets.
Status: Open
Priority: Low.
Title: UNFINISHED CRYSTALLAN CS89X0 DRIVER
Description: I started coding a CrystalLan CS89x0 driver (drivers/net/cs89x0.c),
but never finished it.
Status: Closed.
Priority: Low. I don't plan to finish the CS89x0 driver. It is just
history now. The unfinished coded is retained in case someone
needs to resurrect it.
Title: INTERFACES TO LEAVE/JOIN IGMP MULTICAST GROUP
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 (e.g., "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.
Title: CLOSED CONNECTIONS IN THE BACKLOG
If a connection is backlogged but accept() is not called quickly, then
that connection may time out. How should this be handled? Should the
connection be removed from the backlog if it is times out or is closed?
Or should it remain in the backlog with a status indication so that accept()
can fail when it encounters the invalid connection?
Gregory Nutt
committed
Priority: Medium. Important on slow applications that will not accept
connections promptly.
Title: IPv6 REQUIRES ADDRESS FILTER SUPPORT
Description: IPv6 requires that the Ethernet driver support NuttX address
filter interfaces. Several Ethernet drivers do support there,
however. Others support the address filtering interfaces but
have never been verifed:
C5471, LM3S, ez80, DM0x90 NIC, PIC: Do not support address
filtering.
Kinetis, LPC17xx, LPC43xx: Untested address filter support
Priority: Pretty high if you want a to use IPv6 on these platforms.
Title: UDP MULTICAST RECEPTION
Description: The logic in udp_input() expects either a single receive socket or
none at all. However, multiple sockets should be capable of
receiving a UDP datagram (multicast reception). This could be
handled easily by something like:
for (conn = NULL; conn = udp_active (pbuf, conn); )
If the callback logic that receives a packet responds with an
outgoing packet, then it will over-write the received buffer,
however. recvfrom() will not do that, however. We would have
to make that the rule: Recipients of a UDP packet must treat
the packet as read-only.
Status: Open
Priority: Low, unless your logic depends on that behavior.
Gregory Nutt
committed
Title: NETWORK WON'T STAY DOWN
Description: If you enable the NSH network monitor (CONFIG_NSH_NETINIT_MONITOR)
then the NSH 'ifdown' command is broken. Doing 'nsh> ifconfig eth0'
will, indeed, bring the network down. However, the network monitor
notices the change in the link status and will bring the network
back up. There needs to be some kind of interlock between
cmd_ifdown() and the network monitor thread to prevent this.
Status: Open
Priority: Low, this is just a nuisance in most cases.
Title: FIFO CLEAN-UP AFTER CLOSING UNIX DOMAIN DATAGRAM SOCKET
Description: FIFOs are used as the IPC underlying all local Unix domain
sockets. In NuttX, FIFOs are implemented as device drivers
(not as a special FIFO files). The FIFO device driver is
instantiated when the Unix domain socket communications begin
and will automatically be released when (1) the driver is
unlinked and (2) all open references to the driver have been
closed. But there is no mechanism in place now to unlink the
FIFO when the Unix domain datagram socket is no longer used.
The primary issue is timing.. the FIFO should persist until
it is no longer needed. Perhaps there should be a delayed
call to unlink() (using a watchdog or the work queue). If
the driver is re-opened, the delayed unlink could be
NOTE: This is not an issue for Unix domain streams sockets:
The end-of-life of the FIFO is well determined when sockets
are disconnected and support for that case is fully implemented.
Status: Open
Priority: Low for now because I don't have a situation where this is a
problem for me. If you use the same Unix domain paths, then
it is not a issue; in fact it is more efficient if the FIFO
devices persist. But this would be a serious problem if,
for example, you create new Unix domain paths dynamically.
In that case you would effectively have a memory leak and the
number of FIFO instances grow.
Title: TCP IPv4-MAPPED IPv6 ADDRESSES
Description: The UDP implementation in net/udp contains support for Hybrid
dual-stack IPv6/IPv4 implementations that utilize a special
class of addresses, the IPv4-mapped IPv6 addresses. You can
see that UDP implementation in:
udp_callback.c:
ip6_map_ipv4addr(ipv4addr,
udp_send.c:
ip6_is_ipv4addr((FAR struct in6_addr*)conn->u.ipv6.raddr)))
ip6_is_ipv4addr((FAR struct in6_addr*)conn->u.ipv6.raddr))
in_addr_t raddr = ip6_get_ipv4addr((FAR struct in6_addr*)conn->u.ipv6.raddr);
There is no corresponding support for TCP sockets.
Status: Open
Priority: Low. I don't know of any issues now, but I am sure that
someone will encounter this in the future.
Title: MISSING netdb INTERFACES
Description: There is no implementation for many netdb interfaces such as
getaddrinfo(), freeaddrinfo(), getnameinfo(), etc.
Status: Open
Priority: Low
Title: ETHERNET WITH MULTIPLE LPWORK THREADS
Description: Recently, Ethernet drivers were modified to support multiple
work queue structures. The question was raised: "My only
reservation would be, how would this interact in the case of
having CONFIG_STM32_ETHMAC_LPWORK and CONFIG_SCHED_LPNTHREADS
> 1? Can it be guaranteed that one work item won't be
interrupted and execution switched to another? I think so but
am not 100% confident."
I suspect that you right. There are probably vulnerabilities
in the CONFIG_STM32_ETHMAC_LPWORK with CONFIG_SCHED_LPNTHREADS
> 1 case. But that really doesn't depend entirely upon the
change to add more work queue structures. Certainly with only
work queue structure you would have concurrent Ethernet
operations in that multiple LP threads; just because the work
structure is available, does not mean that there is not dequeued
work in progress. The multiple structures probably widens the
window for that concurrency, but does not create it.
The current Ethernet designs depend upon a single work queue to
serialize data. In the case of muliple LP threads, some
additional mechanism would have to be added to enforce that
serialization.
Gregory Nutt
committed
NOTE: Most drivers will call net_lock() and net_unlock() around
the critical portions of the driver work. In that case, all work
will be properly serialized. This issue only applies to drivers
that may perform operations that require protection outside of
the net_lock'ed region. Sometimes, this may require extending
the netlock() to be beginning of the driver work function.
Status: Open
Priority: High if you happen to be using Ethernet in this configuration.
Title: REPARTITION DRIVER FUNCTIONALITY
Description: Every network driver performs the first level of packet decoding.
It examines the packet header and calls ipv4_input(), ipv6_input().
icmp_input(), etc. as appropriate. This is a maintenance problem
because it means that any changes to the network input interfaces
affects all drivers.
A better, more maintainable solution would use a single net_input()
function that would receive all incoming packets. This function
would then perform that common packet decoding logic that is
currently implemented in every network driver.
Status: Open
Priority: Low. Really just as aesthetic maintainability issue.
Title: BROADCAST WITH MULTIPLE NETWORK INTERFACES
Description: There is currently no mechanism to send a broadcast packet
out through several network interfaces. Currently packets
can be sent to only one device. Logic in netdev_findby_ipvXaddr()
currently just selects the first device in the list of
devices; only that device will receive broadcast packets.
Status: Open
Priority: High if you require broadcast on multiple networks. There is
no simple solution known at this time, however. Perhaps
netdev_findby_ipvXaddr() should return a list of devices rather
than a single device? All upstream logic would then have to
deal with a list of devices. That would be a huge effect and
certainly doesn't dount as a "simple solution".
Gregory Nutt
committed
Title: ICMPv6 FOR 6loWPAN
Description: The current ICMPv6 and neighbor-related logic only works with
Ethernet MAC. For 6loWPAN, a new more conservative ICMPv6
definitions is provided by RFC 6775. This RFC needs to be
supported in order to support ping6 on a 6loWPAN network.
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
If RFC 6775 were implemented, then arbitrary IPv6 addresses,
including addresses from DHCPv6 could be used.
can
UPDATE: With ICMPv6 neighbor discovery, any IPv6 address may
be associated with any short or extended address. In fact,
that is the whole purpose of the neighbor discover logic: It
plays the same role as ARP in IPv4; it ultimately just manages
a neighbor table that, like the arp table, provides the
mapping between IP addresses and node addresses.
The NuttX, Contiki-based 6loWPAN implementation circumvented
the need for the neighbor discovery logic by using only MAC-
based addressing, i.e., the lower two or eight bytes of the
IP address are the node address.
Most of the 6loWPAN compression algorithms exploit this to
compress the IPv6 address to nothing but a bit indicating
that the IP address derives from the node address. So I
think ICMPv6 is useless in the current implementation.
If we want to use ICMPv6, we could dispense with the all MAC
based addressing. But if we want to retain the more compact
MAC-based addressing, then we don't need ICMPv6.
So, the full neighbor discovery logic is not currently useful,
but it would still be nice to have enough in place to support
ping6.
Gregory Nutt
committed
Status: Open
Priority: Low for now. I don't plan on implementing this. It would
only be relevant if we were to decide to abandon the use of
MAC-based addressing in the 6loWPAN implementation.
Gregory Nutt
committed
Title: ETHERNET LOCAL BROADCAST DOES NOT WORK
Description: In case of "local broadcast" the system still send ARP
request to the destination, but it shouldn't, it should
broadcast. For Example, the system has network with IP
10.0.0.88, netmask of 255.255.255.0, it should send
messages for 10.0.0.255 as broadcast, and not send ARP
for 10.0.0.255
For more easier networking, the next line should have give
me the broadcast address of the network, but it doesn't:
ioctl(_socket_fd, SIOCGIFBRDADDR, &bc_addr);
Status: Open
Priority: Medium
o USB (drivers/usbdev, drivers/usbhost)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Title: USB STORAGE DRIVER DELAYS
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. See logic conditioned on CONFIG_USBMSC_RACEWAR.
Gregory Nutt
committed
If queuing of stall requests is supported by the DCD then this workaround
Gregory Nutt
committed
is not required. In this case, (1) the stall is not sent until all
write requests preceding the stall request are sent, (2) the stall is
sent, and then after the stall is cleared, (3) all write requests
queued after the stall are sent.
See, for example, the queuing of pending stall requests in the SAM3/4
UDP driver at arch/arm/src/sam34/sam_udp.c. There the logic is do this
is implemented with a normal request queue, a pending request queue, a
stall flag and a stall pending flag:
1) If the normal request queue is not empty when the STALL request is
received, the stall pending flag is set.
2) If addition write requests are received while the stall pending flag
is set (or while waiting for the stall to be sent), those write requests
go into the pending queue.
3) When the normal request queue empties successful and all of the write
transfers complete, the STALL is sent. The stall pending flag is
cleared and the stall flag is set. Now the endpoint is really stalled.
4) After the STALL is cleared (via the Clear Feature SETUP), the pending
request queue is copied to the normal request queue, the stall flag is
cleared, and normal write request processing resumes.
Title: EP0 OUT CLASS DATA
Description: There is no mechanism in place to handle EP0 OUT data transfers.
There are two aspects to this problem, neither are easy to fix
(only because of the number of drivers that would be impacted):
1. The class drivers only send EP0 write requests and these are
only queued on EP0 IN by this drivers. There is never a read
request queued on EP0 OUT.
2. But EP0 OUT data could be buffered in a buffer in the driver
data structure. However, there is no method currently
defined in the USB device interface to obtain the EP0 data.
Updates: (1) The USB device-to-class interface as been extended so
that EP0 OUT data can accompany the SETUP request sent to the
class drivers. (2) The logic in the STM32 F4 OTG FS device driver
has been extended to provide this data. Updates are still needed
to other drivers.
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
Here is an overview of the required changes:
New two buffers in driver structure:
1. The existing EP0 setup request buffer (ctrlreq, 8 bytes)
2. A new EP0 data buffer to driver state structure (ep0data,
max packetsize)
Add a new state:
3. Waiting for EP0 setup OUT data (EP0STATE_SETUP_OUT)
General logic flow:
1. When an EP0 SETUP packet is received:
- Read the request into EP0 setup request buffer (ctrlreq,
8 bytes)
- If this is an OUT request with data length, set the EP0
state to EP0STATE_SETUP_OUT and wait to receive data on
EP0.
- Otherwise, the SETUP request may be processed now (or,
in the case of the F4 driver, at the conclusion of the
SETUP phase).
2. When EP0 the EP0 OUT DATA packet is received:
- Verify state is EP0STATE_SETUP_OUT
- Read the request into the EP0 data buffer (ep0data, max
packet size)
- Now process the previously buffered SETUP request along
with the OUT data.
3. When the setup packet is dispatched to the class driver,
the OUT data must be passed as the final parameter in the
call.
Update 2013-9-2: The new USB device-side driver for the SAMA5D3
correctly supports OUT SETUP data following the same design as
per above.
Update 2013-11-7: David Sidrane has fixed with issue with the
STM32 F1 USB device driver. Still a few more to go before this
can be closed out.
Status: Open
Priority: High for class drivers that need EP0 data. For example, the
CDC/ACM serial driver might need the line coding data (that
Title: IMPROVED USAGE of STM32 USB RESOURCES
Description: The STM32 platforms use a non-standard, USB host peripheral
that uses "channels" to implement data transfers the current
logic associates each channel with an pipe/endpoint (with two
channels for bi-directional control endpoints). The OTGFS
peripheral has 8 channels and the OTGHS peripheral has 12
channels.
This works okay until you add a hub and try connect multiple
devices. A typical device will require 3-4 pipes and, hence,
4-5 channels. This effectively prevents using a hub with the
STM32 devices. This also applies to the EFM32 which uses the
same IP.
It should be possible to redesign the STM32 F4 OTGHS/OTGFS and
EFM32 host driver so that channels are dynamically assigned to
pipes as needed for individual transfers. Then you could have
more "apparent" pipes and make better use of channels.
Although there are only 8 or 12 channels, transfers are not
active all of the time on all channels so it ought to be
possible to have an unlimited number of "pipes" but with no
more than 8 or 12 active transfers.
Status: Open
Priority: Medium-Low
Description: A CDC/ACM host class driver has been added. This has been
testing by running the USB CDC/ACM host on an Olimex
LPC1766STK and using the configs/stm3210e-eval/usbserial
configuration (using the CDC/ACM device side driver). There
are several unresolved issues that prevent the host driver
from being usable:
Gregory Nutt
committed
- The driver works fine when configured for reduced or bulk-
only protocol on the Olimex LPC1766STK.
- Testing has not been performed with the interrupt IN channel
enabled (ie., I have not enabled FLOW control nor do I have
a test case that used the interrupt IN channel). I can see
that the polling for interrupt IN data is occurring
initially.
- I test for incoming data by doing 'nsh> cat /dev/ttyACM0' on
the Olimex LPC1766STK host. The bulk data reception still
works okay whether or not the interupt IN channel is enabled.
If the interrupt IN channel is enabled, then polling of that
channel appears to stop when the bulk in channel becomes
active.
- The RX reception logic uses the low priority work queue.
However, that logic never returns and so blocks other use of
the work queue thread. This is probably okay but means that
the RX reception logic probably should be moved to its own
dedicated thread.
Gregory Nutt
committed
- I get crashes when I run with the STM32 OTGHS host driver.
Apparently the host driver is trashing memory on receipt
of data.
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
UPDATE: This behavior needs to be retested with:
commit ce2845c5c3c257d081f624857949a6afd4a4668a
Author: Janne Rosberg <janne.rosberg@offcode.fi>
Date: Tue Mar 7 06:58:32 2017 -0600
usbhost_cdcacm: fix tx outbuffer overflow and remove now
invalid assert
commit 3331e9c49aaaa6dcc3aefa6a9e2c80422ffedcd3
Author: Janne Rosberg <janne.rosberg@offcode.fi>
Date: Tue Mar 7 06:57:06 2017 -0600
STM32 OTGHS host: stm32_in_transfer() fails and returns NAK
if a short transfer is received. This causes problems from
class drivers like CDC/ACM where short packets are expected.
In those protocols, any transfer may be terminated by sending
short or NUL packet.
commit 0631c1aafa76dbaa41b4c37e18db98be47b60481
Author: Gregory Nutt <gnutt@nuttx.org>
Date: Tue Mar 7 07:17:24 2017 -0600
STM32 OTGFS, STM32 L4 and F7: Adapt Janne Rosberg's patch to
STM32 OTGHS host to OTGFS host, and to similar implements for
L4 and F7.
Gregory Nutt
committed
- The SAMA5D EHCI and the LPC31 EHCI drivers both take semaphores
in the cancel method. The current CDC/ACM class driver calls
the cancel() method from an interrupt handler. This will
cause a crash. Those EHCI drivers should be redesigned to
permit cancellation from the interrupt level.
Gregory Nutt
committed
Most of these problems are unique to the Olimex LPC1766STK
DCD; some are probably design problems in the CDC/ACM host
driver. The bottom line is that the host CDC/ACM driver is
still immature and you could experience issues in some
configurations if you use it.
That all being said, I know of know no issues with the current
CDC/ACM driver on the Olimex LPC1766STK platform if the interrupt
IN endpoint is not used, i.e., in "reduced" mode. The only loss
of functionality is output flow control.
UPDATE: The CDC/ACM class driver may also now be functional on
the STM32. That needs to be verified.
Status: Open
Priority: Medium-Low unless you really need host CDC/ACM support.
o Libraries (libc/, libm/)
^^^^^^^^^^^^^^^^^^^^^^^^
Title: SIGNED time_t
Description: The NuttX time_t is type uint32_t. I think this is consistent
with all standards and with normal usage of time_t. However,
according to Wikipedia, time_t is usually implemented as a
signed 32-bit value.
Status: Open
Priority: Very low unless there is some compelling issue that I do not
know about.
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 array of pointers.
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().
patacongo
committed
UPDATE: There is growing functionality in libc/termios/ and in the
patacongo
committed
ioctl methods of several MCU serial drivers (stm32, lpc43, lpc17,
pic32). However, as phrased, this bug cannot yet be closed since
this "growing functionality" does not address all termios.h
functionality and not all serial drivers support termios.
Description: There is an issue with the way that getopt() handles errors that
return '?'.
1. Does getopt() reset its global variables after returning '?' so
that it can be re-used? That would be required to support where
the caller terminates parsing before reaching the last parameter.
2. Or is the client expected to continue parsing after getopt()
returns '?' and parse until the final parameter?
The current getopt() implementation only supports #2.
Status: Open
Priority: Low
Title: CONCURRENT STREAM READ/WRITE
Description: NuttX only supports a single file pointer so reads and writes
must be from the same position. This prohibits implementation
of behavior like that required for fopen() with the "a+" mode.
According to the fopen man page:
"a+ Open for reading and appending (writing at end of file).
The file is created if it does not exist. The initial file
position for reading is at the beginning of the file, but
output is always appended to the end of the file."
At present, the single NuttX file pointer is positioned to the
end of the file for both reading and writing.
Status: Open
Priority: Medium. This kind of operation is probably not very common in
deeply embedded systems but is required by standards.
Title: DIVIDE BY ZERO
Description: This is bug 3468949 on the SourceForge website (submitted by
Philipp Klaus Krause):
"lib_strtod.c does contain divisions by zero in lines 70 and 96.
AFAIK, unlike for Java, division by zero is not a reliable way to
get infinity in C. AFAIK compilers are allowed e.g. give a compile-
time error, and some, such as sdcc, do. AFAIK, C implementations
are not even required to support infinity. In C99 the macro isinf()
could replace the first use of division by zero. Unfortunately, the
macro INFINITY from math.h probably can't replace the second division
by zero, since it will result in a compile-time diagnostic, if the
implementation does not support infinity."
Status: Open
Priority:
patacongo
committed
Description: This implementation of dtoa in libc/stdio is old and will not
work with some newer compilers. See
http://patrakov.blogspot.com/2009/03/dont-use-old-dtoac.html
Status: Open
Priority: ??
Gregory Nutt
committed
Description: Only the %f floating point format is supported. Others are
accepted but treated like %f.
Priority: Medium (this might important to someone).
Title: FLOATING POINT PRECISION
Description: A fieldwidth and precision is required with the %f format. If %f
is used with no format, than floating numbers will be printed with
a precision of 0 (effectively presented as integers).
Status: Open
Priority: Medium (this might important to someone).
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
Title: LIBM INACCURACIES
Description: "..if you are writing something like robot control or
inertial navigation system for aircraft, I have found
that using the toolchain libmath is only safe option.
I ported some code for converting quaternions to Euler
angles to NuttX for my project and only got it working
after switching to newlib math library.
"NuttX does not fully implement IEC 60559 floating point
from C99 (sections marked [MX] in OpenGroup specs) so if
your code assumes that some function, say pow(), actually
behaves right for all the twenty or so odd corner cases
that the standards committees have recently specified,
you might get surprises. I'd expect pow(0.0, 1.0) to
return 0.0 (as zero raised to any positive power is
well-defined in mathematics) but I get +Inf.
"NuttX atan2(-0.0, -1.0) returns +M_PI instead of correct
-M_PI. If we expect [MX] functionality, then atan2(Inf, Inf)
should return M_PI/4, instead NuttX gives NaN.
"asin(2.0) does not set domain error or return NaN. In fact
it does not return at all as the loop in it does not
converge, hanging your app.
"There are likely many other issues like these as the Rhombus
OS code has not been tested or used that much. Sorry for not
providing patches, but we found it easier just to switch the
math library."
Ref: https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/7805
UPDATE: 2015-09-01: A fix for the noted problems with asin()
has been applied.
Gregory Nutt
committed
2016-07-30: Numerous fixes and performance improvements from
David Alessio.
Status: Open
Priority: Low for casual users but clearly high if you need care about
these incorrect corner case behaviors in the math libraries.
Gregory Nutt
committed
Title: REPARTITION LIBC FUNCTIONALITY
Description: There are many things implemented within the kernel (for example
under sched/pthread) that probably should be migrated in the
C library where it belongs.
I would really like to see a little flavor of a micro-kernel
at the OS interface: I would like to see more primitive OS
system calls with more higher level logic in the C library.
One awkward thing is the incompatibility of KERNEL vs FLAT
builds: In the kernel build, it would be nice to move many
of the thread-specific data items out of the TCB and into
the process address environment where they belong. It is
difficult to make this compatible with the FLAT build,
however.
Status: Open
Gregory Nutt
committed
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
Title: FORMATTING FIXED WIDTH INTEGERS
Description: Formats like this: lib_vsprintf(_, "%6.6u", 0) do not work.
There is no support for the precision/width option with
integer types. The format is simply is ignored and so can
even cause crashes.
For example:
int hello_main(int argc, char *argv[])
{
printf("Hello, World!!\n");
printf("%3.3u %3.3u %3.3u %3.3u %3.3u\n", 9, 99, 999, 9999, 99999);
return 0;
}
Generates this incorrect output:
NuttShell (NSH) NuttX-7.20
nsh> hello
Hello, World!!
9 99 999 9999 99999
nsh>
That output, of course, should have been:
9 99 999 999 999
The period and the precision value were being ignored (if
floating point was disabled). In that case, parsing of the
variable arguments could get out of sync. But a side
effect of the referenced change is that precision value is
now always parsed (but still incorrectly ignored for the
case of integer formats).
The fix would not be too difficult but would involve change
several functions. It would involve clipping the size of the
number string. For example:
/* Get the width of the output */
uwidth = getusize(FMT_CHAR, flags, n);
if (trunc > 0 && uwidth > trunc)
{
uwidth = trunc;
}
Then limiting the length of the output string to uwidth.
This would probably mean passing an additional parameter to
the many *toascii() functions like:
/* Output the number */
utoascii(obj, FMT_CHAR, flags, (unsigned int)n, uwidth);
Status: Open
Priority: Low
o File system / Generic drivers (fs/, drivers/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NOTE: The NXFFS file system has its own TODO list at nuttx/fs/nxffs/README.txt
Title: MISSING FILE SYSTEM FEATURES
Description: Implement missing file system features:
chmod() is probably not relevant since file modes are not
currently supported.
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
File privileges would also be good to support. But this is
really a small part of a much larger feature. NuttX has no
user IDs, there are no groups, there are no privileges
associated with either. User's don't need credentials.
This is really a system wide issues of which chmod is only
a small part.
User privileges never seemed important to me since NuttX is
intended for deeply embedded environments where there are
not multiple users with varying levels of trust.
truncate - The standard way of setting a fixed file size.
Often used with random access, data base files. There is no
simple way of doing that now (other than just writing data
to the file).
link, unlink, softlink, readlink - For symbolic links. Only
the ROMFS file system currently supports hard and soft links,
so this is not too important.
File locking
Special files - NuttX support special files only in the top-
level pseudo file system. Unix systems support many
different special files via mknod(). This would be
important only if it is an objective of NuttX to become a
true Unix OS. Again only supported by ROMFS.
True inodes - Standard Unix inodes. Currently only supported
by ROMFs.
The primary obstacle to all these is that each would require
changes to all existing file systems. That number is pretty
large. The number of file system implementations that would
need to be reviewed and modified As of this writing this
would include binfs, fat, hostfs, nfs, nxffs, procfs, romfs,
tmpfs, unionfs, plus pseduo-file system support.
Description: The ROMFS file system does not verify checksums on either
volume header on on the individual files.
Status: Open
Priority: Low. I have mixed feelings about if NuttX should pay a
performance penalty for better data integrity.
Title: SPI-BASED SD MULTIPLE BLOCK TRANSFERS
Description: The simple SPI based MMCS/SD driver in fs/mmcsd does not
yet handle multiple block transfers.
Status: Open
Priority: Medium-Low
Title: SDIO-BASED SD READ-AHEAD/WRITE BUFFERING INCOMPLETE
Description: The drivers/mmcsd/mmcsd_sdio.c driver has hooks in place to
support read-ahead buffering and write buffering, but the logic
is incomplete and untested.
Status: Open
Priority: Low
Description: All drivers that support the poll method should also report
Status: Open
Priority: Medium-Low
Description: When I enable CONFIG_RAMLOG_CONSOLE, the system does not come up
properly (using configuration stm3240g-eval/nsh2). The problem
may be an assertion that is occurring before we have a console.
Title: UNIFIED DESCRIPTOR REPRESENTATION
Description: There are two separate ranges of descriptors for file and
socket descriptors: if a descriptor is in one range then it is
recognized as a file descriptor; if it is in another range
then it is recognized as a socket descriptor. These separate
descriptor ranges can cause problems, for example, they makes
dup'ing descriptors with dup2() problematic. The two groups
of descriptors are really indices into two separate tables:
On an array of file structures and the other an array of
socket structures. There really should be one array that
is a union of file and socket descriptors. Then socket and
Another example of how the current implementation limits
functionality: I recently started to implement of the FILEMAX
(using pctl() instead sysctl()). My objective was to be able
to control the number of available file descriptors on a task-
by-task basis. The complexity due to the partitioning of
desciptor space in a range for file descriptors and a range
for socket descriptors made this feature nearly impossible to
implement.
Status: Open
Priority: Low
Title: DUPLICATE FAT FILE NAMES
Description: "The NSH and POSIX API interpretations about sensitivity or
insensitivity to upper/lowercase file names seem to be not
consistent in our usage - which can result in creating two
directories with the same name..."
Gregory Nutt
committed
Example using NSH:
nsh> echo "Test1" >/tmp/AtEsT.tXt
nsh> echo "Test2" >/tmp/aTeSt.TxT
nsh> ls /tmp
/tmp:
AtEsT.tXt
aTeSt.TxT
nsh> cat /tmp/aTeSt.TxT
Gregory Nutt
committed
nsh> cat /tmp/AtEsT.tXt
Gregory Nutt
committed
Title: MISSING FILES IN NSH 'LS' OF A DIRECTORY
Description: I have seen cases where (1) long file names are enabled,
but (2) a short file name is created like:
nsh> echo "This is another test" >/mnt/sdcard/another.txt
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
But then on subsequent 'ls' operations, the file does not appear:
nsh> ls -l /mnt/sdcard
I have determined that the problem is because, for some as-
of-yet-unkown reason the short file name is treated as a long
file name. The name then fails the long filename checksum
test and is skipped.
readdir() (and fat_readdir()) is the logic underlying the
failure and the problem appears to be something unique to the
fat_readdir() implementation. Why? Because the file is
visible when you put the SD card on a PC and because this
works fine:
nsh> ls -l /mnt/sdcard/another.txt
The failure does not happen on all short file names. I do
not understand the pattern. But I have not had the opportunity
to dig into this deeply.
Status: Open
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
Priority: Perhaps not a problem??? I have analyzed this problem and
I am not sure what to do about it. I am suspected that a
fat filesystem was used with a version of NuttX that does
not support long file name entries. Here is the failure
scenario:
1) A file with a long file name is created under Windows.
2) Then the file is deleted. I am not sure if Windows or
NuttX deleted the file, but the resulting directory
content is not compatible with NuttX with long file
name support.
The file deletion left the full sequence of long
file name entries intact but apparently delete only
the following short file name entry. I am thinking
that this might have happened because a version of NuttX
with only short file name support was used to delete
the file.
3) When a new file with a short file name was created, it
re-used the short file name entry that was previously
deleted. This makes the new short file name entry
look like a part of the long file name.
4) When comparing the checksum in the long file name
entry with the checksum of the short file name, the
checksum fails and the entire directory sequence is
ignored by readder() logic. This the file does not
appear in the 'ls'.
See also the NxWidgets TODO list file for related issues.
Description: Testing of all APIs is not complete. See
http://nuttx.sourceforge.net/NXGraphicsSubsystem.html#testcoverage
Status: Open
Priority: Medium
Title: ITALIC FONTS / NEGATIVE FONT OFFSETS
Description: Font metric structure (in include/nuttx/nx/nxfont.h) should allow
negative X offsets. Negative x-offsets are necessary for certain
glyphs (and is very common in italic fonts).
For example Eth, icircumflex, idieresis, and oslash should have
offset=1 in the 40x49b font (these missing negative offsets are
NOTE'ed in the font header files).
Status: Open. The problem is that the x-offset is an unsigned bitfield
in the current structure.
Priority: Low.
patacongo
committed
Title: RAW WINDOW AUTORAISE
Description: Auto-raise only applies to NXTK windows. Shouldn't it also apply
to raw windows as well?
Status: Open
Priority: Low
Title: AUTO-RAISE DISABLED
Description: Auto-raise is currently disabled in NX multi-server mode. The
patacongo
committed
reason is complex:
- Most touchscreen controls send touch data a high rates
- In multi-server mode, touch events get queued in a message
queue.
- The logic that receives the messages performs the auto-raise.
But it can do stupid things after the first auto-raise as
patacongo
committed
I am thinking that auto-raise ought to be removed from NuttX
and moved out into a graphics layer (like NxWM) that knows
more about the appropriate context to do the autoraise.
Status: Open
Priority: Medium low
patacongo
committed
Title: NxTERM VT100 SUPPORT
Description: If the NxTerm will be used with the Emacs-like command line
Gregory Nutt
committed
editor (CLE), then it will need to support VT100 cursor control
commands.
Status: Open
Priority: Low, the need has not yet arisen.
Description: One of the most awkward things to handle in the NX windowing
system is the re-draw callback. This is difficult because it
requires ad hoc, custom logic to be able to do the redrawing
in most cases.
One solution would be to provide a per-window framebuffer.
All rending would be performed into the per-window framebuffer
and the rended bits would be copied the LCD or framebuffer
device memory on demand when the redraw is required.
This would (a) greatly simplify the graphics interface, (b)
greatly improve redraw performance, and (c) enable a more
generic use of the windowing. The downside would be a large
usage of memory to hold all of the framebuffers, one for each
window.
Status: Open
Priority: Low, of mostly strategic value.
Title: VERTICAL ANTI-ALIASING
Description: Anti-aliasing is implemented along the horizontal raster line
with fractional pixels at the ends of each line. There is no
accounting for fractional pixels in the vertical direction.
As a result lines closer to vertical receive better anti-
aliasing than lines closer to horizontal.
Status: Open
Priority: Low, not a serious issue but worth noting. There is no plan
to change this behavior.
Title: REMOVE SINGLE USER MODE
Description: NX graphics supports two modes: A simple single user mode and
more complex multi-user mode selected with CONFIG_NX_MULTIUSER=y.
In this configuration, an application can start the NX server
with boardctrl(BOARDIOC_NX_START); After that, all graphic
interactions are via a thin layer in libnx/. The OS
interface is only via messages sent and received using POSIX
message queues. So this is good code and respects all of the
POSIX interfacing rules. Hence, it works well in all build
modes (FLAT, PROTECTED, and KERNEL builds).
But without CONFIG_NX_MULTIUSER, the single user applications
violate all of the rules and calls internal NX functions
directly. This includes all calls to internal OSfunctions
with names like, nx_open, up_fbinitialize, board_lcd_*, and
others. This is a violation of interfacing standard in all
cases and can only be made to work in the FLAT build mode.
The single user mode does have some desirable properties: It
is lighter weight and so more suitable for very resource limited
platforms. But I think that in the long run the only reasonable
solution is to eliminate the single user mode and provide only
the multi-user mode with the message queue interface.
Status: Open
Priority: Low-Medium, not a serious issue but worth noting. Single user