| /Zephyr-latest/snippets/bt-ll-sw-split/ |
| D | README.rst | 6 You can build with this snippet by following the instructions in :ref:`the snippets usage page<usin…
7 When building with ``west``, you can do:
|
| /Zephyr-latest/boards/atmarktechno/degu_evk/doc/ |
| D | index.rst | 4 and can connect to an OpenThread mesh network. The Kit has a
5 Nordic nRF52840 SoC and NXP A71CH Secure Element, and can
|
| /Zephyr-latest/doc/connectivity/networking/api/ |
| D | websocket.rst | 14 The Websocket client API can be used directly by application to establish
15 a Websocket connection to server, or it can be used as a transport for other
29 protocols like MQTT. The Zephyr MQTT client library can be configured to use
48 The Websocket socket can then be used to send or receive data, and the
51 BSD socket API functions can be used to send and receive application data.
|
| D | net_if.rst | 25 The network interface can be turned ON by calling ``net_if_up()`` and OFF
29 The network interfaces can be referenced either by a ``struct net_if *``
30 pointer or by a network interface index. The network interface can be
38 by DHCPv4, for example. If needed though, the application can set a device's
43 this default interface means can be configured via options like
49 The transmitted and received network packets can be classified via a network
51 (VLANs) are used. Higher priority packets can be sent or received earlier than
52 lower priority packets. The traffic class setup can be configured by
68 :c:enumerator:`NET_IF_UP` flag and is controlled by the application. It can be
83 The PHY status is represented with :c:enumerator:`NET_IF_LOWER_UP` flag and can
[all …]
|
| /Zephyr-latest/doc/connectivity/networking/ |
| D | armfvp_user_networking_setup.rst | 27 More details about Arm FVP user mode networking can be obtained from here:
33 Arm FVP user mode networking can be enabled in any applications and it doesn't
41 * You can use TCP and UDP over IP, but not ICMP (ping).
44 * You can only use DHCP within the private network.
45 * You can only make inward connections by mapping TCP ports on the host to
|
| /Zephyr-latest/samples/modules/canopennode/src/ |
| D | main.c | 202 struct canopen_context can; in main() local
210 can.dev = CAN_INTERFACE; in main()
211 if (!device_is_ready(can.dev)) { in main()
238 err = CO_init(&can, CONFIG_CANOPEN_NODE_ID, CAN_BITRATE); in main()
305 CO_delete(&can); in main()
|
| /Zephyr-latest/samples/bluetooth/bap_unicast_client/ |
| D | README.rst | 13 This sample can be found under
43 You can build both the application core image and an appropriate controller image for the network
52 If you prefer to only build the application core image, you can do so by doing instead:
59 In that case you can pair this application core image with the
66 Similarly to how you would for real HW, you can do:
|
| /Zephyr-latest/samples/bluetooth/bap_unicast_server/ |
| D | README.rst | 13 This sample can be found under
43 You can build both the application core image and an appropriate controller image for the network
52 If you prefer to only build the application core image, you can do so by doing instead:
59 In that case you can pair this application core image with the
66 Similarly to how you would for real HW, you can do:
|
| /Zephyr-latest/samples/bluetooth/cap_initiator/ |
| D | README.rst | 14 This sample can be found under :zephyr_file:`samples/bluetooth/cap_initiator` in the Zephyr tree.
34 You can build both the application core image and an appropriate controller image for the network
43 If you prefer to only build the application core image, you can do so by doing instead:
50 In that case you can pair this application core image with the
57 Similarly to how you would for real HW, you can do:
|
| /Zephyr-latest/samples/bluetooth/pbp_public_broadcast_sink/ |
| D | README.rst | 15 This sample can be found under
36 You can build both the application core image and an appropriate controller image for the network
45 If you prefer to only build the application core image, you can do so by doing instead:
52 In that case you can pair this application core image with the
59 Similarly to how you would for real HW, you can do:
|
| /Zephyr-latest/samples/bluetooth/pbp_public_broadcast_source/ |
| D | README.rst | 15 This sample can be found under
36 You can build both the application core image and an appropriate controller image for the network
45 If you prefer to only build the application core image, you can do so by doing instead:
52 In that case you can pair this application core image with the
59 Similarly to how you would for real HW, you can do:
|
| /Zephyr-latest/doc/services/debugging/ |
| D | cpu_load.rst | 6 Module can be used to track how much time is spent in idle. It is using tracing hooks
12 precision is needed a :ref:`counter_api` device can be used.
14 Load can also be reported periodically using a logging message. Period is configured using :kconfig…
|
| /Zephyr-latest/boards/beagle/beaglev_fire/doc/ |
| D | index.rst | 24 Applications for the ``beaglev_fire`` board configuration can be built as usual:
36 You can get them as a part of SoftConsole SDK.
37 Download and installation instructions can be found on
44 Now you can run ``tio <port>`` in a terminal window to access the UART debug port connection. Once …
45 are connected properly you can press the Reset button which will show you a progress bar like:
51 Once you see that progress bar on your screen you can start pressing any button (0-9/a-z) which
54 With the necessary tools installed, you can connect to the board using OpenOCD.
64 the board. You can use the RISC-V GDB from the Zephyr SDK.
88 …re-services/tree/master/tools/hss-payload-generator>`_ tool to generate an image that HSS can boot.
106 After generating the image, you can flash it to the board by restarting a board that's connected ov…
[all …]
|
| /Zephyr-latest/boards/norik/octopus_io_board/doc/ |
| D | index.rst | 44 More information about the board can be found at the `Octopus IO-Board Product Page`_
64 The GPIO pin header provides 7 I/O pins, which can be used as digital input/output. Some of them al…
69 The Octopus IO-Board can be powered from the following sources:
76 …m USB-C or solar cell, the board can charge the Li-Po battery. The battery voltage can be monitore…
81 …gulator that is used to power the Octopus SoM and peripherals. The EN2 pin can be used to enable/d…
82 This can be used to power off peripherals to save power when they are not needed.
89 Norik Octopus IO-Board can be programmed and debugged using the Tag-Connect TC2030-IDC 6-pin connec…
95 Some examples don't require non secure mode and can be built with ``octopus_io_board/nrf9160`` boar…
110 Replace <tty_device> with the port where the Octopus IO-Board can be found. For example, under Linu…
|
| /Zephyr-latest/doc/connectivity/usb/api/ |
| D | hid.rst | 6 Common USB HID part that can be used outside of USB support, defined in
22 The pre-defined Mouse and Keyboard report descriptors can be used by
|
| /Zephyr-latest/doc/services/device_mgmt/ |
| D | mcumgr_callbacks.rst | 13 of this is with the fs_mgmt group, whereby file access can be gated, the
15 access to said file, or it can rewrite the provided path to a different path
24 The base callback/notification system can be enabled using
30 :c:type:`mgmt_cb` type definition can then be declared and registered by
35 With the system enabled, a basic handler can be set up and defined in
71 Multiple callbacks can be setup to use a single function as a common callback,
72 and many different functions can be used for each event by registering each
73 group once, or all notifications for a whole group can be enabled by using one
74 of the ``MGMT_EVT_OP_*_ALL`` events, alternatively a handler can setup for
76 handlers, events can be combined that are in the same group only, for example
[all …]
|
| /Zephyr-latest/boards/renesas/rzt2l_rsk/doc/ |
| D | index.rst | 7 By simply connecting the bundled cable to your PC, you can immediately start evaluation through an
9 Octal Flash so you can evaluate various functions of the RZ/T2L without an extension board.
13 so you can evaluate various functions of the RZ/T2L without an extension board
16 * Emulator circuit is mounted, and program debugging can be started by simply connecting USB cable
39 The Renesas RZ/T2L MPU documentation can be found at `RZ/T2L Group Website`_
48 Detailed hardware features for the board can be found at `RZ/T2L-RSK Website`_
69 Applications for the ``rzt2l_rsk`` board can be
|
| /Zephyr-latest/boards/renesas/rzn2l_rsk/doc/ |
| D | index.rst | 7 With the on-board emulator, you can start evaluation by simply connecting the bundled cable with
9 you can fully evaluate functions without an extension board.
13 so functions of target MPU can be fully evaluated
16 * Emulator circuit is mounted, and program debugging can be started by simply connecting USB cable
41 The Renesas RZ/N2L MPU documentation can be found at `RZ/N2L Group Website`_
50 Detailed hardware features for the board can be found at `RZ/N2L-RSK Website`_
71 Applications for the ``rzn2l_rsk`` board can be
|
| /Zephyr-latest/doc/kernel/services/synchronization/ |
| D | condvar.rst | 16 Any number of condition variables can be defined (limited only by available RAM). Each
19 To wait for a condition to become true, a thread can make use of a condition
22 A condition variable is basically a queue of threads that threads can put
30 Some other thread, when it changes said state, can then wake one (or more)
38 A condition variable must be initialized before it can be used.
58 Alternatively, a condition variable can be defined and initialized at compile time
70 A thread can wait on a condition by calling :c:func:`k_condvar_wait`.
|
| /Zephyr-latest/doc/connectivity/bluetooth/shell/audio/ |
| D | ccp.rst | 6 The Call Control Server is a role that typically resides on devices that can make calls,
12 The Server can be controlled locally, or by a remote device (when in a call). For
44 The Client can control a remote CCP server device.
45 For example a remote device may have an incoming call that can be accepted by the Client.
|
| /Zephyr-latest/samples/subsys/demand_paging/ |
| D | README.rst | 10 This sample demonstrates how demand paging can be leveraged to deal with
12 can be tagged to be loaded into memory on demand, and also be automatically
26 This application can be built and executed on QEMU as follows:
50 prints can be enabled using :kconfig:option:`CONFIG_LOG` and
|
| /Zephyr-latest/samples/drivers/can/counter/ |
| D | README.rst | 1 .. zephyr:code-sample:: can-counter
24 The sample can be built and executed for boards with a SoC that have an
34 :zephyr-app: samples/drivers/can/counter
45 :zephyr-app: samples/drivers/can/counter
|
| /Zephyr-latest/doc/services/input/ |
| D | gpio-kbd.rst | 8 This is an overview of some common setups and how they can be supported by the
27 The system must support GPIO interrupts, and the interrupt can be enabled on all
49 time can be tweaked by changing the ``settle-time-us`` property.
116 In this case, the driver can be configured to not use interrupt at all, and
120 This configuration can be enabled by setting the ``idle-mode`` property to
135 impossible to select all of them at the same time, the driver can be configured
138 This can be done by setting ``idle-mode`` to ``scan`` and ``poll-timeout-ms``
167 limits the matrix row size to 8. This can be increased to 16 by enabling the
174 populated can be specified using the ``actual-key-mask`` property. This allows
198 The actual key mask can be changed at runtime by enabling
[all …]
|
| /Zephyr-latest/doc/hardware/emulator/ |
| D | bus_emulators.rst | 14 for an I2C compass such that it appears on the I2C bus and can be used
20 been completed. This allows for testing that high-level code can
21 handle these situations correctly. Test coverage can therefore
34 Below that are peripheral drivers, such as the AT24 EEPROM driver. We can test
39 Separately we can test the STM32 and NXP I2C drivers on real hardware using API
41 can validate much of the driver functionality.
43 Putting the two together, we can test the application and peripheral code
48 Using the above framework we can test an entire application (e.g. Embedded
51 With this approach we can:
60 All of this can work in the emulated environment or on real hardware.
[all …]
|
| /Zephyr-latest/doc/connectivity/bluetooth/api/mesh/ |
| D | access.rst | 32 Mesh models have several parameters that can be configured either through
39 The opcode list contains all message opcodes the model can receive, as well as
41 can support any number of opcodes, but each opcode can only be listed by one
54 The AppKey list contains all the application keys the model can receive
58 The maximum number of supported application keys each model can hold is
73 can hold is configured with the :kconfig:option:`CONFIG_BT_MESH_MODEL_GROUP_COUNT`
103 By setting :c:member:`bt_mesh_model_pub.retr_update` to 1, the model can
105 on every retransmission. This can, for example, be used by models that make
106 use of a Delay parameter, which can be adjusted for every retransmission.
107 The :c:func:`bt_mesh_model_pub_is_retransmission` function can be
[all …]
|
