borg

Da kann ich dir nicht zustimmen . Der Source Code ist ja an der Stelle für beide gleich. Eine Enumeration wird losgeschickt wenn das erste mal eine Verbindung zum PC aufgebaut wird. Da wird nicht zwischen Wi-Fi und USB unterschieden. Das in einem Fall der Stapel schon bestromt ist und im anderen nicht hat damit gar nichts zu tun.

Sie verhalten sich gleich. Starte einen Brick Daemon, verbinde dich darauf und steck dann das Brick per USB an -> Du bekommst ein Enumerate. Das gleiche passiert bei der WIFI Extension: Wenn du dich mit der WIFI Extension das erste mal verbindest ist das äquivalent zum einstecken per USB.

Was verwenden die beiden PCs denn für eine CPU?

Kann man erhöhen: http://www.tinkerforge.com/de/doc/Software/IPConnection_Python.html#IPConnection.set_timeout

Ich glaube die KiCad Bauteilenamen sind schon das was am ehesten an eine BOM herankommt. Wenn dir spezifische Bauteile nicht klar sind frag einfach nach. Die Stecker werden zum Teil spezifisch für uns hergestellt, die gibt es dafür aber auch bei uns im Shop zu kaufen. So eine BOM mit DigiKey Artikelnummer oder so (zum direkt selber Bestellen) haben wir leider nicht. Dafür kaufen wir auch bei zu vielen unterschiedlichen Distributoren ein.

Du hast recht! Da ist in der Tat ein Fehler in der Dokumentation, fixen wir gleich . Danke für den Hinweis.

I will add a sentence somewhere, but there is not much to it. If the "tick task" is not called once in 16 seconds, the Brick will restart (the tick task is normally called every ms).

Die .deb entpacken und main.py ausführen müsste eigentlich gehen, ich wüsste nicht was dagegen spricht. Ansonsten kannst du dir die unterschiedlichen Versionen einfach aus dem git clonen und in dem checkout die main.py ausführen, das geht auf jeden Fall. Dazu musst du dann aber einmal die build_all_ui.py ausführen, damit er die GUI Elemente generiert. Dafür brauchst du das pyqt-tools Paket.

Hat mit diesem Thread zu tun: http://www.tinkerunity.org/forum/index.php/topic,1526.msg10100.html#msg10100 Der Watchdog startet den Brick neu wenn 16 Sekunden lang die "tick task" nicht mehr ausgeführt wurde (läuft normalerweise 1x pro ms). Das sollte auch noch funktionieren wenn es einen Hard Fault o.ä. gab. Das einzige Problem ist das man Bugs die nur alle paar Wochen auftreten dann evtl. gar nicht mehr mitbekommt, zumindest wenn das Steuerprogramm robust geschrieben ist. Aber ein sinnvolles Feature ist es auf alle Fälle.

Firmwares: DC Brick 2.0.1, IMU Brick 2.0.1, Master Brick 2.0.6, Servo Brick 2.0.2, Stepper Brick 2.0.2 "forced ACK" nach 10ms ohne Antwort hinzugefügt (für schnellere WIFI Extension Reaktion). Watchdog Timer hinzugefügt (Neustart nach 16s "deadlock"). Download Firmwares: DC Brick, IMU Brick, Master Brick, Servo Brick, Stepper Brick

Firmwares: DC Brick 2.0.1, IMU Brick 2.0.1, Master Brick 2.0.6, Servo Brick 2.0.2, Stepper Brick 2.0.2 Add forced ACK after 10ms without answer (for faster WIFI Extension response). Add watchdog timer (restart after 16s of "deadlock"). Download Firmware: DC Brick, IMU Brick, Master Brick, Servo Brick, Stepper Brick

Soooo, ich hab schlechte Nachrichten . Wir können die Encoder Bricklet Hardware die wir hier haben leider nicht verwenden. Es gibt da leider zwei Problemchen. * Das ganze ist mechanisch nicht ausgereift. Die eigentliche Lichtschranke direkt auf die Leiterplatte zu setzen ist definitiv keine gute Idee, wir hatten ziemliche Probleme das in unserem Beispielaufbau vernünftig anzubringen * Der Encoder den wir auf dem Bricklet haben, hat einen zu kleinen Abstand zwischen den Lichtschranken. Obwohl wir mit einer Frequenz von 10kHz abgefragt haben, konnte ich nur eine Drehzahl von ~1200rpm erreichen. Wir haben uns beratschlagt und sind zum Schluss gekommen, das ein Zähler auf dem Bricklet selbst doch die beste Lösung ist (wie von FlyingDoc vorgeschlagen). Dadurch ist das Encoder Bricklet jetzt leider erst wieder ein ganzes Stück nach hinten gerutscht, wir haben jetzt in nächster Zeit erst einen ganzen Schwung anderer neuer Hardware. Die Arbeit die da bisher reingeflossen ist, geht aber natürlich nicht verloren. Ich hab den ganzen Code erstmal auskommentiert mit ins git eingecheckt: https://github.com/Tinkerforge/bricklib/commit/ea9fa7e221b2d9eb2f4f0ceac81942a9b5e43d39 https://github.com/Tinkerforge/dc-brick/commit/6a1f82b3bdd9cb9d6ed6ab5e7ffd17320cdf77bc https://github.com/Tinkerforge/generators/commit/bddf195c9098607d982f5801ccd5c40150063ee7 Tut mir leid dass das nichts geworden ist, aber es bringt nichts wenn wir unausgereifte Hardware veröffentlichen mit der wir hier noch nicht einmal vernünftige Ergebnisse erzielen können .

Du musst die config.h anpassen, einige der Schnittstellen (I2C, SPI usw) werden auf anderen Pinnen liegen. Ansonsten ist dort auch die CPU Geschwindigkeit angegeben, der 3X macht glaube ich 96MHz (im Vergleich zu 64MHz). D.h. auch die Konfiguration vom PLL musst angepasst werden (board_lowlevel.c). Der Rest dürfte auf beiden SAM3 direkt laufen.

also: lcd.write_line(3, 0, 'T: ' + str(round(temperature,0)) + chr( + 'C')

Wie ist das denn aufgebaut, kann es sein das du irgendwie mechanisch zwei Bricks oder so zusammen drückst und dadurch einen Kurzschluss machst?

Ist nicht persistent, muss bei jedem start gemacht werden (also mit in die Initialisierung packen).

Was ein Krampf . Also GainSpan konnte uns da nicht wirklich weiterhelfen. Es gibt undokumentierte Möglichkeiten an den Timeouts rumzustellen, allerdings wurde dadurch die Firmware instabil. Wir hatten ständig disassociation Events. Ich habe jetzt einen 10ms Timer eingebaut der bei eingehenden Nachrichten (neu-)gestartet wird. Eine ausgehende Nachricht stoppt den Timer. Wenn der Timer bei 0 ankommt, wird eine Dummy Nachricht rausgeschickt die das Zurücksenden eines ACKs erzwingt. Dadurch ist aus deinem 5Hz Ruckeln jetzt ein "100Hz Ruckeln" geworden. Rein akustisch klingt ein Servo mit deinem Programm jetzt genauso wie wenn es über USB betrieben wird. Wenn es zwischendurch Ruckler gibt kommen die durch TCP/IP retransmits. Das kannst du sehr schön in Wireshark sehen, immer wenn es ruckelt laufen in Wireshark rote spalten (retransmit oder duplizierte Nachricht) durch. Dagegen können wir natürlich nichts machen, die Daten gehen nunmal über die Luftschnittstelle. Da geht schonmal was verloren und muss neu geschickt werden . Im Anhang ist eine beta der neuen Master Firmware. Edit: Veraltete Firmware entfernt.

setDefaultText muss bei jedem Start aufgerufen werden (ist nicht persistent).

Also prinzipiell müsstest du das GP2Y0A710K0F ans Distance IR Bricklet anschließen können. Allerdings hat es weder die Löcher an den Seiten noch den gleichen Stecker. D.h. du müsstest das irgendwie selbst passend anlöten. Dann musst du dir noch ein eigene "Spannung/Distanz Abbildung" erstellen (oder direkt mit den analogen Werten arbeiten), das ist aber nicht schwierig: http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Distance_IR.html#spannung-distanz-abbildung

Das ist im LCD fest verdrahtet, das ist keine softwareseitige Zuteilung oder sowas. Diese alphanumerischen LCDs sind aber alle so verdrahtet. Ich vermute das man damit theoretisch jeweils die erste und zweite sowie die dritte und vierte Zeile gleichzeitig schreiben kann (da sie je auf zwei Treiber verteilt sind). Naja die Lösung wäre jeweils den letzten Buchstaben in der Zeile zu überschreiben, wo danach der Cursor dann an der "richtigen" Stelle steht. Also wenn Buchstabe 20 in Zeile 2 geschrieben wird, würden wir danach nochmal Buchstabe 20 in Zeile 1 überschreiben, damit der Cursor danach in Zeile 3 steht. Ich hab es mir auf die TODO Liste geschrieben. Ich befürchte dafür müssten wir uns entweder den geschriebenen Text merken oder wieder auslesen, beides wird im Moment nicht getan und passt vermutlich nicht mehr auf das EEPROM. Da sind beim LCD Plugin nur noch ein paar Byte frei .

Die neue Firmware ist jetzt online. Es gibt jetzt neue API für setI2CMode und getI2CMode in Firmware Version 2.0.1 .

Neue Firmware mit "LCD Monoflop" ist jetzt online. Firmware Version 2.0.2 hat jetzt die zusätzlichen funktionen setDefaultText, getDefaultText, setDefaultTextCounter und getDefaultTextCounter. Mit setDefaultText kann der Ausfall-Text gesetzt werden und mit setDefaultTextCounter kann ein Counter gesetzt werden der den default text auf dem LCD anzeigt sobald er abläuft. Du müsstest jetzt also z.B. den Counter alle 5 Minuten auf 10*60*1000 setzen (10 Minuten). Dann stellst du sicher das der Text nicht angezeigt wird solange eine Verbindung da ist, wenn allerdings keine Verbindung mehr da ist wird spätestens nach 10 Minuten der Default Text angezeigt .

Firmwares: Servo Brick 2.0.1 Plugins: LCD20x4 Bricklet 2.0.2, Temperature Bricklet 2.0.1 Enable/Disable API für "reached callbacks" hinzugefügt (Servo Brick) Standardtext Funktionalität (LCD20x4 Bricklet) I2C Mode-Switch API (100KHz/400KHz) (Temperature Bricklet) Download Firmware: Servo Brick Download Plugin: LCD20x4 Bricklet, Temperature Bricklet

Firmwares: Servo Brick 2.0.1 Plugins: LCD20x4 Bricklet 2.0.2, Temperature Bricklet 2.0.1 Add enable/disable API for reached callbacks (Servo Brick) Add default text functionality (LCD20x4 Bricklet) Add I2C Mode switch API (100KHz/400KHz) (Temperature Bricklet) Download Firmware: Servo Brick Download Plugin: LCD20x4 Bricklet, Temperature Bricklet

Ja, das ist ein bisschen verwirrend, können wir aber nichts gegen machen. Auf dem LCD sind zwei treiber für je zwei Zeilen. Dabei gehören die Zeilen 0 und 2 sowie 1 und 3 zu je einem Treiber. D.h. er springt von Zeile 2 nach 0 (Treiber 1), von 0 aber nach 3 (von Treiber 1 nach Treiber 2). von 3 springt er nach 1 (Treiber 2) und von 1 wieder zurück nach 2 (von Treiber 2 nach Treiber 1). Das sollten wir Dokumentieren, die Frage ist nur wie man das macht ohne totale Verwirrung zu stiften .