sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update readme. Fix stray newline in shenzhou Make.defs

Browse Source
This commit is contained in:
Gregory Nutt 2017-08-08 18:14:40 -06:00
parent 31fa65a381
commit 663f5dfbdd
2 changed files with 11 additions and 18 deletions
Show Stats 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 be beefed up to handle this routinely without asserting and without
leaving the Spirit in a bad state. 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 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. 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 I would say it is functional but fragile in this usage, but probably
robust in a less busy environment. robust in a less busy environment.
2017-08-08: The warning debug messages noted yesterday are no longer 2017-08-08: Added broadcast packet transfers using the hub-based
present. No clue why. broadcast UDP client. This appears to be a problem the HC06
compression and/or decompression. The decompression logic comes up
Added broadcast packet transfers using the hub-based broadcast UDP with the destination address of ff02::ff00:00fe:3500 (which derives
client. This appears to be a problem the HC06 compression and/or from the receiving node address of 37) instead of the all-nodes
decompression. The decompression logic comes up with the multicast address of ff02::0001. It is then out of sync with the
destination address of ff02::ff00:00fe:3500 (which derives from the IPHC headers and is unable to uncompress the rest of the packet
receiving node address of 37) instead of the all-nodes multicast correctly.
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 Trying again with HC1 compression, I see other isses. The first
frame is received correctly, but the following frames have an incorrect 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 we are sending to the multicast or broadcast address, should we
not also disable ACKs, retries, and RX timeouts? What will happen not also disable ACKs, retries, and RX timeouts? What will happen
if multiple radios ACK? At a minimum it could keep the driver 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__ AFLAGS = $(CFLAGS) -D__ASSEMBLY__
NXFLATLDFLAGS1 = -r -d -warn-common NXFLATLDFLAGS1 = -r -d -warn-common
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.ld NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.ld -no-check-sections
-no-check-sections
#NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-pcrel.ld -no-check-sections #NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-pcrel.ld -no-check-sections
LDNXFLATFLAGS = -e main -s 2048 LDNXFLATFLAGS = -e main -s 2048