TinkerForge: Einstieg mit Master Brick 2.1, WIFI Master Extension 2.0 und Voltage/Current Bricklet 2.0

TinkerForge ist eine deutsche Firma aus Schloß Holte-Stukenbrock, die sich seit 2011 bemüht, die Arbeit mit eingebetteten Systemen zu vereinfachen. Ein Stecksystem erübrigt den Griff zum Lötkolben und  detaillierte Kenntnisse in Elektronik werden überflüssig. In diesem Artikel möchte ich testen, in wie weit dies gelungen ist und meine persönliche Erfahrung beschreiben.

Einführung

TinkerForge setzt konsequent auf den Open Source Gedanken und veröffentlicht den Quellcode und weitere Informationen zu den einzelnen Produkten im Firmenaccount auf Github in aktuell 178 Repositories.

Um das Ziel der Vereinfachung zu erreichen, setzt TinkerForge auf ein Baukastensystem aus Bricks, Bricklets und Master Extensions.

Bricks und Master Extensions besitzen eine einheitliche Grundfläche von 4x4cm und werden über den Stack Connector zu Stapeln verbunden. Der wichtigste Brick ist dabei der Master Brick, dieser erfüllt mehrere Aufgaben. Zum einen ermöglicht er den Anschluss von bis zu 4 Bricklets,  bietet die direkte Kommunikation via USB zu einem PC und dienst als Master der Kontrolle des Stapels (nur der Master Brick, um unteren Ende des Stapels dient als tatsächlicher Master, die anderen bieten dann nur  den Anschluss von weiteren maximal 4  Bricklets). Weitere Bricks erlauben den direkten Anschluss von Gleichstrommotoren, Modellbauservos und Schrittmotoren oder dienen als 9-Achsen Lagesensor (IMU Brick). In der Dokumentation findet sich eine Liste der Bricks neben einer Liste der Master Extension.

Bei den Bricklets wird bewusst auf ein einheitliches Format verzichtet, da so ganz unterschiedliche Sensoren, Aktoren, Konverter zu anderen Bussystemen und verschiedenen Mensch-Maschine-Schnittstellen verbunden werden können. Eine vollumfängliche Liste der Bricklets findet man sich in der Bricklet-Dokumentation. Verbunden werden die Bricklets mit vorkonfektionierten Kabeln unterschiedlicher Längen von 6cm bis zu 2m.

Allen Modulen gemein ist ein Raster der Befestigungslöcher von 5mm, zur Befestigung bietet Tinkerforge Montageplatten für den schnellen Aufbau auf dem Schreibtisch an.

Tinkerforge bietet aktuell für 14 Sprachen (davon 3 als spezielle Ausprägungen für mobile Geräte) fertig APIs an. Diese basieren alle auf dem TCP/IP Protokoll, deshalb sollte eine Adaption für weitere Sprachen durchführbar sein (Swift fehlt zum Beispiel in der Liste der unterstützten Sprachen bisher).

Persönliche Erfahrung

Für den Einstieg entschied ich mich für folgende 3 Module:

Das Ziel ist die kombinierte Messung der von einer Solarzelle gelieferten Spannungs- und Stromwerte und der Transfer in ein Grafana.

Bestellt habe ich direkt bei TinkerForge, geliefert wurde ohne Aufschlag bereits am nächsten Tag.

Installation des Brick Daemon (brickd)

Der Brick Daemon abstrahiert als Systemdienst die Kommunikation zwischen den APIs und dem Master Brick über USB. Den Quellcode findet man im brickd-Repository und Pakete für Debian-artige Distributionen zum Download auf tinkerforge.com.

Allerdings ist die Standardkonfiguration des suboptimal, da auf allen IP Adressen des Rechners ohne Authentifizierung gelauscht wird. Hier sollte man sich doch eher auf localhost 127.0.0.1 beschränken. Dies kann nachträglich in der Datei /etc/brickd.conf mit der Option listen.address angepasst werden. Zusaetzlich habe ich einen Pull-Request erstellt, der das Default anpasst.

Nach der Einrichtung der WIFI Master Extension kann jedoch direkt deren IP Verbindung genutzt werden und der brickd wird obsolet.

Installation des Brick Viewer (brickv)

Der Brick Viewer ermöglicht den Zugriff auf auf lokal angeschlossene Bricks über USB und auch per IP auf entfernte Bricks. Auch hier ist der Quellcode im entsprechenden brickv-Repository zu finden, deb-Pakete finden sich als Downloads auf tinkerforge.com.

Leerer Master Brick
Setup-Reiter eines Master Brick ohne weitere Module

Der Brick Viewer zeigt bei einem einzelnen Master Brick natürlich noch nicht viele Informationen an:

Update Dialog
Dialog zum Aktualisieren der Firmwares

Allerdings ist schon jetzt eine Verbindung via USB möglich und es kann zum Beispiel ein Update der Firmware vorgenommen werden (Changelog).

Schließt man nun den Voltage/Current Bricklet 2.0 an einen beliebigen Port des Master Bricks an, so wird dieser automatisch erkannt.

Master Brick mit Voltage/Current Bricklet 2.0
Setup-Reiter eines Master Brick mit angeschlossenem Voltage/Current Bricklet 2.0

Hat man nun der Beschriftung des Bricklets entsprechend die Stromquelle und den Verbraucher angeschlossen, so kann man auf dem entsprechendem Reiter sofort mit der Messung beginnen.

Erste Messung
Einfache Graphen im Brick Viewer

Über die Funktion “Data Logger” im Setup-Reiter kann bereits jetzt mit einer dauerhaften Aufzeichnung von Daten in eine CSV-Datei begonnen werden. Allerdings ist eine USB Verbindung für eine Messung am Fenster (mit der Solarzelle) nicht praktikabel.

Eine Möglichkeit wäre eine der vielen Bastelplatinen mit USB und WLAN zu verwenden oder man greift zur WIFI Master Extension 2.0. Diese ersetzt die USB-Verbindung und den lokalen Brick Daemon durch ein WLAN Modul.

Aufbau des Stapels

Die Bricks und Master Extensions werden über die mitbestellten Befestigungskits verschraubt, nachdem die Module korrekt ausgerichtet worden (man beachte die weiß markierten Ecken!).

Master Brick und WIFI Master Extension 2.0
Stapel aus Master Brick und WIFI Master Extension 2.0

Auch die WIFI Master Extension wird direkt im Brick Viewer erkannt:

WIFI Konfiguration
Konfiguration der WIFI Master Extension 2.0 im Brick Viewer

Nach der Konfiguration als WLAN-Client (General und Mode) muss noch das richtige WLAN ausgewählt werden. Anschließend kann über “Show Status” geprüft werden, ob die WLAN Einrichtung erfolgreich war und welche IP der Stapel bekommen hat. Die kann man dann zur Kommunikation zwischen Brick Viewer und dem Stapel verwenden.

Nutzung der Python API

Das Modul installiert man einfach mit pip:

pip install --user tinkerforge

Folgendes Skript öffnet zunächst eine IPConnection zu dem aufgebauten Stapel über die WIFI Master Extension. Anschließend wird auf das angeschlossene Bricklet zugegriffen und sekündlich die Werte für Spannung, Stromstärke und Leistung ausgegeben.

HOST = "192.168.178.203"
PORT = 4223
UID = "FKC"

from tinkerforge.ip_connection \
    import IPConnection
from tinkerforge.bricklet_voltage_current_v2 \
    import BrickletVoltageCurrentV2
from time import sleep

if __name__ == "__main__":
    ipcon = IPConnection() 
    ipcon.connect(HOST, PORT) 

    vc = BrickletVoltageCurrentV2(UID, ipcon) 

    while True:
        voltage = vc.get_voltage()/1000.
        current = vc.get_current()/1000.
        power = vc.get_power()/1000.

        print(str(voltage) + " V " + \
              str(current) + " A " + \
              str(power) + " W")
        sleep(1)

Weitere Dokumentation zur API findet sich auf der Webseite von Tinkerforge.

Fazit

Mit den Bricks und Bricklets von TinkerForge erhält man ein einfach zu verwendendes Modulsystem. Die Verarbeitung der Module wirkt qualitativ hochwertig. Dies und die einfache Handhabung durch die unterstützende Software rechtfertig in meinen Augen den leicht höheren Preis. Auch die Auswahl der bereits jetzt existierenden Module lädt zu weiteren Experimenten ein.

‘git grep’ oder wie finde ich nochmal, was ich noch tun muss?

In meinem laufenden Projekt homekit_python haben sich inzwischen doch 2 oder 3 TODOs angesammelt. Wie findet man am schnellsten die TODOs die sich in Dateien befinden, die von git verwaltet werden?

Die Antwort ist einfacher, wie ich zunächst annahm: git bietet mit dem Kommando git grep bereits alles was ich benötige:

git grep TODO

Die Ausgabe umfasst in dieser einfachsten Form wie von grep gewohnt alle Treffer:

Weitere git-Kommandos findet man im git Reference Manual.

Python 3: Profiling von Skripten

Auf GitHub habe ich in einem Issue die Anfrage bekommen, die Software sei langsam. Ja, gefühlt ist die Software nicht die schnellste. Aber wie langsam genau? Und für die Optimierung wichtiger,  wo geht die Zeit verloren?

Das kann mit Profiling herausfinden. Ich will hier eine Lösung beschreiben, die ich für elegant und schnell halte, wobei es sich besseres/schöneres/… gibt.

Zunächst installiert man gprof2dot und dot:

pip3 install --user gprof2dot
sudo apt install dot

python3 bietet mit cProfile bereits ein Modul an, welches das Profiling eines Python-Skripts übernimmt. Mit folgendem Kommando startet man das Profilen des Skripts put_characteristic.py (mit dessen Parametern). Für das Module cProfile wird nur der Parameter -o genutzt, der die Ausgabedatei festlegt.

python3 -m cProfile -o profile.pstats \
        homekit/put_characteristic.py -f koogeek.json -c 1.8 -v false

Anschließend verwendet man gprof2dot und dot um eine mehr oder weniger übersichtliche Grafik zu erzeugen, welche aufzeigt, wo die meiste Zeit “liegen bleibt”. Das Ergebnis sieht in unserem Beispiel wie folgt aus:

Ergebnis eines Profilinglaufs

Allerdings muss man auch hier berücksichtigen, dass die Ergebnisse eines einzelnen Laufs nicht repräsentativ sind. Hier sollten mehrere Durchläufe hintereinander geprofiled werden. Allerdings kann man auch bei einem Durchlauf erkennen, das hier Zeroconf zum Auffinden des HomeKit Geräts und das Erstellen der Sessionkeys viel Zeit verbrauchen.

Bilder & Videos fürs Blog

Von Zeit zu Zeit will man in einem Blog Bilder und Videos veröffentlichen. Dabei würde ich gerne manches unter Kontrolle behalten. Deshalb dieser kurze Artikel, der einige Tricks verraten soll.

Bilder

Bilder erstelle ich inzwischen eigentlich immer mit einer Handy-Kamera. Dabei werden inzwischen über die Exif-Daten viele Informationen preis gegeben. Mobiltelefone fügen hier auch gerne Felder ein, die nicht jeden etwas angehen:

  • GPS Position der Aufnahme,
  • Informationen über das Gerät und
  • viele weitere

Einsehen kann man die Exif-Daten eines Fotos mit:

identify -verbose $BILD

Die Exif-Daten können (und sollten) mit folgendem Kommando entfernt werden:

convert $IN -strip $OUT

Für das Blog ist es ab und zu notwendig ein Bild in der Größe zu reduzieren (hier auf 50%):

covert $IN -resize 50% $OUT

Alternativ ist auch die Angabe der Größe in Pixeln (kann das Bild vergrößern):

covert $IN -resize 600@ $OUT

In beiden Fällen werden die Seitenverhältnisse bei behalten.

Videos

Da bei meinen Videos der Ton keine Rolle spielt, wird dieser mit folgendem Befehl entfernt:

ffmpeg -i $INPUT -an $OUTPUT

Oft möchte man das Video nach der Aufnahme um 90 Grad im Uhrzeigersinn drehen (transpose=2 für 90 Grad gegen den Uhrzeigersinn):

ffmpeg -i $INPUT -filter:v transpose=1 $OUTPUT

Einzelbilder können mit folgendem Kommando extrahiert werden:

ffmpeg -i $INPUT -ss $second -vframes 1 $OUTPUT.png

Einen Ausschnitt aus einem Video kann man mit folgendem Kommando erstellen:

ffmpeg -i $INPUT -filter:v crop=$WIDTH:$HEIGHT:$X:$Y $OUTPUT

Anschließend verwandelt man das Video in webm mit einer Bandbreite von 1 Mbit/s  (welches in WordPress direkt abgespielt werden kann):

ffmpeg -i $INPUT -vcodec libvpx-vp9 -b:v 1M $OUTPUT$.webm

 

FPGA: Eingabe über Schalter

Als weiterer Schritt mit dem FPGA Board nach der 7-Segment Anzeige soll die Möglichkeit darstellen ein Byte  über Schalter einzugeben. Zusätzlich soll noch ein Taster verwendet werden, um eine Eingabe gezielt vornehmen zu können. Auch hier gilt, dass auf teureren Boards wie dem Terasic Cyclone V GX Starter Kit entsprechende Hardware bereits vorhanden ist.

Hardware

Auf dieser Webseite wird beschrieben, wie Taster und Schalter einen einen Spartan-3A FPGA angebunden werden. Eine Adaption dieser Schaltung, bei der auch der Taster active low und zusätzlich mit einem Kondensator beschaltet ist, findet man hier:

Aufgebaut auf der üblichen Lochrasterplatine sieht die Platine dann so aus (hier wären die Schalter eine Nummer größer besser gewesen):

Die Pins auf der oberen Seite besitzen folgende Bedeutung:

PIN NummerBedeutung
Pin 0 (links)Switch 1 (Bit 7)
Pin 1 Switch 2 (Bit 6)
Pin 2 Switch 3 (Bit 5)
Pin 3Switch 4 (Bit 4)
Pin 4Switch 5 (Bit 3)
Pin 5Switch 6 (Bit 2)
Pin 6Switch 7 (Bit 1)
Pin 7Switch 8 (Bit 0)
Pin 8Taste
Pin 9VCC
Pin 10 (rechts)GNG

Ansteuerung

Leider sind real existierende Schalter und Taster aufgrund ihrer Bauform nicht frei von Prellen. In der Wikipedia wird Prellen als “mechanisch ausgelöster Störeffekt bei elektromechanischen Schaltern und Tastern bezeichnet: Statt des sofortigen elektrischen Kontakts ruft die Betätigung des Schalters kurzzeitig ein mehrfaches Schließen und Öffnen des Kontakts hervor.”

Exemplarisch zeigt das folgende Bild das Prellen des verwendeten Tasters:

Bilder, die die Situation noch besser verdeutlichen, finden sich im oben verlinkten Wikipedia-Artikel.

Das Entprellen des Tasters habe ich nicht selbst implementiert sondern eine Implementierung von eewiki.net verwendet. Die Theorie ist, dass geprüft wird, ob der zu entprellende Eingang über einen definierten Zeitraum konstant bleibt. In dieser Implementierung wird über einen 19 bit Zähler ein Zeitraum von 10.5 ms bei 50 MHz verwendet. Somit wird erst nach 10.5 ms der Wert des Eingangs weiter gegeben.

Nachdem der Taster zum Einlesen der Werte nun entprellt wurde, ist der VHDL Code nur noch wenige Zeilen lang:

library IEEE;
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity byte_input is
  PORT(
    clk:      in std_logic;
    switches: in std_logic_vector(7 downto 0);
    button:   in std_logic;
    data:     out std_logic_vector(7 downto 0);
    act:      out std_logic
  );
end byte_input;

architecture sim of byte_input is
  signal s_button: std_logic;
begin
  act < = s_button;

  debouncer: entity work.debounce
    port map (
      clk => clk,
      button => not button,
      result => s_button
    );
	
  process(clk)
  begin
    if rising_edge(clk) and s_button = '1' then
      data < = switches;
    end if;
  end process;
end sim;

Es wird zu jedem Clock-Cycle überprüft, ob die Taste gedrückt wurde und wenn ja, der Eingang der Schalter als std_logic_vector(7 downto 0) ausgegeben.

Im GIT findest sich ein kleines Demo-Repository, welches die eingetasteten Werte auf den 2 Siebensegmentanzeigen ausgibt.

Rezension: “CPU-Design – Entwurf eines RISC-Prozessors in VHDL” von Kai-Uwe Mrkor

Der Autor des Buches “CPU-Design – Entwurf eines RISC-Prozessors in VHDL”, Dipl.-Ing. (FH) Kai-Uwe Mrkor, arbeitet zur Zeit an der Technischen Hochschule Brandenburg als Mitarbeiter Labordienst Fachbereich Informatik und Medien.

Inhalt

Das Buch beschreibt nach Einführungen in Prozessorarchitektur (Kapitel 2), Programmierbare Logikanordnungen (Kapitel 3) und den verwendeten FPGA Cyclone II von Altera (Kapitel 4) die Anforderungen an den im Verlauf zu implementierenden Prozessor in Kapitel 5 sowohl der Registersatz als auch die geplante Teilmenge des MIPS-Befehlssatzes.

In Kapitel 6 widmet sich der Autor detailliert den Aufbau eines RISC-Prozessors mit MIPS-Architektur. Dabei wird zunächst eine Implementierung mit einem Takt pro Befehl vorgestellt, die in mehreren Iterationen aufgebaut wird. Dies ermöglicht es dem Leser von arithmetischen und logischen Befehlen über unbedingte und bedingte Sprünge und Load/Store Befehle alle geplanten Op-Codes des Prozessors nachzuvollziehen. Im 2. Teil dieses Kapitels demonstriert der Autor wie eine Ein-Takt-Implementierung durch die Einführung von Zwischenergebnissen (Pipelining) deutlich beschleunigt werden kann.

Kapitel 7 erweitert die implementierte CPU um sinnvolle Peripherie. Angesprochen werden parallele und serielle Schnittstellen sowie Ausgabe über LEDs und Siebensegmentanzeigen.

Kapitel 8 vereint die Ergebnisse aller bisheriger Kapitel und demonstriert die Funktionalität mit kleinen Beispielprogrammen.

Empfehlung

Das Buch bietet eine gute Auffrischung zu den Themen rund um Rechnerarchitektur. Der Aufbau der verschiedenen Stufen der CPU wird schlüssig beschrieben und ist mit den herunter ladbaren Quellen gut nachvollziehbar. Das Buch ist definitiv eine Empfehlung für alle, die sich eingehender mit dem praktischen Aufbau einer CPU in VHDL beschäftigen wollen.

Bezugsmöglichkeiten

Die genauen Daten des Buches:
Kai-Uwe Mrkor: CPU-Design – Entwurf eines RISC-Prozessors in VHDL; epubli Verlag Berlin; ISBN 978-3-8442-6666-5; 2013

Bestellbar über Epubli und natürlich bei Amazon. Die zum Buch gehörenden Dateien sind direkt und http://www.prozessorentwurf.de/ abrufbar.

FPGA: Testen von VHDL mit vunit

Will man seine in VHDL erstellten Komponenten testen bietet sich eine Simulation mit anschließender Überprüfung der entsprechenden Signale an. Dies manuell durchzuführen ist zeitaufwändig und fehleranfällig.

Eine Lösung bietet VUnit in Kombination mit GHDL an. GHDL ist ein quell offener Simulator für VHDL Programme. Leider ist GHDL nicht in den Debian Paketquellen enthalten, da die IEEE Bibliotheken von Debian als unfrei eingestuft werden. Also müssen wir dieses Paket selbst bauen und installieren. Dazu bietet sich eine VM / ein Docker Container oder ähnliches an, da einige Pakete zum Erstellen des Pakets notwendig sind. Folgende Kommandos erstellen aus den Quellen von github ein installierbares Debian-Paket:

apt update
apt install git gnat build-essential zlib1g-dev checkinstall
git clone https://github.com/ghdl/ghdl.git
git checkout v0.35
cd ghdl
./configure --prefix=/usr/local
make
checkinstall -y --install=no --requires=libgnat-6 \
  --maintainer=ghdl@lusiardi.de --nodoc --pkglicense=GPLv2 \
  --pkgversion=0.35
dpkg -i ghdl_0.35-1_amd64.deb

Vorteil: dieses Paket kann über die gewohnte Paketverwaltung installiert und auch wieder deinstalliert werden. Natürlich sollte man immer das aktuellste Release oder auch den Master mit git auschecken.

Anschließend installieren wir VUnit mit

pip install -U vunit_hdl

Nun können mit einem kleinen Python-Wrapper in VHDL geschriebene Unit-Tests ausgeführt werden:

#!/usr/bin/env python2

from os.path import join, dirname
from vunit import VUnit

root = dirname(__file__)

ui = VUnit.from_argv()
lib = ui.add_library("lib")
lib.add_source_files(join(root, "*.vhd"))
ui.main()

Wie sieht aber nun ein solcher Unit-Test aus? Nehmen wir als Beispiel einen 4-bit Parity Generator:

LIBRARY ieee;
USE ieee.std_logic_1164.all;

ENTITY four_bit_parity IS
    PORT (
        data: IN std_logic_vector(3 DOWNTO 0);
        parity: OUT std_logic
    );
END ENTITY;

ARCHITECTURE behavior_four_bit_parity OF four_bit_parity IS
BEGIN
    parity <= data(0) xor data(1) xor data(2) xor data(3);
END behavior_four_bit_parity;

Ein entsprechender Unit-Test könnte nun so aussehen:

library IEEE;
use IEEE.std_logic_1164.all;

library vunit_lib;
context vunit_lib.vunit_context;

entity four_bit_parity_tb is
    generic (runner_cfg : string);
end four_bit_parity_tb;

architecture sim of four_bit_parity_tb is
    SIGNAL d_in: STD_LOGIC_VECTOR(3 DOWNTO 0);
    SIGNAL p: STD_LOGIC;
    constant clk_period : time := 10 ps;
begin
    main : process
    begin
        test_runner_setup(runner, runner_cfg);
        while test_suite loop
            if run("0000") then
                d_in <= "0000";
                wait for 10 ps;
                check_equal(p, '0');
            end if;
            if run("0001") then
                d_in <= "0001";
                wait for 10 ps;
                check_equal(p, '1');
            end if;
        end loop;
        test_runner_cleanup(runner);
    end process;

    uut: entity work.four_bit_parity port map (d_in, p);
END sim;

Nun kann man mit ./run.py die Tests durchführen und erhält (hoffentlich) folgendes Ergebnis:

$ ./run.py 
Re-compile not needed

Starting lib.four_bit_parity_tb.0000
Output file: vunit_out/test_output/lib.four_bit_parity_tb.0000_86984b0155942bf3d3645c1aa56926538590d91f/output.txt
pass (P=1 S=0 F=0 T=2) lib.four_bit_parity_tb.0000 (0.6 seconds)

Starting lib.four_bit_parity_tb.0001
Output file: vunit_out/test_output/lib.four_bit_parity_tb.0001_fdfc81920e3c3468dfe6138ee1107bbf4bea3958/output.txt
pass (P=2 S=0 F=0 T=2) lib.four_bit_parity_tb.0001 (0.6 seconds)

==== Summary =======================================
pass lib.four_bit_parity_tb.0000 (0.6 seconds)
pass lib.four_bit_parity_tb.0001 (0.6 seconds)
====================================================
pass 2 of 2
====================================================
Total time was 1.2 seconds
Elapsed time was 1.2 seconds
====================================================
All passed!

Frohes Testen! Weitere Informationen zu VUnit und den vorhandenen Funktionen findet man in der VUnit Dokumentation. Etwas ist allerdings zu beachten, dass eventuell nicht alle VHDL Konstrukte, die durch GHDL in Tests akzeptiert werden schlussendlich auch durch z.B. Quartus II synthetisierbar sind. Hier sind also eventuell Nacharbeiten am eigentlichen VHDL-Code notwendig.