@ -4,7 +4,8 @@ The firmware for all \textit{ESP8266} based devices in the hackerspace are all b
\textit{Sming} provides the base library for this \textit{ESPer} framework, which provides components and functionality shared by all devices.
\textit{Sming} provides the base library for this \textit{ESPer} framework, which provides components and functionality shared by all devices.
This allows to reuse code providing functionality which is common in multiple devices.
This allows to reuse code providing functionality which is common in multiple devices.
To implement \textit{OTA} updates under the given requirements, we define a topology, which integrates our build infrastructure, firmware repository and MQTT-broker with the IoT wifi network the devices are connected to.
To implement \textit{OTA} updates under the given requirements, we define a topology, which integrates our build infrastructure, firmware repository, and controller with the IoT WiFi network, which the devices are connected to.
For our reference implementation, we particularly chose lightweight and common software projects to allow for easy exchangeability of the individual components.
The base topology used is shown in Figure \ref{fig:topology}.
The base topology used is shown in Figure \ref{fig:topology}.
\begin{figure}[htbp]
\begin{figure}[htbp]
@ -13,16 +14,16 @@ The base topology used is shown in Figure \ref{fig:topology}.
\label{fig:topology}
\label{fig:topology}
\end{figure}
\end{figure}
The continuous integration system is responsible for automatically building and publishing the firmware binary files, as soon as updated source code is available.
It is also in charge of assemble and publishing meta-information required for the update process.
The source code of the \textit{ESPer} project is published into a \textit{Git} source code repository.
From there, the continuous integration system is responsible for automatically building and publishing the firmware binary files, as soon as updated source code is available.
It is also in charge of assembling and publishing meta-information required for the update process.
Both systems are described in detail in the following section.
Both systems are described in detail in the following section.
Updates to the devices firmware is either actively triggered (manually or by the CI system) or on a regular schedule by the devices themselves.
Updates to the devices firmware is either triggered actively (manual or by the CI system) or on a regular schedule by the devices themselves.
This process is described in section \ref{flashlayout}.
This process is described in section \ref{flashlayout}.
For monitoring and maintenance purposes, each device publishes a set of information to a well-known \textit{MQTT} topic after connecting to the network.
For monitoring and maintenance purposes, each device publishes a set of information to a well-known \textit{MQTT} topic after connecting to the network.
Beside already existing dates like device type, chip and flash ID, the information block has been extended with details about the bootloader, SDK and firmware version as well as relevant details from the bootloader configuration, like the currently booted ROM slot and the default ROM slot to boot from.
This allows administrators to find devices with outdated bootloaders and helps to find missing and failed updates.
Beside data like device type, chip and flash ID, the published data includes details about the bootloader, SDK and firmware version as well as relevant details from the bootloader configuration, like the currently booted ROM slot and the default ROM slot to boot from.
This allows administrators to find devices with outdated bootloaders and helps to find missing or failed updates.
\subsection{Common framework and build infrastructure}
\subsection{Common framework and build infrastructure}
@ -42,7 +43,7 @@ To build the software, a \textit{Makefile} \cite{make} is used, which provides a
When a new build process is started, the build system scans for all device specific folders and calls the original build process for each of them.
When a new build process is started, the build system scans for all device specific folders and calls the original build process for each of them.
After the build of the firmware has finished, the build system also creates a fail for each device containing the build version and the firmware signatures.
After the build of the firmware has finished, the build system also creates a fail for each device containing the build version and the firmware signatures.
The source code of the \textit{ESPer} project is published into a \textit{Git} source code repository.
To avoid interferences between different build environments on developers computers and roll out new versions as early as possible, the code has been integrated into a continuous integration (CI) system.
To avoid interferences between different build environments on developers computers and roll out new versions as early as possible, the code has been integrated into a continuous integration (CI) system.
The CI, which is based on \textit{drone}\cite{drone} and provided as part of the hackerspace infrastructure, allows to execute commands on each version published into the \textit{Git} repository.
The CI, which is based on \textit{drone}\cite{drone} and provided as part of the hackerspace infrastructure, allows to execute commands on each version published into the \textit{Git} repository.
In the specific case, whenever a new version gets checked-in into the release branch, the \textit{Makefile} is used to build the binary firmware files and publish them to the firmware repository server.
In the specific case, whenever a new version gets checked-in into the release branch, the \textit{Makefile} is used to build the binary firmware files and publish them to the firmware repository server.
Sven Reissmann
8 years ago