Lines Matching +full:zephyr +full:- +full:bugs +full:-
50 The main purpose of these bsim boards is to be test-benches for
53 least, run with the Zephyr RTOS just like for any other
80 - Unit tests:
83 Zephyr provides a unit testing target (unit_testing) which is not related to
85 - Integration tests on real HW: Allows testing with the real SW
93 - Integration tests on workstation (what the POSIX arch and these boards enable)
95 - Using bsim boards: Allow testing the embedded SW (or a subset), including
98 - Using bsim boards with the BabbleSim Physical layer simulation allows
102 - Using bsim boards, and the `EDTT`_ framework: With the EDTT framework we can
108 - Using Zephyr's :ref:`native_sim <native_sim>` board: It also allows integration testing of
111 that platform. Just like the bsim boards, this Zephyr target board can
112 be used with or without Zephyr's ztest system and twister.
116 - Zephyr's ztest infrastructure and Zephyr's twister:
128 Relationship between Zephyr, the native simulator, the nRF HW models and BabbleSim
131 As shown in the figure below, when you build your embedded application targeting one of Zephyr's
134 Your application is first built and linked with the Zephyr kernel and any subsystems and network
142 :figclass: align-center
144 Relationship between Zephyr, the native simulator, the nRF HW models and BabbleSim.
147 use :ref:`sysbuild<sysbuild>` to build an executable, where, for each MCU, its application, Zephyr
151 Layering: Zephyr's arch, soc and board layers
156 - The `native simulator`_ runner is used to execute the code in your host.
157 - The architecture, SOC and board components of Zephyr are replaced with
159 - The architecture (arch) is the Zephyr :ref:`POSIX architecture<Posix arch>`
163 - The POSIX architecture provides an adaptation from the Zephyr arch API
167 - The SOC ``inf_clock`` layer provides an adaptation to the native simulator CPU "simulation"
168 and the handling of control between the "CPU simulation" (Zephyr threads) and the
170 - The board layer provides all SOC/ IC specific content, including
172 busy wait API (see :ref:`posix_busy_wait<posix_busy_wait>`), and Zephyr's printk backend.
173 Note that in a normal Zephyr target interrupt handling and a custom busy wait
174 would be provided by the SOC layer, but abusing Zephyr's layering, and for the
188 :alt: Zephyr layering in native & bsim builds
189 :figclass: align-center
191 Overall architecture in a Zephyr application in an embedded target vs a bsim
225 real wall-clock time. As described in
249 The communication between a Zephyr device and other simulated devices is
256 :alt: Communication between a Zephyr device and other simulated devices
257 :figclass: align-center
259 Communication between a Zephyr device and other simulated devices
266 About using Zephyr APIs
269 Note that even though part of the bsim board code is linked with the Zephyr kernel,
270 one should in general not call Zephyr APIs from the board code itself.
271 In particular, one should not call Zephyr APIs from the original/HW models
272 thread as the Zephyr code would be called from the wrong context,
275 In general board code should be considered as lower level than the Zephyr OS,
281 The same applies to other Zephyr APIs, including the entropy API, etc.
290 Any message printed to these APIs, and by extension by default to Zephyr's ``printk``,
311 and Zephyr OS, a hook to process possible command line arguments, and, a hook
331 NATIVE_TASKS or Zephyr's PRE/POST kernel driver initialization APIs as this
345 - Basic arguments: to enable selecting things like trace verbosity, random seed,
349 - The HW models command line arguments: The HW models will expose which
352 - Test (bs_tests) control: To select a test for each embedded CPU,
362 - Endianness: Code will be built for the host target architecture, which is
365 may not work in the other due to endianness bugs.
366 Note that Zephyr code is be written to support both big and little endian.
367 - WordSize: The bsim targets, as well as normal embedded targets are 32 bit