zephyr

History

Florian Grandel 1ee4d3ed77 net: l2: ieee802154: document L1/L2 sep. of concerns The method ieee802154_radio_handle_ack() does not belong to the PHY/radio layer but to the L2 layer. It is a callback called from the radio layer into the L2 layer and to be implemented by all L2 stacks. This is the same pattern as is used for ieee802154_init(). The '_radio_' infix in this function is therefore confusing and conceptually wrong. This change fixes the naming inconsistency and extensively documents its rationale. It is assumed that the change can be made without prior deprecation of the existing method as in the rare cases where users have implemented custom radio drivers these will break in obvious ways and can easily be fixed. Nevertheless such a rename would not be justified on its own if it were not for an important conceptual reason: The renamed function represents a generic "inversion-of-control" pattern which will become important in the TSCH context: It allows for clean separation of concerns between the PHY/radio driver layer and the MAC/L2 layer even in situations where the radio driver needs to be involved for performance or deterministic timing reasons. This "inversion-of-control" pattern can be applied to negotiate timing sensitive reception and transmission windows, it let's the L2 layer deterministically timestamp information elements just-in-time with internal radio timer counter values, etc. Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>		2023-06-17 16:20:21 -04:00
..
src	net: l2: ieee802154: document L1/L2 sep. of concerns	2023-06-17 16:20:21 -04:00
app.overlay	samples: net: Remove label property from devicetree overlays	2022-07-19 10:30:39 +02:00
CMakeLists.txt	cmake: increase minimal required version to 3.20.0	2021-08-20 09:47:34 +02:00
prj.conf	samples: Explicitly disable boot USB device support init at boot	2023-01-10 12:21:10 +01:00
README.rst	kconfig: remove redundant IEEE 802.15.4 defaults or selections	2022-08-05 12:56:47 +02:00
sample.yaml	samples: net: fix tags/identifiers	2023-06-02 04:47:06 -04:00

README.rst

.. _wpan_serial-sample:

802.15.4 "serial-radio" sample
##############################

Overview
********

The wpan_serial sample shows how to use hardware with 802.15.4 radio and USB
controller as a "serial-radio" device for Contiki-based border routers.

Requirements
************

The sample assumes that 802.15.4 radio and USB controller are supported on
a board. You can pick, for example, a transceiver such as a CC2520 or RF2xx
using overlays, or by using an SoC with a built-in radio, such as a kw41z,
nrf5, or samr21.

Building and Running
********************

#. Before building and running this sample, be sure your Linux system's
   ModemManager is disabled, otherwise, it can interfere with serial
   port communication:

   .. code-block:: console

     $ sudo systemctl disable ModemManager.service

#. Build the sample Zephyr application to a board with a 802.15.4 radio
   and USB controller. There are configuration files for various setups
   in the ``samples/net/wpan_serial`` directory:

   - :file:`prj.conf`
     This is the standard default config. This can be used by itself for
     hardware which has native 802.15.4 support.

   To build the wpan_serial sample:

   .. zephyr-app-commands::
     :zephyr-app: samples/net/wpan_serial
     :board: <board name>
     :conf: "prj.conf [overlay-<RADIO>.conf]"
     :goals: build
     :compact:

   Here's how to build and flash the sample for the Atmel SAM R21
   Xplained Pro Development Kit.

   .. zephyr-app-commands::
     :zephyr-app: samples/net/wpan_serial
     :board: atsamr21_xpro
     :goals: build flash
     :compact:

#. Connect board to Linux PC, /dev/ttyACM[number] should appear.
#. Run Contiki-based native border router (6lbr, native-router, etc)
   Example for Contiki:

   .. code-block:: console

     $ cd examples/ipv6/native-border-router
     $ make
     $ sudo ./border-router.native -v5 -s ttyACM0 fd01::1/64

Now you have a Contiki native board router.  You can access its web-based
interface with your browser using the server address printed in the
border-router output.

.. code-block:: console

  ...
  Server IPv6 addresses:
   0x62c5c0: =>fd01::212:4b00:531f:113a
  ...

Use your browser to access ``http://[fd01::212:4b00:531f:113a]/`` and you'll
see available neighbors and routes.