borg Geschrieben January 10, 2017 at 11:05 Geschrieben January 10, 2017 at 11:05 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? Zitieren
batti Geschrieben January 10, 2017 at 12:52 Geschrieben January 10, 2017 at 12:52 Gerne könnt ihr auch etwas dazu schreiben was euer Grund für die Entscheidung gegen oder für einen neuen Stecker ist. Zitieren
Nic Geschrieben January 10, 2017 at 13:39 Geschrieben January 10, 2017 at 13:39 Sehr interressant, dass habe ich mir schon gedacht, d.h. solche Extra-Platinen wie in http://www.tinkerunity.org/forum/index.php/topic,3701.msg23448.html#msg23448 beschrieben, wären dann eher möglich? Ich verstehe allerdings noch nicht ganz - neben dem Benefit Unabh. vom Prozessor, und 7poligen Stecker - den Vorteil innerhalb der TF Architektur. Wenn die neuen Bricklets einen eigenen Copo haben, wie kommuniziert der Bricklet mit seinem Brick, und wie verhält es sich bei 4 Bricklets an einem Brick. Greift der Brick auch wieder im Zeitscheibenprinzip die Ports ab, um zu checken ob eine Datenüb. zum Bricklet erfolgen muss, oder geht das jetzt plain und ohne Zeitverzug durch. Ich könnte mir auch alternativ vorstellen, die von den 10 Polen freigewordenen 3 Leitungen eben für solche "customized" Steuerungen wie direkte Endlagenschalter zu nutzen. Wenn die Bricklets neue Copos und 7polige Stecker bekommen, was bedeutet das für die API die wir in der Anwendungsentw. verwenden? Bedeutet es strukturelle Anpassungen etc? Persönlich ist es mir wurscht ob neue oder alte Stecker, mit den alten hatte ich eig. nie Probleme. Viel wichtiger war und ist mir kompakte, flexible Verbindungskabel, die es es auch erlaubt enge Bauräume zu nutzen. In Grunde sollten solche Stecker/Buchsen bzw. Kabel nicht zu klobig und zu hart zum Biegen sein. Was ich oft vermisst habe sind freie Lötpunkte oder wie z.B. beim RaspberryPi Zero sogen. "Probe Points" PPx..., um enge Verkabelung selbst zu lösen. Yoctopuce stattet alle seine Devices mit kleinen Lötaugen aus, Sensoren oder Displays lassen sich platzsparend von der Hautplatine trennen und wieder verlöten. Zitieren
cschneider Geschrieben January 10, 2017 at 13:50 Geschrieben January 10, 2017 at 13:50 Ich würde ehrlich gesagt, einen noch einfacheren Stecker bevorzugen. Grove verwendet einen 4 poligen Stecker. Damit kann man entweder 2 Analogwerte, zwei Digitalwerte oder i2c übertragen. Mit i2c sollte eine Kommunikation mit co Prozessoren problemlos möglich sein. Im Fall von i2c kann man den Buss dann auch einfach auf mehrere Buchsen ausdehnen. Wäre das vielleicht eine bessere Lösung? Zitieren
borg Geschrieben January 10, 2017 at 13:53 Autor Geschrieben January 10, 2017 at 13:53 Ich verstehe allerdings noch nicht ganz - neben dem Benefit Unabh. vom Prozessor, und 7poligen Stecker - den Vorteil innerhalb der TF Architektur. Der Hauptvorteil ist die bessere Usability der Stecker. Wenn die neuen Bricklets einen eigenen Copo haben, wie kommuniziert der Bricklet mit seinem Brick, und wie verhält es sich bei 4 Bricklets an einem Brick. Greift der Brick auch wieder im Zeitscheibenprinzip die Ports ab, um zu checken ob eine Datenüb. zum Bricklet erfolgen muss, oder geht das jetzt plain und ohne Zeitverzug durch. 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. Ich könnte mir auch alternativ vorstellen, die von den 10 Polen freigewordenen 3 Leitungen eben für solche "customized" Steuerungen wie direkte Endlagenschalter zu nutzen. 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! Wenn die Bricklets neue Copos und 7polige Stecker bekommen, was bedeutet das für die API die wir in der Anwendungsentw. verwenden? Bedeutet es strukturelle Anpassungen etc? Das ändert technisch gar nichts. Wenn wir bei dem alten Stecker bleiben werden 3 Leitungen einfach für immer ungenutzt bleiben. Zitieren
borg Geschrieben January 10, 2017 at 13:58 Autor Geschrieben January 10, 2017 at 13:58 Ich würde ehrlich gesagt, einen noch einfacheren Stecker bevorzugen. Grove verwendet einen 4 poligen Stecker. Damit kann man entweder 2 Analogwerte, zwei Digitalwerte oder i2c übertragen. Mit i2c sollte eine Kommunikation mit co Prozessoren problemlos möglich sein. Im Fall von i2c kann man den Buss dann auch einfach auf mehrere Buchsen ausdehnen. Wäre das vielleicht eine bessere Lösung? 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. Zitieren
batti Geschrieben January 10, 2017 at 14:03 Geschrieben January 10, 2017 at 14:03 Ich würde ehrlich gesagt, einen noch einfacheren Stecker bevorzugen. Grove verwendet einen 4 poligen Stecker. Damit kann man entweder 2 Analogwerte, zwei Digitalwerte oder i2c übertragen. Nicht zu vergessen, dass der Grove Stecker noch um einiges größer ist wie der aktuell vorgeschlagene. Damit wären Bricklets, wie das Temperature Bricklet, von der Größe her nicht möglich. Zitieren
batti Geschrieben January 10, 2017 at 14:10 Geschrieben January 10, 2017 at 14:10 Das Thema dreht sich gerade sehr um technische Details. Eure Ideen sind sehr interessant und wir diskutieren sie gerne mit euch. Unser hauptsächliches anliegen war aber eher auf die Usability bezogen. Unsere größte Sorge ist es, dass ein zweiter Satz Kabel zu Verwirrungen führt. So würde es: * die aktuellen Kabel geben (10pol auf 10pol) * Kabel für die neuen Bricklets geben (10pol auf 7pol) Dies macht das System komplizierter. Der Nutzer muss sich dann Fragen was für ein Kabel brauche ich wann? Was muss ich bestellen etc. Bei den Produkten im Shop würde es in den Drop Down Boxen natürlich nur die passenden Kabel geben. Als Zubehör aber natürlich beide Varianten. Vielleicht ist die Sorge auch unbegründet, aber dies ist bei uns aktuell das größte Problem. Insbesondere weil es diesen Zustand für eine sehr lange Zeit geben wird. Zitieren
Nic Geschrieben January 10, 2017 at 14:23 Geschrieben January 10, 2017 at 14:23 Meine Frage Wenn die Bricklets neue Copos und 7polige Stecker bekommen, was bedeutet das für die API die wir in der Anwendungsentw. verwenden? Bedeutet es strukturelle Anpassungen etc? und neben dem Benefit Unabh. vom Prozessor, und 7poligen Stecker - den Vorteil innerhalb der TF Architektur. bezog sich vordergründig auf die API, die wir als Enkunden verwenden. Also keine zwangsläufigen Anpassungen wenn ich von GPSv1 auf GPSv2 umziehe oder vom alten IO4 auf IO4 mit 7poligen Stecker. Bricklet mit Copo sind aber i.d.R. leistungsfähiger und entlasten den Brick; sie können eigenständig Code ausführen, z.b. Timer, aufwendige Berechnungen, Encodersignale jenseits der 1000hz usw. Unsere größte Sorge ist es, dass ein zweiter Satz Kabel zu Verwirrungen führt. 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. Zitieren
borg Geschrieben January 10, 2017 at 14:47 Autor Geschrieben January 10, 2017 at 14:47 bezog sich vordergründig auf die API, die wir als Enkunden verwenden. Also keine zwangsläufigen Anpassungen wenn ich von GPSv1 auf GPSv2 umziehe oder vom alten IO4 auf IO4 mit 7poligen Stecker. Bricklet mit Copo sind aber i.d.R. leistungsfähiger und entlasten den Brick; sie können eigenständig Code ausführen, z.b. Timer, aufwendige Berechnungen, Encodersignale jenseits der 1000hz usw. 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. Unsere größte Sorge ist es, dass ein zweiter Satz Kabel zu Verwirrungen führt. 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. Zitieren
BorgelMorgel Geschrieben January 10, 2017 at 14:48 Geschrieben January 10, 2017 at 14:48 Einfache Antwort: Mir ist es schon passiert das sich ein Pin verbogen hat und wir haben schon oft lose Kabel an schwingungsempfindlichen Aufbauten beobachtet. Aus diesem Grund kann ich die evtl. Entscheidung für einen neuen Steckertyp, welcher diese Probleme nicht mehr aufweist nur begrüßen. Zitieren
raphael_vogel Geschrieben January 10, 2017 at 15:02 Geschrieben January 10, 2017 at 15:02 Auf jeden Fall neue Stecker. Wenn der Stack in einem engen Gehäuse verbaut ist weiss ich nie wie rum das Kabel reinkommt und ob es komplett drin ist. Zu den technischen Details: So wie ich das verstehe, wird es dann auch abgespecktere (und auch billigere ) Master Bricks geben? Zitieren
borg Geschrieben January 10, 2017 at 15:08 Autor Geschrieben January 10, 2017 at 15:08 Zu den technischen Details: So wie ich das verstehe, wird es dann auch abgespecktere (und auch billigere ) Master Bricks geben? 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. Zitieren
Nic Geschrieben January 10, 2017 at 15:36 Geschrieben January 10, 2017 at 15:36 Wie groß sind die 7poligen Stecker/Buchsen dann letztendlich? Ragt das mehr über die Platinenkante? Zitieren
batti Geschrieben January 10, 2017 at 15:38 Geschrieben January 10, 2017 at 15:38 Die benötigte Fläche auf der Leiterkarte ist identisch (Breite/Tiefe des Steckers). Die Buchse auf der Platine ist nur etwas höher. Daher können wir sie genauso platzieren. Zitieren
borg Geschrieben January 10, 2017 at 15:41 Autor Geschrieben January 10, 2017 at 15:41 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 Zitieren
mchott Geschrieben January 11, 2017 at 11:10 Geschrieben January 11, 2017 at 11:10 Hi .. es freut mich, wenn sich das TFsystem weiter entwickelt. Mir geht es dabei nicht so sehr um die technischen Feinheiten..ich hab eine zweiteilige Meinung. Den Stecker zu ändern endet in dem Chaos, in dem ich täglich festhänge, wenn ich mit USB zutun habe. Es gibt so derart viele unterschiedliche Möglichkeiten von Kabeln, dass ich immer 8 falsche habe. Meinen TF-Baukasten verwende ich wie Lego zum "Spielen" und da stecke ich immer mal was anderes zusammen und das wäre in Zukunft dann eben nicht mehr so toll, weil ich dann neben den immer falschen Längen die immer falschen Kabelenden habe. ABER eine radikale Umstellung wie beim USB-C, also eine Ende vom langen Irrweg, hat auch etwas, denn man kann nicht immer auf einem alten Stand beharren, nur um abwärts kompatibel zu bleiben. Daher wäre eine Umstellung langfristig sinnvoller, weil die Kabel flexibler und handlicher werden. An einer langfristigen Ausrichtung kann den Nutzern von TF ja nur gelegen sein. Die bisherigen Stecker sind fummelig und es kann einiges passieren, aber daran habe ich mich nie gestört. Da wäre eine neue Kantenlänge von 5x5 sehr viel störender, selbst wenn die Stecker dann noch "besser" wären. Und jetzt möchte ich nicht bei TF sitzen und diese Entscheidung fällen. Egal wie die Entscheidung ausfällt sie hat kurz-/langfristige Vor-/Nachteile und da würde ich einfach einen Weg einschlagen, der für TF einen langfristig bedeutsamen Vorteil hat, denn davon profitiere ich als Nutzer letztendlich am Meisten. Zitieren
developer Geschrieben January 11, 2017 at 15:02 Geschrieben January 11, 2017 at 15:02 Weniger Kabel - weniger Bruchmöglichkeiten. Wie stramm sitzen denn die neuen Stecker ? Bei den alten hatte ich immer Angst die zu arg reinzudrücken. Aber Stecker hin oder her - ich freue mich eher auf das was Nic geschrieben hat wenn es denn Wahr ist: "Bricklet mit Copo sind aber i.d.R. leistungsfähiger und entlasten den Brick; sie können eigenständig Code ausführen, z.b. Timer, aufwendige Berechnungen, Encodersignale jenseits der 1000hz usw." Das wird (hoffentlich) neue Möglichkeiten öffnen. Grüsse, Dim Zitieren
photron Geschrieben January 11, 2017 at 15:40 Geschrieben January 11, 2017 at 15:40 Wie stramm sitzen denn die neuen Stecker ? Bei den alten hatte ich immer Angst die zu arg reinzudrücken. Der neue Stecker sitzt in dem Sinne gar nicht stramm, da er einrastet und sich nicht durch strammen Sitz in der Buchse halten muss. Zitieren
Loetkolben Geschrieben January 11, 2017 at 19:17 Geschrieben January 11, 2017 at 19:17 Hallo zusammen, hier meine Anmerkungen/Fragen/Bedenken/Vorschlaege Ich bin gegen Nasen an den Bricklet Steckern, da man bei einem vollen Stabel noch mit Werkzeug hantieren muss um die Nase zu dearretieren. Vorsichtiges ziehen am Kabel (was man normalerweise nicht macht) ist perfekt fuer die aktuellen Brickletstecker. Wieso 7 Leitungen? Ich koennte mir auch nur 3 Leitungen vorstellen, da doch auf der Schnittstelle ein eigenes Protokoll gefahren werden kann oder MUSS? Ich wuensche mir ein eigenes Protokoll zwischen Brick und Bricklet, damit man auch mal 10m lange Sensoren machen kann. Natuerlich muss die Uebertragungsgeschwindigkeit dann angepasst werden, aber fuer Wettersensoren reicht langsames auslesen. Ein OLED kann man so nicht ansteuern. Bei 7poligen Kabeln wird man mit neuen Bricks nur noch die neuen Bricklets ansteuern koennen, da I2C ja fehlt,oder? Da kaemen doch dann 7pol-7pol Kabel zum Einsatz. (Noch eine Kabelvariante) Wenn man generell bei 10 poligen Kabeln bleiben wuerde, wuerde dann bei neuen Bricks noch I2C unterstuetzt werden fuer alte Bricklets? Mein Wunsch aus dem Bauch zu neuen Kabeln waere, dass sie duenn und rund sind, wie ein ein Headsetkabel und als Stecker so etwas wie einen Microusb Stecker haben. Diese parallelen Draehte empfinde ich als unbequem. Und wenn schon einzelne Draehte, dann so wenig wie moeglich. Anbei noch 2 ebay Angebote A und B um zu zeigen welche Stecker man ggf. auch nehmen kann, wobei die immer schwer abzuziehen sind, da sie dafuer nicht ausgelegt sind. Nur mal in den Raum gefragt: Kann man sich auch so was vorstellen? Neue Bricklets nur noch an neuen Bricks mit 3 poligem Kabel. Masterbrick 3.0 wird 2 neue und 2 alte Ports haben. Masterbrick 4.0 nur noch 6 neue Ports. Soweit erstmal. Der Loetkolben Zitieren
Unexpected Geschrieben January 11, 2017 at 20:18 Geschrieben January 11, 2017 at 20:18 Klasse, dass ihr (wie bereits positiv gewohnt) die Community mit einbindet und euch Feedback einholt. Wenn eure Dokumentation weiterhin so gut ist, wie sie es derzeit ist und schon lange war, sehe ich kein Problem darin, den Usern die richtige Verwendung der Kabel darzustellen. Mir selbst ist es leider auch schon ab und an passiert, dass Pins verbogen waren oder man sich nicht sicher war, wie fest die Verbindung nun wirklich ist. Besonders wenn man viel „bastelt“ werden die Verbindungen irgendwann sehr lose. Und ein beruhigendes „klick“ wäre für die Haptik super (oder ähnliche Varianten mit einem Feedback oder gleichbleibender Passung). Daher stimmte ich klar für eine Umstellung der Stecker und Buchsen. Viele Grüße Unex Zitieren
borg Geschrieben January 11, 2017 at 21:21 Autor Geschrieben January 11, 2017 at 21:21 Ich bin gegen Nasen an den Bricklet Steckern, da man bei einem vollen Stabel noch mit Werkzeug hantieren muss um die Nase zu dearretieren. Vorsichtiges ziehen am Kabel (was man normalerweise nicht macht) ist perfekt fuer die aktuellen Brickletstecker. Da sehe ich aktuell kein Problem, die Nase des GH Steckers lässt sich wirklich einfach runterdrücken, viel angenehmer als die SH Stecker. Wieso 7 Leitungen? Ich koennte mir auch nur 3 Leitungen vorstellen, da doch auf der Schnittstelle ein eigenes Protokoll gefahren werden kann oder MUSS? 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. Ich wuensche mir ein eigenes Protokoll zwischen Brick und Bricklet, damit man auch mal 10m lange Sensoren machen kann. Natuerlich muss die Uebertragungsgeschwindigkeit dann angepasst werden, aber fuer Wettersensoren reicht langsames auslesen. Ein OLED kann man so nicht ansteuern. 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 Bei 7poligen Kabeln wird man mit neuen Bricks nur noch die neuen Bricklets ansteuern koennen, da I2C ja fehlt,oder? Da kaemen doch dann 7pol-7pol Kabel zum Einsatz. (Noch eine Kabelvariante) Wenn man generell bei 10 poligen Kabeln bleiben wuerde, wuerde dann bei neuen Bricks noch I2C unterstuetzt werden fuer alte Bricklets? 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. Mein Wunsch aus dem Bauch zu neuen Kabeln waere, dass sie duenn und rund sind, wie ein ein Headsetkabel und als Stecker so etwas wie einen Microusb Stecker haben. Diese parallelen Draehte empfinde ich als unbequem. Und wenn schon einzelne Draehte, dann so wenig wie moeglich. Anbei noch 2 ebay Angebote A und B um zu zeigen welche Stecker man ggf. auch nehmen kann, wobei die immer schwer abzuziehen sind, da sie dafuer nicht ausgelegt sind. 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. Zitieren
Loetkolben Geschrieben January 12, 2017 at 00:25 Geschrieben January 12, 2017 at 00:25 Hallo borg, erstmal danke fuer die Informationen und Antworten. Nur eine kurze Anmerkung. Natuerlich braucht ihr ein schnelles Interface zwischen Brick und Bricklets (gerne SPI), ABER man sollte die Geschwindigkeit pro Port so weit drosseln koennen, dass man auch "Long Distance" Bricklets ermoeglichen kann. Der Loetkolben Zitieren
photron Geschrieben January 12, 2017 at 10:41 Geschrieben January 12, 2017 at 10:41 Loetkolben, die Geschwindigkeit wird pro Port einstellbar sein. Zusätzlich wird es auch Error Counter geben mit denen du die Qualität der Kommunikation zwischen Brick und Bricklet bestimmen kannst. Zitieren
Loetkolben Geschrieben January 13, 2017 at 01:46 Geschrieben January 13, 2017 at 01:46 Danke, ich leg mich wieder hin. Der Loetkolben. Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.