Production device requirements

Please see the production device requirements in the Device Management documentation. For example configurations of Client Lite memory maps, please see memory map examples.

Reference boards

The reference boards have two configurations for Client Lite:

• *1 - You need to modify the BG96 hardware to make it work. See instructions.
• *2 - ISM43362 Wi-Fi in this module has some issues in very crowded Wi-Fi airspace. We recommend a Wi-Fi firmware update.

The difference between non-RTOS and RTOS builds is the availability of threads. Threads are easier to use than fully event-loop-based software, but the cost is in the size (RAM ~6kB and ROM ~10kB).

The networking stacks in Mbed OS that work without threads are:

• Quectel BG96 cellular.
• ESP8266 Wi-Fi through Mbed OS master (PR #12022).

All other network stacks require threads at this stage.

Porting other Mbed OS boards

Porting of boards is similar in Izuma Device Management Client and Client Lite with the exception of the lack of the Platform Adaptation Layer (PAL) in Client Lite. The main items to configure are the allocations for the different software parts (bootloader, application, storage, firmware update management area). For details, see the mbed-bootloader repository. Please contact us if you need support with board porting.

Memory map examples

Client Lite provides a memory efficient solution with internal flash only. The actual RAM and ROM consumption figures depend on:

• The target board.
  • Board support code and drivers vary a lot in size.
  • Internal flash erase sectors sizes have a significant impact, as the software blocks must be aligned to them.
  • Networking stack and buffer sizes.
• Configurations used (TLS offloading or MCU-hosted TLS, for example).
• Bootloader size and configuration (for example, external flash requires more drivers for the bootloader).
• Sensor software drivers, application logic complexity (simple on/off or machine learning).
• Number of traces enabled.

Enabling traces can easily nearly double the flash requirements. Working without traces is possible, but troublesome. For development purposes, we recommend you to have hardware with a larger flash to accomodate debug print needs.

Always try out your intended combination before deciding your final hardware selection.

A typical, small sensor solution would be using for example the following type of flash layout:

We highly recommend using a dual-bank memory architecture for improved performance. Keep the running code (bootloader, application) in the first bank and the rest (storage, firmware area) in the second bank.