|
|
[ Home
] [ zurück ] [ Seitenende ] [ Teil 4 ] |
|
|||||
|
|
micro:bit-Programmieren, Teil 5 1. Einleitung
Wir benutzen heutzutage, d.h. im Zeitalter von
Windows 7 und 10, USB-Geräte wie z.B. die Maus, die Tastatur, den
USB-Speicherstick, den USB-Drucker und die externe USB-Festplatte wie
selbstverständlich, als hätte es nie etwas anderes gegeben. Nicht zuletzt
auch deswegen, weil wir unsere Smartphones mittels eines USB-Kabels und eines
kleinen USB-2.0-Micro-B-Steckers,
der in das Gerät gesteckt wird, aufladen. Wenn wir aber wissen wollen, was
vor USB war, dann müssen wir zunächst klären, was USB bedeutet und was USB
eigentlich ist. >> Der Universal Serial Bus (USB) [ˌjuːnɪˈvɜːsl
ˈsɪɹiəl bʌs] ist ein serielles Bussystem zur Verbindung eines Computers mit externen Geräten. Mit USB ausgestattete Geräte
oder Speichermedien, wie etwa USB-Speichersticks, können im
laufenden Betrieb miteinander verbunden (Hot Plugging) und angeschlossene Geräte sowie deren Eigenschaften
automatisch erkannt werden. Vor der Einführung von USB gab es eine Vielzahl
verschiedener Schnittstellentypen mit
unterschiedlichsten Steckern zum Anschluss von Zubehör und Peripheriegeräten an Heim- und Personal Computer. Fast alle diese
Schnittstellenvarianten wurden durch USB ersetzt, was für die Anwender
Vereinfachungen mit sich brachte, die jedoch durch die Vielzahl an
unterschiedlichen USB-Steckern und -Buchsen wieder teilweise relativiert
wurden. USB wurde 1996 mit einer maximalen Datenrate von 12 Mbit/s als USB 1.0 eingeführt.
Im Jahr 2000 ist Version USB 2.0 spezifiziert worden, mit
480 Mbit/s die heute noch meistverbreitete Version. Bei dem 2014 eingeführten
Standard USB 3.1 Gen 2 beträgt die maximale Brutto-Datentransferrate für SuperSpeed+ 10 Gbit/s.[1] 2017 wurde
USB 3.2 mit einer Übertragungsrate von bis zu 20 GBit/s spezifiziert.[2][3]
<< (Quelle: Wikipedia) Bei Windows 98 gab es noch keine voll umfänglich
funktionierende USB-Unterstützung. Die kam erst mit Windows
98 SE („Second Edition“, Zweite Ausgabe), das ab dem 10. Juni 1999 als
deutsche Version verfügbar war. Das ist jetzt 20 Jahre her, wobei USB 2.0
inzwischen unter Windows XP, Windows 7 und 10 zuverlässig funktioniert. Nicht
verschwiegen werden soll aber, dass bei der neueren Notebooks und Desktop-PCs
unter Windows 10 inzwischen USB 3.0
auf dem Vormarsch ist. Vor den USB-Zeiten, d.h. vor mehr als 20 Jahren, gab es
Mäuse und Tastaturen, die über zwei runde, etwa 8 mm große „PS/2-Stecker“,
die grün- und violettfarbig eingefärbt waren, damit man sie besser
unterscheiden konnte, betrieben wurden. Dabei handelte es sich ebenfalls wie
bei USB um eine serielle Schnittstelle: >> An Notebooks und einigen kompakten Industrie-PC-Hauptplatinen war dagegen nur eine PS/2-Buchse vorhanden, die fast immer für Maus und Tastatur geeignet ist und – außer bei sehr alten Modellen – auch für beides gleichzeitig mit einem speziellen Y-Kabel genutzt werden kann. Maus und Tastatur unterscheiden sich in ihrem Verhalten beim Einschalten und beim Reset, sodass das Notebook zwischen beiden unterscheiden kann, wenn sie direkt angeschlossen sind. Um sie gleichzeitig an eine PS/2-Buchse anschließen zu können, werden die beiden ansonsten ungenutzten Pins in der Buchse als zusätzliche Takt- und Datenleitungen benutzt. Das Y-Kabel verbindet +5 V und GND des Steckers (Notebook) mit beiden Kupplungen, und je ein Paar aus Takt- und Datenleitungen mit je einer Kupplung. Es werden also nicht einfach alle Kontakte parallel geschaltet, sonst würden sich Maus und Tastatur gegenseitig blockieren. Einige Hersteller haben die
freien Pins auch für andere Zwecke benutzt, beispielsweise um eine Maus für
den kombinierten Betrieb an PS/2 und RS-232 auszulegen
oder um mit einer zusätzlichen Taste auf der Tastatur den PC einzuschalten.
Das kann bei bestimmten Kombinationen von Computern und Mäusen
beziehungsweise Tastaturen zu Problemen führen. Bei den meisten aktuellen
PC-Systemen haben die Hersteller die PS/2-Schnittstelle zugunsten des
hot-plug-fähigen USB ganz aufgegeben. Für alte Betriebssysteme emuliert das
BIOS aber weiterhin mehr oder weniger gut die PS/2-Schnittstelle, auch wenn
Maus und Tastatur tatsächlich über USB angeschlossen sind. << (Quelle: Wikipedia)
Ab 1987 verfügten als erstes die sogenannten „IBM PS/2“-Destop-PCs
über die bunten PS/2-Anschlüsse für den Anschluss der Tastatur (violett) und
Maus (grün), das sich aber auch verschiedenen Gründen nicht auf dem PC-Markt
der „Industriestandard kompatiblen“-PCs durchsetzen konnte: >>
Das neue System bot eine Menge Vorteile, war aber z. B.
nicht kompatibel zu alten Erweiterungskarten oder Disketten und
äußerst teuer. Als Betriebssysteme konnten PC-DOS,
das neue OS/2 oder
gar das Unix-Derivat AIX gewählt werden.
IBM ließ sich den Microchannel sowie weite Teile des Systems
patentieren und verlangte hohe Lizenzzahlungen von Herstellern, die selbst
ein PS/2-kompatibles System anbieten wollten, um zu verhindern, dass die
eigenen Rechner von Nachbauten vom Markt verdrängt würden, wie es beim PC geschehen
war. Die Konkurrenz unter Führung
von Compaq rebellierte;
dieses Unternehmen hatte bereits ein System auf Basis des Intel 386 im
Angebot, das jedoch mit den alten ISA-Steckplätzen versehen war. Das PS/2
konnten sich wegen nur mäßigen Erfolgs nicht durchsetzen. Die nötige
Geschwindigkeit für den IO-Bereich wurde bei den PC-Nachbauten durch neue,
offene Schnittstellen (EISA, VESA Local Bus und
später PCI) nachgerüstet. Der
Microchannel verschwand 1995 mit den letzten PS/2 vollständig vom Markt. Der überschätzte Erfolg hatte Konsequenzen,
IBM hatte seine Marktmacht im PC-Bereich verloren, fortan galt bedingungslose
Abwärtskompatibilität auch auf Hardware-Ebene als oberstes Gebot im
PC-Bereich. Nach den PS/2 Modellen brachte IBM die Reihe PS/ValuePoint auf
den Markt – diese Rechner waren u. a. mit AT-Bus deutlich kompatibler zu
den ursprünglichen IBM-PC Modellen. Letztendlich gab IBM 2005 das Segment
aber an Lenovo ab.
<< (Quelle: Wikipedia)
Vor der nur kurz andauernden Zeit der „IBM
PS/2“-Desktop-PCs gab es neben den „IBM-PCs“ aus
Kostengründen hauptsäch nur „Industriestandard
kompatible PCs“ von diversen Anbietern wie z.B. Commodore, Compaq, Vobis,
ESCOM, Osborne oder Zenith,
die es allesamt schon lange nicht mehr gibt. So verfügten die aus den 80er Jahren
stammenden Personal
Computer (PCs) alle über eine Schnittstellen-Einsteckkarte für die
parallele „Centronics“-Druckerschnittstelle
sowie die serielle „RS232“-Schnittstelle
für den Anschluss einer Maus, eines seriellen Druckers oder eines analogen Modems
mit 9-poligem „Sub-D“-Stecker, um mit diesem ins Internet gehen zu können. >> Serielle
Schnittstellen im weiteren Sinn sind sehr weit verbreitet und existieren in
sehr vielen Ausprägungen und Varianten. Es gehören dazu neben Punkt-zu-Punkt
Verbindungen wie RS-232 und RS-422 auch
Netzwerk- und Busschnittstellen, wie z. B. Ethernet, CAN-Bus oder RS-485.
Datenraten, mögliche Übertragungsdistanzen und andere Eigenschaften unterscheiden
sich z. T. beträchtlich, so existiert für fast jeden Anwendungsbereich
eine passende Schnittstellendefiniton. Siehe dazu die Auflistung weiter
unten. Serielle Schnittstellen
unterscheiden sich nicht nur durch den verwendeten Steckverbinder und
die elektrischen Übertragungsparameter, sie benutzen auch unterschiedliche
Methoden zur Übertragungssteuerung, Datenflusskontrolle und zur
Synchronisation (siehe dazu Kommunikationsprotokoll). Sie können in
eine Richtung ("simplex") oder in beide Richtungen
("duplex") arbeiten, Letzteres entweder abwechselnd
("halb-duplex") oder gleichzeitig ("voll-duplex") (siehe
dazu Duplex (Nachrichtentechnik)). <<
(Quelle: Wikipedia) Siehe auch „RS232-Schnittstelle“
von W&T, „Die
RS232-/V.24-Schnittstelle“ von ADONTEC sowie „Serielle
Schnittstelle, Rolf Keller, c't 1983, Heft 12, S.82ff“ Sehr interessant, aufschlussreich und mit praktischer „Python“-Programmierung für den „Calliope mini“-/“micro:bit“-Rechner ist auch das Tutorial „Kommunikation in Rechnernetzen“ mit dem Kapitel „4. Sender und Empfänger“ von „Das elektronische Schulbuch“. 2. Von
USB auf mbed umschalten und Daten austauschen
Wie bereits weiter oben in der Einleitung erwähnt, lassen
sich z.B. dem Smartphone oder Tablet-PC mittels des USB-Kabels und eines
kleinen USB-2.0-Micro-B-Steckers,
der am anderen Kabelende in das Gerät gesteckt wird, aufladen. Aber nicht nur
das! Über und mit dem USB-Kabel lassen sich beim Smartphone
auch Daten z.B. in Form von Dateien (Fotos, Audios, Videos, Textdateien usw.)
auf den heimischen Desktop-PC übertragen. Zu diesem Zweck muss man bei seinem Smartphone die App
„Einstellungen“ (→Zahnradsymbol) wie folgt aufrufen:
(Zum Vergrößern bitte auf eines der Bilder klicken!)
(Zum Vergrößern bitte auf das Bild klicken!) Nachdem für das Smartphone die Einstellung „Dateien
übertragen“ ausgewählt wurde, wird das „Android“-Dateisystem des Smartphones
automatisch in das „Windows“-Dateisystem eingebunden und steht sofort im
„Windows“-Dateimanager „Explorer“ wie folgt zur Verfügung:
(Zum Vergrößern bitte auf das Bild klicken!)
Wenn man nun anstelle des (Android-) Smartphones den
kleinen „micro:bit“-Rechner
mittels des USB-Kabel
an den Windows-PC
anschließt, dann wird dieser über die USB-Stromversorgung des Windows-PCs nicht nur
mit Strom versorgt, sondern auch noch das auf dem „micro:bit“-Rechner zuletzt
genutzte und gespeicherte Programm gestartet! Außerdem wird der „micro:bit“-Rechner und dessen (Flash-) Speicher
als externes Laufwerk wie z.B. E:\ in das „Windows“-Dateisystem des
„Windows“-PC wie folgt eingebunden:
(Zum Vergrößern bitte auf das Bild klicken!) Obwohl der kleine „micro:bit“-Rechner und dessen (Flash-) Speicher
als externes Laufwerk wie z.B. E:\ in das „Windows“-Dateisystem des
„Windows“-PC eingebunden wurde,
(Zum Vergrößern bitte auf das Bild klicken!) lässt er sich später nicht gleich, d.h. nicht sofort aus
dem „Windows“-Dateisystem
„dismounten“, d.h. abmelden. Aber nach einer gewissen Weile klappt es
dann aber doch! Der Grund dafür dürfte der sein, dass es sich bei dem
engl. „USB
Device“, d.h. USB-Gerät, um ein engl. „embedded“
Gerät, d.h. eingebettetes
Gerät, handelt, das über sein eigenes, kleines Betriebssystem namens „mbed OS“ verfügt: >> Mbed OS ARM Mbed OS ist ein kostenloses
Open-Source-Embedded-Betriebssystem, das speziell für die "Dinge"
im Internet der
Dinge entwickelt wurde. Es enthält alle Funktionen, die Sie für die Entwicklung
eines verbundenen Produkts auf der Basis eines ARM Cortex-M-Mikrocontrollers
benötigen, einschließlich Sicherheit, Konnektivität, Echtzeitbetriebssystem
und Treibern für Sensoren und E/A-Geräte. << (Quelle: „mbed“-Homepage) Wie man im
obenstehenden Bild im roten Rahmen sieht, verfügt der kleine „micro:bit“-Rechner über das „mbed OS“-Betriebssystem, wobei „OS“ für engl.
„Operating System“, d.h. Betriebssystem steht. Ferner sieht man, dass „mbed OS“ über ein engl. „Virtual File System (VFS)“, d.h. ein virtuelles
Dateisystem verfügt, das den „micro:bit“-Rechner als USB-Gerät in das „Windows“-Dateisystem
einbindet.
Nach der
Installation des seriellen Gerätetreibers für den USB-Anschluss am „Windows“-PC sieht man
im sogenannten Gerätemanager von
Windows 10 den „mbed Serial Port“ (hier mit
COM6):
(Zum Vergrößern bitte auf das Bild klicken!)
(Zum Vergrößern bitte auf das Bild klicken!) In diesem Zusammenhang stellt sich im obenstehenden Bild
noch die Frage, weshalb der serielle
Port „COM6“ für den Zugang über den USB-Anschluss
des „Windows“-PCs
ausgewählt wurde. Ganz einfach deswegen, weil es sich bei diesem um den
nächsten freien Port auf dem „Windows“-PC handelte! So, was jetzt auf dem „Windows“-PC noch fehlt, ist eine
entsprechende Software mit der sich die über USB seriell übertragenen Daten
anzeigen lassen. Diesbezüglich empfiehlt sich der allseits bekannte „PuTTY“ bei
dem es sich um einen schnellen und kleinen Telnet-Client für
Windows handelt, der auch noch eine Reihe anderer Protokolle unterstützt:
(Zum Vergrößern bitte auf eines der Bilder klicken!) Wenn man sich, wie in den obenstehenden Bildern zu sehen
ist, für die höchste Übertragungsgeschwindigkeit von 115
200 Baud entscheidet, dann gilt es zu beachten, dass das USB-2.0-Micro-B-Kabel
nicht länger als 2 m sein darf! Bezüglich der weiteren Vorgehensweise sei noch erklärt,
dass wir den „Windows“-PC zusammen mit PuTTY als Empfänger für den Empfang
seriell übertragener Daten verwenden und den kleinen „micro:bit“-Rechner als
Sendestation zum Senden serieller Daten. Diesbezüglich müssen wir uns nun als nächstes daran
machen und für den „micro:bit“-Rechner ein kleines Programm entwerfen, das in
einer Endlosschleife fortwährend Daten seriell über das USB-2.0-Micro-B-Kabel
an den „Windows“-PC überträgt:
(Zum Vergrößern bitte auf das Bild klicken!) Wie man im nachfolgenden Screenshot sieht, wird die
serielle Schnittstelle des „micro:bit“-Rechners beim Start des „micro:bit“-Programm
microbit_teil_05_prog_01.hex
initialisiert und dabei das Senden serieller Daten auf „USB_TX“ sowie das Empfangen
serieller Daten auf „USB_RX“ umgeleitet. Dazu muss man wissen, dass die serielle Datenübertragung beim „micro:bit“-Rechner standardmäßig
über die Pins wie z.B. „Pin P0“
… „Pin P2“,
die sich übrigens unten als sogenannte „Rundbuchsen“ für
Bananenstecker befinden, erfolgt (siehe nachfolgendes Bild). Dabei werden für
die serielle Datenübertragung insgesamt aber nur zwei Anschlüsse, engl. „pins“ benötigt. Und zwar jeweils
ein Pin für das Senden („TX“) von seriellen Daten und ein
weiterer Pin für das Empfangen („RX“) von seriellen Daten. Wenn man die serielle Datenübertragung mittels der Pins „Pin P0“
… „Pin P2“
realisieren will, dann müsste man die beiden Geräte, d.h. den
„micro:bit“-Rechner als Sender („TX“ = Transfer) und den „Windows“-PC als
Empfänger („RX“ = Receive) mittels zweier Klingeldrähte miteinander
verdrahten bzw. koppeln. Damit es bei der seriellen Übertragung dann aber zu
keinen Störungen kommt (Übersprechen, Überlagern von Signalen usw.) müsste
man die beiden Klingeldrähte miteinander verdrillen, so dass ein engl. „Twisted Pair Kabel“
entsteht. Unabhängig von der Zweidraht-Übertragung gibt es bei der
seriellen Datenübertragung aber noch ein drittes Verbindungskabel.
Nämlich die sogenannte „Masse“ oder engl.
„Ground (GND)“, die dazu dient, dass sich beide Geräte
(„micro:bit“-Rechner und „Windows“-PC) auf dem selben Massepotential
(= Null-Spannungs-Potential) befinden. >> Rx ist: die Bezeichnung für einen Empfänger bzw. für das Empfangen
einer Funksendung im Funkverkehr oder von Computer-Daten
(Herunterladen); Rx steht für den englischsprachigen
Begriff Receiver, wobei das x als „Kürzel“ für
die Buchstaben nach dem R anzusehen ist (Gegensatz:
Transmitter (Tx)
= Sender) << (Quelle: Wikipedia) Da wir im vorliegenden Fall die seriellen Daten aber über
das USB-2.0-Micro-B-Kabel
übertragen, muss das Senden und Empfangen beim „micro:bit“-Rechner auf die USB-Schnittstelle
wie folgt umgeleitet werden:
(Zum Vergrößern bitte auf das Bild klicken!) Kennen Sie die Geschichte „Vom Hasen und vom
Igel“ der Gebrüder Grimm? Wer war zuerst da? Der Hase oder der Igel? Ähnlich verhält es sich mit den seriell übertragenen
Daten. Da es sich bei der seriellen Datenübertragung über keine
getaktete, d.h. synchrone
Datenübertragung handelt, sondern um eine quasi chaotische, d.h. asynchrone Übertragung handelt,
kann jeder Empfänger auch gleichzeitig senden und jeder Sender auch
gleichzeitig empfangen, sodass es zwischen Sender und Empfänger keinerlei
Absprachen „Wer sendet wann? Und wer empfängt wann?“ gibt. Da wir im vorliegenden Fall die seriellen Daten aber nur
in eine Richtung, quasi als Einbahnstraße, und zwar vom
„micro:bit“-Rechner als Sender („TX“ = Transfer) zum „Windows“-PC als
Empfänger („RX“ = Receive) versenden, müssen wir nur dafür sorgen, dass das „PuTTY“-Programm
als Erstes gestartet wird und sich empfangsmäßig quasi unentwegt auf
die Lauer legt und lauscht, ob eventuell Daten gesendet werden. Nachdem also das „PuTTY“-Programm als Erstes gestartet
wurde, startet man das „micro:bit“-Programm microbit_teil_05_prog_01.hex
als zweites Programm, indem man dieses auf den „micro:bit“-Rechner überspielt,
sodass sich dieses sofort automatisch startet und mit dem Senden serieller
Daten beginnt:
(Zum Vergrößern bitte auf das Bild klicken!) Der kleine „micro:bit“-Rechner sendet nun also permanent serielle
Daten, bis dass der Strom ausfällt oder man die Stromversorgung via USB-2.0-Micro-B-Kabel
unterbricht. Wenn das „PuTTY“-Programm ordnungsgemäß konfiguriert und
gestartet wurde, sodass die vom „micro:bit“-Rechner gesendeten Daten auch
tatsächlich empfangen und im „PuTTY“-Fenster angezeigt werden (siehe
obenstehendes Bild), dann flackert die gelbe LED (= „Power On“) auf der
Rückseite des „micro:bit“-Rechner ganz schnell und signalisiert auf diese
Weise, dass Daten übertragen werden. Beendet man das „PuTTY“-Programm auf dem „Windows“-PC,
sodass von diesem keine Daten mehr empfangen werden, dann hört das schnelle
Blinken der gelben LED (= Power On“) des „micro:bit“-Rechners auf, leuchtet
diese wieder wie zuvor ununterbrochen!
Aber zum Glück lässt sich der eklatante und
benutzerfeindliche Mangel umgehend beseitigen, indem man das Programm
entsprechend erweitert, sodass sich das serielle Senden von Daten an den
„Windows“-Rechner mittels des „micro:bit“-Tasters A starten und mittels des „micro:bit“-Tasters
B auch wieder anhalten lässt (siehe „micro:bit“-Programm microbit_teil_05_prog_02.hex):
(Zum Vergrößern bitte auf das Bild klicken!) Nach dem „gewaltsamen“ Unterbrechen der Stromzufuhr durch
Abziehen des USB-2.0-Micro-B-Kabels
lässt sich der „micro:bit“-Rechner wieder in Betrieb nehmen, indem man die Stromzufuhr
durch Aufstecken des USB-2.0-Micro-B-Kabel wieder herstellt, sodass
dann auch wieder das „micro:bit“-Laufwerk als USB-Gerät in das „Windows“-Dateisystem einbunden wird
und wie gewohnt zur Verfügung steht, um „micro:bit“-Programme
aufspielen zu können. - Wie man sieht, ist das Programmieren eines Programms zum
Senden der Zeichenkette „#this*“ innerhalb der Endlosschleife „dauerhaft“ mittels
serieller Datenübertragung an den empfängerseitigen USB-Client „PuTTY“ wider Erwarten
gar nicht so schwer. Trotzdem wissen wir bereits, dass hinter der seriellen
Datenübertragung noch mehr steckt. Und zwar das ·
eingebettete,
engl. „embedded“, Betriebssystem, engl. „OS“ (= Operating System“ namens „mbed OS“,
des „micro:bit“-Rechners,
·
zu
der es übrigens auch eine online
sowie offline
Entwickler-/Programmier-Umgebung zum Programmieren des „micro:bit“-Rechners gibt und
nicht zu vergessen ·
die
im „micro:bit“-Rechner
als auch im „Windows“-PC
verbaute „Universal
Asynchronous Receiver Transmitter“ Hardware „UART“
für die serielle bzw. emulierte „RS232“- sowie „USB 2.0/3.0“-Schnittstelle nebst
USB-Buchsen. Ferner wissen wir, dass praktisch zu jeder Hardware auch eine entsprechende Schnittstelle nebst ´(Software-) Treibern als auch ggf.
ein entsprechendes, eingebettetes
(kleines) Betriebssystem gibt. Diesbezüglich kann es auch sein, dass wir uns zusätzlich
noch ·
mit
„pySerial“
beschäftigen müssen, das einerseits zwar im „MicroPython“
für AMR Cortex Prozessoren wie
z.B. des „micro:bit“-Rechners
implementiert ist, andererseits aber nicht in der Programmierumgebung „MS Visual Code“
von Microsoft, sodass „micro:bit“-Programme mit „MicroPython“ nicht so ohne
Weiteres programmieren lassen. Da wir später auch noch die Datenübertragung mittels
serieller Schnittstelle und Python programmieren wollen, schauen wir mal
nach, ob wir und was wir diesbezüglich von der Programmierung einer seriellen
Datenübertragung unter „JavaScript“ lernen können:
(Zum Vergrößern bitte auf das Bild klicken!) Den „JavaScript“-Sourcecode (= Programmkode) kann man
sich hier im Browser auch direkt anschauen: Programm microbit_teil_05_prog_02.js
(siehe im obenstehendes Bild). Wenn man das im obenstehenden Bild angezeigte „JavaScript“-Programm
nach „MicroPython“
übersetzt, dann fällt sofort auf, dass die serielle Datenübertragung des „micro:bit“-Rechners
nicht auf den „USB-2.0-Micro-B-Kabel“-Anschluß des „Windows“-PC
umgeleitet werden muss:
(Zum Vergrößern bitte auf das Bild klicken!) Der im obenstehenden Bild gezeigte „MicroPython“-Sourcecode des Programms microbit_teil_05_prog_02.py
lässt sich übrigens auch direkt im Browser anschauen bzw mittels rechter Maustaste und dann „Ziel speichern unter …“
herunterladen und installieren! Werfen wir bei dieser Gelegenheit zwecks besseren Verständnisses
noch einen Blick auf die Hardware
des „micro:bit“-Rechners:
>> Ziel- und Schnittstellen-MCUs
Eine der coolsten Funktionen von micro:bit ist die Art und Weise,
wie es sich als USB-Laufwerk darstellt, wenn es über USB angeschlossen ist,
und über diese Schnittstelle programmiert werden kann, ohne dass Treiber
installiert werden müssen.
Unabhängig davon, welchen Code Sie auf Ihrem micro:bit ausführen oder wie Sie es schaffen, das Gerät zum
Absturz zu bringen, können Sie über die USB-Verbindung
immer ein neues Programm erstellen. Dies wird ermöglicht, indem auf dem micro:bit ein separater 'Interface-Chip' oder
'Interface-MCU' [= Microcontroller Unit] für USB-Verbindungen,
Programmierung und Debugging vorhanden ist. Auf dem micro:bit
ist dieser Chip eine Freescale KL26Z . Der
Chip, auf dem der Entwicklercode
ausgeführt wird und an den alle Peripheriegeräte
angeschlossen sind (nRF51822), wird als "Ziel-MCU" bezeichnet. Weitere Informationen zur Verbindung dieser
beiden Geräte finden Sie auf der Hardware- Seite
und im Schaltplan.
(Zum Vergrößern bitte auf das Bild klicken!) Die Ziel- und Schnittstellen-MCUs sind über zwei
Schnittstellen verbunden: ·
Serial Wire
Debug (SWD) zur Programmierung
der Ziel-MCU ·
UART
zum Senden von Nachrichten zwischen den beiden Geräten. In der Praxis wird
der UART von der Ziel-MCU über USB
direkt zum PC
übertragen! << (Quelle: DAPLink
und die USB-Schnittstelle, microbit.org)
Wer lesen kann, will früher oder später auch schreiben
können. Schließlich dient Lesen und Schreiben der Kommunikation, gibt es z.B.
bei Tageszeitungen die sogenannten Leserbriefe. Leserbriefe sind dabei der
Rückkanal, wenn auch extrem dünn angesiedelt und größtenteils auch durch den
Redakteur gesteuert, der entscheidet, welcher Leserbrief veröffentlicht wird
und welcher nicht. Einen (Rechts-) Anspruch auf das Veröffentlichen des
eigenen Leserbriefes gibt es also nicht. Anders verhält es sich beim Datenaustausch
über die serielle „UART“-Schnittstelle. Dort ist es nämlich mittels
Programmierung möglich, einen sogenannten Rückruf auszusenden bzw. zu
veranlassen. Und das ist gut so, erfolgt doch der serielle Datenaustausch
asynchron, d.h. ohne Taktung, quasi auf Zuruf, wobei sich aber der Empfänger
die Ohren zuhalten kann, wenn er nichts hören, d.h. nichts empfangen will.
Umgekehrt kann der Empfänger nicht verhindern, eben wegen der asynchronen
Übertragung, dass der Sender massiv und dauerhaft an die Tür anklopft bzw. an
diese lautstark trommelt, um Gehör zu finden. Dazu aber später mehr. Wie man im nachfolgenden Bild sieht, ist es nicht schwer,
aus dem Sendeprogramm (siehe Bild
15) ein entsprechendes Empfangsprogramm zu programmieren:
(Zum Vergrößern bitte auf das Bild klicken!) In JavaScript sieht dann das Programm microbit_teil_05_prog_03.js
(Download mittels rechter Maustaste und „Ziel speichern unter …“) wie folgt
aus:
(Zum Vergrößern bitte auf das Bild klicken!) In MicroPython sieht dann das im obenstehenden Bild
gezeigte Programm microbit_teil_05_prog_03.py
(Download mittels rechter Maustaste und „Ziel speichern unter …“):
(Zum Vergrößern bitte auf das Bild klicken!) Im Zusammenhang mit dem „JavaScript“- und „MicroPython“-Programm
(siehe obenstehendes Bild) stellt sich nun die Frage, wie sich dieses testen
lässt, d.h. wie sich an dieses serielle Daten z.B. in Form eines Textstrings
senden lassen. Ganz einfach mit dem „PuTTY“-ähnlichen, dafür aber auch sendefähigen(!)
Programm „RealTerm“, das man
sich übrigens von Google Translate wie folgt [ übersetzen
] lassen kann. Weitere, ausführliche Infos zum „RealTerm“-Programm finden sich [ hier
]. - Um später einen Textstring seriell an das „JavaScript“-
oder „MicroPython“-Programm
senden zu können, muss man zunächst die serielle Schnittstelle richtig
konfigurieren. Im vorliegenden Fall läuft dabei die serielle
Kommunikation über den Port „COM6“, da es sich bei diesem um den nächsten
freien, seriellen Port auf dem „Windows“-PC handelt. Nach der Konfiguration des Ports „COM6“ muss man diesen
mittels Mausklick auf die Schaltfläche
„Open“ aktivieren, d.h. öffnen:
(Zum Vergrößern bitte auf das Bild klicken!) Erst nachdem die serielle Schnittstelle „COM6“ richtig
konfiguriert und geöffnet wurde, lässt sich der Textstring „Test!“ an den „micro:bit“-Rechner
seriell wie folgt übertragen:
(Zum Vergrößern bitte auf das Bild klicken!) Das in MicroPython programmierte Programm microbit_teil_05_prog_03.py
hat aber noch einen Schönheitsfehler. Und zwar den, dass auch leere
Daten in Form des Textstrings „None“ in der Laufschrift auf dem „micro:bit“-Rechner
angezeigt werden, was auf Dauer natürlich stört. Aber gut zu wissen, dass
leere Daten auch Daten sind, ebenso wie die Zahl Null, die auch eine Zahl
ist, obwohl wir an der Hand „null Finger“ zum dezimalen Zählen haben.
(Zum Vergrößern bitte auf das Bild klicken!) Wie man aber im obenstehenden Bild sieht, lässt sich die
Anzeige des Textstrings „None“ auf einfache Weise, nämlich durch eine
entsprechende „if“-Abfrage
(siehe roter Kasten) unterbinden (siehe Programm
microbit_teil_05_prog_04.py,
Download mittels rechter Maustaste und „Ziel speichern unter …“). Python
„Serials“ unter Windows 10 installieren Wie wir bereits weiter oben gesehen haben, verfügt der „micro:bit“-Rechner
über alles, was man zur Programmierung der „Universal Asynchronous Receiver Transmitter“
Hardware „UART“,
d.h. für die serielle bzw. emulierte „RS232“- sowie „USB 2.0/3.0“-Schnittstelle nebst USB-Buchse
braucht. Microsoft
Windows als multimediales, netzwerkfähiges, „multithread“-
und „multiuser“-fähiges
Betriebssystem selbst ist aber leider noch nicht für das „IoT“, das engl. „Internet of Things (and Services)“ ausgelegt.
So z.B. gibt es die serielle Schnittstelle in Form von USB-Anschlüssen
hauptsächlich nur für den Anschluss von USB-Geräten wie z.B. USB-Maus,
USB-Tastatur, USB-Drucker oder externe USB-Festplatte, weniger jedoch für die
Kommunikation und Datenübertragung über die seriellen Ports. Der Grund dafür
ist der, dass der Anwender seine „Plug and play“-fähigen
Geräte einfach nur anstöpseln, gleichzeitig aber von dem ganzen Drumherum,
d.h. der hard- und softwaremäßigen Implementierung in
das Windows-Betriebssystem, nichts wissen will. Wenn es also darum geht, dass wir später „Python“-Programme
unter Windows programmieren, dann müssen wir zunächst die derzeit aktuelle Version „Python 3.7.4“ aus
dem Internet herunterladen und installieren. Kennen Sie den Unterschied zwischen der Installation
eines „Windows“-Programms
für einen bestimmten (oder alle) Benutzer und einer sogenannten Systeminstallation?
Die Installation eines „Windows“-Programms für eine
sogenannte Systeminstallation
führt u.a. dazu, dass das Programm dem „Windows“-Betriebssystem als Ganzes installiert
wird. Und zwar mit entsprechenden Einträgen der Installation in die
sogenannte „Windows“-Registry-Datenbank.
Und zwar vollkommen unabhängig vom gerade aktiven, am „Windows“-System
angemeldeten Benutzer! Demzufolge werden bei der Systeminstallation auch entsprechende System-Verzeichnispfade eingetragen, wohin z.B. das entsprechende Programm installiert wurde, C:\Programme C:\ProgramData C:\Program
Files C:\Programme (x86) wo es sich vom „Windows“-Betriebssystem
finden und aufrufen lässt. Dabei gilt es unbedingt zu beachten, dass man die „Spaces“, d.h. die Leerzeichen im Verzeichnispfad möglichst durch entsprechende, äquivalente Steuerzeichen „%20“ C:\Program%20Files C:\Programme%20(x86) ersetzt!
Es verhält sich
nämlich nicht zwangsläufig so, dass ein in Java, C/C++ oder Python
entwickeltes Programm, das es ja auch für andere Betriebssysteme wie z.B.
Linux, MacOS oder iOS von Apple gibt, auch mit den Leerzeichen unter dem „Windows“-Betriebs-
und Dateisystem zurecht kommt, da
es lange (Windows-) Verzeichnis-
oder auch Dateinamen mit Leerzeichen z.B. unter Linux nicht gibt! Da bei der Installation u.a. auch den Datei-Erweiterungsnamen *.py für „Python“-Quellkode-Programme,
*.js
für „JavaScript“-Quellkode-Programme
usw. die entsprechenden Programme selbst zugewiesen werden, sodass das sich
z.B. ein „Python“-Programm
direkt im Microsoft „MS Visual Code“-Programm aufrufen lässt, ohne
dass man den MS Programmier-Editor explizit zuvor gestartet haben muss; er
startet sich nämlich dabei wie von selbst und zwar zusammen mit dem
aufgerufenen „Python“-Programm!
Die sogenannte Systeminstallation erkennen Sie also immer daran,
dass diese in eines der obenstehenden Programm-Verzeichnisse
installiert wird, während eine Benutzer definierte Installation z.B. in den Verzeichnispfad C:\Benutzer\Benutzername\AppData\Roaming\Python\Python37 oder englisch C:\Users\Benutzername\AppData\Roaming\Python\Python37 installiert wird. Während es sich früher meistens so verhielt, dass „Windows“-Programme
zwangsläufig als System-Programme installiert wurden, verhält es
sich inzwischen so, dass diese neuerdings als Benutzer definierte Installationen
in den Verzeichnispfad C:\...\AppData\Roaming\.. installiert werden! Meistens dann mit der unangenehmen
Folge, dass die installierten Programme selbst nicht mehr „wissen“ wohin sie
installiert wurden, weil der Installations-Verzeichnispfad nicht automatisch
als System-Verzeichnispfad
in die Windows-Registry
aufgenommen wird. Besonders ärgerlich wird es dann, wenn man später, d.h.
nachträglich das Zusatz-Programm „pySerial“
installieren will. Wurde dieses z.B. im Verzeichnispfad C:\Programme\pyserial-3.4 installiert, während das Konsole-Programm „Python“ in den Verzeichnispfad C:\Programme\Python37 installiert bzw. abgespeichert wurde, dann findet Python
später nicht das pySerial, hat man zunächst keine Chance, dieses
nachträglich in Python zu
integrieren! Wenn man das „pySerial“-Programm erfolgreich installieren will und zwar so, dass es vom „Python“-Hauptprogramm auch gefunden und sich von diesem als integraler Bestandteil nutzen lässt, dann muss man pySerial tunlichst als ein Unterverzeichnis von Python wie folgt installieren: C:\Programme\Python37\pyserial-3.4 Dabei spielt die Installations-Reihenfolge
eine wichtige Rolle: 1.
das
„Python“-Hauptprogramm
und dann 2.
das
„pySerial“-Programm! In diesem Zusammenhang muss man wissen, dass ein (Haupt-)
Programm im Prinzip praktisch alle Unterverzeichnisse
als Bestandteil eines Hauptverzeichnisses
nach einem (Unter-) Programm vorwärts
durchsuchen und dieses finden kann. Umgekehrt gibt es die Rückwärtssuche, die vom Hauptverzeichnis C:\Programme\Python37 des (Haupt-) Programms aus startet und
dann später beim Wurzelverzeichnis C:\ ankommt und dabei auch das Unterprogramm im Verzeichnis C:\Programme\pyserial-3.4 findet,
nicht, da sie zu aufwendig zu programmieren wäre. Das kostenlose Programmier-Editor-Programm
„Visual Studio Code“ von Microsoft gibt
es, wie man im nachfolgenden Bild sieht, in zwei Setup-Versionen. Und zwar als Benutzer-Installationsprogramm, engl. „User Installer“ und als System-Installationsprogramm, engl. „System Installer“:
(Zum Vergrößern bitte auf das Bild klicken!) Wenn Sie sich für das System-Installationsprogramm
entscheiden, machen Sie nichts falsch, sind Sie auf der sicheren Seite, gibt
es praktisch keine Probleme, wenn Sie später weitere Zusatzprogramme installieren und
ins Hauptprogramm
integrieren wollen. Vorausgesetzt natürlich, dass Sie das Zusatzprogramm
in ein Unterverzeichnis des Hauptprogramms installieren (siehe oben)! Was aber macht man als Anwender, wenn es ein zu
installierendes Programm und dessen Setup nicht als System-Installationsprogramm
gibt bzw. man darüber im Unklaren gelassen wird, ob es sich bei dem Setup-Programm
tatsächlich um eine Systeminstallation handelt oder nicht? Wenn man als Anwender wissen will, was beim Setup
nebst Installation
so alles vonstatten geht, dann sollte man vorab einen Blick in die Benutzer
definierte Installation werfen: (Zum Vergrößern bitte auf das Bild klicken!)
(Zum Vergrößern bitte auf das Bild klicken!)
(Zum Vergrößern bitte auf das Bild klicken!) Wenn man zusätzlich zum „Python for Windows“-Programm
(siehe obenstehendes Bild) dann auch noch das „pySerial“-Programm in den Verzeichnispfad
C:\Programme\Python37\pyserial-3.4 installiert, dann sollte man die „pySerial“-Installation noch wie
überprüfen, indem man im „Python for Windows“-Programm den (Python-)
Import der „Serial“-Funktion
wie folgt abfragt:
(Zum Vergrößern bitte auf das Bild klicken!) Textstring
„Hello World!“ an den „micro:bit“-Rechner senden So, nachdem alles klappt, d.h. die Programme „Python for Windows“ und
„pySerial“
ordnungsgemäß funktionieren, können wir uns daran machen und das kleine „Python“-Programm
microbit_teil_05_prog_05.py,
Download mittels rechter Maustaste und „Ziel speichern unter …“) wie folgt erstellen:
(Zum Vergrößern bitte auf das Bild klicken!) Die Anzeige des Textstrings
„Hello World!“ erfolgt auf dem kleinen 5x5
LED-Pixel großen Display des „micro:bit“-Rechners in Form der entsprechenden
Laufschrift mit dem „Python“- Programm microbit_teil_05_prog_04.py,
Download mittels rechter Maustaste und „Ziel speichern unter …“), das
natürlich zuvor auf den „micro:bit“-Rechner aufgespielt und nach
der Laufschriftanzeige „Start …“ mittels Tastendruck auf den „Taster A“
gestartet werden muss:
(Zum Vergrößern bitte auf das Bild klicken!) Nachdem das serielle
„micro:bit“-Anzeigeprogramm
aufgespielt und mittels Tastendruck auf den „Taster A“ (siehe obenstehendes
Bild) gestartet wurde, lauscht der kleine Rechner am seriellen „USB-2.0-Micro-B-Kabel“-Anschluß
geduldig auf eine eingehende Nachricht, die dann auch tatsächlich eintrifft! Und zwar gesendet vom obenstehenden „Python“-Programm microbit_teil_05_prog_05.py,
Download mittels rechter Maustaste und „Ziel speichern unter …“). Die auf dem [ Video ] zu
hörenden Nebengeräusche stammen nicht vom „micro:bit“-Rechner, sondern von
der benachbarten Baustelle ;-) |
||||||
|
|
[ Home
] [ zurück ] [ Seitenanfang ] [ Teil 4 ] |
|
