ThingsBoard Client SDK 0.16.0
Client SDK to connect with ThingsBoard IoT Platform from IoT devices (Arduino, Espressif, etc.)
Loading...
Searching...
No Matches
Public Member Functions | List of all members
OTA_Handler< Logger > Class Template Reference

Handles the complete processing of received binary firmware data including writing the data into some kind of storage. More...

#include <OTA_Handler.h>

Inheritance diagram for OTA_Handler< Logger >:
[legend]

Public Member Functions

 OTA_Handler (Callback< bool, size_t const &, size_t const & >::function publish_callback, Callback< bool, char const *const, char const *const >::function send_fw_state_callback, Callback< bool >::function finish_callback)
 Constructor. More...
 
void Start_Firmware_Update (OTA_Update_Callback &fw_callback, size_t const &fw_size, char const *fw_checksum, mbedtls_md_type_t const &fw_checksum_algorithm)
 Starts the firmware update with requesting the first firmware packet and initalizes the underlying needed components. More...
 
void Stop_Firmware_Update ()
 Stops the firmware update completly and informs that user that the update has failed because it has been aborted, ongoing communication is discarded. More...
 
void Process_Firmware_Packet (size_t const &current_chunk, uint8_t *payload, size_t const &total_bytes)
 Called when the chunk response is received from the server and if successfull sends the request for the next chunk. More...
 
void update ()
 Used to update the watchdog timer which uses a simple software time in the background. Ensure to call recently often for higher precision. Meaning the timer is actually triggered closer to the specified waiting time. More...
 

Detailed Description

template<typename Logger>
class OTA_Handler< Logger >

Handles the complete processing of received binary firmware data including writing the data into some kind of storage.

Note
Storage the binary data is saved into, could be the flash memory of the device itself or the SD card as an intermediary medium, depends on the IUpdater implementation used. Processing of received binary firmware data consits of, creating a hash of the received data and in the end ensuring that the complete OTA firmware was written successfully and that the hash is the one we initally received. Furthermore it also includes simple error handling by requesting retransmission of binary firmware data if it failed or timed out while requesting a part of that binary firmware data
Template Parameters
LoggerImplementation that should be used to print error messages generated by internal processes and additional debugging messages if THINGSBOARD_ENABLE_DEBUG is set

Constructor & Destructor Documentation

◆ OTA_Handler()

template<typename Logger >
OTA_Handler< Logger >::OTA_Handler ( Callback< bool, size_t const &, size_t const & >::function  publish_callback,
Callback< bool, char const *const, char const *const >::function  send_fw_state_callback,
Callback< bool >::function  finish_callback 
)
inline

Constructor.

Parameters
publish_callbackCallback that is used to request the firmware chunk of the firmware binary with the given chunk number
send_fw_state_callbackCallback that is used to send information about the current state of the over the air update
finish_callbackCallback that is called once the update has been finished and the user should be informed of the failure or success of the over the air update

Member Function Documentation

◆ Process_Firmware_Packet()

template<typename Logger >
void OTA_Handler< Logger >::Process_Firmware_Packet ( size_t const &  current_chunk,
uint8_t payload,
size_t const &  total_bytes 
)
inline

Called when the chunk response is received from the server and if successfull sends the request for the next chunk.

Note
The processing of the chunk data starts with writing the given amount of bytes of the packet data with the given IUpdater implementation. Additionally that data is also written into hash function that will be used to compare the expected complete binary data and the actually received binary data once the update is finished
Parameters
current_chunkIndex of the chunk we recieved the binary data for
payloadNon owning pointer to the firmware packet data of the current chunk. Does not need to be kept alive, because the formatting message is only used for the scope of the method itself
total_bytesAmount of bytes in the current firmware packet data

◆ Start_Firmware_Update()

template<typename Logger >
void OTA_Handler< Logger >::Start_Firmware_Update ( OTA_Update_Callback fw_callback,
size_t const &  fw_size,
char const *  fw_checksum,
mbedtls_md_type_t const &  fw_checksum_algorithm 
)
inline

Starts the firmware update with requesting the first firmware packet and initalizes the underlying needed components.

Parameters
fw_callbackCallback method that contains configuration information, about the over the air update
fw_sizeComplete size of the firmware binary that will be downloaded and flashed onto this device
fw_checksumNon owning pointer to the string representation of the complete firmware binary checksum, should be the same as the checksum calculated from the actually written data in the end. Does not need to be kept alive, because the string data is copied into a local member variable
fw_checksum_algorithmAlgorithm type used to hash the firmware binary

◆ Stop_Firmware_Update()

template<typename Logger >
void OTA_Handler< Logger >::Stop_Firmware_Update ( )
inline

Stops the firmware update completly and informs that user that the update has failed because it has been aborted, ongoing communication is discarded.

Note
Be aware the written partition is not erased so the already written binary firmware data still remains in the flash partition, shouldn't really matter, because if we start the update process again the partition will be overwritten anyway and a partially written firmware will not be bootable

◆ update()

template<typename Logger >
void OTA_Handler< Logger >::update ( )
inline

Used to update the watchdog timer which uses a simple software time in the background. Ensure to call recently often for higher precision. Meaning the timer is actually triggered closer to the specified waiting time.


The documentation for this class was generated from the following file: