Add common log level for all IEEE802154 drivers.
Change-Id: If92c96b14e630d4482aadf9cacb25662d6663399
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
Sample projects that pair the frdm_k64f board with a cc2520 require
additional pinmux settings beyond the standard frdm_k64f pinmux. These
settings used the private k64 pinmux API rather than the public pinmux
API.
Because the mcux pinmux driver now always supports the public pinmux API
(vs. the k64 pinmux driver which only supported it in pinmux dev mode),
we can convert the frdm_k64f_cc2520 projects to use the public pinmux
API and the mcux pinmux driver.
Change-Id: Idfae8393171b007d8629e34bfae64255f55c6792
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
This will help to track only what's wanted (ipv6, tpc, udp, else...) if
needed to.
Change-Id: I5c2e5e582db629b5d0e1cd98004f693c50f532a4
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
When zephyr receives a 15.4 frames it allocates 1 RX buf (nbuf) and 1
DATA (buf), and it gets queued on net stack for post processing.
Problem: receiving a lot of frames is just completely nominal and very
fast (timing is critical in radio, and the rx thread of the radio driver
has a high priority, much higher than net stack's rx post processing).
So guess what happens when CONFIG_NET_NBUF_RX_COUNT=10 though let's say
12 packets are coming in?
The RX buffer pools gets empty and soon the system hangs on getting a
newly allocated one.
This proper CONFIG_NET_NBUF_RX_COUNT tweak fixes the issue, however some
future work will reduce the need of so many RX meta buf:
- l2's recv could be called right away at net_recv_data, before queuing
the buffer for post-processing, but this could affects reception
timing on radio side, which is critical.
- An l2 pre-processing (in the middle of what current l2 recv does)
could be implemented, it would be technology depenedent (aka: not
mandatory on all l2) and could quickly decide what to do and at best
drop the whole, or at least drop the RX meta buf (frag would still be
kept). Let's see.
Jira: ZEP-1427
Change-Id: Ic75b02efa36e35b450c02b3e6439a8d73f03f839
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Fixes echo_client and echo_server samples.
Fixes compile error:
...
src/built-in.o: In function `fdrm_k64f_cc2520_pinmux_setup':
samples/net/echo_client/src/../../common/cc2520_frdm_k64f.c:93:
undefined reference to `_fsl_k64_set_pin'
samples/net/echo_client/src/../../common/cc2520_frdm_k64f.c:93:
undefined reference to `_fsl_k64_set_pin'
samples/net/echo_client/src/../../common/cc2520_frdm_k64f.c:93:
undefined reference to `_fsl_k64_set_pin'
...
Change-Id: I590f88f6bd083a30deea77fa860f001a3a55b278
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Common code found in samples/net/common
App is built with:
make BOARD=frdm_k64f CONF_FILE=prj_frdm_k64f_cc2520.conf
Note: debug messages are enabled on many parts of the system, and these
are killing the timings. So it's not unusual at all to see rx errors on
cc2520 side. Without most of the debug, much less error will occur (if
any when dbg is fully disabled).
Change-Id: Ib6f0868c300652270661e72e80108804308164ab
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Maureen Helm