Projekte

Archiv der Kategorie: Projekte

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.

Dokumentations-Mangel beim CC2541 Lack of documentation for the CC2541

Der CC2541 wird von Texas Instruments dediziert für die Verwendung von BLE angepriesen. Man darf erwarten, dass dies entsprechende, BLE-spezifische Anpassungen in Hardware beinhaltet. Beim Blick ins Datenblatt (S.3) findet man diesbzgl. erstmal nur die Link Layer Engine (LLE), welche dem Entwickler den low-level-Funkteil im 2.4GHz-Bereich abnimmt (GFSK,FIFO,etc.) und entsprechende Konfigurations- bzw. Steuermöglichkeiten über die dedizierten RF Register bietet. Sowohl die LLE, als auch die RF Register sind aber auch in anderen SoCs der CC253x/4x-Reihe enthalten. Im Grunde ist das Block-Diagram aller dieser SoCs identisch, obwohl sie für verschiedene Funkstandards angepriesen werden, was die Frage aufwirft, worin sich die SoCs überhaupt unterscheiden. Könnte es Hardware-Teile geben, die nicht im Datenblatt dokumentiert sind ?

Die Antwort gibt der User Guide (Rev.F): Die LLE kann in verschiendenen Modi betrieben werden – proprietär, d.h. nach eigenem Gutdünken Senden und Empfangen, oder im BLE-Modus, der (bisher) nur durch die Closed Source-Bibliotheken für IAR bedient werden kann (die auch nur mit der IAR Workbench funktionieren). Wird der Modus nach dem Setzen des LLE Enable Bits geändert, hat er keinen Effekt mehr, heißt es im User Guide weiter (S.301), was unterstreicht, dass der Funkteil des SoC dann hardwareseitig anderst funktioniert. Weder im Datenblatt noch im User Guide ist dieser BLE- Hardware-Teil dokumentiert.

Am Rande bemerkt, sieht das LLE Control Register für den Modus überdies zwei Bit vor, was vier, statt der zwei dokumentiert möglichen Betriebsmodi bedeutet.

Gewöhnliche 8051-Programme laufen nicht auf dem CC2541

Mit dem freien 8051-IDE MCU8051IDE haben wir versucht, ein Hallo Welt-Programm auf den CC2541 zu flashen. Das IDE hat uns aus unserem Hallo Welt-Assembler-Code ein 8051-Binärprogramm erzeugt, das wir mit cc-tool auf den CC2541 flashen konnten. Leider hat das Programm dort nicht das getan, was es sollte: eine LED blinken zu lassen.

Grund dafür ist aller Wahrscheinlichkeit nach, dass im CC2541 kein Standard-8051 verbaut ist. Wie im Datenblatt sowie im User Guide nachzulesen ist, gibt es einige Änderungen:

  • teilweise geänderte Adressen der Register im RAM
  • zusätzliche Register für zusätzliche Hardware-Funktionalitäten
  • evtl. Notwendigkeit für Setup-Instruktionen (z.B. Richtung) vor der Ansteuerung von I/O-Pins
  • eine Instruktion pro Takt, anstatt 12 Takte pro Instruktion

Um ein Hallo Welt-Programm auf dem CC2541 zum Laufen zu bekommen, wird es daher notwendig sein, direkt mit der Entwicklung in C mit dem sdcc C-Compiler zu beginnen. sdcc verfügt über eine cc2530.h, die aus einem User Guide abgeleitet wurde, das für CC253x und CC254x gleichermaßen gilt. Sie sollte bei Einbindung die Nutzung aller CC2541-Register sowie der angeschlossenen Funktionalitäten ermöglichen.

Ein Programm in den CC2541 flashen How To

Der Bluetooth 4.0-fähige 8051-Chip CC2541 von Texas Instruments, der auf dem Tinysine HM-10 Modul zu finden ist, besitzt eine Schnittstelle zum hardwarenahen Debuggen, den Debug Port, der aus den zwei Leitungen Debug Clock (DC) und Debug Data (DD) besteht. Die Besonderheit bei diesem Port im Gegensatz zu RS-232 oder SPI besteht darin, dass die Kommunikation in beide Richtungen – Daten vom PC zum Chip und umgekehrt – über denselben Pin erfolgt (und daher auch nicht gleichzeitig stattfinden kann). Takt- und Daten-Pins sind auf dem HM-10 herausgeführt, allerdings nicht auf die 2,54mm-Pins der TinySine Ausbrech-Platine. Sie lassen sich aber leicht nachrüsten (Foto wird nachgereicht). Wenn DC, DD, Reset und GND herausgeführt sind, kann man diese Pins an den CC Debugger von Texas Instruments anschließen. Der SmartRF Programmer hat im Test leider nicht funktioniert, zumindest nicht unter Windows, obwohl er es eigentlich sollte. Der CC Debugger ist sogar offiziell Open Hardware, der Schaltplan ist auf der Seite von Texas Instruments zu finden. Seine Funktionsweise ist im zugehörigen User Guide dokumentiert. Die zum Programmieren der Chips erforderliche Software lässt sich ebenfalls dort herunterladen (wenn man einen TI-Account hat). Nachbauten des SmartRF Programmer lassen sich günstig auf eBay erwerben. Zur Programmierung unter Linux steht cc-tool zur Verfügung. Links:

2x TinySine BLE-Module am Raspberry Pi How To

In der gestrigen #tt-Session haben wir u.a. versucht, zwei BLE-Module gleichzeitig an einen Raspberry Pi anzuschließen. Nachdem schon beim letzten Mal die Kommunikation mit einem einzelnen Modul funktioniert hat, wollten wir es mit zweien versuchen, um schon mal eine „Di-Angulation“ per BLE versuchen zu können, bis wir ein drittes BLE-Modul haben.

Die Schwierigkeit beim Anschließen von zwei Modulen liegt darin, dass eigentlich pro Modul ein UART benötigt wird, der Raspberry aber nur einen hat. USB-Serial-Adapter konnten wir nicht nehmen, da diese mit CMOS (5V) operieren, aber TTL (3.3V) benötigt wird. Also haben wir versucht, mit GPIO-Pins Transistoren zu schalten, welche die RX- und TX-Pins jeweils zum gewünschten BLE-Modul durchschalten.

Hat aber nicht geklappt. Warum nicht? Vielleicht, weil Bipolartransistoren in Gegenrichtung sperren (also wie eine Diode wirken) und so ein einmal auf High gesetzter Pin nicht mehr auf Low gezogen werden kann. Das würde allerdings eher dem Verhalten eines FET oder IGBT entsprechen. Bipolartransistoren schalten bei Strömen. Wenn sie am Ausgang (Emitter) nicht mit einer Senke (Erde,Minuspol) verbunden sind, fließt möglicherweise nicht genug Strom, um den Transistor gängig zu schalten.

Nächster Ansatz: Pull-down Widerstände, um Pegel auf Empfängerseite auf Low zurückzuziehen.

SVGs in Android-Apps Analysis

Für Logos und auch für Spiele wäre es sehr nützlich, ein Android-Element (View) zu haben, das Vektorgraphiken erzeugen bzw. laden (rendern) kann, die man zur Laufzeit aus der App heraus manipulieren kann. Zum Rendern gibt es bereits ein paar Lösungen:

androidsvg
svg-android
http://code.google.com/p/svg-android/source/browse/trunk/svgandroid/src/com/larvalabs/svgandroid/SVGParser.java

Diese bieten bereits mächtige Render-Fähigkeiten aber noch keine Manipulationsmöglichkeit zur Laufzeit.

Möglicherweise ist es an der Zeit, dass wir entsprechende Bibliotheken in Angriff nehmen.

metabox-Tastatur an Raspberry Pi How To

Die Metabox war eine im deutschsprachigen Raum in den 90/00er-Jahren produzierte Set-Top-Box mit 486er CPU. Eine der Besonderheiten war die Infrarot-Tastatur, die direkt über einen IR-Empfänger auf dem Mainboard funktioniert hat. Die Box selbst ist überholt, aber die Tastatur ist nach wie vor ein nettes Gadget, da sie leicht, kabellos (AA-Batterien) und kompakt ist und auch eine Maus mit 6 Buttons featuret. Der infrarote Übertragung sorgt zudem für niedrigen Energieverbrauch und beschränkt die Abhörbarkeit auf Sichtweite.

Wie lässt sich die Tastatur mit einem Linux-System verwenden ?

Am Raspberry Pi können wir mithilfe der in einem früheren Beitrag beschriebenen „Ynfrastruktur“ die Infrarot-Signale der Tastatur empfangen:

RC-5 ?

irrecord meldet bisher noch „Something went wrong.“ …