Startseite > Embedded > Hardware > Per Klick zum Funktionsmuster

Rapid Demonstrator Service

Per Klick zum Funktionsmuster

15. März 2017, 11:22 Uhr | Von Dr. Claus Kühnel

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Inbetriebnahme und erster Systemstart

Die Inbetriebnahme beginnt mit einigen Tests, die eine Qualifizierung des erstellten Board erlauben. Einer der einfachsten Tests beim Beginn einer Inbetriebnahme ist der sogenannte Smoke Test. Dem Namen des Tests entsprechend sollte beim Anlegen der Betriebsspannung kein Rauch aufsteigen. Besser ist allerdings, die in der Nähe des Steckers für die Betriebsspannung befindliche Sicherung herauszunehmen und durch ein Strommessgerät zu ersetzen. Zuerst wird die Stromaufnahme ohne System-on-Module (SOM) gemessen, um Kurschlüsse auf dem Basis-Board auszuschließen. Danach kann die Stromaufnahme des Gesamtsystems mit aufgestecktem SOM gemessen werden. Folgende Werte der Stromaufnahme sollten erreicht werden:

SOM entfernt: <100 mA
SOM bestückt, System gebootet: <500 mA

Während Desktop-Systeme für eine Vielzahl von Funktionen sowie die einfache Erweiterung mit zukünftigen Features ausgelegt werden, sind Hardware und Software bei Embedded-Systemen auf einen klar definierten Funktionsumfang hin ausgerichtet und optimiert. Features wie automatische Treiberinstallation oder benutzergetriebene Installation neuer Software sind hier nicht gewünscht.

Der Bedarf an Flash- und RAM-Speicher sollte sich kontrolliert minimal halten lassen und das System soll so statisch wie möglich aufgesetzt sein. Jede Art von Komplexität oder Flexibilität ist ein Stabilitätsrisiko. Bedingt durch die unterschiedlichen Zielarchitekturen wird außerdem eine genaue Kontrolle über den Build-Prozess benötigt. Das Betriebssystem wird also für das Zielsystem neu übersetzt, anstatt nur binäre Pakete zu installieren.
In den letzten Jahren wurden aus den genannten Gründen verschiedene Linux-Build-Systeme für den Embedded-Bereich geschaffen, wie z.B. Buildroot, PTXDist und das Yocto-Projekt. Für Yocto spricht, dass inzwischen ein Großteil der Halbleiterhersteller Yocto-basierte Referenz-BSPs anbieten. Es ist nicht durch einen einzelnen Hersteller oder Dienstleister getrieben, sondern durch eine Gruppe von Mitgliedern und Third Parties [3]. Beim Buildprozess von Yocto [4] werden (konfigurierbar) die folgenden Dateien erzeugt:

Bootloader und Konfiguration,
Oftree,
Linux-Kernel,Dateisystem(e).

Das Dateisystem kann in unterschiedlichen Formaten erzeugt werden. Dies ist für die speziellen Speicher- und Bootmedien eines Embedded-Systems wichtig:

ext3/4 für Standardmedien wie SD/USB/Festplatten,
ubifs für NAND-Flash,
ein komprimiertes Dateisystem für z.B. Netzwerk-Mount.

Außerdem wird auch ein SD-Image erstellt, welches bereits die notwendige Partitionierung enthält, um von der SD-Karte booten zu können. Das SD-Image kann mit Hilfe von Linux-Standard-Werkzeugen wie dd direkt auf eine SD-Karte kopiert werden.

Phytec-Module sind entweder mit NAND-Flash oder mit eMMC bestückt. In den Rapid Development Kits [7] und im RDS wird das Betriebssystem bereits vorinstalliert in diesem Speicher ausgeliefert. Zusätzlich steht es dem Kunden aber auch frei, andere Arten des Image von einem öffentlichen FTP-Server herunterzuladen. Nach dem abgeschlossenen Bootvorgang meldet sich das System fertig zum Login. Durch Aufruf des Kommandos uname wird gezeigt, dass ein Linux-Kernel 4.1.36 installiert ist.

Funktionstest der Peripherie

Beim Test der Peripherie geht es vorrangig darum, dass das Layout des Basis-Board den Anforderungen entspricht und dass das BSP korrekt die Hardware ansteuert. Der Boot-Prozess selbst kann über die Debug-Schnittstelle und einen ebenfalls von Phytec bereitgestellten RS-232-Adapter verfolgt werden. Der Boot-Prozess ist nach ca. 20 Sekunden mit dem Erscheinen des CLI-Prompt abgeschlossen.
Die HDMI-Schnittstelle wird durch Anschluss eines HDMI-Monitors getestet. Mit dem Anschluss von Tastatur und Maus über USB kann das System komplett bedient werden. Im Folgenden wird das System aber „headless“ betrieben, d.h. über die Debug-Schnittstelle oder über SSH. Der Vorteil bei Betrieb über die Debug-Schnittstelle ist, dass bereits während des Boot-Prozesses die Mitteilungen des Bootloader sichtbar sind.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Durch die Verbindung des Ethernet-Anschlusses mit einem Netzwerk-Switch ist das Board ins Netzwerk integriert und kann auch über SSH und SCP erreicht werden. Die IP-Adresse wird über DHCP bezogen. Die digitalen Ein- und Ausgänge lassen sich über das sysfs-Dateisystem erreichen. Der in Bild 5 gezeigte Screenshot zeigt das Einlesen eines DIP-Switch (GPIO48) und die Ansteuerung eines Relais (GPIO65). Die vier LEDs auf dem Basis-Board können über /sys/class/leds/RDS:green1 bzw. ..2 und /sys/class/leds/RDS:red1 bzw. ..2 angesprochen werden. Die über den I2C-Bus angesteuerte RGB-LED wird vergleichbar angesteuert (/sys/class/leds/blue:user3, ../green:user2, ../red:user1). Die Shell-Scripts im (öffentlichen) Google Drive [2] verdeutlichen die Vorgehensweise. Einige Peripherie-Elemente werden über den I2C-Bus angesteuert. Die i2c-tools sind im Image bereits enthalten.

Die Funktion des I2C-Busses wird durch eine einfache Abfrage des Temperatursensors DS75 getestet. Dabei wird der Einfachheit halber nur ein Ergebnisregister abgefragt, wodurch die Auflösung reduziert und auf positive Temperaturen beschränkt wird. Die vollkommene Dekodierung des Ergebnisses bringt bezüglich der Funktion aber keine neuen Erkenntnisse und wurde deshalb unterlassen. Bild 6 zeigt eine Abfrage des Sensors und die Ausgabe des Temperaturmesswertes.

Erweiterungen der Peripherie können über den USB vorgenommen werden. Die Funktion des USB wurde mit einem USB-Stick getestet. Das Programm hdparm wird zum Lesen und Setzen von Parametern für ATA-Laufwerke genutzt. Es hat aber auch die angenehme Eigenschaft, die Lesegeschwindigkeit von Laufwerken testen zu können. Diese Eigenschaft wird hier genutzt, um einen Anhaltspunkt für die ordnungsgemäße Funktion des Anschlusses zu erhalten. Die konkreten Werte sind dabei von sekundärer Bedeutung. Der Aufruf von hdparm zeigt die korrekte Funktion des Massenspeichers und plausible Werte für die Datenraten beim Schreiben und Lesen.

Das mini-PCI-Express-Interface hatte der Autor für den Anschluss einer SSD vorgesehen. Die dazu bestellte mSATA-SSD von Kingston erreichte ihn aber nicht vor dem Abgabetermin dieses Beitrags. Die Ergebnisse werden in einem Blog [5] veröffentlicht.