borg

The new servers with the new homepage are now finally online. The new DNS entry should be known by all of the nameservers by now too. If you find bugs, dead links or you have improvement suggestions please tell us here .

So, die neuen Server mit der neuen Homepage sind jetzt endlich online. Der neue DNS Eintrag sollte sich auch bei allen Nameservern bereits herumgesprochen haben. Bugs, tote Links und Verbesserungsvorschläge bitte in diesen Thread .

The microcontrollers are indeed a little bit more expensive then the EEPROM (which they replace). We currently plan to use the XMC1X00 series industrial MCUs from Infinion for most Bricklets. Modern cortex-m0 micros are probably less expensive then you expect, see here for an idea about the price: http://www.mouser.de/ProductDetail/Infineon-Technologies/XMC1100Q024F0064ABXUMA1/?qs=sGAEpiMZZMuoKKEcg8mMKKywyJ6nXWno8US%2fnU9Cn6GgzMDTUpM3rw%3d%3d

Da sehe ich aktuell kein Problem, die Nase des GH Steckers lässt sich wirklich einfach runterdrücken, viel angenehmer als die SH Stecker. Da wir Stromversorgungen auf den Bricklets vermeiden wollen benötigen wir 5V/GND/3.3V Für die Datenleitungen kommt nur etwas in Frage, das wir per DMA sprechen können und einen Durchsatz von 1000 Nachrichten mit ~80 Byte (64 Byte + Header) pro Sekunde bei 4 Seriell angesprochenen Bricklets erlaubt. Da RS485 oder andere differentielle Schnittstellen zu teuer sind für die kleinen Bricklets bleibt eigentlich nur noch I2C und SPI über. Bei den Datenraten die wir benötigen ist SPI stabiler. Daher die 4 weiteren Leitungen. Wir haben ein eigenes Protokoll für die Co-Prozessor Bricklets, siehe oberster Kommentar hier: https://github.com/Tinkerforge/brickletboot_xmc/blob/master/software/src/bootloader_spitfp.c Grundsätzlich dazu: Die Firmwares auf den Bricklets sind nur kompatibel zu den SAM3/SAM4 MCUs von Atmel. Auf Grund von politischen Änderungen bei Atmel müssen wir aktuell davon ausgehen, dass es für die SAM3/SAM4 Reihe keine Langzeitverfügbarkeit geben wird, wie man es vielleicht von den AVRs kennt. Daher ist ein Umstieg zu einer Lösung mit definiertem Protokoll zwischen Brick und Bricklet alternativlos und bringt auch gleich noch viele andere Vorteile mit. Es braucht sich aber keiner Sorgen zu machen das er irgendwann ein älteres Bricklet nicht mehr ansprechen kann, wir haben kein Problem damit uns nochmal 1000 Master Bricks auf Lager zu legen nachdem wir alle Bricklets umgestellt haben. Die alten Bricks werden immer kompatibel zu den neuen Bricks im Stack sein. Daher kann man das beliebig mischen. So etwas wie Micro-USB, was nicht schon für einen anderen Standard vorgesehen ist und wofür wir günstig Kabel herstellen lassen können gibt es aber leider nicht . Mal davon abgesehen das USB Kabel für Bricklets ziemlich klobig wären.

New homepage and server infrastructure Blog Entry

Neue Homepage und Serverinfrastruktur Blogeintrag

So your fear is that in 3.5 years one of the old Master Bricks breaks and you can't get them anymore so you would have to replace the cables? I don't think this will be a problem, we will still sell Master Bricks that are compatible to the old generation of Bricklets as long as we can get the parts.

SH (alt, http://www.jst-mfg.com/product/pdf/eng/eSH.pdf): Tiefe 4.25mm Höhe 2.95mm Breite 12mm GH (neu, http://www.jst-mfg.com/product/pdf/eng/eGH.pdf): Tiefe 4.05mm Höhe 4.35mm Breite 12mm

I think you may have misunderstood the changes. There is a complete compatibility between the old and new generation of Bricklets during the three years. There are also two different things: There is the switch from "dumb Bricklets" to "Bricklets with co-processor" and there is the switch from 10-pole to 7-pole. The switch from dumb to co-processor Bricklets is necessary, there is really no other viable option. But from a user perspective you won't even notice this. The API and how it is used etc stays the same. If we don't change the connector you won't even notice a difference. The connector change is something for better usability and it is a difference that the user will notice (albeit a small difference). That is why we asked about it. Edit: I added the sentence "In both scenarios the old Bricklets and the Bricklets of the new generation are completely compatible to each other and the old Bricks." to the blog entry and poll to make it more clear !

Das ist der Langzeitplan, ja! Aber wir können die Bricks natürlich erst mit den neuen Steckern ausstatten wenn wir die Bricklets komplett umgestellt haben. Daher wird das ein wenig dauern bis es soweit ist.

Die API wird für den Nutzer gleich bleiben. Da wir die API jetzt einmal für alle Bricklets anfassen, haben wir natürlich die Möglichkeit Verbesserungen durchzuführen und Fehler auszumerzen. Das neue GPS Bricklet bietet z.B. API um an die Position aller Satelliten zu kommen die das GPS Modul gesehen hat und einen Callback für den 1Hz Takt der bei GPS generiert wird. Des weiteren kann es GPS sowie Galileo und du kommst auch an die Satelliten- und Positionsdaten für die Galileo Satelliten. Kann ich mir nicht vorstellen, wenn das die Sorge der Anwender wird, brauchen sie erst gar nicht mit der Programmierung anfangen. U.U. wird es zu Versehen bei der Bestellung kommen, wenn das aber idiotensicher im Shop auswählbar ist, dann kein Problem. Sehe ich Mittlerweile auch so, hat bei uns intern aber zu soviel Diskussion geführt das wir uns dazu entschieden haben einfach die Kunden zu fragen . Bisher ist die Umfrage ja auch ziemlich eindeutig.

Um eine große Auswahl an Sensoren etc nutzen zu können benötigen wir 3.3V, 5V und GND. Dazu haben wir im neuen Standard 4 Leitungen für die Kommunikation. Diese 4 Leitungen sind notwendig um weiterhin 1000 Nachrichten pro Sekunde bei einer maximalen Nachrichtengröße von 64 byte mit vier angeschlossenen Bricklets zu unterstützen. Rein technisch haben wir uns da bereits sehr viele Gedanken gemacht. Ein I2C Bus hätte auch den riesigen Nachteil das wir wieder einen 8m langen Bus bekommen wenn jemand 4x2m Bricklet Kabel verwendet. Angenommen wir wollten über I2C auch den oben angesprochenen Durchsatz erreichen, wären wir weit weg von 400kHz standard I2C. Des weiteren wäre das ein großes Problem bezüglich EMV. CE-Kompatibilität ist bei uns notwendig.

Der Hauptvorteil ist die bessere Usability der Stecker. Das ist in dem Sinne gar nicht festgelegt. Ein neuer Master Brick welcher passende Hardwareeinheiten passende angeschlossen hat könnte durchaus mehrere Bricklets gleichzeitig abfragen. Ein alter Master Brick wird weiterhin round-robin die Bricklets abfragen, allerdings kann das Bricklet in der Zwischenzeit in aller Ruhe Berechnungen machen und z.B. Flanken im MHz-Bereich zählen. Dies ist im alten System einfach nicht möglich. Das ist aber unabhängig vom verwendeten Kabel. Wir hätten gerne eine kleinstmögliche standardisierte Schnittstelle. Das spricht gegen 3 Leitungen die in den meisten Fällen nicht genutzt werden. Rein technisch macht das auch keinen Sinn, da die 3 Leitungen die wegfallen als Bus über alle 4 Brickletanschlüsse gemeinsam genutzt werden (I2C). Das I2C wird aktuell zum auslesen der EEPROMs genutzt, dies brauchen wir mit Co-Prozessor natürlich nicht mehr. Dadurch versprechen wir uns auch eine Steigerung an Stabilität, da ein Brick mit vier angeschlossenen 2m Kabel keinen 8m langen Bus mehr aufbaut! Das ändert technisch gar nichts. Wenn wir bei dem alten Stecker bleiben werden 3 Leitungen einfach für immer ungenutzt bleiben.

Detaillierte Erklärung zur Umfrage: Siehe Blogeintrag Zusammenfassung: Auf Grund einer Änderung in der Funktionsweise von Bricklets haben wir die Möglichkeit auf neue, benutzerfreundlichere Bricklet-Stecker umzusteigen. Dabei sehen wir diese zwei Szenarios: Szenario 1 * Die Stecker bleiben so wie sie sind für alle Module. * Es gibt die normalen 10-Pol zu 10-Pol Bricklet-Kabel für die alte sowie neue Bricklet Generation. Szenario 2 * Die Stecker auf den neuen Co-Prozessor Bricklets sind 7-Pol JST GH. * Es gibt zwei Bricklet-Kabel-Varianten: 10-Pol zu 10-Pol für alte Bricklets und 10-Pol zu 7-Pol für die neue Bricklet Generation. * Nachdem alle Bricklets umgestellt sind (vielleicht in 3 Jahren) können die Stecker auf den Bricks auch auf 7-Pol umgestellt werden. * Danach gibt es dann nur noch 7-Pol zu 7-Pol Bricklet-Kabel. In beiden Szenarien sind die alten Bricklets und die Bricklets der neuen Generation komplett kompatibel zueinander und zu den alten Bricks. Was würdet ihr vorziehen?

A detailed description of the poll can be read in the blog. Summary: Because of changes in the functionality of Bricklets we will be able to change the current connector to a new one that is more user friendly. We see two possible scenarios: Scenario 1 * The connectors remain the same for all of the building blocks. * The normal 10-pole to 10-pole Bricklet cable is compatible to the new and old generation of Bricklets. Scenario 2 * The connector on the new co-processor Bricklets is a 7-pole JST GH. * There are two Bricklet cable variants: 10-pole to 10-pole for the old Bricklets and 10-pole to 7-pole for the new generation of Bricklets. * After all Bricklets are converted (perhaps in 3 years) we will be able to change the connectors of the Bricks to the new 7-pol variant. * After that we only need 7-pole to 7-pole cables for the whole system. In both scenarios the old Bricklets and the Bricklets of the new generation are completely compatible to each other and the old Bricks. What do you prefer?

I already added the API in the Motion Detector source code, will be available with the next Bindings release. https://github.com/Tinkerforge/motion-detector-bricklet/commit/f327f00f01dafd6a01bc4bc704b49e686aea94bb

Rückblick auf 2016 Blogeintrag

Looking back at 2016 Blog Entry

Plugin: RS232 Bricklet 2.0.3 Fix Bug with baudrates below 4800 baud Change RESET beahvior to be compatible with new hardware version Plugin: Motion Detector Bricklet 2.0.1 Add API to turn status LED permantenly on/off Download: RS232 Bricklet, Motion Detector Bricklet

Plugin: RS232 Bricklet 2.0.3 Fix Bug mit Baudraten kleiner als 4800 Baud Ändere RESET-Verhalten um Kompatibilität mit neuer Hardware Version herzustellen Plugin: Motion Detector Bricklet 2.0.1 Füge API zum permanenten an/ausschalten der Status LED hinzu Download: RS232 Bricklet, Motion Detector Bricklet

Alles klar, gucke ich mir dann an wenn sie hier ankommen. Ich bin gespannt!

For the Master Brick there is a disable_wifi2_status_led() as well as a disable_status_led() function. For the Motion Detector Bricklet we currently don't have such an API. I will write in on my TODO list, adding this API is not a huge amount of work. edit: Translated to English, accidentally answered in German .

http://www.tinkerunity.org/forum/index.php/topic,673.msg22745.html#msg22745

Kannst du dir mal die Bricklet Stecker vom Master Brick und von den Bricklets angucken? Ist da vielleicht irgendwo einer der Pinne krumm o.ä und verursacht einen Kurzschluss? Mein Test den ich hier gestartet hatte (mit 4x Temp IR) läuft jetzt seit über einer Woche durch .

mh, passt die UID? Eine falsche UID würde am einfachsten erklären warum es nicht funktioniert. Da du nur einen Setter aufrufst würdest du auch keine Fehlermeldung bekommen.