LoRaWANStack class is our controller layer on top of our
current MAC and PHY layer. It provides services to an implementation
of LoRaWANBase class.
It is a singleton class owing to the fact that the mac layer underneath
is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps
requests and getting responses back from the mac layer using confirmations and
indications.
In essense this class is a special handle for
mac layer underneath which is predominantly reference design based.
In future we may refactor the LoRaMac.cpp code to make it object oriented
and cleaner.
At one end, it binds the application selected radio driver with the PHY layer
and at the other end it provides services to upper layers handling the mac via
well defined APIs.
For proper selection of a PHY layer, user must use Mbed config system.
For this purpose an mbed_lib.json is provided which can be overriden by the
user defined mbed_app.json. By default the EU868 band is selected as a PHY layer.
User must set relevant keys for the selected connection mechanism.
The actual mac algorithms are being used as it is in the reference
implementation.
We introduce an internal class that starts a thread and constructs an event queue
to handle deffered calls from interrupt context for RTOS. The code base is
compatible with Mbed-OS 2 as well.
GetPhyEventHandlers() API provides mac callback funtions for PHY layer,
which are in turn delegated to radio driver from the PHY layer.
LoRaMacInitialization() is augmented with LoRaPHY parameter which let's
the MAC layer know which particular PHY layer is in use.
LoRaMacSetTxTimer() and LoRaMacStopTxTimer() are used when duty cycle is
off for testing purpose or to support custom application timers.
If the duty cycle is off, mac and phy layer work togather to figure
out the next possible transmission time.
LoRaMacCrypto APIs are provided which provide seemless integration of
mbedTLS into mac layer for cryptography. User application is supposed to
provide proper mbedTLS configuration file.
All other APIs are retained as it is.
LoRaPHY is the abstract class for the LoRa PHY layer which governs
the LoRaRadio and provides some common functionality to all regional
implementations.
We support 10 regions and every region comes loaded with default parameters.
These parameters can be changed by the Mac layer or explicitely by the stack
controller layer using APIs provided. This layer in essence detaches Mac completely
from PHY and provides more modular approach to the entire system.
Apart from class structure, the internal functionality is directly deduced from
semtech reference implementation that's why most of the internal data structures are
used on 'as is' basis.
In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e.,
the lora radio driver, ensuring that the radio is accessed from a single entry point.
A seperate data structure file is added which is common to PHY layers only.
All network interfaces for LoRaWAN protocol must implement this
class. In order to be compatible with Mbed-OS applications, any
implementation of this class must use the data structures and
Mbed-OS timers provided.
lorawan_data_structures may look repetitive but this is essential
as we have a plan to use a reference implementation for LoRaWAN mac
layer from Semtech. Some of the data structures provide seemless
transition from semtech implementation (as MAC layer) to the Mbed-OS
control layers above.
features/lorawan/lorastack is the placeholder for future items like mac and
phy layers. system/ will contain all the common bits.
All Mbed-OS drivers for LoRa radio devices must implement
this pure virtual class in order to be compliant with Mbed-OS
applications.
This class comes loaded with all necessary data structures.
The implementations of this class can come out of tree.
Cortex-M23 doesn't support ARMv8-M Main Extension and so doesn't support:
ldm r0, {r0, r1, r2, pc}
Fix it by going Cortex-M0/M0+ way:
ldm r0, {r0, r1, r2, r3}
bx r3
Rework so that everything is a FileHandle, including
stdin/stdout/stderr.
Provide legacy functionality of calling serial_getc and serial_putc as
an internal "DirectSerial" FileHandle.
Add a JSON option to use UARTSerial instead.
Add hooks for target and application to provide custom FileHandles.
Allow for CRLF conversion to work on any FileHandle that isatty(),
as stdin/stdout or any other FILE. Optimise the conversion so it
doesn't force all write calls to be 1 byte. Limit the conversion
to the stdio layer, so that read() and write() work the same as
the FileHandle methods - this seems less confusing.
Rationalise layers a little more to add the POSIX standard fdopen(int)
and a local open(FileHandle) to map a FileHandle to a POSIX file
descriptor.
fdopen(FileHandle) is now a composite of those two, rather than being
a primitive.
Related to the review of #5857, I fixed the TRNG function for GR-LYCHEE.
- I modified to zeroize "recv_data" before the function return.
- I added the processing that check the return value of I2C.read function. If return value is error, "output" is zeroized before function return.
- In trng_get_bytes_esp32 function, there is a time lag in the period from ESP32 reset to start working, error may occur when "Write" is called. Thus, I added a retry counter due to address this concern. There is not this counter for "Read" since it is called after "Write".
Hasnain Virk
Martin Kojtal
Cruz Monrreal
Jimmy Brisson
bcostm
Kari Severinkangas
Wolfgang Betz
Antti Yli-Tokola
ccli8
deepikabhavnani
Wilfried Chauveau
Oren Cohen
Ashok Rao
gorazd
Kevin Bracey
TomoYamanaka