Design-Praxis / Embedded Software
OTA-Schnittstellen für µC-Apps
Fortsetzung des Artikels von Teil 6
Ergebnisse
Neben den funktionalen Anforderungen und dem Durchlaufen zahleicher Tests sind die Leistungsdaten der Software ebenfalls entscheidend für den Projekterfolg. Zwei Kenngrößen, die üblicherweise zum Messen der Leistungsdaten von Embedded Software verwendet werden, sind Speicherplatz (Footprint) und Anzahl der Zyklen. Der Footprint bezieht sich auf den Platz, den die Software-Applikation im flüchtigen (SRAM) und nichtflüchtigen (Flash) Speicher einnimmt. Mit Zyklen ist die Anzahl der Mikroprozessor-Taktzyklen gemeint, welche die Software für eine bestimmte Aufgabe benötigt.
Obwohl die Taktzyklen der Software-Laufzeit ähneln, tragen sie der Tatsache Rechnung, dass die Software während des OTA-Updates in Betriebsarten mit geringer Stromaufnahme (Low Power Modes) schaltet, in denen der Prozessor inaktiv ist und keine Zyklen anfallen. Zwar wurde das Software-Referenzdesign nicht für diese Kenngrößen optimiert, ist jedoch nützlich für den Leistungsvergleich (Benchmarking) des Programms und zum Vergleich der Entwicklungskompromisse.
Jobangebote+ passend zum Thema
Bild 11 und Bild 12 zeigen den Speicherbedarf des OTA-Update-Software-Referenzdesign, implementiert auf dem ADuCM4050 ohne Zwischenspeicherung. Die Zahlen entsprechen den Komponenten in Bild 10. Wie Bild 11 zeigt, benötigt die gesamte Applikation etwa 15 kB Flash-Speicher. Dies fällt hinsichtlich der 512 kB Flash-Speicher auf ADuCM4050 gering aus.
Die Applikationssoftware für den OTA-Update-Prozess benötigt nur etwa 1,5 kB, wobei der Rest für Bibliotheken, beispielsweise DFP, Micro-ECC und ADF7242-Stack, verwendet wird. Die Ergebnisse helfen, den Entwicklungskompromiss bezüglich der Rolle, die der SSBL im System spielen sollte, zu veranschaulichen. Der größte Teil des Speicherbedarfs von 15 kB stellt der Update-Prozess. Der SSBL selbst beansprucht nur etwa 500 Byte mit zusätzlich 1 bis 2 kB DFP-Code für den Gerätezugriff, wie der Flash-Treiber.
Zum Evaluieren des Overheads der Software werden, mit jedem empfangenen Datenpaket, die Zyklen gezählt und die durchschnittliche Anzahl von verbrauchten Zyklen pro Paket betrachtet. Jedes Datenpaket benötigt AES-128 Entschlüsselung, SHA-256 Hashing, einen Schreibvorgang in das Flash Memory und Paket-Metadaten-Überprüfung.
Bei einer Nutzdatengröße von 64 Byte und ohne Caching beträgt der Overhead zur Verarbeitung eines einzigen Datenpakets 7409 Zyklen. Mit einem Core-Taktsignal von 26 MHz entspricht dies einer Verarbeitungszeit von etwa 285 µs. Der Wert wurde mithilfe des Cycle-Counting-Treibers im ADuCM4050DFP berechnet (unangepasste Zyklen) und ist der Durchschnitt beim Herunterladen eines Programms mit 100 kB (etwa 1500 Pakete).
Der minimale Daten-Overhead pro Paket kann auf die Treiber im DFP zurückgeführt werden, welche bei Bus-Transaktionen die DMA-Hardware-Peripherie am ADuCM4050 nutzen und die Treiber den Prozessor während jeder Transaktion in einen Stromsparzustand (Low Power Sleep State) bringen. Unter deaktiviertem Stromsparzustand im DFP und Änderung der Bus-Transaktionen, derart dass sie kein DMA nutzen, steigt der Overhead pro Datenpaket auf 17297 Zyklen.
Dies verdeutlicht, wie sich die effiziente Nutzung von Bausteintreibern auf eine Embedded-Software-Applikation auswirkt. Während der Overhead auch durch eine kleine Anzahl von Daten-Bytes pro Paket gering gehalten wird, bringt eine Verdopplung der Daten-Bytes pro Paket auf 128 nur eine geringe Zunahme an Zyklen, woraus 8362 Zyklen für das gleiche Experiment resultieren.
Taktzyklen und Speicherplatz verdeutlichen auch den oben genannten Kompromiss beim Zwischenspeichern (Caching) von Paketdaten, statt sie jedes Mal im Flash-Speicher abzulegen. Ist im Flash-Speicher eine Zwischenspeicherung von einer Page aktiviert, verringert sich der Overhead pro Datenpaket von 7409 auf 5904 Zyklen. Diese Verringerung der Zyklen um 20% ergibt sich aus der Fähigkeit, den Flash-Schreibvorgang für die meisten Pakete zu überspringen und nur wenn der Cache gefüllt ist, einen Flash-Schreibvorgang durchzuführen.
Die Reduzierung wird mit einem höheren SRAM-Speicherplatz erkauft. Ohne Zwischenspeicherung benötigt der HAL nur 336 Byte SRAM (Bild 12). Wird jedoch Caching verwendet, muss Platz von einer kompletten Page im Flash-Speicher reserviert werden, was die SRAM-Ausnutzung auf 2388 Byte erhöht. Die Flash-Memory-Ausnutzung des HAL steigt wegen des zusätzlichen Codes, der benötigt wird, um zu ermitteln, wann der Pufferspeicher geleert werden muss, ebenfalls leicht an.
Die Ergebnisse veranschaulichen die konkrete Auswirkung von Entwicklungsentscheidungen auf die Leistungsfähigkeit der Software. Es gibt keine Patentlösung. Vielmehr stellt jedes System andere Anforderungen und muss unterschiedliche Auflagen erfüllen. Die OTA-Update-Software muss daher so abgestimmt werden, dass sie alle relevanten Vorgaben erfüllt. (ct)
- OTA-Schnittstellen für µC-Apps
- Das Wesen einer Software-Applikation
- Der Second-Stage Bootloader (SSBL)
- Entwicklungskompromiss: Die Rolle des SSBL
- Funktionale Sicherheit und Kommunikation
- Versuchsaufbau
- Ergebnisse
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Airbus Cyber Security
»Cyber-Security wird zunehmend als Enabler für das IoT gesehen«
Edge Computing
Rechnen, wo Rechenleistung gebraucht wird
Mobilfunkmodul mit µC
LTE-Modem und µC als System-in-Package
Mess- und Prüftechnik / IoT-Sensorknoten
Das Zephyr von vorne aufgezäumt
Systemdesign / Safety&Security
Updateszenarien für und mit Linux
