Posts mit dem Label Meadow werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Meadow werden angezeigt. Alle Posts anzeigen

Sonntag, 28. März 2021

Da will man wieder... (Meadow)


Seit Monaten lag mein Meadow Microcontroller unbenutzt im Schrank, wie auch die eingekauften Sensoren, die teilweise noch verpackt waren. Mein Ziel war eigentlich am Samstag ein neues Code-Beispiel zusammen zu schreiben für die Verwendung eines CO2 Sensor im .NET Umfeld.

Also begann ich mit dem Lesen von Dokumentationen und bereits bestehenden Code aus der C++ Welt und schrieb entsprechend dann die .NET Lösung. Dann sollte der Programmcode auf den Meadow geschrieben werden … aber es kam anders. Ein Blogeintrag über das Suchen und Finden von Fehlern, bevor ein Blogeintrag entsteht..


Fehler beim Verwenden von Dingen

Nicht aussagekräftige Fehler können einen aufhalten und kosten Zeit. Letztes Mal war es das Bereitstellen mit F5, welches bei allen Anwendungen zum Kompilieren und Starten genutzt wurde, welches aber bei dem Meadow nicht so funktioniert. Hier muss mit der rechten Maus-Taste auf das Projekt und anschließend auf Deploy geklickt werden. Einfach, aber so etwas kann einen echt ausbremsen.
 

Dieses Mal trat der Fehler beim Verwenden der Komponenten aus dem Meadow Framework auf, welches folgende Meldung im Debug Output zeigte:

ioct1 Esp32Command failed OperationNotPermitted

Der Satz sagte mir nicht, dass meine MeadowOS Version zu alt ist. Mein letztes Projekt vom August 2020 verblieb bis zuletzt unverändert. Aber auch diese funktionierte nicht mehr und stieg mit der Fehlermeldung aus, dass die Datei Mono.Security.dll nicht gefunden wurde.

Welche Abhängigkeiten habe ich hier an der Stelle, wenn ich nicht das NuGet Packet Meadow.Foundation v0.17.0 und sowie auch das .NET Framework 4.7.2  geändert habe?


Das alleine reichte nicht

Wenn ich Deploy geklickt hatte, dann hing Visual Studio. Das ließ sich beheben, indem ich die USB- Verbindung zum Meadow trennte. Idealerweise muss man auf dem Meadow nur den Reset Button drücken, damit das Deployment weiter fortschreitet.

 

Niemals ein funktionierendes System ändern?

Oder besser bekannt: never change a running system. Wieso also kann es nicht weiterhin funktionieren, wenn man nichts verändert? OK, ich habe Visual Studio 2019 immer aktualisiert, aber ich aktualisiere nicht immer die einzelnen Projekte. Außer das verwendete Framework ist so alt, das man dessen Frameworks nachinstallieren muss.

Ich habe eine alte Windows Form Anwendung, die selbst nach über 12 Jahre immer noch geht. Ok, ich muss hier .NET Framework 2.0 nachinstallieren, welches automatisch nachgefragt wird, und nur noch zustimmen.

 

Aktualisierung benötigt

Weiter geht’s: Ich komme nicht dran vorbei, die entsprechenden Aktualisierungen am Projekt vorzunehmen und auch den Meadow mit einer aktuelle OS Version zu flashen. Auf der Webseite 'Wilderness Labs' kann man die aktuellen Binaries herunterladen.
Wie sich später herausstellte, sind es zwei Zip Datei. Beim nochmaligen Durchlesen der Beschreibung "Deploy Meadow OS" stellte ich fest, dass die Beschreibung selbst aktualisiert wurde.
Finde ich gut, aber der Textaufbau auf der Seite ist nicht linear und erschwert das Lesen, obwohl die Beschreibung relativ sauber beschrieben ist. Mal ist der auszuführende Befehl rechts und mal direkt im Text eingerückt. Vielleicht eine Kleinigkeit und vielleicht ein Problem meiner Wahrnehmung, weil ich scheuklappenartig den Text lese und am Rand eh nur Werbung vermute (Anmerkung an der Stelle, auf der Webseite sind keine Werbe Ads vorhanden).

 

Schritt für Schritt

Gehen wir also nochmal Punkt für Punkt die Beschreibung durch:

Haste .NET 5.0 SDK?
Nein. Wird also installiert.

Wie sieht es mit Meadwo.CLI aus?
Auch nicht. Wird installiert.

Update USB Treiber für Bootloader?
Noch aktuell.

Aktuelle Meadow OS und Network Binaries?
Hatte ich heruntergeladen.
Später sah ich rechts im blauen Feld den Befehl, mit dem sich die aktuellen Version einfach in den vorgesehenden Ordern herunteladen lässt und dessen ZIP Inhalt auch automatisch entpackt. (COMMAND: meadow --Download)

Meadow in den Bootloader Modus umschalten?
Geht. Boot Button gedrückt halten und dann anschließen.

Meadow.OS und Coprocessor Firmware flashen mit dem Befehl: meadow --FlashOS?
Geht nicht. Endet mit der Unbehandelten Ausnahmefehler: System.ComponentMode.Win32Exception

Grrrr… Why?!?

 

Die Community fragen

Davon verspreche ich mir in der Regel nicht viel. Anscheinend ist das Thema 'Lösungen' in einem Forum untergegangen, seit dem Stackoverlfow exisitiert. Damit will ich nicht ausschließen, dass sich dort keine Lösungen finden. Man muss halt nur ein paar mehr Seiten lesen und nicht hilfreiche Kommentare ertragen.

Meine letzte Frage in dem Forum wurde bis heute nur von mir selbst beantwortet. Vielleicht peinlich, dass ich nicht mehr wusste, dass die Nutzungserfahrung für das Bereitstellen beim Meadow nicht mehr gelten.

Dass eine Frage von mir nicht von einem anderen User beantwortet wurde, ist nicht das erste Mal. Gleiches Forum, anderer Microcontroller. Fairerweise muss man sagen, dass dort nicht viele Nutzer aktiv sind und auch somit nicht viel geantwortet wird.

 

Try and Error

Nacheinander habe ich die Meadow OS Versionen heruntergeladen und dessen Inhalt betrachtet. In älteren Version fand ich auch dann die damalige verwendete CLI. Leider fand ich den verwendeten Befehl nicht wieder und wusste auch nicht direkt, nach was ich im Netz suchen musste.

Einen Tag später suchte ich weiter nach einer Lösung und stellte fest, dass ich wohl ein Problem mit dem Dfu-util hatte beziehungsweise dieser schlicht weg fehlte. Der folgende Befehl installiert das Tool in den Windows/System32 Order. Ggf. muss CMD oder PowerShell als Administrator ausgeführt werden.

meadow --InstallDfuUtil

Nach dem Installieren konnte nun endlich der Flashvorgang erfolgreich durchgeführt werden.
Nun erklärte sich mir ENDLICH die zuvor aufgetretene Exception, welches als Information nicht aus der Meadow.Cli ausgegeben wurde.
Ok, vielleicht hätte der Fehlertext "…\DfuUpload.cs:line 141 …" mich darauf aufmerksam machen sollen.


Endlich den Meadow benutzen… oder auch nicht

Nachdem ab- und anschließen des Meadow Boards und öffnen der Solution, führte ich den 'gewohnten' Deploy Vorgang aus. Die Spannung stieg!!
Ich sah zu, wie im Output Fenster die Daten hochgeladen wurden. Beim letzten Eintrag wechselten hier der Tab zu "Error List". Hier wurde nichts angezeigt, dafür stand im letzten Eintrag vom "Output" einer neuen Exception… Grrr

Erfolgreich, aber die MeadowClie scheint nicht zu funktionieren

 

Zurück zur Beschreibung

Wiederholt rief ich die Beschreibung auf Wilderness Lab auf und versuchte zu deuten, ob der Schritt drei danach richtig eingerückt war oder noch zu der Beschreibung mit Linux gehörte. Anscheinend ist Schritt drei wirklich Schritt drei und somit war der Aktualisierungsvorgang noch nicht durch. Folgender Befehl:

meadow --MonoDisable -s [PORT]

Wenn der Befehl hängt, dann Reset-Button auf dem Meadow Board und nochmal.


Dann…

meadow --MonoUpdateRt

… und wenn es wieder hängt, Reset und nochmal.


Und zuletzt noch einer…

meadow --FlashEsp

… der sollte anschließend normal durchlaufen.

 

USB Stecker ab- und wieder anschließen

Kommt mir vor wie bei Karate Kid mit auftragen und polieren. War der Vorgang erfolgreich, sollte das Demo Programm laufen. Das ist dann daran zusehen, wenn die LED ständig die Farbe wechselt.


Endlich den Meadow benutzen… yeah es geht

Langer Weg zum Ziel und ich kann mein eigentliches Vorhaben wieder aufnehmen. Das kommt dann mit dem nächsten Blogeintrag. Wenn nicht schon wieder ein Update ansteht...


Rückblickend

Letzten Endes fehlten mir die Erfahrungen mit welche Probleme ich rechen muss.
Ärgerlich, wenn so viel Zeit mit dem Suchen nach Fehlern drauf geht. Keine Ergebnisse zu finden und dabei auf der falschen Fährte unterwegs zu sein. Deshalb schrieb ich diesen Eintrag, allerdings brachte mich meine Freundin darauf, diesen Vorgang zu einem eigenen Thema zu machen.
Und eigentlich sind die Wege zu den Lösungen zu unserer Problemen, die wir als Bastler im Internet suchen, auch mal ein Beitrag wert.

Sonntag, 16. August 2020

Analog Digital Wandler ADS1115 einlesen (Meadow)

Meistens, wenn ich ein Modul finde, das ich noch nicht kenne, dann existiert bereits eine Bibliothek, die in C/C++ geschrieben ist.

Schaut man im .NET Umfeld, dann ist wiederum meistens nichts zu finden. Damit ist mein Interesse geweckt, etwas darüber zu schreiben und natürlich ein Beispiel-Code hier auf meinem Blog zu veröffentlichen.

Seit fast einem Jahr liegt bei mir der Meadow und läuft aktuell mit dem Beispielprogramm. Dieser Controller zielt auf ‚Internet of Things‘- Themen ab und ist der direkte Nachfolger vom Netduino. Im Gegensatz zu dem Netduino, kann mit dem Meadow in der aktuellen C# (8.0) und .NET Framework (4.7.3) Version geschrieben werden. Dies bedeutet auch, dass gegenüber dem veraltetem .NET Micro Framework vieles neu aufgebaut wurde und folglich neue Lösungen geschrieben werden können.

 Benötigt:

  • Meadow
  • Breadboard
  • Jumper Leitungen
  • Potentiometer (oder alternative ein Widerstand und ein Lichtempfindlicher Widerstand)
  • ADS1115

 

Kurzes über den AD Wandler

Bevor ich mit der Zielbeschreibung loslege, müssen einige Details zu dem AD Wandler genannt werden. Beispielsweise, wie hoch darf die Eingangsspannung sein, die auf den vier Eingängen angelegt wird?

Betriebsspannung (VDD)

2V bis 5,5V

Stromaufnahme (Continuous Mode)

150uA

Industrieschnittstelle

I²C

Adresse

0x48 (Kann geändert werden durch Pin Select)

Eingänge

4

Abtastrate

8 bis 860

Eingangsspannung

-0,3V bis +0,3V über der Betriebsspannung (VDD)

Eingangsstrom

10mA bei fortlaufender Messung, 100mA bei einzel Messung

Für manche Anwendung ist auch die Betriebstemperatur wichtig, die hier von -40°C bis +125°C sein darf.


Anforderung

An einem Potitiometer soll die anliegende Teilspannungshöhe geändert werden. Die abgeleitete Teilspannung soll am Eingang A0 eingehen. Über einen Methoden Aufruf soll der Eingang eingelesen und dessen Wert über die Output Konsole ausgegeben werden.

 

Schaltungsaufbau

Im folgendem Bild ist zu sehen, dass ich kein Potitiometer verwende (schlichtweg, weil ich keinen hatte). Alternativ verwende ich einen 10k Ohm Widerstand und einen üblichen Lichtempfindlichen Widerstand (Lichtsensor 30 - 90 KOhm).


Verwenden von bestehenden Informationen

Zuerst wollte ich den bestehenden C++ Code migrieren nach C# und .NET Framework. Das bedeutet im Grunde, dass ich die Methodennamen und die #define Direktiven mit dessen Biteinstellungen (HEX Werte) direkt übernehme. Aber nach und nach stellte ich fest, dass einige Inhalte sich auf andere Module wiederum bezogen und ich immer wieder im Datenblatt nach sehen musste, was eigentlich die einzelne Biteinstellung für das Modul bedeutet. Ein Beispiel ist die Standard Einstellung 128SPS (Samples per second) für den ADS1115 Modul, aber im Adafruit Code steht etwas von 1600SPS.

Das Gute daran ist, man erarbeitet sich selbst eine Lösung, wie die Einstellungen abgebildet werden. Das macht den Aufbau der Klasse einfacher und die Beschreibungen zielgenauer.


Programm code

Im folgenden Beispiel aus dem ‚SimpleCode‘-Branch wurde nur das übernommen, was den Standard- Einstellungen entsprach. Z.B. Bitstellungen, die mit 0 belegt sind (bzw. in HEX 0x00 Wert) mussten nicht sein, da das Anlegen der Konfiguration immer mit 0 beginnt. Der folgende Code ist aus der Klasse ‚SimpleAds1115‘ und hat für den Abruf eine öffentliche Methode ‚ReadSingleInputValue‘ zum Abruf der anliegenden Spannung. Die Parameter-Eingabe bestimmt, welcher Eingang gelesen wird.

 internal class SimpleAds1115 : App<F7Micro, SimpleAds1115>  
 {  
   private readonly II2cPeripheral _i2CPeripheral;  
   public SimpleAds1115()  
   {  
     var i2CBus = Device.CreateI2cBus();  
     this._i2CPeripheral = new I2cPeripheral(i2CBus, 0x48);  
   }  
   internal ushort ReadSingleInputValue(AdsInput input)  
   {  
     // disable the comparator  
     // Single-shot mode (default)  
     // Operational status/single-shot conversion start  
     // - Begin a single conversion  
     ushort config = 0x8103;  
     config |= (ushort)input;  
     byte[] data = new byte[] { (byte)(config >> 8), (byte)(config & 0xff) };  
     this._i2CPeripheral.WriteRegisters(0x01, data);  
     Thread.Sleep(9);  
     var result = this._i2CPeripheral.ReadRegisters(0x00, 2);  
     return (ushort)((result[0] << 8) | result[1]);  
   }  
 }  

Vollumfänglich wird später die Klasse ‚Ads1115‘, die zu dem jetzigen Zeitpunkt nicht fertig ist.


Auf den Meadow schreiben

Sobald die Anwendung über Deploy auf dem Meadow geschrieben wurde, kann über das Fenster 'Output' das Ergebnis der anliegenden Spannung gelesen werden. Mit der Static Methode ‚GetVoltage‘ wird der gelesene Wert umgerechnet in Volt. Den Wert 22610 entnahm ich bei einem Eingangssignal von 5V. An der Stelle könnt Ihr den zu kalibrierenden Wert ersetzen, wenn bei Euch mit 5V ein anderer Wert gemessen wird.

 


Vorsicht mit der maximalen Eingangsspannung

In Standard Einstellungen sind die Eingänge bis 6,144V. Bei dieser Einstellung sollte nicht mehr als 0,3V anliegen, weil dies zur einer Beschädigung des Moduls führen könnte.


Fazit

Zunächst das Offensichtliche:  wenn das eigene Projekt mehr Analog-Digital Wandler benötigt, dann ist dieses Modul genau richtig. In einem I²C Bus können bis zu vier Module adressiert werden. Doch dieses Modul hat noch weitere Funktionen, um sich auf die Bedingungen eines Projektes besser anzupassen. Die Eingänge können auf gezielte Maximal-Spannungen eingestellt werden. Die Anzahl der Messungen pro Sekunde gehen bis zu 860SPS (Samples per second). Die vier Eingänge werden durch ein Multiplex Funktion angesprochen, so das von vier Eingänge auf zwei Eingänge umgestellt werden kann. Mit dem einstellbaren Komparator kann auf spezifische Bedingung reagiert werden.

 

Meadow Code
Github – ExampleAds1115 (SimpleCode Branch)

Ameisen Simulation und andere Dinge

Wer lange sich schon mit C# beschäftig, hat sicherlich schon mal was von AntMe gelesen oder gehört. Diese Idee hatte ich aufgegriffen und mi...