zephyr/samples/subsys/mgmt/osdp
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
..
control_panel includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> 2022-09-05 16:31:47 +02:00
peripheral_device includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> 2022-09-05 16:31:47 +02:00
README.rst

README.rst

.. _osdp-sample:

Open Supervised Device Protocol (OSDP)
######################################

Open Supervised Device Protocol (OSDP) is an IEC standard (IEC 60839-11-5)
intended to improve interoperability among access control and security products.
It supports Secure Channel (SC) for encrypted and authenticated communication
between configured devices.

OSDP describes the communication protocol for interfacing one or more Peripheral
Devices (PD) to a Control Panel (CP) over a two-wire RS-485 multi-drop serial
communication channel. Nevertheless, this protocol can be used to transfer
secure data over any stream based physical channel. Read more about `OSDP here
<https://libosdp.gotomain.io/>`_..

Although OSDP is steered towards the Access and Security industries, it can be
used as a general communication protocol for devices in a secure way without
too much resource requirements. The security is not top-notch (AES-128) but it
is reasonable enough, given that the alternative is no security at all.

OSDP Supports the control of the following components on a PD:
   - LED
   - Buzzer
   - Keypad
   - Output (GPIOs)
   - Input Control (GPIOs)
   - Displays
   - Device status (tamper, power, etc.,)
   - Card Reader
   - Fingerprint Reader