OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/samples/boards/nrf/nrf53_sync_rtc
History
Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> 
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.

The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.

NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
 		2022-09-05 16:31:47 +02:00
..
net includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> 2022-09-05 16:31:47 +02:00
src includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> 2022-09-05 16:31:47 +02:00
CMakeLists.txt cmake: Update cmake_minimum_required to 3.20.0 2022-07-04 10:18:45 +02:00
README.rst
…
prj.conf samples: nrf53_sync_rtc: drop IPM support 2022-08-08 10:52:10 +02:00
sample.yaml samples: nrf53_sync_rtc: drop IPM support 2022-08-08 10:52:10 +02:00

README.rst 

.. _nrf53_sync_rtc_sample:

Synchronized RTC
################

Overview
********

Sample is showing how RTC clocks used for system clock on application and network
core are synchronized. The result of synchronization is an offset value on network
core which can be applied to the system tick for logging timestamping.

Sample is using IPM driver and IPC HAL to produce events which occur at same time on
both cores. Application core periodically reads current system tick and stores it in
the shared memory and triggers IPC task which results in the interrupt on the network
core. In the context of the IPC interrupt handler, network core is logging timestamp
from shared memory and local system tick updated by the offset. User can observe
that before synchronization procedure is completed, timestamps differ significantly
and once procedure is completed timestamps are synchronized. Network core timestamp
may be slightly behind (usually 1 tick) due to latency introduced by the
interrupt handling.

For simplicity and low latency sample is not using more sophisticated IPM protocols.

Building the application for nrf5340dk_nrf5340_cpuapp
*****************************************************

.. zephyr-app-commands::
   :zephyr-app: samples/boards/nrf/nrf53_sync_rtc
   :board: nrf5340dk_nrf5340_cpuapp
   :goals: flash "flash --hex-file build/sync_rtc_net-prefix/src/sync_rtc_net-build/zephyr/zephyr.hex"

Open a serial terminals (for example Minicom or PuTTY) and connect the board with the
following settings:

- Speed: 115200
- Data: 8 bits
- Parity: None
- Stop bits: 1

When you reset the development kit, the following messages (one for master and one for remote) will appear on the corresponding serial ports:

.. code-block:: console

   *** Booting Zephyr OS build v2.7.0-rc1-89-ge755863d66c9  ***
   [00:00:00.306,915] <inf> main: IPC send at 10056 ticks
   [00:00:00.356,903] <inf> main: IPC send at 11695 ticks
   [00:00:00.406,921] <inf> main: IPC send at 13334 ticks
   [00:00:00.456,939] <inf> main: IPC send at 14973 ticks
   [00:00:00.506,958] <inf> main: IPC send at 16612 ticks
   [00:00:00.556,976] <inf> main: IPC send at 18251 ticks
   [00:00:00.606,994] <inf> main: IPC send at 19890 ticks
   [00:00:00.657,012] <inf> main: IPC send at 21529 ticks
   [00:00:00.707,031] <inf> main: IPC send at 23168 ticks
   [00:00:00.757,049] <inf> main: IPC send at 24807 ticks


.. code-block:: console

   *** Booting Zephyr OS build v2.7.0-rc1-89-ge755863d66c9  ***
   [00:00:00.054,534] <inf> main: Local timestamp: 1787, application core timestamp: 10056
   [00:00:00.104,553] <inf> main: Local timestamp: 3426, application core timestamp: 11695
   [00:00:00.154,571] <inf> main: Local timestamp: 5065, application core timestamp: 13334
   [00:00:00.204,589] <inf> main: Local timestamp: 6704, application core timestamp: 14973
   [00:00:00.254,608] <inf> main: Local timestamp: 8343, application core timestamp: 16612
   [00:00:00.514,892] <inf> sync_rtc: Updated timestamp to synchronized RTC by 8270 ticks (252380us)
   [00:00:00.557,006] <inf> main: Local timestamp: 18252, application core timestamp: 18251
   [00:00:00.607,025] <inf> main: Local timestamp: 19891, application core timestamp: 19890
   [00:00:00.657,043] <inf> main: Local timestamp: 21530, application core timestamp: 21529
   [00:00:00.707,061] <inf> main: Local timestamp: 23169, application core timestamp: 23168
   [00:00:00.757,080] <inf> main: Local timestamp: 24807, application core timestamp: 24807

Observe that initially logging timestamps for the corresponding events on both cores
do not match. Same with local and remote timestamps reported on network core. After
RTC synchronization is completed they start to match.