borg

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. firmware_master_brick_2.0.6-beta1.bin

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 .

Wow

Die Änderung ist schon im git: https://github.com/Tinkerforge/temperature-bricklet/commit/297302349d14c347b9f85e7f6013227a3d1f255e Ist nur noch nicht veröffentlicht weil die neuen Binding Versionen noch nicht raus sind (gibt ja neue API dafür). Bei den Bindings fügen wir gerade noch Funktionalität hinzu um schneller WIFI disconnects zu erkennen, da fehlen aber nur noch zwei sprachen. Ich denke das ist aber dann am Dienstag soweit.

Wir haben noch keine Antwort, die Mühlen mahlen da bei sowas leider langsam . Wir sind noch dran, es gibt zumindest die Möglichkeit das wir händisch eine leere Nachricht rausschicken, wenn nach kurzer Zeit einer Anfrage keine Antwort rausgeht. Also immer wenn eine Nachricht reinkommt wird ein 10ms Timer gestartet. Wenn eine Nachricht rausgeht wird dieser Timer gestoppt (mit der rausgehenden Nachricht wird ja auch ein ACK geschickt). Falls der Timer bei 0 ankommt schicken wir eine Dummy-Nachricht raus, um ein das ACK zu erzwingen. Damit wären dann in deinem Fall die 200ms Wartezeit auf 10ms verringert worden, dafür werden aber "unnötige" Daten geschickt (aber halt auch nur wenn sowieso keine Daten rausgehen). Das IC was wir für die Ethernet Extension verwenden ist sehr low-level verglichen mit dem WIFI Modul. Dadurch gibt es diese Probleme gar nicht (wir haben das sozusagen selbst in der Hand). Da können keine Buffer voll laufen, da dem PC die Größe des Buffers mit der TCP window size mitgeteilt wird, wie es gedacht ist. Das hat natürlich auch nachteile, ich musste z.B. für die Ethernet Extension selbst einen DHCP Client implementieren, das war ganz schön aufwendig. Bei dem WIFI Modul ist die API einfach beschissen. Es ist so, dass mit jedem Byte was wir rausschicken wir auch gleichzeitig eins empfangen. Da kann man nichts gegen machen. Wenn jetzt viele Nachrichten intern generiert werden (z.B. die Reached Callbacks vom Servo) und wir so viele Daten von extern bekommen, das in jeder ms neue Daten zum auslesen da sind, dann brauchen wir die Buffer. In dem Fall ist es nämlich so, das wir z.B. 20 ausgehende Bytes generieren, die eingehenden Paket haben aber nur die Größe 10. Nun können wir aber nur ein Paket gleichzeitig behandeln, d.h. wir müssen 10 Byte Buffern damit wir das 20 Byte Paket überhaupt rausschicken können. Wenn der Buffer voll läuft müssen wir anfangen die ausgehenden Pakete wegzuwerfen. Total bekloppt . Aber das hat nichts mit dem delayed ACK zu tun, wodurch du im Moment diese 5hz siehst.

I think we will add a watchdog feature for the next Master Brick Firmware release. We currently have not agreed internally if the watchdog should be on or off by default, we will have to discuss that again tomorrow.

Each Brick runs the code for his Bricklets. A Brick can be in SPI Master Mode (The bottom Master Brick) and in SPI Slave Mode. The SPI Master builds a routing table of UID<->Stack height/RS485 address/Chibi address. On the basis of this routing table the SPI Master can route messages to the correct Brick. This is the part of the firmware that changed in Protocol V2. In V1 the routing table was create once on startup, that worked fine with USB but had problems with RS485/WIFI. Now the routing table is created dynamically, if the Master doesn't know a UID the packet is just broadcasted. This can mean that the system is a little bit slower for the first few seconds, but that is well worth the other advantages.

Das ist leider nicht ganz so einfach. Wenn es nur eine "Kaufzusage" ist, ohne das wirklich Geld fließt, ist die Chance zu hoch das ein Großteil der "Käufer" dann am Ende doch abspringen. Bei der Kaufzusage Geld nehmen und erstmal behalten und das Geld wieder zurück überweisen falls eine gewisse Anzahl nicht erreicht wird ist in Deutschland nicht so einfach legal zu machen. Was vermutlich auch der Grund ist warum es Kickstarter noch nicht für Deutschland gibt. Vorbestellungen mit einem festen Termin für Produkte die bereits in Produktion sind oder einen festen Produktionstermin haben, haben wir ja schon ein paar mal gemacht und machen wir auch grundsätzlich für ausverkaufte Produkte .

Die Ethernet Extension wird absolut stabil sein. Dort wird es keinerlei Verbindungsprobleme geben, versprochen . Wir testen da jetzt schon seit Monaten dran rum um das sicherzustellen. Das hier angesprochene delayed ACK "Problem" gibt es bei der Ethernet Extension auch nicht, dort kann man delayed ACKs nämlich ausstellen .