Ingenieur

Hallo, Yuna, nur als Idee. Vielleicht macht es Sinn, ein Projekt mit älteren Kindern zu machen, einen MasterBrick von Grund auf zu bauen und zu löten? Zum Glück stellt TinkerForge ganze Information zu den Bricks/Bricklets online. Ich denke, es wäre für Kinder interessant zu sehen, wie ein funktionierender Chip aus einer Reihe von Halbleiterelementen entsteht. Vielleicht hat TinkerForge bereits Das Layout für die neue Version von MasterBrick mit den neuen Anschlüssen veröffentlicht. Viele Grüße, Kirill

Hallo Teddy, ich habe mir vor zirka einem Jahr so eins ausgelegt und zusammengelötet (siehe ). Wenn ich richtig verstehe, neues Layout braucht auch weniger SMD Elemente? Wird dadurch die neue Version von MasterBrick auch etwas günstiger? Danke, Kirill

Vom Design her, finde ich die Aqara Temperature Humidity Sensor von Xiaomi sind die besten. Um sich von dem Xiaomi Hub zu lösen und zu vermeiden, dass die Daten nach China unkontrolliert übergeben werden, sollte man die Sensoren von Xiaomi hacken neu flashen (z.B. wie bei https://faire-ca-soi-meme.fr/hack/2017/02/27/hack-xiaomi-mi-smart-temperature-and-humidity-sensor/) und mit einem eigenem ZigBee Hub koppeln. Ich persönlich nutze Thermostate von TADO, damit habe ich in jedem Zimmer die Temperatur und Feuchtigkeitmessung.

Die Geschichte lief weiter. Da meine Hände schon auf dem Layout vom MasterBrick waren, habe ich für mich das Layout auf 7-Pin Konnektor umgestellt. Dabei wird nicht nur die Verbindung sicherer und robuster, spart man auch an dem I2C Hub und den Elementen drum herum. Natürlich geht damit die Abwärtskompatibilität zu den 10-Pin Bricklets verloren.

Hallo, falls es kein Gehemnis ist, kannst Du kurz erzählen, was für ein Hardware habt iht mit dem SteppeBrick umgesetzt? Viele Grüße, Kirill

Hallo, es gibt sehr viele Varianten, für die man entscheiden könnte. Generell wird solche Funktionalität unter dem Begriff „Inter-process communication“ ausgehängt. Mehr Information kannst Du bei Google zu dem Begriff finden. In meinen privaten Projekten habe ich bislang die Bibliothek ICE von ZeroC verwendet. In meinem Berufsleben habe ich mehr mit dem OmniOrb (CORBA) zu tun. Die beiden Bibliotheken implementieren die RPC (remote procedure call) Paradigma der Interprozesskommunikation. Dabei bist Du nicht gezwungen, dass die Prozesse auf einem Hardware laufen und können beliebig im Netz verteilt werden. Eine einfachere Variante ist die „Shared memory“. Das ist eine sehr robuste und schnelle Methode, die bei uns für die zeitkritischen Anwendungen genommen wird. P.S. Vorsicht, da ich auch nicht vom Fach und nur ein Quereinsteiger bin. Viele Grüße, Kirill

Also... Leider die Bestellung bei einem anderen PCB Hersteller hat nichts gebracht. Ich hatte auch wie bei der ersten PCB Lieferung einen Kurzschluss zwischen 3V3 und GND. Keine Ahnung warum es so ist. Ich tippe erstmal auf eigene Blödheit. Allerdings um das Problem zu lösen, habe ich alle die Vias und Tracks gelöscht und das Layout neuverlegt. Und es dreht sich. Das Brick blinkt 😊.

Hallo Bastian, danke für den Tipp! Viele Grüße, Kirill

Hallo, ich habe in der Tat die ganze Leiterkarte selbst bestückt. Das Löten an sich ist halt nicht das größte Problem. Trotz der Tatsache, dass ich vor den Arbeiten an den Tinkerforge Produkten nur ein Paar mal im Leben gelötet habe. Man brauch halt nur eine gute Halterung für die Leiterkarte, ein Lötkolben 😊, unbedingt eine Heißluftstation und viel Zeit. Das größte Problem, welches ich sehe, ist die Lagerung von den Elementen. Laut meiner Erfahrung wird die meiste Zeit für die Suche der zu lötenden Elemente gebraucht. Auch es ist sehr wichtig zu wissen, welche Elemente man und in welcher Menge hat. Dies alles habe ich durch eine Datenbank realisiert, wo ich alle meine Käufe eintrage. Auch in der Datenbank lege ich die BOMs für die Bricklets und die Bricks ab. Zurzeit habe ich circa 160 Typen von Elementen (für circa 20 Bricks/Bricklets Typen). Alle die Elemente befinden sich in einer Kiste. In der Kiste liegen sie nach der ID gruppiert (1-50, 51-100, 101-151, 151-200). Auch habe ich ein kleines Python Skript erstellt, welches die Elemente zusammenstellt und prüft, ob alle Elemente vorhanden sind. Auch dient die Ausgabe letztendlich als eine Einleitung zum Bestücken. Ich erledige es einfach der Reihe nach (siehe Anhang). PCB bestelle ich bei unterschiedlichen Anbietern auch China. Man kann sie natürlich auch selbst machen. Dafür brauch man aber Paar Chemikalien, die ich ungern in der Wohnung haben würde, da ich zwei kleine Kinder habe. P.S. Das Problem habe ich noch nicht verstanden. Ich gehe davon aus, dass die Leiterkarte von Tinkerforge Kollegen in Ordnung ist. Mein Verdacht ist die Fertigung selbst. Ich habe mir bei einem anderen Anbieter die gleichen PCBs bestellt und schaue mal, ob sie ein anderes Verhalten zeigen. Bei diesen Leiterkarten habe ich das Problem noch nicht geortet (die Stelle von dem Kurzschluss). Ich habe sie stark mit Kälte Spray abgekühlt und mit circa 12V/1A versorgt. Die Wärmequelle ist aber irgendwo in den inneren Layers. Deswegen lässt sie sich nicht erkennen. Viele Grüße, Kirill

Ja genau, auf der unbestückten Leiterkarte messe ich den auch (siehe auf dem Bild unten). Ich dachte erstmal auch, dass es an einem falsch gelöteten Element liegt. Und Ihr habt es auch auf einer unbestückten Leiterkarte gehabt? War das ein Produktionsfehler? Kirill

Hallo Tinkerforge, wie ich in einem Post erwähnt habe, lasse ich die Logik meiner Applikation auf dem MasterBrick laufen. Obwohl ich bis heute keine Schwierigkeiten in Sicht der Performance von SAM3S erlebt habe, habe ich mir überlegt ein MasterBrick mit dem SAM4S onboard zusammenzulöten. Bei einem PCB Hersteller habe ich mir die aktuelle Version von dem MasterBrick 2.1 machen lassen und fleißig mit den Elementen bestückt. Leider nach dem alles fertig war, habe ich festgestellt, dass nichts lief und sich an dem 3.3v Spannungsregler eine sehr starke Wärmequelle entwickelt hat. Dann habe ich bei einem nicht bestückten PCB die Wiederstand zwischen der 3.3V und der GND Net gemessen und einen Kurzschluss festgestellt (siehe Bild). Höchstwahrscheinlich liegt es an einem Fehler bei der Produktion von dem PCB (z.B. Track Abstände nicht eingehalten). Meine Frage ist, ob Ihr es mal in ähnlicher Form so ein Problem begegnet habt? Viele Grüße, Kirill

Hallo Tinkerforge, ich möchte mir ein langes Bricklet Kabel (größer als 3m) konfektionieren. Könntet ihr die passenden Drähte (Querschnitt) dazu empfehlen bzw. welche nimmt ihr bei den Kabeln aus ihrem Shop Angebot? Habt ihr Erfahrung bis zu welcher Länge funktioniert es mit der Kommunikation zwischen Brick und Bricklet? Vielen Dank im Voraus, Kirill

Danke für den Tipp. Ich schau mal tatsächlich in die Richtung von NTP oder PTP. Falls Interesse besteht, findest du im Anhang das von mir adoptierte Layout für den Bricklet. silent_stepper_bricklet.pdf

Ich habe mir bereits einen Silent Stepper Bricklet zusammengelötet. Die Ausführung ist dem Silent Stepper Brick ähnlich. Als das MCU habe ich den XMC1400 genommen. Aktuell programmiere ich die für mich passende Schnittstelle. Die ersten Tests habe ich schon hinter mir und der Stepper dreht sich. Diesbezüglich habe ich dann eine nächste Frage . Für meine Ziele möchte ich das auf zwei oder mehrehren Silent Stepper Bricklets die Aufgaben scheduled synchron ablaufen. Dafür sollen die Uhr auf allen Bricklets auch synchron ticken. Hast du eine Idee wie man so was realisieren könnte?

Danke für die schnelle Antwort. Wie gesagt, ich benutze aktuell meine Lösung. Somit ist die Frage erstmal nicht akut. Theoretisch könnte man einen Extension Brick auf der Basis eines Omega2 bauen (in der konstruktiven Ausführung ähnlich zu der WiFi Erweiterung). Bei der Omega2 hat man Linux + WiFi. Falls ich mich richtig erinnere: alles circa für 15 Euro bei Amazon. Ist die Roadmap irgendwo veröffentlich? Da ich manchmal die Sachen, die mir bei den bestehenden Bricklets und Schnittstellen fehlen, selbst implementiere, wäre es für mich sinnvoll im Sinne den Rad nicht neue zu entwickelt. Z.B. zurzeit baue ich mir auf der Basis des Silent Stepper Bricks einen Silent Stepper Bricklet. Falls ihr es im kurzfristigen Plan habt, ist die Arbeit dann überflüssig . Gruß, Kirill

Hallo Tinkerforge, ich habe einen Vorschlag für die Erweiterung der C/C++ Schnittstelle bzw. für die Erstellung einer neuen Implementierung. Diese Implementierung soll die Ausführung einer einfachen Logik auf dem Master Brick gewährleisten. Meiner Meinung nach wäre es für die ganz einfache Projekte, die auch robust seien sollen, sehr nutzbar. Ich habe z.B. zwei Pumpen, die in der Abhängigkeit der gemessenen Temperatur eingeschaltet oder ausgeschaltet werden (Aufbau der Steuerungseinheit siehe auf den Bildern unten). Eine Raspberry Pi oder einen RED Brick zu nehmen, wäre für das Problem ein Overkill. Aus diesen Gedanken habe ich die Generatoren der C/C++ Schnittstelle modifiziert, um die Abhängigkeit von dem ip_connection.h zu eliminieren. Die generierten Dateien erhalten somit nur die Strukturdefinitionen und die FIDs und lassen sich in das Projekt des Master Bricks einkompilieren. Zusätzlich sollte die Brickletslogik für die Ausführung auf dem Master Brick programmiert werden. Als letztes kam die Kapselung der Anwendungslogik in einem FreeRTOS Task. Die Frage ist, ob man von euch solche Implementierung erwarten könnte? Auch wäre interessant einen bestimmten Speicherblock für die Anwendungslogik zu reservieren. So könnte man die Logik dem Master Brick aus dem Brickv flashen. Gruß, Kirill

Hallo Theo, danke schön für die Einweisungen. Es hat für das ThermocoupleBricklet 1.0 ohne Probleme nach Paar Minuten geklappt. Kann sein, dass die Konfiguration nicht alle Einstellungen implementiert. Es reicht aber für die meisten Fälle meiner Anwendung. "thermocouple ":{ "bricklet": "BrickletThermocouple", "className": "ThermocoupleBricklet", "brickletConfig": "thermocoupleDeviceConfig", "package": "thermocouple", "deviceType": "thermocouple", "callbackChannels": "false", "hasConfig": "true", "channels": [ { "id": "temperature", "baseName": "Temperature", "externalDevice": "false", "callbackChannel": "true", "actuator": "false", "hasConfig": "true", //TODO i2cMode "thresholdSupport": "false", "callbackPeriodSupport": "true", "field": "temperatureChannel", "sensorValueType": "int", "valueType": "DecimalValue", "callbackMethod": "temperature", "getterMethod": "getTemperature()", "valueConverter": "Tools.calculate100(", "ohchannelid": "temperature", "ohunit": "SIUnits.CELSIUS" } ] }, Viele Grüße, Kirill

Hallo Theo, findet man das Projekt unter deinen Repositories? Falls man für die fehlenden Bricklets selbst die Bindings realisieren möchte. Viele Grüße, Kirill

Hallo Bastian, es hat funktioniert . Danke! Viele Grüße, Kirill

Hallo Tinkerforge: bezüglich der Entwicklung eines Bricklets habe ich nächste Fragen: - Das Timeout für das BMI “ASC BSL with timeout” ist standartmäßig auf 333 ms eingestellt. Hat es einen Grund? Die Frage kommt, weil für mich war nicht so einfach in der gegebenen Zeit das MCU für das neue Bootstraper Flashen ansprechen zu können 😊. Deswegen sollte ich das Timeout auf 1 s stellen. - Wie kann man die entwickelte Firmare debuggen (log-Ausgabe)? Wie macht ihr das? Über den dafür vorgesehen Debug Pin? Viele Grüße, Kirill

Eigentlich schade. Ich sehe schon, dass immer wieder in den alten Themen die Ideen einen 3D Drucker, eine Fräse oder einen Laser Engraver auf der Tinkerforge Basis zu bauen vorkommen. Kirill

Danke! dann habe ich einen USB/TTL Konverter nicht umsonst bestellt. Kirill

Hallo Tinkerforge, habt ihr keine zukünftigen Pläne einen Bausatz oder eine Steuerungseinheit mit einer Firmware für 3D Drucker anzubieten (z.B. wie https://github.com/Smoothieware)? Ich glaube, da das Community von 3D Druck ziemlich groß ist, kann es potenziell einen großen Markt für euch eröffnen? Kirill

Hallo zusammen, verstehe ich es richtig, dass wenn man ein eigenes Bricklet auf der Basis von XMC1x00 bastelt, soll man das jungfräuliche MCU über die serielle Schnittstelle mit dem Bootstrapper flashen? Und erst dann ist man in der Lage die eigene Firmware auf das Bricklet über den Brickv aufspielen? Danke, Kirill

Wenn wir bei der Lösung bleiben, bei welcher wir 50% Speicher für den eigenen Bootloader verwenden, könnte man erwarten, dass ihr sich in der Zukunft für die SAM4S Prozessoren entscheidet mit 1024Kb oder 2x1024Kb Flash? Dann wird das Thema "Over The Air" doch mehr realistischer? Verstehe ich richtig, dass die SAM4S Prozessoren "pin to pin" zu der SAM3S Serie identisch sind und man könnte durch einfaches umlöten und Anpassen der Software ein Brick upgraden?