This post is now out of date after a number of MBED wrapper related bugs were fixed in 0.4.2. Long story short the EventQueue caused all kinds of problems that took a while to track down. The updated examples are similar to the one in this post, the only change being the EventQueue instance is no longer required.
The CMWX1ZZABZ module combines:
- SX1276 transceiver
- three IO lines for RF switching (RFI, RFO, PA_BOOST)
- TCXO with power on/off control
- a STM32L072CZ MCU (192K flash, 20K RAM)
- 32768Hz XTAL for the MCU
If you want to evaluate this module on MBED the best development kit in my opinion is the DISCO_L072CZ_LRWAN1.
This post shows how to use LDL 0.4.0 on MBED with the DISCO_L072CZ_LRWAN1 development kit. It also points out some noteworthy practical features of the wrapper.
Importing the Wrapper
The wrapper can be added to a project with the following mbed-cli command:
The wrapper source is not in the root of the LDL repository but MBED will find it without any special steps.
This demo is much like every other I have written for LDL. It performs over-the-air-activation before dropping into a loop that uses a data service to send “hello world” as often as possible.
This app must be compiled using the MBED bare-metal profile since the RTOS profile doesn’t work so well when you only have 20K of RAM.
Configuration File (mbed_app.json)
I’ve used the configuration file to define EUIs, define keys, and enable tracing. The LDL wrapper itself doesn’t require you to define anything in the configuration file. I’m defining keys and EUIs here because it’s convenient.
Radio Driver Subclassing
The LDL wrapper lets the developer implement accessory IO by way of subclassing the basic radio driver.
In the case of the CMWX1ZZABZ module there are four accessory IO lines that have nothing to do with the SX1276 driver:
- TCXO on/off
- receive enable
- RFO enable
- Boost enable
The LDL::CMWX1ZZABZ class is able to handle these lines correctly without any changes being made to the common driver code.
Security Module Subclassing
Developers with particular security requirements (e.g. a requirement to use a security chip) can implement them by subclassing the abstract security module (LDL::SM).
The LDL::DefaultSM subclass is provided for demo apps like the one in this post.
- It uses the cryptographic code packaged with LDL
- It is constructed with pointers to the root keys
- It stores derived keys in volatile memory
Data Store Subclassing
LoRaWAN devices need to persist counters, identifiers, and session state. Developers with particular storage requirements can implement them by subclassing the abstract data store (LDL::Store).
The LDL::DefaultStore subclass is provided for demo apps like this one in this post.
- you pass it the identifiers in the constructor
- it stores devNonce and joinNonce in volatile memory
- it doesn’t store session
Using arm-none-eabi-gcc 8.28 and the debug bare-metal profile: