Wie allseits bekannt hat Microchip 2016 Atmel übernommen und bietet jetzt nicht nur PIC-Mikrocontroller, sondern auch Atmel-Produkte einschließlich der AVR-Mikrocontroller an. Microchip wird die AVR-Serie nicht nur beibehalten, sondern sogar erweitern und neue Funktionen und Merkmale hinzuzufügen. Tools und Evaluierungsboards enthalten nun also das Beste von allen Produkten, die von Microchip angeboten werden. In diesem Kontext möchten wir Ihnen die Entwicklungsboards AVR-IoT und PIC-IoT WA von Microchip vorstellen, die der WLAN-Anbindung zu AWS IoT Core (Amazon Web Services) dienen.

Die ersten Schritte in die Welt von Cloud-Storage und -Computing sind nicht ganz trivial. Der Betrieb einer sicheren Datenübertragung zu einem Cloud-Service wie AWS bei geringem Energiebedarf kann für Entwickler ziemlich herausfordernd ausfallen. Microchip bietet hierfür zwei Entwicklungs-Boards an, die den Zugang zu AWS IoT Core ermöglichen und dabei eine sichere Kommunikation über WLAN bei geringem Energieverbrauch bieten und die nötige Entwicklungszeit verkürzen. Bevor wir die Hard- und Software detailliert beleuchten, werden wir zunächst den Lieferumfang zeigen und überlegen, was man von diesen Lösungen erwarten kann.

 

Was ist drin?

Auf den beiden fast identischen Kartons (Bild 1) ist ein Link und ein QR-Code aufgedruckt, die zu der zugehörigen Produkt- Webseite führen.

Bild 1. Beide Kartons nebeneinander.

Da fast jeder über mehr als genug USB-Kabel verfügt, sind diese aus Platz- und ökologischen Gründen nicht enthalten. Die beiden Kartons enthalten unterschiedliche Boards. Das Entwicklungsboard PIC-IoT WA (Produkt-Nummer: EV54Y39A) basiert auf der zentralen MCU PIC24FJ128GA705. Das Entwicklungsboard AVR-IoT WA (Produkt-Nummer: EV15R70A) basiert auf einer ATmega4808-MCU aus der AVR-Reihe. Man hat also bei gleicher Funktion die Wahl zwischen einer PIC- oder einer AVR-Lösung.

In Bild 2 sieht man, dass sich nicht nur die Kartons, sondern auch die Boards stark ähneln.

Bild 2. Beide Entwicklungsboards ohne Verpackung.

Am rechten Rand der Platinen (Bild 3) sitzt eine Mikro-USB-Buchse, die das Board mit Strom versorgt und das System mit dem Debugger verbindet.

Bild 3. Debugger- und Stromversorgung.

Neben dem USB-Anschluss ist der Debugger zu sehen, und darüber befindet sich eine Ladeschaltung für Lithium-Akkus. Ist ein solcher angeschlossen, kann das Board als netzunabhängige Lösung verwendet werden.

 

Hardware der Entwicklungsboards

Die Stromversorgung beherbergt das Li-Ion/LiPo-Lade-IC MCP73871, das vom Abwärtswandler MIC33050 mit integrierter Induktivität unterstützt wird. Diese Kombination eignet sich für eine Lithium-Akkuzelle mit einer Ladeschlussspannung von 4,2 V (wichtig bei Auswahl der Zelle); der DC/DC-Wandler bietet einen Strom von bis zu 600 mA.

Das Lade-IC fungiert als ideale Diode und verhindert einen Rückfluss des Stroms vom Akku zurück zum USB-Anschluss. Es gibt noch mehr auf der Platine, das eine genauere Betrachtung verdient: Weiter links sieht man mit dem Temperatursensor MCP9808 und dem Krypto-Co-Prozessor ATECC608A zwei ICs und einen Lichtsensor. Der Krypto-Chip kann zwar zur sicheren Kommunikation zwischen dem Board und den AWS IoT Core Services eingesetzt werden, doch ist er nicht darauf beschränkt, sondern ermöglicht sichere Kommunikation mit verschiedenen Cloud-Diensten.

In der Mitte befindet sich der zentrale Mikrocontroller. Die Variante mit dem PIC24FJ128GA705 bietet 128 KB ECC-Flash und 16 KB RAM. Bei 32 MHz Takt erreicht diese MCU 16 MIPS und bietet ein schönes Set an Peripherie sowie einen Low-Power-Modus. Bei der Variante ATmega4808, einer der neueren AVR-MCUs, stehen 48 KB Flash und 6 KB RAM zur Verfügung. Bezüglich Peripherie ähnelt er eher einer XMEGA- als einer typischen AVR-MCU. Der ATmega4808 erreicht mit einem Takt von bis zu 20 MHz maximal 20 MIPS und bietet erweiterte Peripherie sowie Energiespar-Optionen.

Am linken Platinenrand sitzt das WLAN-Modul ATWIN1510 (Bild 4).

Bild 4. Das WLAN-Modul ATWINC1510.

Es unterstützt als per SPI angebundenem 2,4-GHz-Single-Band-Controller den Netzwerkzugang nach IEEE 802.11 b/g/n. Das Modul bietet mehr als nur WLAN: Man kann es quasi als Netzwerk-Coprozessor betrachten, der anspruchsvolle Aufgaben wie die Verschlüsselung des Traffics und TCP/IP-Paketverarbeitung übernimmt.

Die mittigen Buchsenreihen an beiden Seiten (Bild 5) sind mikroBus-Click-Board-Steckverbinder, mit denen man zusätzliche Sensoren und Geräte aus dem Sortiment oder mikroBus-kompatible Geräte z.B. zur 3D-Bewegungserkennung aufstecken kann.

Bild 5. Der mikroBus-Anschluss des Entwicklungsboards AVR IoT WA.

Dreht man das Board um, dann entdeckt man, dass die verfügbaren Anschlüsse mit ihrem Namen und Pin-Nummer gekennzeichnet sind (Bild 6).

Bild 6. Die Rückseite des Entwicklungsboards mit Pin-Bezeichnungen.

Wer an weiteren Details der Platinen wie etwa Schaltplänen interessiert ist: Microchip stellt schön gestaltete Anleitungen für beide Varianten zur Verfügung, die nicht nur viele Informationen bieten, sondern auch einen Schnellstart für die AWS-Verbindung beinhalten.

 

Vorinstallierte Software

Beide Boards kommen mit vorinstallierten Beispielanwendungen, die einen direkten Out-of-the-Box-Test für den AWS IoT Core unter Verwendung eines Microchip-Accounts ermöglichen. An dieser Stelle eine Warnung, die auch in der Schnellstartanleitung zu finden ist: Die mit diesem Account verschickten Daten stehen allen Zugangsberechtigten zur Verfügung. Praktisch bedeutet das hier, dass sie quasi öffentlich zugänglich sind. Die Integration der Boards ins eigene Netzwerk ist unkompliziert: Beim Anschluss des Boards an einen PC erscheint ein neues Massenspeicherlaufwerk namens CURIOSITY. Die Datei CLICK-ME.HTM im Stammverzeichnis kann in einem Browser geöffnet werden. Sie führt durch die nötigen Konfigurationsschritte. Zuerst aktualisiert man die Firmware für die MCU auf die neueste Version (Bild 7), sonst gibt es Probleme bei der Konfiguration des WLANs.

Bild 7. Die Datei CLICK-ME.htm zur Konfiguration der Boards.

Da die Firmware des Sicherheits-Chips dadurch noch nicht aktualisiert ist, kann er noch veraltete Firmware samt veralteter oder Zertifikate enthalten. Sollten sich Probleme bei der AWS-Verbindung ergeben, werfen Sie einen Blick in den Textkasten „Was noch nicht im Manual steht“. Dort ist nachzulesen, wie man alle Komponenten des Boards auf die neueste Version aktualisiert. Für die Aktualisierung ziehen Sie die heruntergeladene Datei mit der Extension „hex“ auf das Laufwerk CURIOSITY. Anschließend wird die neue Firmware automatisch in den Flash-Speicher übertragen und die MCU neu gestartet.

Das Board in das eigene WLAN zu bekommen ist eine Sache von wenigen Klicks. die Eingabe der Zugangsdaten zur Ihrem WLAN erfolgt direkt via CLICK-ME.HTM (Bild 8).

Bild 8. Nach erfolgreicher WLAN-Verbindung kommen die ersten Daten an.

Dabei wird eine WIFI.CFG-Datei erzeugt, die per Drag & Drop auf das Laufwerk CURIOSITY gezogen wird, um die WLAN-Zugangsdaten in der MCU zu speichern und damit eine Verbindung zum WLAN herzustellen. Ist diese Verbindung hergestellt, wird das Board versuchen, sich mit dem AWS-Service zu verbinden und dann mit der Veröffentlichung von Daten zu beginnen.

 

Wie geht es weiter?

Der kleine Knopf unter den Sensorwerten führt durch die nächsten Schritte. Der erste ist die Einrichtung von MPLABX (Bild 9).

Bild 9. Aufbau der AVR GNU Toolchain.

Nach der Fusion von Microchip und Atmel wurde die MPLABX-Entwicklungsumgebung, die ursprünglich für die PIC-Entwicklung gedacht war, um AVR- und SAM-Chips ergänzt. Auch wenn das nicht mit dem Look & Feel von Atmel-Studio (basiert auf Visual Studio) übereinstimmt, ist es erfreulich, dass man so nicht mehr auf Windows festgelegt wird. Auch Benutzer von MacOS und Linux werden damit AVR-basierte Projekte entwickeln können – Letztere gar auf AMD64-Maschinen. Wer nur eine 32-bit-CPU zur Verfügung hat oder aber noch ein 32-bit-Betriebssystem verwendet, wird mit der neuesten Version von MPLABX Pech haben. MPLABX basiert auf der Entwicklungsumgebung Netbeans, die einst als IDE für Java begann und im Laufe der Zeit auf andere Sprachen erweitert und später von Microchip zu MPLABX modifiziert wurde. Zum Entstehungszeitpunkt dieses Artikels war die Version 5.45 aktuell, die hier auf einem Windows-Rechner verwendet wurde. Die verschiedenen Architekturen benötigen entsprechende Compiler und die Support-Dateien. Der einfache Weg hierfür ist, sie bei genügend Platz auf dem Laufwerk gleich während der Installation mitzuinstallieren. Man muss lediglich die verwendete Architektur auswählen, um die Support-Dateien zu erhalten. Bezüglich Compiler wird man nach der Installation darüber informiert, dass man ihn von der Microchip-Website holen muss. Wer den von Atmel Studio 7 gewohnten AVR-GCC-Compiler verwenden will, muss diesen manuell von der Microchip-Seite herunterladen, die Zip-Datei extrahieren und den Compiler manuell zu MPLABX hinzufügen (Bild 9). Hier wird der Pfad zum Verzeichnis angegeben, in dem die Compiler-Dateien extrahiert wurden. Er muss zum Ordner bin führen – ansonsten wird die AVR8-Toolchain nicht erkannt. Da die Beispielprojekte standardmäßig mit der XC-Compiler-Serie kompiliert werden, ist dieser Schritt ist nicht erforderlich, aber hilfreich, wenn man an die Arbeitsweise des AVR-GCC gewöhnt ist.

 

Entwicklungsboard AVR-IoT WA

Hier muss man die neueste AVR-IoT-WA-Anwendung herunterladen. Nach dem Herunterladen des Codes kann dieser mit MPLABX geöffnet werden (Bild 10).

Bild 10. Überblick über das MPLABX-Projekt und die Dokumentation.

Durch das angeschlossene Board bekommt man auch alle Ressourcen und Links zur Dokumentation präsentiert. Der Code wird für die nächsten Schritte des Tutorials benötigt und ermöglicht die Anpassung der Anwendung für eigene Zwecke oder aber er inspiriert zu eigenen Ideen und Entwicklungen. Bild 11 zeigt das geöffnete und erweiterte Projekt.

Bild 11. Erweitertes Beispiel-Projekt für das AVR-Board.

Der letzte Schritt des Tutorials für das AVR-Board zeigte zum Zeitpunkt meiner Experimente noch nicht die neueste Struktur des Codes. Es braucht einige Sekunden, um die wesentlichen Teile des Codes zu finden. Zur Erleichterung werden in Bild 12 die erforderlichen Code-Änderungen gezeigt, damit die grüne LED als Aktuator arbeiten kann.

Bild 12. Tutorial Schritt 3 – hier muss der Code modifiziert werden.

Nachdem der Quellcode geändert wurde, kann er auf das AVR-Board hochgeladen werden und der LED-Status kann mit dem Schiebeschalter gesteuert werden (Bild 13).

Bild 13. Dieser Schalter steuert den Status der LED auf der Platine.

Abgesehen von diesem kleinen Glitch funktioniert das Board wunderbar. Wenn man das Tutorial durchgearbeitet hat, stehen einem noch die Microchip IoT Developer Guides for AWS für weitere Informationen und zur Verwendung dieser Boards mit Amazons Web-Services zur Verfügung.

 

Entwicklungsboard PIC-IoT WA

Hier muss die PIC-IoT-WA-Anwendung heruntergeladen werden. Der Code kann in MPLABX geöffnet werden und hat die gleiche Struktur wie der Code für den AVR. Das Tutorial funktioniert fast genauso wie das des AVR – nur dass ein PIC mehr Flash, zusätzliche Peripherie und auch etwas mehr RAM bietet (Bild 14).

Bild 14. Ressourcenverbrauch beim PIC-basierten Board.

Man beachte, dass ein PIC im Vergleich zu AVR mehr Breakpoints in der Hardware für das Software-Debugging und Daten-Watchpoints bietet, wobei die Instruktionen pro Takt weniger effizient sind als bei AVR-MCUs. Wer den bereitgestellten Code untersuchen möchte: Der Code von main.c ist wirklich kurz:

 

#include "mcc_generated_files/application_manager.h"

 

int main(void)

{

    application_init();

    

    while (1)

    {

        runScheduler(); 

    }

    return 0;

}

 

Die Initialisierung aller Komponenten erfolgt in application_init(). Diese Funktion steckt in application_manager.c, wo die meisten höheren Funktionen zu finden sind. Der Code verwendet die Funktion runScheduler(), um alle anfallenden Aufgaben zu erledigen und zeitlich zu koordinieren. Hiervon wird die Funktion timeout_callNextCallback() aufgerufen, welche fällige Aufgaben ausführt:

 

inline void timeout_callNextCallback(void)

{

    if (executeQueueHead == NULL)

        return;

    bool tempIE = (IEC0bits.T1IE == 1?1:0);

    IEC0bits.T1IE = 0;

    timerStruct_t *callBackTimer = executeQueueHead;

    // Done, remove from list

    executeQueueHead = executeQueueHead->next;

    // Mark the timer as not in use

    callBackTimer->next = NULL;

    if(tempIE)

    {

        IEC0bits.T1IE = 1;

    }

    uint32_t reschedule = callBackTimer->callbackPtr(callBackTimer->payload);

    // Do we have to reschedule it? If yes then add delta to absolute for reschedule

    if(reschedule)

    {

        timeout_create(callBackTimer, reschedule);

    }

}

 

Der Code prüft, ob etwas zur Ausführung bereit ist, und wenn nicht, kehrt er sofort zurück. Im Folgenden deaktiviert der Code zunächst für eine kurze Zeit einen Timer-Interrupt, worauf wir später eingehen werden, greift das Element, das zur Ausführung bereit ist, und ruft die Funktion auf. Der Aufruf uint32_t reschedule = callBackTimer->callbackPtr(callBackTimer->payload); führt die Funktion aus, und die Funktion selbst gibt die Zeitspanne zurück, in der sie erneut aufgerufen werden muss. Wenn diese Zeitspanne größer als Null ist, wird sie mit der angegebenen Zeitspanne in eine Liste von wartenden Aufgaben zurückgestellt. Der erwähnte Timer und Timer-Interrupt ist der andere Teil, der das System die Tasks ausführen lässt. In einem definierten Intervall wird die Funktion timeout_isr aus dem Timer-Interrupt heraus aufgerufen.

 

void timeout_isr(void)

    {

        timerStruct_t *next = listHead->next;

        absoluteTimeofLastTimeout = listHead->absoluteTime;

        lastTimerLoad = 0;

 

    if (listHead != &dummy) {

    enqueueCallback(listHead);

}

 

    listHead = next;

 

    startTimerAtHead();

}

 

Vereinfacht gesagt überprüft der Code eine Liste von Aufgaben. In der Liste können sich wirklich auszuführende Aufgaben befinden oder Dummy-Aufgaben, die nichts tun. Muss eine Aufgabe ausgeführt werden, wird sie in eine Liste mit fälligen Aufgaben eingetragen. Die nächste auf ihre Ausführung wartende Aufgabe der Liste wird geholt, und der Zeitgeber passt sein Intervall entsprechend an. Die Liste fälliger Aufgaben bearbeitet die schon erwähnte Funktion timeout_callNextCallback. Die ISR plant und bereitet die Aufgaben timer-gesteuert vor, die als Nächstes ausgeführt werden müssen. In Kombination mit der Funktion timeout_callNextCallback wird ein Zyklus erzeugt, in dem die Aufgaben verwaltet und zeitgesteuert ausgeführt werden. Wenn keine Tasks mehr ausgeführt werden müssen, könnte die MCU in den Ruhezustand versetzt werden und darauf warten, dass sie durch den Timer oder andere Events wieder geweckt wird. Dieses Konzept eignet sich nicht nur für dies Anwendung, sondern könnte auch für andere Projekte interessant sein, um Tasks mit reduziertem Stromverbrauch auszuführen.

 

Einen Schritt weiter

Für das AVR-IoT WA Board finden Sie hier eine Anleitung, um das Beispielprojekt mit Hilfe von MPLABX komplett neu zu erstellen. Dadurch wird man besser mit der Entwicklungsumgebung und der Programmierung vertraut. Doch Achtung: Auch wenn das alles gut funktioniert, werden einige Teile und Plug-Ins noch Verbesserungen ihrer Benutzerfreundlichkeit und Stabilität erfahren. Die Bilder 15, 16 und 17 zeigen einige Schritte auf dem Weg durch die Assistenten.

Bild 15. MPLABX-Projektstart.
Bild 16. Auswahl des Ziels.
Bild 17. Konfigurator für Microchip-Code.

Nach der Absolvierung der Schritte der Anleitung hat man ein Projekt, das auch mit dem AVR-GCC kompiliert werden kann, falls man für diesen speziellen Compiler geschriebenen Code einbinden muss.

Bild 17 zeigt auch die Komponenten, die im AWS-Beispiel-Projekt enthalten sind, darunter CryptoAuthLibrary, WINC15XX oder Message Queue Telemetry Transport (MQTT). Sie beschäftigen sich mit den Sicherheitsfunktionen der beiden Boards. AWS IoT Core verwendet MQTT für den Datenaustausch. Wenn keine zusätzlichen Messungen vorgenommen werden, werden die Daten im Klartext ausgetauscht, so dass die Daten auf dem Weg vom Gerät oder zurück verändert werden könnten. Um das zu verhindern nutzt man MQTT Transport Layer Security (TLS) zur Verschlüsselung der Kommunikation. Auf beiden Boards befindet sich ja ein ATECC608A, der die kryptographische Arbeit von der MCU abnimmt. Zwecks Sicherheit bietet der WINC1510 TLS-verschlüsselte Kommunikation und kann dabei durch den ATECC608A unterstützt werden, damit die übertragenen Daten nicht verändert werden können. Aufgrund der Verwendung von MQTT ist man nicht auf den AWS IoT Core beschränkt. Man benötigt lediglich einen MQTT-Broker, der die Verbindungen annimmt und Daten verarbeitet.

 

Einfacher Einstieg

Sowohl Preis der Boards als auch ihre Software-Unterstützung sind auf gutem Niveau. Kombiniert mit den gut ausgestatteten Dokumentations- und Debugging-Möglichkeiten bieten die Boards einen einfachen Einstieg in die Welt der vernetzten Geräte, die mit beschränkter Energieaufnahme laufen. Die integrierte Ladeschaltung für Lithium-Akkus erlaubt den direkten Einsatz im Feld. Der mikroBus-Steckverbinder ermöglicht Zugriff auf eine Menge zusätzlicher Hardware für eigene Projekte. Man kann mit diesen Boards bei der bevorzugten MCU-Architektur bleiben, oder aber man nutzt die Gelegenheit, die jeweils andere MCU-Gattung samt ihren Möglichkeiten kennenzulernen. In Kombination mit dem Onboard-Debugger und der plattformübergreifenden Lösung für alle drei wichtigen Betriebssysteme bieten die Boards eine mehr als vollständige Lösung.
 

Was noch nicht im Manual steht

Es kann sein, dass beim gelieferten Board mit älterer Firmware die Daten für den ATECC608A veraltet sind. Dann kann sich das Board zwar problemlos mit Ihrem WLAN verbinden, aber keine Verbindung zum AWS IoT Core herstellen. Sie können dann nicht die Schritte der Anleitung nachvollziehen. Um die neueste Firmware auch für den ATECC608A und den Onboard-Debugger aufzuspielen, kann man das IoT Provisioning Tool verwenden. Es läuft auf allen drei wichtigen Betriebssystemen als Kommandozeilen-Anwendung. Hierzu entpackt man die heruntergeladene Datei, und startet das Terminal (MacOS und Linux) bzw. eine Befehlszeile (cmd.exe bei  Windows). Für Windows lautet der Befehl iotprovision-bin.exe -c aws -m sandbox. Anschließend ist das Board „up to date“ und alle erforderlichen Zertifikate sind vorhanden. Für die Verwendung von Google-Services sollte man sich das Video-Tutorial von Microchip zum Wechsel des Cloud-Providers anschauen.