HiFive1 Rev. B

Vor wenigen Tagen war nun das über Mouser bestellte und von CrowdSupply gelieferte HiFive1 Rev. B Board im Postkasten.

HiFive1 Rev. B

Das HiFive1 Rev, B Board weist die folgenden Features auf:

  • MCU – SiFive Freedom E310-G0002 32-Bit RV32IMAC processor @ bis zu 320+ MHz (1.61 DMIPS/MHz)
  • Storage – 32 MBit SPI Flash
  • Connectivity – ESP32-SOLO-1 WiFi & Bluetooth module
  • I/Os (19 x Digital I/O Pins, 19 x external Interrupt Pins, 1 x external Wakeup Pin, 9 x PWM Pins, 1/3 SPI Controllers/HW CS Pins)
  • I/O Voltages –  3.3 V
  • USB – 1 x micro USB Port für Power, Programming und Debugging (via Segger J-Link)
  • Power Supply – 5 V via USB oder 7 – 12V via DC Jack; Operating Voltage: 3.3 V und 1.8 V
  • Dimensions – 68 mm x 51 mm
  • Gewicht– 22 g

Zur Programmierung kann das Freedom-E SDK herangezogen werden, was allerdings einen Linux-Rechner erfordert. ‌Alle Informationen hierzu sind unter https://github.com/sifive/freedom-e-sdk​ zu finden.

Die beim HiFive1 vorhanden Unterstützung der Arduino IDE wurde nicht weitergeführt.

Das Eclipse-basierte, wesentlich komplexere Freedom Studio läuft auch auf Windows.

Eine erste Idee von der Performance des HiFive1 Rev. B bekommt man über den Dhrystone Benchmark.

Resultat Dhrystone Benchmark (Out of the Box) (Das Ergebnis ist noch falsch – Bild wird ersetzt)

Mit diesem Ergebnis liegt der HiFive1 Rev. B in der Nähe von Cortex-M3/M4/A5.

MCUDIPS/MHz
HiFive1 Rev. B1.6
Cortex-M31.24
Cortex-M41.25
Cortex-A51.6

Quelle: https://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/MCU/AN_304-FT900-Microcontroller-Benchmark.pdf

Rapid Prototyping mit M5Stack

Wem es bislang an Baugruppen mit einem vernünftigen Gehäuse für die Entwicklung seiner Prototypen gemangelt hat, dem wird mit M5Stack Komponenten eine ansprechende Lösung angeboten.

Hier sind aus dem Angebot von M5Stack zwei Core Module:

Generell weisen beide Core Module einen ESP32 als Controller auf.

Die M5Stack Komponenten werden von zahlreichen Lieferanten angeboten und sind nicht nur bei Bezug aus Fernost sehr preiswert.

KomponenteAliexpress
M5Stack CoreUS$ 27.60
M5StickCUS$ 9.90
ENV UnitUS$ 3.20

Ich habe mit dem M5StickC erste Versuche unternommen, um seine Eignung für ein portables Messgerät zu testen. Der M5StickC ist mit einem 80 mAh LiPo-Akku ausgerüstet, was keine großen Akkulaufzeit erwarten lässt.

Der M5StickC ist mit einem Power System Management Chip AXP192 ausgestattet, der ein USB-kompatibles Ladegerät, DC-DC-Wandler, Low-Dropout-Linearregler, Spannungs- /Strom- /Temperaturüberwachung und Multi-Kanal 12-Bit ADC aufweist. Die Überwachung des Ladezustand des LiPo-Akkus kann über diesen Chip erfolgen.

Der ESP32 weist zwei I2C-Busse auf. Über den ersten werden die internen Chips AXP32 (0x34), BM8563 (0x51) und SH200Q (0x6C) angesteuert. Der zweite I2C-Bus ist am GROVE-Connector verfügbar.

Für einen ersten Test schließe ich eine ENV Unit über den GROVE-Connector an. Dieses Modul beinhaltet einen DHT12 (0x5C) und einem BMP280 (0x76) Sensor und erfasst damit Temperatur, relative Luftfeuchte und barometrischen Druck.

Das Programmbeispiel M5StickC_ENV.ino erfüllt zwei Aufgaben:

  1. Erfassen von Temperatur, relativer Luftfeuchte und barometrischem Druck über die angeschlossene ENV Unit.
  2. Erfassen von Batteriespannung und Ladestrom für den LiPo-Akku

Das Programmbeispiel ist auf Github abgelegt.

Ausgehend von einem voll aufgeladenen LiPo-Akku habe ich die USB-Verbindung getrennt und das angegebene Programmbeispiel batterie-betrieben laufen lassen. Es hat sich folgender Entladevorgang gezeigt.

Nach reichlich 60 Minuten war die Kapazität des Akkus erschöpft und das System schaltete sich ab. Die folgenden Bilder demonstrieren diesen Vorgang.

Beginn mit voll aufgeladenem LiPo-Akku
Entladung nach 10 Minuten
Erneutes Aufladen des LiPo-Akkus

Es soll an dieser Stelle noch ausdrücklich darauf hingewiesen werden, dass für den Betrieb hier keine WiFi-Verbindung genutzt wurde. Eine WiFi-Verbindung erhöht den Stromverbrauch deutlich, so dass wesentlich geringere Laufzeiten erwartet werden müssen.

Maduino GPRS A6

Maduino GPRS A6 ist ein kostengünstiger Netzwerkknoten für das IoT. Der Hersteller
Makerfabs mit Sitz in Shenzhen, China hat auf dem Board einen Mikrocontroller ATmega 328, ein GRRS/GSM-Modul AI-Thinker A6, ein und ein integriertes Power-Management integriert.

Maduino GPRS A6

Das GRPS/GSM-Modul A6 unterstützt Quad-Band 850/900/1800/1900 MHz, das jedes GSM-Netzwerk abdeckt. In Verbindung mit einer SIM-Karte können Daten über GPRS übertragen werden. In meinem Post 2G für IoT Anwendungen hatte ich hierzu entsprechende Hinweise gegeben.

Das Modul kann über die Arduino IDE programmiert werden. Im Wiki sind Hinweise zur Inbetriebnahme und Programmierung enthalten. Hinweise zu einem Firmware Update sind hier zu finden.

Erfassen von Wetterdaten – gar nicht so einfach

Mit zahlreichen, heute angebotenen Sensoren zur Erfassung von Wetterdaten, wie Temperatur, relativer Luftfeuchte, Druck u.a.m. können mit etwas Elektronik sehr einfach Wetterdaten erfasst und im Internet bereit gestellt werden.Openweathermap.org bietet beispielsweise ein API an, mit dessen Hilfe diese Daten im Openweathermap Mapping sichtbar werden. Anforderungen an die Messstelle selbst habe ich auf deren Website nicht gefunden.

Temperatur Mapping

Das Temperatur Mapping in meinem Umfeld zeigt am 2.05.2019 bei bedecktem Wetter keine grösseren Abweichungen.

Mich hat das Verhalten der Openweathermap Messstation an meinem Wohnort im Vergleich zu lokalen Wettersensoren interessiert. Ich habe deshalb selbst einen Temperatursensor DS18B20 in einem von direkter Sonneneinstrahlung geschütztem Bereich installiert und vergleiche die beiden Messwerte. Bei großzügiger Betrachtung kann man sagen, dass beide Messwerte einen Offset von 2.5 ° aufweisen. Selbst wenn man diesen Offset eliminiert, gibt es über den Tagesverlauf unerfreuliche Abweichungen.

Da die Messwerte doch rechte Unterschiede auswiesen, habe ich ein weiteres Außenthermometer hinzugenommen, was allerdings in den Morgenstunden durch Sonneneinstrahlung keine brauchbaren Werte liefert. Das Außenthermometer sendet seine Daten nur zwischen 5:00 und 20:00, was für den Vergleich aber unerheblich sein sollte.

Die Grafik zeigt deutlich, dass ohne Sonnenbestrahlung die Ergebnisse der Openweathermap Wetterstation ausreichend gut repräsentiert werden.

Die Wahl der entsprechenden Messbedingungen entscheidet also erwartungsgemäß über das Ergebnis

Die Situation der im Internet zugänglichen Messstellen kann aber auch ganz anders aussehen. J. Kachelmann zeigt das in seinem Blog im Tagesanzeiger mit dem Titel „Das ideale Geschenk zur Konf“ und wirbt für die gute alte Wetterhütte, die immer noch nicht an Bedeutung verloren hat und für zuverlässige Messwerte die Grundlage schafft.

Angekündigt: MAIXDUINO

Maixduino, Sipeed’s neues MAiX-Board, führt die Arduino IDE und -Bibliotheken mit den MAiX RISC-V Boards (Kendryte K210-Chips) zusammen, wodurch eine großen Anzahl vorhandener Open-Source Arduino-Bibliotheken für die schnelle Entwicklung und das Prototyping mit Sipeed’s RISC-V Boards eingesetzt werden kann.

On-board sind K210 und ESP32. Auch die KPU des K210 wird unterstützt.

Ich verfolge Sipeed auf Twitter, um die Verfügbarkeit nicht zu verpassen. Sipeed’s Development Boards sind unter https://www.seeedstudio.com/sipeed zu finden.

Maixduino

2G für IoT-Anwendungen

Bislang schon bereits für tot erklärt und mit Abschaltungsszenarien belegt, stellt das mittlerweile betagte 2G-Netz immer noch eine Alternative zu 3G/4G und 5G dar.

Dass ein schnelles Internet und damit 5G seine Bedeutung haben, ist keineswegs strittig. IoT Anwendungen mit geringem Datenvolumen und mglw. auch geringen Datenraten kommen aber mit deutlich weniger Ressourcen aus.

Vergleicht man die Netzabdeckung der deutschen Telekom, dann bietet auch das 4G-Netz noch Lücken, die das 2G-Netz nicht bietet. Bei den anderen Anbietern sieht das weniger erfreulich aus.

Netzabdeckung 4G Telekom

Kostengünstige GSM-Module sowie preiswerte und flexible IoT-Tarife lassen 2G für IoT-Anwendungen (M2M) durchaus interessant erscheinen.

Ich verwende für einen abgesetzten Temperatursensor einen Arduino Uno und ein SIM800L EVB.

SIM800L EVB am Arduino Uno

Alternativen sind z.B. Maduino GPRS oder das GSM Modul aus der M5Stack-Familie.

Auf die Software selbst möchte ich hier nicht eingehen. Programmbeispiele zum SMS-Versand und HTTP-Zugriff sind auf Github zu finden.

Ich verwende hier den Mobilfunkanbieter ThingsMobile, der sich ausschließlich dem IoT widmet und international aufgestellt ist.

Der SMS-Versand ist einfach und bequem, allerdings kostenmäßig nicht zu empfehlen. Ich sende den Temperaturmesswert über HTTP-GET alle 5 Minuten an den Thingspeak-Server zu Visualisierung. Die erhobenen Messwerte können über die URL abgegriffen werden. Der Sensor selbst liegt auf meinem Arbeitstisch, misst also nur die Raumtemperatur.

Interessant sind die entstehenden Kosten. Aus dem Thingsmobile Report für die vergangene Woche kann man die folgenden Daten entnehmen:

Report für KW15

Der Datenverkehr belief sich auf 2.19 MB, die € 0.22 gekostet haben. Der Auszug aus dem Detailreport gibt einen Überblick über die versendeten Daten. Die Datenpakete sind entweder 980 oder 1950 Byte, was zu 370 KB am Tag führt. Diese 370 KB kosten dann € 0.036.

Auszug aus dem Report für den 15.04.2019

Bei diesen Kosten kann aus meiner Sicht für so oder ähnlich angelegte IoT-Anwendungen bedenkenlos mit dem 2G-Netz gearbeitet werden.

Open-Source Real-Time OS für das IoT

Steht man heute vor der Aufgabe, ein neues Embedded System zu entwickeln, dann wird in den Anforderungen kaum die Anforderung nach einer Netzwerkverbindung fehlen. Dabei spielt es in erster Linie keine Rolle, ob es sich um eine drahtlose oder drahtgebundene Kommunikation handelt, ob die Kommunikation durch die Anwendung genutzt wird oder einen Remote Access für Konfiguration und Service darstellt. Möglicherweise lassen sich diese Dinge auch kaum vernünftig trennen.

Ein Embedded System, welches derartige Anforderungen erfüllen muss, ist mit vernünftigem Entwicklungsaufwand nicht ohne Betriebssystem umsetzbar. Die Suche nach einem für die betreffende Aufgabenstellung geeigneten Betriebssystem umfasst, viele und sehr unterschiedliche Aspekte.

Betrachtet man die Langlebigkeit von Investitionsgütern, dann erscheint schon aus strategischen Gründen der Einsatz eines OS-RTOS zwingend. Einer ersatzlosen Abkündigung eines etablierten, proprietären RTOS kann auf diese Weise der Schrecken genommen werden. In einer gewissen Klasse von Embedded Systems bis hin zu Supercomputern gibt es mit Linux ein ausgezeichnetes Beispiel für ein solches Open Source Betriebssystem.

Damit ist Linux heute ein mächtiges Betriebssystem, welches aber auch gewisser Ressourcen bedarf und für Systeme mit kleinem Footprint, geringen Ressourcen und möglichst für Batteriebetrieb angepasstem Stromverbrauch weniger geeignet ist.

Analysiert man aus Github Daten für Code Frequency, Commits und Contributions für Contiki, RIOT und Zephyr, dann kann deutlich eine größere Aktivität der Community beim Zephyr OS gegenüber den anderen beiden RTOS verzeichnet werden. Natürlich ist das Zephyr OS auch ein „junges“ RTOS, was nicht in allen Bereichen bereits ausgereift sein kann.

Das Zephyr Project (https://www.zephyrproject.org/what-is-zephyr) ist ein von der Linux Foundation gehostetes Collaboration-Projekt, eine Open Source Zusammenarbeit, die führende Kräfte aus der gesamten Branche zusammenbringt, um mit dem Zephyr OS ein skalierbares Echtzeit-Betriebssystem (RTOS) für mehrere Architekturen ressourcenbeschränkter Geräte zu entwickeln.

Der in der Zeitschrift Design & Elektronik erschienen Beitrag mit dem o.a. Titel (Design & Elektronik 3/2019, S. 42-48  ) soll Einblicke in das Zephyr OS und die Zephyr Entwicklungsumgebung geben. An Hand einiger einfacher und nachvollziehbarer Programmbeispiele wird die Vorgehensweise bei der Programmierung von Anwendungen und der Build Prozess dokumentiert. Die Programmbeispiele selbst sowie dazugehörige Screenshots sind auf Github unter https://github.com/ckuehnel/zephyrtests abgelegt.

Das Zephyr OS ist ein Open Source RTOS, welches durch das von der Linux Foundation gehostete Zephyr Project und die Nähe zu Linux das Potential hat, bei Embedded Systems mit kleinem Footprint in Zukunft vergleichbar erfolgreich zu werden, wie es Linux bei Systemen mit mehr Performance schon länger ist. Der Erfolg wird sicher stark durch die Community geprägt. Ausdauer und Kraft sind der Community zu wünschen. Die zentrale Mailinglist des Zephyr Projects [ https://lists.zephyrproject.org/g/main ] gibt aktuell Auskunft über die laufenden Aktivitäten.