Alle Beiträge von Matthias

Roboter steuern per Bluetooth Smart

In unserer gestrigen Session haben wir ein TinySine HM-10 Modul verwendet, um einen kleinen Roboter über Bluetooth LE per App zu steuern.

Hier zwei Fotos vom Roboter:

Zu sehen ist die Plexiglas-Grundplatte, auf deren Unterseite zwei DC-Motoren angeschlossen sind, darüber der Batterie-Pack, ein L298 H-Brücken-Modul, ein Arduino mit Shield zum Anschließen von u.a. Servo-Motoren und auf letzterem das Bluetooth-Modul.

Eigentlich ist der entsprechende Slot vorgesehen für ein Serial Wifi-Modul, aber das TinySine-Modul passt auch – wenn man links und rechts einen Pin überstehen lässt.

Im Arduino-Code muss die SoftwareSerial-Bibliothek eingebunden und mit Pin 1 und 2 als empfangenden bzw. sendenden Pin initialisiert werden. Nun kann man sich mit der Nordic Semiconductor nRFGo-App auf dem Smartphone mit dem HM-10 Modul über BLE verbinden und Steuerbuchstaben an den Arduino funken, die letzterer dann auswerten und zur Steuerung der Motoren heranziehen kann.

Hier ein YouTube-Video von einer Demonstrationsfahrt:

Eclipse zur nRF51822-Entwicklung Setting up Eclipse to develop for the nRF51822

Wir sind zwar sehr geschickt im Umgang mit der Konsole bei der Entwicklung von Firmware für den nRF51822: Man muss nur openocd mit -c „set WORKAREASIZE 0;“ und der passenden openocd.cfg starten und kann dann mit arm-none-eabi-gdb mycode.elf/.hex den eigenen Code testen.

Manchmal möchte man aber Eclipse verwenden: Es ist eine schöne graphische, plattformübergreifende Oberfläche, in der alle notwendigen/nützlichen Entwickler-Features bequem als Buttons oder festeinstellbare Konfigurationsoptionen bereit stehen.

Wir haben mal Nordic’s Tutorial zur Verwendung von Eclipse ausprobiert. Teilweise sind wir anders vorgegangen, u.a. da wir nicht eins der offiziellen Developer Boards, sondern unsere eigenen JTAG-Adapter mit einem Waveshare Core51822 verwenden. Unser Vorgehen möchten wir hier kurz präsentieren:

Zunächst lädt man die aktuellste, stabile Eclipse IDE für C/C++ Entwickler herunter. Bei uns ist das Mars bzw. Mars 2.

Um die GNU ARM-Tools vonhttp://gnuarmeclipse.github.io/debug/openocd/ zu installieren, muss man eine neue Quelle in Eclipse hinzufügen:
http://gnuarmeclipse.sourceforge.net/updates
Dann muss man installieren, (fast) wie es im Tutorial aufgelistet wird:

  • Cross Compiler
  • Packs
  • OpenOCD

und das GDB via OpenOCD-Tool.

Wie hier beschrieben, kann man es dann in Eclipse > Run Configurations > GDB via OpenOCD hinzufügen.

ICprog debuggt nRF51822 ICprog debugs nRF51822

Nach anfänglichen Schwierigkeiten, konnten wir den ICprog von InCircuit.de heute sowohl unter Windows als auch unter Linux in Betrieb nehmen. Mit der Hilfe von Paul Fertser vom #OpenOCD-Kanal auf Freenode konnte eine funktionierende OpenOCD-Konfiguration für den Adapter erstellt werden.

Hinweis: Die LEDs auf der Platine leuchten nur bei Verwendung der seriellen Schnittstelle (Port B), nicht bei Verwendung von JTAG/SWD.

Unter Windows war zunächst das Problem zu lösen, dass libusb nicht gefunden und nach Installation als nicht kompatibel bemängelt wurde. Ein Blick in die Installations-Quellen von OpenOCD genügte, um dies zu lösen: In einem Unterordner gibt es ein README, in dem die entsprechend nachzuinstallierende libusb-Windows-Software verlinkt ist. Danach funktioniert der Adapter.

Unter Linux wollte openocd den Adapter zunächst nicht im SWD-Transfer-Modus betreiben:

Nach kurzer Fehlersuche wurde uns klar, dass das Ubuntu-Paket OpenOCD in der veralteten Version 0.7.0 vertreibt. Zum Aktualisieren haben wir den Quellcode geklont (Version 0.10.0) und selbst kompiliert, was reibungslos von Statten geht:

und als Superuser:

Über den SWD Widerstands-Hack mit einem 430 Ohm-Widerstand konnte nun erfolgreich der nRF51882 auf dem Waveshare Core51822-Board gedebuggt werden:

Man beachte, dass der Jumper auf dem ICprog NICHT gesetzt sein darf. Der nRF51 muss von einer externen Spannungsquelle (oder Batterie) mit 3V / 3.3V versorgt werden, keinesfalls mit 5V vom ICprog.

In-Circuit’s ICprog JTAG-Adapter ausprobiert Testing In-Circuit's ICprog JTAG-Adapter

Heute haben wir uns den JTAG-Adapter „ICprog“ von In-Circuit.de angeschaut. Der Schaltplan des Adapteres steht auf der Artikel-Seite im Shop zur Verfügung. Im Wiki des Unternehmens finden sich außerdem eine allgemeine Beschreibung mit Pin-Belegung sowie eine Beschreibung der Verwendung mit OpenOCD.

Dass der Schaltplan bereitsteht, erfreut uns und ermöglichte uns das Anschließen des nRF51822 unter Zuhilfenahme des JTAG-zu-SWD Widerstands-Hacks.

Kommunizieren konnten wir bisher leider nicht. Die Windows-Version von OpenOCD scheint Statements mit Präfix „ft2232“ nicht mehr zu akzeptieren (veralteter Syntax), sodass das Einbinden von interface/openocd-usb.cfg in unserer openocd.cfg fehlschlägt. Wir haben In-Circuit angeschrieben und hoffen auf ihre Hilfe bei der Erstellung einer funktionierenden openocd.cfg.

Erwähnenswert ist, dass sich ungewöhnlicherweise die Batterie erwärmte, welche den nRF51822 mit 3V versorgte, sowie die Adapterplatine (welches Bauteil genau, ist unklar). Wir haben darauf geachtet, nicht die 5V vom USB (mit der auf der Platine vorhandenen Brücke) auf den Ausgang zu legen, da der nRF51822 nicht 5V-tolerant ist. Ob der Adapter auf 3V kommunizieren kann und ob die Pin-Belegung in unserem Aufbau korrekt war, könnte nochmal geprüft werden (Man beachte, der Adapter hat am Ausgang das Pin-Layout eines AVR-JTAG-Adapters, nicht das eines ARM-10pin-Adapters)

Bilder vom Adapter:
713235486_151337 Platine von oben
Platine von unten Ausgang

Wir wollen eine WunderBar!

Auf der diesjährigen Maker Faire in Berlin hatten wir erstmals Gelegenheit Relayr.io’s WunderBar live zu bestauen. Die WunderBar ist ein Starter Kit für das IoT – das Internet der Dinge.

Internet der Dinge bezeichnet die Erweiterung alltäglicher Gegenstände mit einem Mikroprozessor, der sich mit Mikroprozessoren in anderen Geräten vernetzen kann. Der Prozessor erweitert über Sensoren und Aktoren die rein „mechanische“ Funktion des jeweiligen Gerätes durch Funktionen, welche erst durch den Informationsaustausch mit anderen Geräten möglich werden.

Am Beispiel der WunderBar geschieht der Informationsaustausch über Funk, genauergesagt Bluetooth Low Energy, realisiert mithilfe des Nordic Semiconductor nRF51822. Wir hatten unlängst schon auf diesem Blog über den Chip berichtet.  Er ist seinen Konkurrenzprodukten durch seine ausführliche Dokumentation voraus, welche die Firmware-Entwicklung erheblich erleichtert.

Auf der WunderBar finden sich ein Hauptmodul und sechs BLE-Module. Das Hauptmodul enthält neben dem nRF51822 einen Freescale-Prozessor und einen WLAN-Chip. Durch die letzteren beiden kann über den heimischen Router eine Anbindung ans Internet realisiert werden. Verbindet man das Haupt-Modul darüber mit Relayr.io’s Cloud, so kann man auch von unterwegs mit den heimischen Module interagieren.

Die sechs BLE-Module tragen neben einem nRF51822 jeweils Sensor und/oder Aktor, z.B. eine LED, ein Gyrometer, ein Accelerometer usw. Versorgt werden die BLE-Module mit Knopfbatterien auf der Rückseite, das Hauptmodul mit einem flachen Akku.

Sowohl Hardware als auch Software sind offen und frei verfügbar. Update 30.11.2015: Leider ist nur die Hardware offen und gut dokumentiert. Die Software ist, bis auf ein paar C-Bibliotheken zum Auslesen der Sensor-Werte, Closed Source.

Nachdem wir uns ohnehin mit dem nRF51822 auseinandersetzen und bereits dabei sind, Lösungen zu entwickeln, welche die WunderBar teilweise schon abdeckt, haben wir uns zwei „WunderBarren“ bestellt. Wir freuen uns darauf, erste Schritte damit zu unternehmen!

Programme für’s Fairphone compilieren

Rein technisch unterstützt das Fairphone Bluetooth Low Energy (BLE), aber es gibt (nach  unserem Kenntnisstand) kein Android-Image, was diese Fähigkeit des SoC aufgreifen könnte, da erst ab 4.3 (API Level 18) ein Interface für BLE implementiert ist.

Wir kamen daher auf den Gedanken, evtl. auf einer „tieferen Linux-Ebene“ außerhalb der Android-VM die BLE-Fähigkeiten des SoC zu testen. Unter Umständen besteht nämlich die Möglichkeit, BLE durch eine in der APK mitgelieferte System-Bibliothek auch dann einer App zur Verfügung zu stellen, wenn die VM kein Interface dafür anbietet.

Der im Fairphone verbaute SoC ist der MediaTek MT6589. Er hat vier Kerne, die den ARMv7-Instruktionssatz (Quelle) implementieren und enthält außerdem laut Spezifikation den besagten Bluetooth 4.0-fähigen Transceiver.

In einem ersten Test versuchten wir mithilfe eines ARM-Cross-Compilers ein simples printf(„Hello world2“); – Programm zu übersetzen. Dabei darf man nicht vergessen, mit dem Kommandozeilenparameter -static zu linken:

Mit adb push haben wir die resultierende, ausführbare Datei auf das Telefon gespielt und konnten sie dann in der adb shell ausführen.

Nun können wir beginnen, unsere Werkzeuge auf das Telefon zu spielen und testen, ob wir von der Kommandozeile aus Bluetooth nutzen können.

Links:

nRF51822 – Ein Blick auf den Die

Die Zeptobars-Gruppe hat sich die Arbeit gemacht, den beliebten Bluetooth Low Energy-Chip nRF51822 von Nordic Semiconductor von seinem Package zu befreien und ein Foto des Die veröffentlicht.

http://zeptobars.ru/en/read/nRF51822-Bluetooth-LE-SoC-Cortex-M0

Wir haben uns das Bild mal angesehen.

nRF51822

Neben zwei großen Gate-Seen sind noch drei Blöcke zu erkennen, die mutmaßlich als DC-DC-Wandler, Funk-Einheit (rechts unten), SRAM (links unten) und Flash (rechts oben) zu identifizieren sind. Ringsherum an den Rändern sind deutlich die Pads zu erkennen, welche im Package auf die BGA-Kugeln herausgeführt werden.

Am rechten Rand der mutmaßlichen Radiofrequenz-Einheit findet sich die Aufschrift „RADIO 434S RS“ bzw. „RADIO 4345 R5“. Die beiden ringförmigen bzw. oktogonalen Konstrukte könnten Spulen d.h. Induktivitäten sein, die am 2.4GHz-Schwingkreis teilhaben. Die benachbarten rechteckigen Flächen könnten dann entsprechend Kapazitäten sein. Die Funktion der sechs quadratischen Windungen ist unklar, möglicherweise Resonatoren bzw. Taktgeber (Clock oder PLLs). Sowohl Spulen als auch Quadrate könnten aber auch ein oder mehrere DC-DC-Wandler darstellen.

Der RAM-Block ist erkennbar am Vorhandensein der Adress- bzw. Daten-Multiplexer, die auf der linken Seite über und unter den horizontal verlaufenden Spannungsversorgungssträngen herausschauen. An der unteren Kante des Blocks dürfte außerdem der Puffer zu sehen sein, der die aus der Speichermatrix abgerufenen Daten zwischenspeichert und ggf. weiter auswählt. Die Dicke und langstreckige Verzahnung der Spannungsversorgungsleitungen über dem SRAM dient vermutlich der Konstruktion einer lokalen Kapazität, welche zeitlich variablen Strombedarf unter Vermeidung von Leitungsinduktivitäten puffert.

Den Flash-Speicher kann ich nicht klar identifizieren, vielleicht ist es der Teil rechts oben, insbesondere die drei kleinen, zweigeteilten, hellblau-erscheinenden Quadrate, an deren Rändern sich augenscheinlich Multiplexer befinden. Dagegen spricht, dass diese Elemente überraschend klein wären.

Die beiden Gate-Seen gehören vermutlich zum selben Logik-Block, nämlich dem Prozessor mitsamt aller seiner Komponenten, ALU etc. Die Verdrahtung erinnert an Bilder von Qrouter, d.h. aus einem generischen Transistor-Modell um die übrigen Die-Blöcke herumfließend generiert. Links oben scheint der See nicht komplett gefüllt d.h. ausgenutzt zu sein.

Umstellung auf Nordic Semiconductor

Nach den gravierenden Schwierigkeiten, mit denen wir bei der Verwendung von Texas Instruments‘ CC2541 Bluetooth Low Energy – Chip konfrontiert waren, und nachdem der TI Support unsere Hilfe-Anfragen nicht beantwortet hat, haben wir uns entschieden, auf BLE – Produkte von Nordic Semiconductor umzustellen.

Der neue Chip, mit dem wir die BLE-Welt erkunden wollen, heißt nRF51822. Das Echo der Bastler-Community im Internet fällt beim nRF51822 deutlich positiver aus, als beim CC2541, was uns hoffen lässt.

Die Platine, mit der wir nunmehr entwickeln, heißt MD0330, hier ein Foto.

Eine freie GSM-Masten-Datenbank für offline Standortbestimmung

GPS erlaubt Nutzern von Smartphones und anderen Geräten, auf der ganzen Welt gebührenfrei ihren Standort zu bestimmen. Leider kann so eine Standortbestimmung je nach Witterung bzw. Sichtverhältnis zu den GPS-Satelliten mitunter mehrere Minuten dauern. Um dies zu beschleunigen, kann man auf das „A“ in „AGPS“ zurückzugreifen, das für „Assisted“ steht, die Miteinbeziehung der sichtbaren GSM-Masten in die Standortbestimmung. Welche Masten verfügbar sind, erlaubt praktisch verzögerungslos einen Rückschluss auf die ungefähre Position, die ggf. auch mit unvollständig vorliegenden GPS-Werten verfeinert werden kann.

Für diese Triangulation ist freilich erforderlich, dass man den Standort der jeweils sichtbaren GSM-Masten kennt. Um die Standorte abzurufen, greifen Smartphones ab Werk auf das Internet zu, doch dies bringt einige Probleme mit sich:

  • Es setzt voraus, dass eine Internet-Verbindung besteht.
  • Es erzeugt zusätzlichen, ggf. kostenpflichtigen Traffic.
  • Es öffnet eine Tür für Manipulationen der Standort-Daten.
  • Es ermöglicht dem Provider, den eigenen Standort festzustellen.

Die Lösung ist eine offline-Datenbank, also eine Datenbank aller GSM-Masten weltweit, die der Benutzer bei bestehender Internetverbindung, also z.B. im häuslich WLAN, herunterlädt zusammen mit einer Ersatz-App für den Standort-Dienst (Location Provider), welche anstelle der Internetverbindung die lokale Datenbank nutzt.

UnifiedNlp ist eine solche App und es gibt verschiedene Datenbanken für sie.

Tobias Kuban hat nun auf Github die Datenbanken von OpenCellId und Mozilla Location Services zu einer globalen Karte von GSM-Masten für UnifiedNlp zusammengeführt. Die Datenbank ist entpackt ca. 1 GB groß und kann hier heruntergeladen werden:

Nach dem Herunterladen des Archivs kann es mit xz (Linux) oder 7-Zip (Linux,Windows) entpackt werden:

und bei per microUSB angeschlossenem Smartphone mit adb rübergeladen werden:

Dazu muss noch das UnifiedNlp Frontend und Backend installiert werden, z.B. aus F-Droid.