Startseite > Messen + Testen > Sensorik > OTA-Schnittstellen für µC-Apps

Design-Praxis / Embedded Software

OTA-Schnittstellen für µC-Apps

17. Dezember 2018, 13:17 Uhr | Benjamin Bucklin Brown, Analog Devices

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 5

Versuchsaufbau

Bei den Ultra-Low-Power-Mikrocontrollern, welche die hier erwähnten Speicher-, Kommunikations- und Security-Entwicklungsherausforderungen meistern, handelt es sich um die Bauteile ADuCM3029 und ADuCM4050 von Analog Devices. Die Mikrocontroller enthalten die im Beitrag erläuterten Hardware-Peripheriefunktionen für OTA-Updates, wie beispielsweise Flash-Speicher, SRAM, Crypto-Beschleuniger und Zufallszahlengenerator. Die Bauteile der Familie befinden sich in Dual-Flatpack-Gehäusen (DFPs) und ermöglichen die Entwicklung einer OTA-Update-Lösung. Die DFPs enthalten Peripherietreiber mit einfachen und flexiblen Schnittstellen zur Nutzung der Hardware.

Hardware-Konfiguration

Um die hier beschriebenen Konzepte zu überprüfen und zu validieren, wurde ein OTA-Update Software-Referenzdesign auf Basis des ADuCM4050 entwickelt. Für den Client ist ein ADuCM4050 EZ-KIT mit einem ADF7242 verbunden und zwar über den Horseshoe-Verbinder an der Transceiver-Erweiterungskarte.

Jobangebote+ passend zum Thema

Ingenieur/Elektroingenieur/Elektrotechniker als Field Application Engineer

GEYER Electronic GmbH, Planegg

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Das Client Device befindet sich links in Bild 9. Für den Server wurde eine Python-Applikation entwickelt, die auf einem Windows-PC läuft. Die Python-Applikation kommuniziert über den seriellen Port mit einem weiteren ADuCM4050 EZ-KIT, welches ebenfalls und in gleicher Weise wie beim Client mit einem ADF7242 verbunden ist. Das EZ-KIT rechts in Bild 9 enthält jedoch keine OTA-Update-Logik und leitet lediglich vom ADF7242 erhaltene Pakete an die Python-Applikation weiter.

Software-Komponenten

Das Software-Referenzdesign partitioniert den Flash-Speicher des Client gemäß Bild 3. Die Haupt-Client-Applikation wurde so entwickelt, dass sie portabel und konfigurierbar ist, um in anderen Anordnungen oder auf anderen Hardware-Plattformen genutzt werden zu können. Bild 10 zeigt die Software-Architektur des Client Device.

Obwohl die gesamte Applikation manchmal als SSBL bezeichnet wird,
erfolgt ab Bild 10 eine logische Trennung des echten SSBL-Bereichs (in blau) vom OTA-Update-Bereich (in rot), da letzterer nicht notwendigerweise komplett in die gleiche Applikation implementiert werden muss. Die Hardware-Abstraktions-Schicht in Bild 10 hält die OTA-Client-Software portabel und unabhängig von darunterliegenden Bibliotheken (in orange).

Die Software-Applikation enthält die Boot-Reihenfolge in Bild 3, ein einfaches Kommunikationsprotokoll zum Herunterladen der neuen Applikation vom Server und die Hash-Kette. Jedes Paket im Kommunikationsprotokoll verfügt über einen 12 Byte großen Metadaten-Header, 64 Byte Nutzdaten (Payload) und eine 32 Byte große Übersicht (Digest). Darüber hinaus hat es die folgenden Leistungsmerkmale:

Caching: Unterstützung für No-Caching oder Caching einer Seite im Flash-Speicher, je nach Anwenderkonfiguration.
Inhaltsverzeichnis: Das Inhaltsverzeichnis ist so ausgelegt, dass es lediglich zwei Applikationen enthalten kann und die neue Applikation wird automatisch in den ältesten Bereich heruntergeladen, um eine Fallback-Applikation zu haben. Dies bezeichnet man als A/B-Update-Konzept.
Messaging: Unterstützung für den ADF7242 oder UART für Messaging, je nach Anwenderkonfiguration. Beim Einsatz des UART für Messaging entfällt das linke EZ-KIT in Bild 9 und es verbleibt das Kit auf der rechten Seite für den Client. Dieses Over-the-Wire Update-Konzept ist nützlich zum Hochfahren des Systems und zum Debugging.