Blog

Im letzten Blogeintrag haben wir über die ersten Prototypen des RED Bricks berichtet. Bei dem Design ist uns ein Fehler unterlaufen, so dass ein Prozessorpin fälschlicherweise mit Ground verbunden war. Um diese Verbindung zu trennen haben wir, mit einem eigentlich viel zu großen Bohrer, eine Durchkontaktierung aufgebohrt. Das erste RED Brick konnten wir so zum Leben erwecken. Nun ist eine Woche vergangen und wir sind ein ganzes Stück weiter.

Mit den letzte Woche angekommenen 0.3mm Bohrern haben wir den Schaltungsfehler auf weiteren RED Bricks repariert. Den Bohrer korrekt zu Positionieren war selbst mit dem genutzten Kreuztisch nicht immer 100%ig möglich, so dass z.T. etwas neben der Durchkontaktierung gebohrt wurde und andere Leiterbahnen in der 6-lagigen Leiterplatte verletzt wurden. In Summe konnten wir sechs RED Bricks zum Leben erwecken.

U-Boot/Linux Image

Wir haben viel Arbeit in U-Boot (Bootloader) und das Linux Image des RED Bricks gesteckt. Zu den Aufgaben gehörte es die Toolchain aufzubauen, Build-Skripe zu schreiben, Hardwaremodifikationen zu implementieren (LEDs, DDR, Schnittstellen), das Image zu konfigurieren (Sprache, Hostname, etc.) usw. Besonders aufwendig ist die Optimierung der Bootzeit. Viele Dienste, Treiber etc., die standardmäßig vorhanden sind, sind auf dem RED Brick nicht sinnvoll und können entfernt werden. Zur Zeit stehen wir bei einer Bootzeit (inkl. grafischer Oberfläche) von ca. 45 Sekunden. Wir werden diese aber weiter optimieren. Neben dem Image mit grafischer Oberfläche wird es auch ein deutlich abgespecktes Image ohne grafische Oberfläche geben, dass deutlich schneller booten wird. In ersten Tests konnten wir bereits Bootzeiten von 15 Sekunden erreichen.

HDMI

Da einige HDMI Signale direkt neben der besagten Durchkontaktierung verlaufen, funktioniert HDMI nicht auf allen reparierten RED Bricks. Zum Teil haben wir diese beim Bohren erwischt. Sind diese Leiterbahnen nicht getroffen worden, funktioniert HDMI aber: (Screenshot direkt auf dem RED Brick erstellt)

USB Host

Funktioniert ebenfalls. Wir nutzen aktuell zum Beispiel einen USB WIFI Stick um das RED Brick ins Netzwerk zu bringen.

Arbeitsspeicher und Hitzetest

Die Anbindung des DDR Speichers an den Prozessor ist recht komplex und muss gründlich getestet werden. Mit dem Werkzeug stress haben wir dem RED Brick ordentlich eingeheizt. Stress belastet Prozessor, Arbeitsspeicher und die SD Karte und lastet das System vollständig aus. Instabile Plattformen können mit diesen Tests erkannt werden. Wir haben das RED Brick bei diesen Tests über Stunden ohne Kühlkörper betrieben, es wurde sehr heiß. Es traten aber keine Probleme auf. Zusätzlich nutzten wir memtester, das verschiedene Tests mit dem Arbeitsspeicher durchführt. Wir konnten ebenfalls keine Probleme feststellen. Mittels sysbench und dd konnten wir die erwartete Performance erzielen. Somit scheinen hier auch keine Probleme zu existieren.

Euer Daumendrücken scheint also geholfen zu haben. Danke!

Wie geht es weiter?

Bei dem Linux Image gibt es immer noch einiges zu tun. Parallel beschäftigen wir uns aktuell damit eigene Kerneltreiber zu entwickeln, die zur Kommunikation mit brickv notwendig sind. Über diese Schnittstelle soll später das Brick konfiguriert, sowie die eigenen Programme übertragen werden. Wir halten euch weiter auf dem Laufenden.

Es ist eine Weile vergangen, seitdem wir das RED Brick hier im Blog angekündigt haben. Wir sind nun ein ganzes Stück weiter und freuen uns euch ein Status-Update geben zu können:

Die Bestellung der Leiterplatten mit der Klärung der technischen Details, die Lieferzeit der Leiterplatten von einem Monat und die Planungen/Vorbereitungen beim Bestücker haben dazu geführt, dass wir erst letzten Freitag die ersten Prototypen “mit nach Hause” nehmen konnten.

Basierend auf dem Sunxi Linux, dass sich der Unterstützung von Allwinner Prozessoren widmet, haben wir unser eigenes Debian Image entwickelt. Leider funktionierte dies nicht sofort auf dem Prototypen, so dass eine Fehlersuche angesagt war. Zum Glück bieten die Allwinner Prozessoren eine einfache Möglichkeit direkt mit dem Prozessor zu kommunizieren, die sogenannte FEL Schnittstelle. Damit konnten wir herausfinden, dass der Prozessor nicht von der SD Karte booten konnte. Nach längerer Suche war der Schuldige auch direkt gefunden: Der Prozessor besitzt eine JTAG Schnittstelle, welche ebenfalls zum Debuggen genutzt werden kann. Über zwei Prozessorpins kann festgelegt werden, auf welchen Pins dieses verfügbar ist. Die JTAG Schnittstelle wurde unglücklicherweise so konfiguriert, dass sie auf den Pins für die SD Karte läuft und somit die SD Karte nicht funktioniert. Der Prozessor bietet verschiedene Schnittstellen zum Anschließen einer SD Karte, diese wurden während der Designphase auch häufiger gewechselt. Leider wurde anschließend vergessen, die JTAG Schnittstelle anzupassen.

Die schuldigen Pins befinden sich direkt unter dem Prozessor, sind also von außen nicht mehr erreichbar. Daher haben wir Versuche unternommen eine andere SD Karten Schnittstelle zum laufen zu bekommen. Zum Glück befindet sich auf der “General Purpose”/Kamera Schnittstelle ebenfalls eine SD Karten Schnittstelle. Nach etwas fädeln hatten wir diese auch angeschlossen:

Die Schnittstelle haben wir nicht zum laufen bewegen können. Die Datenblätter des Prozessors sind leider nicht sonderlich aussagekräftig. Unter Umständen ist es unmöglich direkt von dieser SD Karten Schnittstelle zu booten. Alternativ sind es elektrische Probleme oder die Konfiguration unseres Images ist nicht korrekt gewesen.

Daher blieb uns nur die Möglichkeit irgendwie die Verbindung der JTAG-Konfigurations-Pins zu trennen und somit die korrekte JTAG Konfiguration herzustellen. Wir hatten alle bestellten Prozessoren bereits bestückt, so dass eine neue Bestückung, mit modifizierter Leiterplatte, nicht so schnell zu bewerkstelligen war. Auch ein Runterlöten des Prozessors (FBGA), Trennen der Verbindungen, Reballing und das erneute Drauflöten war so recht keine Option. Der Abstand zwischen RAM und Prozessor ist sehr gering, so dass dieses nicht so einfach möglich gewesen wäre. Daher haben wir die Durchkontaktierung, die einen der beiden Pins mit der Masselage verbindet, ausgebohrt und somit die Verbindung getrennt. Ein interner Pull-Up im Prozessor sorgt nun dafür, dass dieser Pin “High” ist.

Aber wie bohrt man eine Durchkontaktierung, die einen Außendurchmesser von 0,3mm und eine Bohrung von 0,15mm besitzt, aus?

Mit diesem provisorischen Aufbau haben wir es versucht. Leider hatten wir nur einen 0,5mm Bohrer zur Hand, so dass wir sehr viel mehr wegnehmen mussten als notwendig. Den Bohrer überhaupt halbwegs passend über der Durchkontaktierung zu positionieren war schon nicht ganz einfach. Die Bohrtiefe konnten wir nur nach Gefühl ermitteln. Die besagte Masse-Lage besitzt zur Top-Lage (da wo der Prozessor drauf sitzt) einen Abstand von 0,2mm. Diese Verbindung musste aufgebohrt werden ohne all zu tief in den Prozessor zu bohren und diesen zu zerstören.

Das Ergebnis unserer destruktiven Arbeit seht ihr im obigen Bild. Unsere Anspannung, als wir das Brick an einem Rechner angeschlossen haben und auf die ersten Lebenszeichen warteten, könnt ihr euch vielleicht vorstellen. Umso größer war die Freude als wir die ersten Lebenszeichen sehen konnten:

Wie geht es jetzt weiter?

Wir sind jetzt dabei das Brick zu testen. Es muss nun zeigen, dass es auch stabil funktioniert. Morgen kommen hoffentlich kleinere Bohrer an, so dass wir weitere Bricks zum leben erwecken wollen. Anschließend werden wir uns den Schnittstellen widmen und HDMI sowie USB Host testen. Als nächstes sind dann die Stapel-Schnittstellen zu den Bricks und Extensions dran. Unser Linux Image wird parallel weiterentwickelt, hier sind noch einige Anpassungen und Optimierungen durchzuführen. Eine große Aufgabe die dann wartet, ist die Implementierung eines Linux Kernel Treibers für SPI zur Stapelkommunikation und sofern notwendig, die Anpassung der Stapelkommunikation aller Bricks. Eine weitere große Aufgabe ist die Implementierung der Benutzerschnittstellen und der internen Programmausführung.

Mit den Prototypen sind wir sehr zufrieden. Die Fehler die wir bisher im Hardwaredesign gefunden haben lassen sich einfach beheben. Aktuell sieht es sogar so aus als würden wir die SMD-Rakelschablonen von den Prototypen in der Serienfertigung verwenden können, da keine Pads umgesetzt werden müssen.

Wir werden euch mit weiteren Blogeinträgen auf dem laufenden halten. Drückt uns bitte die Daumen, dass das RED Brick die weiteren Tests besteht ;-)

Mit dem Starterkit: Internet der Dinge haben wir heute ein weiteres Starterkit veröffentlicht. Es ist zum Einführungpreis von 49,99€ erhältlich.

Das Internet der Dinge (engl.: Internet of Things) stellt eine Evolution des bisherigen Internets dar. Es vernetzt nicht nur Menschen und Rechner, sondern soll diese auch mit anderen “Dingen” vernetzen. Zu den Dingen können Haushaltsgeräte, Fahrzeuge, Industrieanlagen eigentlich alles gehören mit dem wir täglich interagieren.

Das Starterkit: Internet der Dinge besteht im wesentlichen aus einem Remote Switch Bricklet und einem Master Brick und ermöglicht es daher 433MHz Aktoren, wie Funksteckdosen, Funkdimmer und Hausautomatisierungskomponenten wie Jalousiesteuerungen zu steuern. Die für das Kit entwickelte Webseite iot-remote.com ermöglicht es diese Aktoren, und die damit verbundenen Geräte, direkt ohne Programmieraufwand zu steuern. Die Seite nutzt die Tinkerforge Javascript-Bindings und ist nach dem Download der Webseite offline nutzbar (ohne weitere Internetkommunikation). Das heißt, dass eine Kommunikationen nur zwischen dem steuernde Gerät, wie z.B. PC, Smartphone oder Tablet, und dem Aktor stattfindet. Es läuft also keine Kommunikation über einen Tinkerforge-Server oder ähnlich. Wer also nicht programmieren möchte, kann mit dieser Seite ganz einfach seine Wohnzimmerbeleuchtung oder andere 230V Verbraucher über das Internet steuern.

Diejenigen, die gerne eigene Projektideen umsetzen möchten, können die Bindings für das Remote Switch Bricklet nutzen und ggf. weitere Tinkerforge Module integrieren. So wäre zum Beispiel eine licht- oder temperaturabhängige Steuerung über das Ambient Light, bzw. Temperature Bricklet möglich. Das Starterkit-Gehäuse ist mit zusätzlichen Aussparungen für eine Ethernet Extension versehen, so dass diese direkt integriert werden kann. Somit kann auf einen Raspberry PI o.ä., der als Gateway dient, bei Bedarf verzichtet werden.