Aksal/nuttx
3
1
Fork 1
mirror of https://github.com/apache/nuttx.git synced 2026-09-01 22:53:01 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 3

Merged nuttx/nuttx into master

Browse source
This commit is contained in:
Masayuki Ishikawa 2017-08-09 17:24:58 +09:00
commit 62e68ff8d2
5 changed files with 14 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

26
configs/b-l475e-iot01a/README.txt
View file

@ -583,26 +583,19 @@ Configuration sub-directories
be beefed up to handle this routinely without asserting and without
leaving the Spirit in a bad state.
One remaining issue with the above is that when we fail to go to the TX
state, there is a lot of warning debug output. ANY debug output while
the Spirit is heavily loaded WILL cause failures and packet loss!
Perhaps using a RAMLOG would remedy this.
The TCP test beats the radio very hard and it is actually heartening
that there are no failures that lead to data loss in this environment.
I would say it is functional but fragile in this usage, but probably
robust in a less busy environment.
2017-08-08: The warning debug messages noted yesterday are no longer
present. No clue why.
Added broadcast packet transfers using the hub-based broadcast UDP
client. This appears to be a problem the HC06 compression and/or
decompression. The decompression logic comes up with the
destination address of ff02::ff00:00fe:3500 (which derives from the
receiving node address of 37) instead of the all-nodes multicast
address of ff02::0001. It is then out of sync with the IPHC headers
and is unable to uncompress the rest of the packet correctly.
2017-08-08: Added broadcast packet transfers using the hub-based
broadcast UDP client. This appears to be a problem the HC06
compression and/or decompression. The decompression logic comes up
with the destination address of ff02::ff00:00fe:3500 (which derives
from the receiving node address of 37) instead of the all-nodes
multicast address of ff02::0001. It is then out of sync with the
IPHC headers and is unable to uncompress the rest of the packet
correctly.
Trying again with HC1 compression, I see other isses. The first
frame is received correctly, but the following frames have an incorrect
@ -614,4 +607,5 @@ Configuration sub-directories
we are sending to the multicast or broadcast address, should we
not also disable ACKs, retries, and RX timeouts? What will happen
if multiple radios ACK? At a minimum it could keep the driver
unnecessarily busy.
unnecessarily busy. There is some prototype code to do just this
in the driver, but does not seem to work.

3
configs/shenzhou/scripts/Make.defs
View file

@ -99,8 +99,7 @@ CPPFLAGS = $(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES)
AFLAGS = $(CFLAGS) -D__ASSEMBLY__
NXFLATLDFLAGS1 = -r -d -warn-common
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.ld
-no-check-sections
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.ld -no-check-sections
#NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-pcrel.ld -no-check-sections
LDNXFLATFLAGS = -e main -s 2048

1
net/ipforward/ipfwd_dropstats.c
View file

@ -41,6 +41,7 @@
#include <errno.h>
#include <nuttx/mm/iob.h>
#include <nuttx/net/ip.h>
#include <nuttx/net/netstats.h>

1
net/ipforward/ipfwd_poll.c
View file

@ -42,6 +42,7 @@
#include <stdint.h>
#include <nuttx/net/netdev.h>
#include <nuttx/net/net.h>
#include "devif/devif.h"
#include "ipforward/ipforward.h"

2
net/netdev/netdev_lladdrsize.c
View file

@ -108,7 +108,7 @@ static inline int netdev_pktradio_addrlen(FAR struct net_driver_s *dev)
*
****************************************************************************/
int netdev_type_lladdrsize(FAR struct net_driver_s *dev)
int netdev_dev_lladdrsize(FAR struct net_driver_s *dev)
{
DEBUGASSERT(dev != NULL);