Monatliches Archiv: Januar 2015

FHEM: Zufällige Zeit-Offsets

Möchte man sein Haus automatisieren, stehen einem ein ganzer Zoo von verschiedenen Systemen zur Verfügung: HomeMatic, FS20, EnOcean, Peha, KNX und viele mehr. Leider haben die Steuerzentralen der einzelenen Systeme eins gemeinsam: Sie können nur Komponenten des eigenen Systems ansprechen und lassen sich schlecht erweitern.

Daher hat Rudolf Koenig mit einigen anderen Entwicklern eine universelle Hausautomatisierungszentrale entwickelt: FHEM. Hiermit lassen sich, wenn man entsprechende Gateways auf die jeweiligen Funksysteme hat, beliebige Systeme anbinden.

Möchte man Rollos automatisieren, so bietet die Sunset-Funktion einen einfachen Weg, bei Sonnenuntergang die Rollos herunterzufahren. So sorgt der Befehl


define Zimmer1.Rollo.Herunter at *{sunset(0,"17:00","22:00")} set Zimmer1.Rollo off

dafür, dass das Rollo Kueche.Rollo bei Sonnenuntergang heruntergefahren wird, jedoch nicht vor 17:00 und nicht nach 22:00.

Macht man das für alle Rollos auf diesem Weg, ergibt sich jedoch ein Problem. Das ganze sieht ziemlich automatisiert aus und taugt für keine 5 Pfennig (ähh…Cent) als Anwesenheitssimulation. Man würde schließlich wenn man anwesend ist, auch nicht alle Rollos gleichzeitig herunterfahren können. Praktisch wäre ein zufälliger Offset. FHEM bietet diese Funktion leider nicht von Haus aus, aber man kann sich schnell so eine Funktion selber bauen:

Diese Funktion packt man z.B. in die 99_myUtils.pm (vor das 1;) und lädt in der FHEM-Weboberfläche mit dem Befehl reload 99_myUtils.pm die Datei neu.… Weiter lesen

Speicher beim STM32 (Cortex-M3/Cortex-M0) sparen

In der letzten Zeit programmiere ich recht viel mit dem STM32. Dabei handelt es sich um einen Microcontroller mit ARM-v7 Kern (Cortex-M0, Cortex-M3, Cortex-M4), der sich grob im Preisniveau von AVRs bewegt, aber deutlich performanter ist. Seitens des Herstellers (ST Microelectronics) wird eine angenehm nutzbare Firmware-Library (Standard Peripherals Library) mitgeliefert, sodass man eigentlich direkt starten kann. Achsoo, GCC gibts natürlich auch als Compiler: . Das ganze wird dann unter Eclipse programmiert und mit OpenOCD debuggt.

Jetzt aber zum eigentlichen Thema. Wenn man nämlich wie von ST in den Beispielen der Firmware-Library die Peripherie initialisiert, dann sieht das in etwa so aus:

Zum einen ist dieser Code recht unübersichtlich, zum anderen passiert aber hier etwas, was man eigentlich gar nicht möchte. Zuerst wird nämlich auf dem Stack Speicher für die Struktur reserviert, dann im Programm Feld für Feld mit Werten gefüllt und danach an die Init-Funktion übergeben. Im Assembler sieht das übrigens so aus:

Ziemlich aufwendig für ein wenig Initialisierung, die sich nie ändert, gell? In Summe sind das 56 Bytes Programmcode.

Wenn man nun geschickt C99-Struct-Initialisierungen mit ein paar Speichermodifiern kombiniert, so erhält man folgenden Code, der effektiv das Gleiche macht:

Zusätzlich kann man noch die Funktionssignatur der Funktion GPIO_Init ändern, sodass man einen Pointer übergibt, an dem sich weder die Adresse noch der Inhalt ändert:

Damit werden die Daten nicht erst im RAM aufbereitet und dann an die GPIO_Init übergeben sondern die Funktion bekommt direkt die Flash-Adresse der Daten übergeben.… Weiter lesen