For OpenTag v2. See OTlib v1 reference below
OTlib (/otlib) is a main subdirectory in the OpenTag source root. As of OpenTag v2, OTlib contains only functional models and object-like features that are useful to all parts of OpenTag. Prior to v2, OTlib contained all platform-independent code, but now the Mode 2 Stack features have been moved into /m2 and the system tasks like mpipe and veelite into /otsys.
The OTlib files are written entirely in C and are portable to any platform that has a suitable C compiler and build environment (the standard is GCC). The implementations (C Code) are stored in /otlib and the headers in /include/otlib.
OTlib code has no platform-specific dependencies, although certain modules in OTlib are typically enhanced by optional, platform-specific optimizations. OTlib includes data modules and function modules. OTlib is fully atomic; it does not expose tasks, callbacks, or any sort of non-atomic / non-linear functionality.
|ALP||OT Application Layer Protocol Support||otlib/alp.h||alp_main.c, alp_tmpl.c, alp_api_client.c, alp_api_server.c, alp_dashforth.c, alp_logger.c, alp_security.c, alp_sensor.c|
|Authentication||OT Authentication & Security Module||otlib/auth.h||auth.c|
|Buffers||Required buffers for OpenTag||otlib/buffers.h||buffers.c|
|CRC16||CRC16 calculation & checking||otlib/crc16.h||crc16.c|
|Crypto||Base EAX cryptography interface||otlib/crypto.h||crypto.c|
|Logger||Logger Interface (OpenTag's print)||otlib/logger.h||logger.c|
|Queue||Data queue “object” for streaming IO||otlib/queue.h||queue.c|
|Utils||Helpful utility functions||otlib/utils.h||utils.c|
The ALP Module provides an interface for managing M2DEF-based Application Layer Protocols defined by DASH7 Mode 2 and also used intrinsically by OpenTag. OpenTag can also use this format as a form of inter-process, inter-layer, or inter-chip communication.
Both the DASH7 Mode 2 specification as well as OpenTag's core Veelite filesystem define user IDs and user-based access privileges. The Authentication Module provides a way to authenticate and secure data messages, and to identify them as Root/User/Guest.
OpenTag is a system for data communication, so data buffers are important. The Buffer Module is a lightly-structured data heap with no memory-management requirements (i.e. no malloc)
The CRC16 Module implements block-based and stream-based calculation methods for CRC16.
The Crypto Module provides a generic interface to EAX encryption, which is the standard for OpenTag. The Crypto Module can be ignored if using the Auth Module instead.
The Logger is basically a “print” function for OpenTag. It is an M2DEF-formatted ALP, and it supports binary, text, and other sorts of outputs.
The Queue Module is the standard way in OpenTag to manipulate, inspect, and reference data buffers. OpenTag Queues are particularly designed to work with streaming data I/O, where writing and reading may be happening in parallel by independent processes.
OpenTag Utils provide various, handy features for OpenTag users.
You may include individual OTlib modules into your C projects as shown below (using queue and crc16 as examples):
#include <otlib/queue.h> #include <otlib/crc16.h>
Additionally, if you want to simply include the entire OTlib, just do the following:
Headers that define how the platform module must be implemented. The actual implementations are the responsibility of the platform developer, and they go into appropriate folders inside the OTplatform directory.
As it is a system for data communication, data buffers are important to OpenTag. The Buffering modules are defined and implemented within OTlib.
relocated to otstack
The DASH7 Physical Layer – the way data is encoded and modulated into a radio signal, the characteristics of this signal, and any other processes that physically interface with radio signals – is mostly implemented in the Radio Module. Some features are likely to be implemented in the radio hardware, others in the radio driver, and, potentially, others in the Encode Module that is part of OTlib.
DLL is relocated to otstack
The DASH7 Data Link Layer, or MAC (Media Access Control) provides data integrity features and rules that govern the way the channels can be accessed. The CRC Module is the primary means of managing data integrity. Additionally, the system interface contains data elements important to the data link layer as well definitions for the Kernel.
other than Veelite, relocated to otstack
The “upper layers” are dialog and data-centric, whereas the “lower layers” (DLL, PHY) are communication-centric. Protocols and data definitions are implemented in the upper layers. DASH7 specifies a network layer (layer 3), a transport layer (layer 4), a session layer (layer 5), and a presentation layer (layer 6).
Security (as well as everything else) requires some type of data cryptography and some type of authentication. The DASH7 specification defines user access permissions, and it also includes some frameworks for implementing both authentication and cryptography. However, it does not specify the exact means of authentication or cryptography. OpenTag is working to implement these authentication and cryptography methods.
needs updating for OTv2, ALP is much more mature now