Willkommen, Christian!

Einleitung

@clemens erzählte mir vorhin, dass @ckrohne auf seiner Linux-Workstation nun ebenfalls eine lokale Sandbox-Installation betreibt. Exzellent und herzlich Willkommen!

Es handelt sich wohl um eine CentOS-Installation, bei der es u.U. auch ein paar Klippen zu umschiffen gab [1]. Dazu würden wir gerne etwas mehr erfahren, damit wir sukzessive den Anwendungskomfort weiter verbessern können.


  1. Betrieb der Terkin-Sandbox für MicroPython auf Debian GNU/Linux 9 (stretch) oder Ubuntu 14.04.6 LTS (Trusty Tahr) ↩︎

A post was split to a new topic: Betrieb der Terkin-Sandbox für MicroPython auf CentOS

Hallo Andreas,

für mich als Neuling ist alles erstmal ziemlich unübersichtlich und muss erstmal erfahren, wie alles zusammenhängt.

Leider ist meine Entwicklungsumgebung offensichtlich nicht optimal, so hatte ich zunächst unter Windows 7 begonnen, was allerdings nicht erfolgreich war, da die USB-Verbindung nicht erkannt wurde. Daher der Umstieg auf Linux CenOS 7. Da habe ich Deine Sandbox-Beschreibung verwendet, da ich keine graphische Oberfläche an diesen Rechner habe (nur Konsole) und das ging soweit ganz gut, bin aber nicht mit dem Firmware-Update zurecht gekommen. Außerdem gab es Versions-Schwierigkeiten mit pip und python.

Aber WLAN und FTP hatte ich zumindest am Laufen allerdings sehr instabil.

Nach Rücksprache mit @clemens wäre die graphische Bedienung mit dem Pycom-Firmware-Update- und Atom-Tool komfortabler, so dass ich doch umgestiegen bin auf Ubuntu. Das ist jetzt mein letzter Stand. Mit dem Pycom-Firmware-Update-Tool konnte ich ein Firmware-Update durchführen auf die Version 1.16.1 (latest) und die aktuelle BOB Software mit dem Atom-Tool laden.

Das Laden der SW ist allerdings sehr instabil, die einzelnen Dateien werden immer wieder abgebrochen und war erst nach etlichen Versuchen erfolgreich. Wenn die SW dann anläuft, kann die WLAN- Verbindung zum Router nur sehr sporadisch aufgebaut werden - selten wird auf ein Ping geantwortet. Per telnet oder http bin ich noch gar nicht rangekommen.

Ich hatte die Hoffnung, dass vielleicht die von Clemens erwähnte Version (FiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire.tar.gz) besser läuft - aber da weiß ich jetzt nicht, ob das überhaupt eine Ubuntu-Version ist, und wenn ja wie ich die Laden kann?
Wie du siehst, habe ich drei Wege verfolgt - was würdest du vorschlagen, mit welchem OS ich weitermachen soll?

Wegen der Instabilität der laufenden SW sowohl unter CentOS als auch unter Ubuntu, stelle ich mir die Frage, ob vielleich mit der HW etwas nicht stimmt!

Eine Sache ist mir aufgefallen! Auf dem Pycom FiPy - Board sind zwei Connektoren für Antennen! Ist eine externe Antenne vielleicht zwingend notwendig, die habe ich nämlich nicht und wenn ja, welche ist zu bestücken? Dies würde allerdings nicht Instbilität beim Laden der BOB-SW mittels Atom erklären!

1 Like

Danke, für einige meiner Fragen hast du ja schon eine Antwort geschrieben.

1 Like

Hi Christian,

Das könnte in der Tat mit der Dragonfly-Firmware stabiler über die Bühne gehen.

Das klappt entweder über die Prozedur – wie oben beschrieben – innerhalb der Make-basierten Sandbox, oder über das grafische Benutzerinterface, indem im folgenden Dialog “Flash from local file” ausgewählt wird, wo man dann den Pfad zur Datei FiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire.tar.gz angibt.

2019-10-25%2022_32_30-Pycom%20Upgrade

Auf jeden Fall solltest Du aber vorher den erase_all-Vorgang ausführen, entweder per oben beschriebenem make erase-device, oder direkt per pycom-fwtool-cli -p "your com port" erase_all. Ansonsten kann es in der Tat zu den von Dir beobachteten Instabilitäten bei der WiFi-Konnektivität kommen.

Viel Erfolg!

Viele Grüße,
Andreas.

Hallo Andreas,
das hat jetzt geklappt, das Laden der BOB-SW läuft jetzt wirklich stabil durch und die SW läuft zyklisch durch die Messung (allerdings noch ohne angeschlossene Sensoren). WLAN geht weiterhin nur sehr sporadisch / meist “No network connection”.
In den nächsten Tagen werde ich das ganze nochmal unter CentOS probieren.
Gruß
Christian

2 Likes

Hast Du den erase_all Vorgang wie oben beschrieben ausgeführt?

Ja hatte ich gemacht:

pycom-fwtool-cli --port /dev/ttyUSB0 erase_all
pycom-fwtool-cli --port /dev/ttyUSB0 flash --tar FiPy-1.20.1.r1-0.6.0-pybytes-dragonfly.tar.gz

Allerdings unter Ubuntu!

Das ist völlig in Ordnung.

Hm, dann weiß ich leider auch nicht direkt weiter.

Wir haben festgestellt, dass die WiFi-Konnektivität nicht immer gut auf Anhieb läuft, deswegen fassen wir beim Terkin-Datenlogger mehrmals nach, um bei der initialen Verbindungsaufnahme auf Anhieb Konnektivität zu bekommen.

Versuche mal das Timeout Hoch zu setzen hat bei mir und meiner Fritzbox auf alle fälle geklappt.
Bei einigen Routern dauert es anscheinend länger bis eine Verbindung aufgebaut wird.

Wenn Du Die Hiverize-Firmware mit dem Webinterface drauf hast glaube ich unter Grundkonfiguration.
von 1000 auf 10000 oder 15000

Und wenn Du die Hiveeyes Firmware verwendest:
Die W-Lan Config in der config die zeile um timeout ergänzen. aber mit der Hiveeyes Firmware hatte ich persönlich nie Probleme. da steht das Timeout auch standardmäßig auf 15 000

{'ssid': 'FooBar', 'password': 'SECRET', 'timeout': 15.0},

gruß Micha

2 Likes

Danke Micha,
mit dem längeren Timeout klapp’s jetzt gut.
/Christian

2 Likes

Einleitung

So nun habe ich den Betrieb der Terkin-Sandbox für MicroPython unter CentOS
lauffähig bekommen - war letztendlich dann doch recht schnell, dank der vorhandenen guten Doku.

Vorbereitungen

Zuerst die Installation der Notwendigen Pakete unter CentOS:

sudo yum -y install python python3 python-virtualenv lftp
sudo yum -y install pip
sudo yum -y install py-notifier
sudo yum -y install unoconv
sudo yum upgrade python pip
sudo yum install pip
sudo yum install python
sudo yum install py-notifier
sudo yum -y install python3
sudo yum  uninstall python

Installation der Pycom Firmware

Dann die Installation der hiveeyes-micropython-firmware:

sudo usermod -aG dialout $USER
cat /etc/group
git clone https://github.com/hiveeyes/hiveeyes-micropython-firmware
cd hiveeyes-micropython-firmware
make setup

liefert bei mir zwar Fehler, aber es scheint trotzdem zu gehen!

Board an USB anschließen und Device ermitteln:

make list-serials  //liefert bei mir z. B.
Serial Device: /dev/ttyS1
Serial Device: /dev/ttyS0
USB Serial Device 04d8:ef98 with vendor 'Pycom' serial 'Pyd63419' intf 'Expansion3' found @/dev/ttyACM0

Das Ergenis in der Variablen MCU_PORT setzen:

export MCU_PORT=/dev/ttyACM0

pycom_firmware_update - Tool installieren - ich habe dafür pycom_firmware_update_1.16.1-amd64 benutzt:
Nach Entpacken der beiden tools nach /usr/bin/...:

sudo tar -xzf pycom_firmware_update_1.16.1-amd64.tar.gz -C /usr/bin/

Aktuelle Firmware-Version Downloaden- ich habe die Version “FiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire” benutzt.
Dann auf die Firmware vom Board löschen und die Firmware laden:

pycom-fwtool-cli --port /dev/ttyACM0 erase_all
pycom-fwtool-cli --port /dev/ttyACM0 flash --tar /media/WD-NAS/trash/BOB/FiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire/FiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire.tar.gz

Installation des Terkin-Datenloggers

Nun kann das Board programmiert werden.
Zunächst das Netzwerk:

make device-info
make ip-address
make connect-wifi ssid=MySSID password=MyPassword

Dann sollte der DHCP-Server das Board mit einer IP-Adresse versorgen. Das sollte in der Regel
der Router machen hier kann dann auch die MAC-Adresse des Boards ermittelt werden und ich habe dann im DHCP-server für diese MAC-Adresse eine fest IP-Adresse vergeben. Das macht die Suche und weitere Bedienung einfacher.

# Get most recent development sources
git pull

# Setup the sandbox environment on your workstation
make setup

# Upload framework and datalogger to the device
make install

Konfiguration vornehmen

settings.py” anpassen gemäß Vorgabe von “settings.example-bob.py

# Upload program sketch and invoke hard reset.
# This just uploads "boot.py", "main.py" and "settings.py".
make sketch-and-run

Fazit

Danach lief die SW auf dem Board und liefert alle 60 Sekunden Daten.

Rückfrage

Allerdings werden nicht immer alle Daten geliefert - da stellt sich mir die Frage, warum.
Es sind auch einige Fehler im Log-Protokoll zu sehen.

@Andreas: Was ist hierfür die Ursache?
Log.txt (28,2 KB)

2 Likes

Hallo Christian,

Exzellent! Glückwunsch und danke. Schön, dass alles so reibungslos geklappt hat.

Hier gibt es auch noch einen “Fastpath”. Das könnte in etwa so klappen:

export MCU_PORT=192.168.1.42
make recycle-ng MPY_CROSS=true MPY_TARGET=pycom MPY_VERSION=1.11

Das lädt dann die Quelldateien per FTP hoch, was deutlich schneller über die Bühne gehen müsste als über die UART/REPL. Außerdem werden die Dateien vorher schon ins Bytecode-Format übersetzt, so dass die insgesamte Datenmenge deutlich geringer ist.

Viele Grüße,
Andreas.

2 posts were merged into an existing topic: Fehlende Meßwerte bei den DS18B20- und BME280-Sensoren