Chip Award Gewinner
Produkt des Jahres 2012
Chip Award

Neue Bricklets: Color, NFC/RFID und Solid State Relay

geschrieben von admin am 11.08.2014 16:12:00.

Wir haben euer Feedback genutzt und heute drei neue Bricklets inklusive Zubehör veröffentlicht:

1) Color Bricklet

http://www.tinkerforge.com/de/doc/_images/Bricklets/bricklet_color_in_action_600.jpg

Das Color Bricklet ist mit einem präzisen Farbsensor ausgestattet. Dieser misst die Farbe im RGB Farbmodell, die Farbtemperatur und die Beleuchtungsstärke mit jeweils 16Bit Auflösung! Eine per Software schaltbare LED erzeugt bei Bedarf eine definierte Beleuchtung, so dass über die Licht-Reflektion die Farbe eines Objekts sehr genau und wiederholbar bestimmt werden kann. Damit ist das Bricklet zum Beispiel zum Sortieren von Gegenständen geeignet. Während das Ambient Light Bricklet bis zu ~1000 Lux messen kann, kann das Color Bricklet problemlos Beleuchtungsstärken in Höhe von mehreren 10000 Lux auswerten.

2) NFC/RFID Bricklet

http://www.tinkerforge.com/en/doc/_images/Bricklets/bricklet_nfc_rfid_tilted_600.jpg

Mit dem NFC/RFID Bricklet können diverse 13.56MHz Tags gelesen und geschrieben werden. Das Bricklet unterstützt Mifare Classic, NFC Forum Typ 1 und 2 RFID/NFC Tags mit beliebigem Speicherplatz. Passende Tags haben wir als Scheckkarte, Schlüsselanhänger oder Aufkleber mit in dem Shop aufgenommen. Als Beispiel könnte man mit dem Bricklet eine intelligente Katzenklappe entwickeln, bei der die Katze ein NFC Tag als Halsband trägt. Man stelle sich die Möglichkeiten vor: Zutrittskontrolle, Aufzeichnung der Zeiten (Betreten/Verlassen), eine twitternde Katzenklappe,… Uns fallen viele spannende Anwendungen ein. Dieses Beispiel ist auch gut um eine wichtige Eigenschaft von NFC zu erklären: Die Reichweite ist vom NFC-Standard auf 10cm begrenzt. Die Katzenklappe soll ja nicht bereits aufgehen, wenn die Katze nur 10m entfernt an ihr vorbeiläuft.

3) Solid State Relay Bricklet

http://www.tinkerforge.com/en/doc/_images/Bricklets/bricklet_ssr_w_heatsink_tilted_600.jpg

Das Schalten größerer Lasten, wie zum Beispiel Motoren, stellt immer wieder ein Problem dar. Mit dem bisherigen Dual Relay Bricklet lassen sich sehr einfach verschiedenste Spannungen schalten. Gerade aber bei großen 230V Lasten können die verbauten mechanischen Relais Probleme machen. Die Schaltfunken können zu Störungen führen, die das System instabil werden lässt. In diesem Fall kann man zum Beispiel über geeignete Snubber (siehe Dual Relay Bricklet Dokumentation) oftmals die Probleme lösen. Einfacher ist die Nutzung von Solid State Relais. Diese schalten nicht mechanisch sondern über elektronische Bauteile. Ein Schaltfunke und die damit verbundenen Störungen treten nicht auf. Da keine Mechanik verbaut ist hält so ein Relais deutlich mehr Schaltzyklen aus (verschleißfrei) und besitzt eine galvanische Trennung zwischen dem Steuerungs-Eingang und der Lastseite (Ausgang).

Mit dem Solid State Relay Bricklet bieten wir jetzt eine Möglichkeit diese Relais sehr einfach anzusteuern. Damit es direkt losgehen kann bieten wir ein Relais zum Schalten von Wechselstrom mit einer maximalen Schaltleistung von 25A bei 380V und eins zum Schalten von Gleichstrom mit einer maximalen Schaltleistung von 80A bei 50V. Als weiteres Zubehör bieten wir eine Schutzabdeckung, die ein Berühren der Kontakte verhindert, sowie einen Kühlkörper, der beim Schalten von mit hoher Schaltleistung notwendig ist.

Wir haben unterschiedliche Typen und Hersteller von Solid State Relais getestet. Die Relais in unserem Shop sind von hoher Qualität verglichen mit den super billigen Relais die man direkt aus China kaufen kann. Obwohl das Bricklet diese günstigen Relais schalten kann (zumindest wenn man ein Kabel anlötet), wollen wir ausdrücklich davon abraten ein 2€ Solid State Relais zu verwenden. Wir haben sehr schlechte Erfahrungen gesammelt als wir diese mit unserer Elektronischen Last getestet haben.

Vollautomatischer Fotografiedrehteller

geschrieben von admin am 04.08.2014 14:51:00.

Nachdem wir einige Erfahrung im Erstellen der Fotos für die Dokumentation und des Shops sammeln konnten und unser Equipment laufend verbessert haben, wollten wir nun für weitere Aufnahmen einen Drehteller nutzen. Professionelle Foto-Drehteller kosten einiges, so haben wir unseren eigenen gebaut um 360° Fotos erstellen zu können.

Vorweg erstmal das Ergebnis und ein kleines Video welches den Drehteller in Aktion zeigt (das Video ist qualitativ nicht hochwertig, wir haben es mit einem Handy gemacht, die Kamera war ja gerade anderweitig beschäftigt ;-) ).

360° Foto eines Bricklets.

Aus dem Tinkerforge Baukastensystem verwenden wir ein Industrial Quad Relay Bricklet sowie ein Stepper Brick. Der Quellcode zum ansteuern des Stepper Bricks und des Quad Relays befindet sich auf github.

Die weiteren Zutaten für diesen Drehteller belaufen sich auf wenige Teile:

http://download.tinkerforge.com/_stuff/photography_turn_table_1.jpg

Wir haben einen Schrittmotor (14€) und Hub (6€) von Pololu sowie zwei Schneidebretter (1€, 3€) als Auflage und Fuß gekauft. Dazu kommt ein Drehkugellager von Ebay (10€) sowie ein paar Holzreststücke als Abstandshalter und Schrauben, sowie Winkel aus der Restekiste.

Summa Summarum also wirklich nicht zu teuer!

Nachdem Hub und Drehkugellager an das obere Brett, der Schrittmotor an den Hub, Abstandshalter an das untere und obere Brett, sowie die Winkel zwischen die Abstandshalter geschraubt wurden, sieht das ganze dann so aus:

http://download.tinkerforge.com/_stuff/photography_turn_table_2.jpghttp://download.tinkerforge.com/_stuff/photography_turn_table_3.jpg

Dem geübten Auge wird aufgefallen sein, dass die Schrauben, die das Drehkugellager mit dem oberen Brett verbinden, nicht komplett reingeschraubt sind. Dies war leider Aufgrund der zu hohen Qualität des Kugellagers notwendig. Das Kugellager, welches wir gebraucht bei Ebay erstanden haben, ist super leichtgängig, trägt 250kg und hat keinerlei Spiel in seitlicher Richtung. Letzteres hat sich als Problem herausgestellt.

Da der Hub direkt mit dem Schrittmotor verbunden ist und der Schrittmotor wiederum seinen Platz Aufgrund der Position des Drehkugellagers bekommt, muss der Hub absolut mittig zwischen dem Drehkugellager sitzen. Wenn er nur 0,5mm daneben sitzt hängt das Kuggellager. Ups! Trotz mehrmaligem an- und abschrauben konnten wir die benötigte Genauigkeit nicht erreichen. Daher haben wir dem Kugellager einfach händisch ein bisschen Spiel gegeben indem wir es nicht komplett festgeschraubt haben.

Jetzt haben wir einen Drehteller den wir an eine beliebige Position fahren können, um das ganze vollständig zu automatisieren benötigen wir aber auch noch eine Möglichkeit automatisch zu fotografieren. Das Auslösen kann bei unserer Canon 500D einfach über einen 2,5mm Klinkenstecker passieren. Dieser hat 2 Adern und Schirmung. Zum fokussieren kann die Schirmung mit der roten Ader verbunden werden und zum Auslösen mit der weißen.

http://download.tinkerforge.com/_stuff/photography_turn_table_4.jpghttp://download.tinkerforge.com/_stuff/photography_turn_table_5.jpghttp://download.tinkerforge.com/_stuff/photography_turn_table_6.jpg

Wir haben dazu einfach ein Klinkensteckerkabel geopfert, den Adern und der Schirmung Adernendhülsen verpasst und diese vier Adern dann mit dem Industrial Quad Relay verbunden. Jetzt können wir die Kamera Auslösen, in dem wir Relais 1 schalten sowie Fokussieren, indem wir Relais 2 Schalten. Das war einfach!

Das Endergebnis mit weißer Fotounterlage auf dem Brett sieht wie folgt aus:

http://download.tinkerforge.com/_stuff/photography_turn_table_7.jpg

In unserer (natürlich auch selbstgebastelten) Fotoecke macht es sich wunderbar:

http://download.tinkerforge.com/_stuff/photography_turn_table_8.jpg

API Bindings und Package Management

geschrieben von admin am 25.07.2014 14:38:00.

In der Vergangenheit waren die Installations- und Benutzungsanleitungen der API Bindings davon ausgegangen dass ein Nutzer sich mit einer von uns unterstützen Sprache bereits auskennt. In den letzten Tagen haben wir daran gearbeitet die Dokumentation diesbezüglich zu verbessern. Es sollte nun auch für einen Anfänger möglich sein die API Bindings zu installieren und eines der Testbeispiele auszuführen ohne etwas auf einer anderen Seite nachlesen zu müssen.

Die Links zu den Installations- und Benutzungsanleitungen für die von uns unterstützten Sprachen können in der Dokumentation gefunden werden.

Einen Vorschlag den wir sehr oft bekommen haben war, Packages und Package Repositories für Sprachen zu unterstützen die soetwas anbieten. Wir haben uns anfangs dagegen ausgesprochen, da die API Bindings automatisch generiert werden und das hochladen eines Paketes einen weiteren manuellen Schritt zum Prozess des freischalten neuer Bindingsversionen hinzufügt.

Allerdings haben wir in letzter Zeit so viele Anfragen diesbezüglich bekommen das wir uns entschieden haben Packages in Repositories zu bringen für Sprachen wo dies für uns einfach möglich. Aktuell unterstützen wir Maven (Java), NPM (JavaScript), CPAN (Perl), PyPI (Python) und GEM (Ruby). Dies bedeutet, dass man nun die Bindings für diese Sprachen mit einem einfachen Kommandozeilen One-Liner installieren und aktualisieren kann.

http://download.tinkerforge.com/_stuff/repo_logos.jpg

Java - Maven:

Füge Abhängigkeit zu deiner pom.xml hinzu

JavaScript - NPM:

> npm -g install tinkerforge

Perl - CPAN

> cpanm Tinkerforge

Python - PyPI

> pip install tinkerforge

Ruby - GEM

> gem install tinkerforge

Erstes LiveHacking in Hamburg

geschrieben von admin am 15.07.2014 14:49:00.

Wie im letzten Blogpost angekündigt, hat gestern Abend das erste LiveHacking in Hamburg stattgefunden:

http://download.tinkerforge.com/_stuff/live_hacking.jpg

Bastian war bei diesen Event mit dabei, das von der Java User Group Hamburg, Sven Ruppert (Codecentric AG) und Alexander Bischof organisiert wurde. Die Teilnehmer wurden in die Räumlichkeiten der Hacker- und Makerspace Attraktor e.V eingeladen und konnten ihre eigenen Ideen mit dem Tinkerforge Baukastensystem umsetzen. Es hat sehr viel Spaß gemacht euch bei der Nutzung unserer Module über die Schulter zu schauen und mit euch Ideen auszutauschen. Ein paar Kleinigkeiten und Bugs sind uns aufgefallen, die wir natürlich beseitigen wollen. Die ersten Bugfixes haben wir direkt heute morgen veröffentlicht.

Es sind weitere LiveHackings bundesweit geplant, bei denen wir Sven Ruppert unterstützen werden. Seinen Bericht könnt ihr hier finden . Danke für das sehr positive Feedback und die Verbesserungsanregungen! Wir freuen uns auf die weiteren Events.

LED Strip Bricklet unterstützt WS2811 und WS2812(B)

geschrieben von admin am 10.07.2014 14:23:00.

Mit der neuen Firmware Version 2.0.4 unterstützt das LED Strip Bricklet nun neben dem LED Treiber WS2801 auch die Treiber WS2811, WS2812 und WS2812B (auch bekannt als “NeoPixel”).

Zum testen haben wir unterschiedliche LED Strips sowie eine 256 Pixel große LED Matrix von unterschiedlichen Herstellern angesteuert.

http://download.tinkerforge.com/_stuff/ws2812b_led_matrix.jpg

Des weiteren haben wir auf der Maiker Faire ein WS2812B Strip mit dem RED Brick zwei Tage ohne Aussetzer ansteuern können. Die Anleitungen in der Dokumentation wurden entsprechend angepasst. Sie Erklären nun auch wie die neu unterstützten Treiber angeschlossen werden müssen (die Clock-Leitung wird nicht mehr verwendet).

Bundesweites LiveHacking mit Tinkerforge

geschrieben von admin am 27.06.2014 16:48:00.

http://download.tinkerforge.com/_stuff/jug_hamburg.jpg

Wir möchten euch heute über eine Reihe von Veranstaltungen berichten die in verschiedenen Städten der Bundesrepublik und sogar im Ausland stattfinden wird. Am Montag, den 14.07. wird in Hamburg die erste Veranstaltung mit dem Namen “Tinkerforge und IoT” stattfinden. Diese, als LiveHacking bezeichnete, Veranstaltungsreihe wird von Sven Ruppert geleitet. Die Teilnahme ist kostenlos. Eine Beschreibung könnt ihr hier finden.

Sven arbeitet für die Codecentric AG und hält zum Beispiel Vorträge über Java bei Java User Groups (JUGs) oder schreibt als Gastautor Artikel für Jaxenter und EclipseMagazin. Aktuell beschäftigt er sich mit dem Thema “Internet der Dinge”. Bei seiner Suche nach geeigneter Hardware ist er auf uns gestoßen und nutzt seitdem das Baukastensystem für seine Vorträge. Die Bricks und Bricklets werden genutzt um Teilnehmer mit Java8 im Zusammenhang mit IoT vertraut zu machen.

Bastian wird die Veranstaltung in Hamburg, die leider bereits vollständig ausgebucht ist, besuchen, Rede und Antwort stehen und natürlich mit einem Blogpost berichten. Weitere LiveHackings sind bereits geplant.

RED Brick Software-Infrastruktur

geschrieben von admin am 20.06.2014 12:12:00.

Nachdem wir bisher lediglich über die Hardware des RED Bricks berichtet haben, wollen wir heute näher auf die Software eingehen.

Achtung: Dieser Artikel geht auf die technischen Details, der Software des RED Bricks ein. Dieses Hintergrundwissen ist für die Nutzung des RED Bricks später nicht notwendig!

Die folgende grafische Übersicht, über die aktuell geplante Software-Infrastruktur, soll in diesem Blog Post erklärt werden.

http://download.tinkerforge.com/_stuff/red_brick.png

Überblick

Die Farben in der Grafik besitzen folgende Bedeutung:

  • Blau: Tinkerforge Software Komponenten

  • Grün: Tinkerforge Hardware im Stack des RED Bricks

  • Lila: Tinkerforge Hardware extern angeschlossen

  • Orange: Externe Software Komponenten

Der Stack, sowie Mini USB und USB A, werden in der Grafik als Schnittstellen zwischen RED Brick und der Außenwelt dargestellt.

Über den Mini USB Anschluss werden mittels eines Composite USB Gadget Treibers zwei USB Klassen bereitgestellt: Die erste Klasse stellt einen Serial Port dar, über den ein einfacher Shell Access auf den RED Brick hergestellt werden kann. Die zweite Klasse stellt die Brick API zur Verfügung, d.h. ein RED Brick, der per USB an einen PC angeschlossen wird, taucht dort wie jeder andere Brick auf. Er hat ein API wie alle anderen Bricks und Bricklets. Über diese API kann der RED Brick konfiguriert werden. Dazu gehört die Übertragung des Anwender-Programms, die Einstellung wann das Programm ausgeführt werden soll (einmal, jede Stunde einmal, beim Start des RED Bricks, usw.), sowie andere Konfigurationen. Der RED Brick kann also wie eine Black Box betrachtet werden, die über Hochsprachen Bricks und Bricklets steuern kann.

Über die Stapel-Stecker können alle Bricks sowie die Ethernet Extension und RS485 Extension mit dem RED Brick genutzt werden. Für die Ethernet Extension wird ein Treiber geschrieben, der diese als normale Ethernet Schnittstelle im Linux System erscheinen lässt (eth0).

Über den USB A Anschluss können beliebige USB Geräte angeschlossen werden (Maus, Tastatur, WLAN Stick) und natürlich auch weitere Tinkerforge Hardware.

Diese Anschlüsse können alle gleichzeitig genutzt werden. Ein RED Brick Stapel, der per Mini USB an einem PC angeschlossen ist, Bricks und Bricklets verwendet, weitere Bricks und Bricklets über die RS485 Extension nutzt, mit dem Internet über die Ethernet Extension verbunden ist und weitere Geräte über USB A angeschlossen hat, ist also problemlos möglich.

Im folgenden werden die einzelnen Komponenten die notwendig sind für dieses System vorgestellt:

Linux Distribution

Die auf Debian basierte Linux Distribution des RED Bricks ist bereits sehr weit voran geschritten. Die Konfigurationen, die für die Komponenten (RAM, Stromversorgung) und Schnittstellen (USB Mini/A, HDMI, SD Card, SPI/I2C/UART im Stack, GPIO, LEDs, etc) am Linux Kernel stattfinden müssen, sind abgeschlossen. Alle Tinkerforge Bindings und die dazu gehörenden Compiler und Interpreter sind auf der Distribution vorinstalliert. Dazu kommen die wichtigsten Bibliotheken für jede Sprache die wir unterstützen, damit auch komplexere Entwicklungen stattfinden können.

Des weiteren können zwei Images Erzeugt werden:

  • Full Image: Dieses Image stellt alle Funktionen des RED Bricks zur Verfügung, inklusive einem Grafiktreiber für OpenGL und Grafikausgabe per HDMI.

  • Fast Image: Dieses Image ist auf maximale Geschwindigkeit ausgelegt. Die GPU ist in diesem Image beispielsweise totgelegt, wodurch die Bootzeit signifikant verringert werden kann.

Mit dem Full Image verhält sich der RED Brick wie ein PC. Mit dem Fast Image verhält sich der RED Brick eher wie ein Ersatz für den Master Brick, der eine OnDevice API für C/C++, C#, Delphi/Lazarus, Java, JavaScript, MATLAB/Octave, Perl, PHP, Python, Ruby, Shell und Visual Basic .NET hat.

Status: 100%

SPI Stack Kommunikation

Die Kommunikation mit Bricks und Bricklets im Stack findet über SPI statt. Das aktuell verwendete Protokoll, welches zwischen den Bricks gesprochen wird, ist für die SAM3S4 Prozessoren entwickelt worden, die wir in den Bricks verwenden. Dieses Protokoll ist zwar sehr effizient, es würde das Linux System des RED Bricks aber leider in die Knie zwingen. Die Lösung stellt die Nutzung von DMA dar, da der Prozessor während der Kommunikation nicht belastet wird. Unser bisheriges Protokoll ist nicht DMA kompatibel. Daher muss für die SPI Kommunikation ein neues Protokoll entworfen werden, dass mit dem DMA Controller der SAM3S4 Prozessoren, als auch mit dem des A10s Prozessors kompatibel ist. Dieses Protokoll muss dann auf dem RED Brick sowie den anderen Bricks implementiert werden.

Status: 25%

Das neue Protokoll ist komplett ausgearbeitet und die Implementierung für die SPI Slaves ist fertig. Aktuell sind wir dabei die Implementierung des SPI Master Treibers auf dem RED Brick zu schreiben. Momentan sieht es so aus als könnten wir dafür /dev/spidev verwenden, welches die Entwicklung vereinfacht, da sie komplett im Brick Daemon stattfinden kann. Falls es dort zu Performanceeinbrüchen kommt, können wir aber Problemlos die relevanten Teile direkt in den Linux Kernel bringen.

RED Brick API Daemon

Der RED Brick API Daemon ist ein Daemon, der die API des RED Bricks implementiert. D.h. dieser Daemon implementiert die Konfiguration die über Mini USB stattfindet.

Status: 25%

Die wichtigsten Komponenten der API sind ausgearbeitet und die notwendige Infrastruktur (Kommunikation mit Brick Daemon etc) ist implementiert.

Composite USB Gadget Driver

Der Composite USB Gadget Driver stellt zwei Schnittstellen über Mini USB zur Verfügung. Mittels diesem Treiber taucht der RED Brick als “normaler Brick” am PC auf, es kann aber gleichzeitig ein Zugriff auf die Shell des Linux auf dem RED Brick stattfinden.

Status: 100%

Der Treiber ist fertig und funktional.

Benutzerschnittstelle

Das Endziel ist es den RED Brick über den Brick Viewer konfigurierbar zu machen. Die API des RED Bricks sollte nur von “Power-Usern” überhaupt genutzt werden müssen. Der “normale” Nutzer überträgt sein Programm und konfiguriert den RED Brick nur über den Brick Viewer.

Status: 0%

Mit der Implementierung der Benutzerschnittstelle haben wir noch nicht begonnen.

Ethernet Treiber (W5200)

Auf der Ethernet Extension nutzen wir den WIZnet W5200 IC um Ethernet zu sprechen. Für diesen gibt es leider noch keinen Linux Kernel Treiber. Allerdings gibt es bereits Treiber für die sehr ähnlichen W5100 und W5300, was die Implementierung eines solchen Treibers vereinfacht.

Status: 0%

Mit der Implementierung wurde noch nicht begonnen.

RS485 Extension Support

Die Unterstützung für die RS485 Extension hat aktuell die niedrigste Priorität und wird erst nach der Veröffentlichung des RED Bricks starten.

Maker Faire 2014

geschrieben von admin am 12.06.2014 16:29:00.

http://download.tinkerforge.com/_stuff/MakerFaireHannover.jpg

Im letzten Jahr hat die erste deutsche Maker Faire in Hannover stattgefunden. Wir waren dabei und konnten mit euch einige interessante Gespräche führen. Dies ist ein guter Grund für uns auch dieses Jahr and der Maker Faire teilzunehmen.

Die Maker Faire findet vom 05.- 06. Juli wieder im Hannover Congress Centrum statt, allerdings diesmal mit deutlich vergrößerten Räumlichkeiten. Weitere Informationen findet ihr auf: http://makerfairehannover.com/.

Wir werden natürlich Prototypen des RED Bricks mit im Gepäck haben. Wir freuen uns auf euch!

Überarbeitete Dokumentation und Kits

geschrieben von admin am 06.06.2014 16:18:00.

Screenshot von Tinkerforge Dokumentation

Dokumentation

Wir haben die Dokumentation aufgeräumt. Eine neu geschaffene Einstiegsseite soll einen Überblick über Bricks, Bricklets, Master Extensions und die Konzepte hinter dem Tinkerforge Baukastensystem geben.

In dem Zuge haben wir die Dokumentation aller Produkte überarbeitet. Wie es der Fehlerteufel so will, ist dort sicher auch irgendwo etwas schief gelaufen. Bitte gebt uns Bescheid, wenn wir tote oder falsche Links entdeckt. Danke!

Kits

Ebenfalls überarbeitet haben wir die Zusammenstellung des Education und Tinker Kits:

Das Education Kit ist dazu gedacht in der Ausbildung eingesetzt zu werden. Das Kit wurde längere Zeit nicht überarbeitet. Die Menge an Bricklets, die direkt genutzt werden können, ohne das extern irgendwelche in Eigenleistung gefertigten Komponenten angeschlossen werden müssen ist mit der Zeit immer größer geworden. Ein Grund es zu überarbeiten. So haben wir als Beispiel das bisher im Kit vorhandene IO-16 Bricklet, an dem Taster oder LEDs angeschlossen werden können, durch Bricklets wie Motion Detector Bricklet oder Multi Touch Bricklet ersetzt. Die im Kit vorhandenen Module ermöglichen nun eine Vielzahl an Projekten, die einfach durch Zusammenstecken der mitgelieferten Module realisiert werden können.

Das Tinker Kit dient dazu die Hardware bereitzustellen um nahezu jedes erdenkliche Projekt zu realisieren. Auch dieses Kit hatten wir lange Zeit nicht aktualisiert, so dass die Frage aufkam welche neuen Module in das Kit kommen sollten und welche wir vielleicht rausnehmen wollen. Wir haben uns dazu entschieden einfach alles in das Kit gepackt. In dem Kit sind nun alle Tinkerforge Module mindestens einmal enthalten. Genau das richtige, für einen Grundstock an Modulen wenn man noch nicht weiß in welche Richtung die Reise geht.

RED Brick

Beim RED Brick geht es auch gut voran. Nächste Woche werden wir euch hier über den aktuellen Stand informieren.

RED Brick: Tut es? Oder tut es nicht?

geschrieben von admin am 21.05.2014 12:45:00.

RED Brick Prototyp verschiedene Ansichten

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)

RED Brick Prototyp LXFE Screenshot

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.

Wichtige Informationen

Über Uns

 

Folge Uns