borg

Das ist ein guter Einwand, im Moment geht die Konfiguration verloren. Ich kann die Einstellung allerdings wieder herstellen. Baue ich in die nächste Master Brick Firmware mit ein .

Firmwares: Master Brick 2.0.4 Reset WIFI Modul nach Disassociation von AP. Fix Problem mit ändern der Slave Adresse von Chibi und RS485 Extension. WIFI Ringbuffer ist jetzt außerhalb der State Machine und die State Machine kann Byte für Byte gefüttert werden (dadurch wird es möglich später den DMA Controller für WIFI Kommunikation zu nutzen, evtl in 2.0.5 schon). Download Firmwares: Master Brick

Firmwares: Master Brick 2.0.4 Reset WIFI Module after disassociate from AP Fix problem with changing of slave addresses of Chibi and RS485 Extension Externalize WIFI ringbuffer and feed bytes in state machine byte by byte (will allow the use of DMA controller later on) Download Firmwares: Master Brick

Also, ich benutze hier Eclipse + CDT + OpenOCD + CodeSourcery GCC zum debuggen: Meine openocd.cfg sieht wie folgt aus: source [find interface/jlink.cfg] source [find board/atmel_sam3s_ek.cfg] Ich starte mit openocd -f openocd.cfg Dann brauchst du das CDT Eclipse Plugin mit GDB Hardware Debugging: https://sites.google.com/site/stm32discovery/open-source-development-with-the-stm32-discovery/getting-hardware-debuging-working-with-eclipse-and-code-sourcey Als Debug Einstellung dann Use remote target, JTAG Device = Generic TCP/IP. host name = localhost und port number = 3333 verwenden. Das ist zumindest meine Konfiguration. Dazu die Toolchain von CodeSourcery: https://sourcery.mentor.com/sgpp/lite/arm/portal/subscription?@template=lite In Eclipse hab ich unter C/C++ Build -> Build Variables -> Builder Settings einfach "make -C ${ProjDirPath}/build" eingestellt, um direkt das Makefile zu nutzen.

Hast du schonmal versucht den Brick nochmal in den Bootloader zu versetzen (z.B. USB einstecken während erase gedrückt ist)? Ist der Brick im Moment noch im Stack? Wenn ja solltest du vielleicht doch mal versuchen ihn auszubauen.

Anbei eine neue Master Brick Firmware zum Testen. Ich hab die Einstellung vom Keep Alive Timer wieder auf Default gestellt und Resette jetzt einmal das Komplette WIFI Modul und Konfiguriere neu wenn ich ein Disassociation Event vom AP bekomme. Dadurch sollte das "Connection Refused" Problem definitiv gelöst sein . Wenn es jetzt immernoch da ist, muss es was mit dem AP zu tun haben. brick_master_firmware_2_0_4-beta1.bin

Interessant! Gucke ich mir am Montag an. Was für einen AP verwendest du (Hersteller, Modell)? Edit: AP geht ja aus dem Screenshot hervor: Fritzbox 7112. In 2.0.2 hatte ich etwas am "Association Keep Alive Timer" geändert, was bei unserem AP dazu geführt hat, das er sich weniger oft Disassociated hat. Bei dir hat es offensichtlich den gegenteiligen Effekt. Das "Connection Refused" Problem nach einerm Dis- und Reassociation hat auch RSchiessl (schreibt hier manchmal im Forum). Der hatte mir per Email auch schon mitgeteilt, dass die Probleme mit 2.0.2 schlimmer geworden sind. Ich wette ihr habt den gleichen AP, ich bringe das mal in Erfahrung . Damit haben wir jetzt einen Anhaltspunkt (Keep Alive Timer) bzgl dieses Problems. Das Problem gab es übrigens in Protokoll 1.0 auch schon. Was wir jetzt in Erfahrung bringen müssen: Kommt bei der WIFI Extension irgendwas an nach der Reassociation nicht mehr klar oder verschluckt der AP sich aus irgendwelchen Gründen.

Es ist vermutlich am einfachsten, wenn du das Joystick Bricklet selbst ausliest (anstatt über das Bricklet Plugin zu gehen). Du findest in der config.h die Definitionen der einzelnen Bricklet ports: #define BRICKLET_A_ADDRESS 84 #define BRICKLET_A_ADC_CHANNEL 12 #define BRICKLET_A_PIN_1_AD {1 << 12, PIOC, ID_PIOC, PIO_INPUT, PIO_DEFAULT} #define BRICKLET_A_PIN_2_DA {1 << 25, PIOA, ID_PIOA, PIO_INPUT, PIO_DEFAULT} #define BRICKLET_A_PIN_3_PWM {1 << 0, PIOC, ID_PIOC, PIO_INPUT, PIO_DEFAULT} #define BRICKLET_A_PIN_4_IO {1 << 4, PIOC, ID_PIOC, PIO_INPUT, PIO_DEFAULT} #define BRICKLET_A_PIN_SELECT {1 << 8, PIOC, ID_PIOC, PIO_OUTPUT_0, PIO_DEFAULT} .. Um die analogen Werte des Joysticks auszulesen, musst du zuerst den adc aktivieren "adc_channel_enable(BRICKLET_X_ADDRESS) und du kannst die Werte mit adc_channel_get_data(BRICKLET_X_ADDRESS) auslesen. Der Joystick hat allerdings zwei Achsen, D.h. du musst zwischen den einzelnen Achsen umschalten, das geht über PIN_3 und PIN_4. Dabei unbedingt darauf achten, dass immer nur einer der beiden Pinne auf high ist. PIN_3 ist die X-Achse und PIN_4 die Y-Achse. Über PIN_2 kannst du den Button abfragen. Am besten baust du die Abfrage vermutlich in die tick_task und die adc Initialisierung in die stepper_init. Für den Joystick würde ich immer ein Achse auslesen, PIN_3 und PIN_4 auf low stellen, eine Tick warten, einen der Pinne auf high stellen, einen Tick warten und dann die andere Achse auslesen usw. Zum initialen Konfigurieren der Pinne benötigst du PIO_Configure, für das setzen auf high/low PIO_Set und PIO_Get und für das auslesen vom Button PIO_Get. Desweiteren solltest du in der brick_init in init.c den bircklet_init() Aufruf auskommentieren, damit das Joystick Bricklet Plugin nicht zusätzlich ausgeführt wird (sonst schaltet das Plugin zwischen den Achsen hin und her). Ich hoffe das hilft. Der Übergang von der Kommunikation mit dem PC zum On Device Programming ist leider nicht so einfach, sonst hätten wir schon längst eine low-level API dafür fertig .

Die Master Brick Firmware 2.0.3 (zusammen mit dem neuesten Brickv) sollten jetzt Passwörter bis 64 Zeichen erlauben .

Firmwares: Master Brick 2.0.3 Kleineres USB Timeout bei erster Enumerierung, damit Enumerierungsprozess schneller abschließt. WIFI Config wird nicht neugelesen nachdem Verbindungsversuch fehlgeschlagen ist Download Firmwares: Master Brick

Firmwares: Master Brick 2.0.3 Use smaller USB timeout on startup enumeration, to allow faster enumeration Dont reread the config after the first WIFI association fails Download Firmwares: Master Brick

Ich hab den Client über Nacht laufen lassen und heute morgen hatte "sendall" in der Tat eine Exception geschmissen. Das hier ist aus der .net Dokuemntation, ich finde spezifisch zu Python nichts passendes. Sollte aber allgemein gelten: Soweit ich das verstehe, hat das Betriebssystem einen Buffer für TCP/IP und wenn ich "send" aufrufe, werden Daten in den Buffer kopiert. Sobald sie im Buffer sind bekomme ich zurückgegeben wieviel Byte in den Buffer kopiert wurden. D.h. an der Stelle gibt es keine Garantie das die Daten auch wirklich ankommen. Jetzt ist die Frage wie ich mein Linux hier konfiguriert habe, dass es so lange dauert bis der Kernel mitbekommt das er die Nachrichten nicht los wird und mir den Socket schließt. Ich teste das mal noch mit ein paar anderen Rechnern

Wirklich??? Hast du wirklich das Netzwerkkabel gezogen? Oder hast du eines der Programme mit strg+c beendet? Das macht nämlich einen Unterschied.

Ich hab hier mal einen Thread dazu aufgemacht: http://www.tinkerunity.org/forum/index.php?topic=1380.msg8724#msg8724 Da gibt es auch zwei kleine Python Programme die das eigentliche Problem demonstrieren (ohne WIFI Extension).

Problem: Wie in diesem Thread zu sehen, bekommt ein Programm welches ausschließlich Callback verwendet und über WLAN betrieben wird ein Verbindungsabbruch von der Gegenseite nicht mit. Dies liegt grundsätzlich erst einmal an der Funktionsweise von Sockets, der "Read Socket" blockiert und bekommt einfach keine neuen Nachrichten mehr und auf den "Write Socket" wird nicht geschrieben. Dadurch kann eine Verbindung nicht automatisch neu aufgebaut werden, da keinerlei Hinweis auf eine Verbindungstrennung vorhanden ist. Ein Workaround habe ich im obigen Thread schon gepostet, Wenn wir regelmäßig den "Write Socket" nutzen (z.B. durch Aufruf eines Getters), bekommen wir mit wenn die Gegenseite wieder da ist und es wird automatisch eine neue Verbindung aufgebaut. Jetzt könnte man diese "Ping Funktionalität" fest in die Bindings einbauen, allerdings stellt mich dies als Lösung nicht zufrieden. Es ist weiterhin so, dass eine Disconnect erst dann aufgerufen wird, wenn die Gegenseite wieder da ist. Nicht aber wenn die Verbindung das erste mal abbricht. Problemerklärung: Um zu zeigen, dass dies eine Prinzipielle Eigenschaft von Sockets ist, hier ein Beispielaufbau: PC1 (simuliert WIFI Extension indem ein Socket geöffnet wird und eingehende Daten ausgegeben werden): # WIFI Extension simulation import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind(('', 1234)) s.listen(1) conn, addr = s.accept() while 1: data = conn.recv(1024) print data conn.close() PC2 (simuliert Client der mit WIFI Extension spricht): # Client import socket import time s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('192.168.178.153', 1234)) while True: s.sendall('Hello, world') time.sleep(1) s.close() Wenn ich dieses Programm auf beiden Rechnern starte, gibt PC1 jede Sekunde einmal "Hello World" aus. Wenn ich jetzt das Ethernet Kabel trenne (oder äquivalent die WLAN Verbindung unterbreche), passiert auf beiden seiten _nichts_, Der Server bekommt keine Nachrichten mehr und der Client gibt keine Fehler. Wenn ich jetzt das Programm auf PC2 neustarte und dann das Ethernet Kabel wieder einstecke, bekomme ich dies auf PC1 mit (da "sendall" einen Fehler schmeißt, da die Gegenseite die Socket Verbindung noch nicht kennt). Erst jetzt bekomme ich mit, dass die Gegenseite nicht mehr erreichbar war und kann eine neue Verbindung aufbauen. Exakt das gleiche passiert mit der WIFI Extension, dadurch bekommen wir den Verbindungsabbruch erst mit, wenn die WIFI Extension wieder in Reichweite ist oder sich neugestartet hat o.ä. Lösungsvorschlag: Eine mögliche Lösung wäre folgendes: Alle Bindings schicken in regelmäßigen Abständen (alle 2-5 Sekunden?) ein Ping raus. Wenn dies mehr als 3 mal hintereinander passiert, gehen wir davon aus dass die Verbindung getrennt wurde, schmeißen einen DISCONNECTED Callback und versuchen eine neue Verbindung aufzubauen. Vorteil: Eine Verbindungstrennung wird frühzeitig erkannt, nicht erst wenn eine Verbindung wieder aufgebaut werden kann. Der neue Verbindungsaufbau passiert zur gleichen Zeit wie zuvor auch, es gibt dadurch keine Vorteil bzgl. der "Neuverbindungsgeschwindigkeit". Was meint ihr? Ist das den Aufwand Wert? Wird es da zuviele "False Positives" geben (3x Timeout obwohl Verbindung nicht unterbrochen war)?

Firmwares: Master Brick 2.0.2 Fixes für stabilere WIFI Extension: Command/Data Modus entfernt, nur eine Stelle für Empfangen/Senden Ermöglich viel besseres Error Handling, Logging und Debugging [*]Brickd speichert Nachrichten nur wenn "Return Expected" = 1 [*]Analysiere alle Command-Responses mit lesbarer Antwort [*]Analysiere <ESC>O, <ESC>F, <ESC>A Optionen ausgiebiger [*]Entferne Nachrichten von Brickd wenn socket getrennt [*]WIFI Initialisierung jetzt Asynchron Ermöglicht ein Kommunizieren mit Master Brick während Initialisierung [*]5 Minuten Timeout für "Hang-Up-Detection" (statt 3) [*]Empfangene Daten werden ausgewertet während Commands geschickt werden [*]Benutze andere ATS Konfigurationen [*]Analysiere Startup/Reset Nachrichten [*]Neue Data-State-Machine [*]API für langen WPA Schlüssel hinzugefügt (bis zu 64 Buchstaben) Download Firmwares: Master Brick

Firmwares: Master Brick 2.0.2 Fixes for a more stable WIFI Extension: Remove command/data mode, use only one place for receiving/sending Allows for much better error handling, debugging and logging [*]Only save messages in brickd if return expected [*]Parse all command responses with human readable response [*]Parse <ESC>O, <ESC>F, <ESC>A options more thoroughly [*]Remove messages from brickd if socket disconnected [*]Make WIFI initialization asynchronous Allows to communicate with Master Brick while WIFI is connecting [*]Use 5 minute timeout before we assume a hang up (instead of 3) [*]Evaluate received data while sending command [*]Use different ATS configuration [*]Parse startup/reset message [*]Refactor data state machine [*]Add API for long WPA key (up to 64 chars) Download Firmwares: Master Brick

Das funktioniert, ich habs gerade getestet. Du musst die IPcon nicht selbst neu aufbauen. Es ist über WLAN in der Tat so, dass der Socket einen Disconnect nicht mitbekommt wenn nur Callbacks verwendet werden. Dagegen können wir allerdings nichts machen, WLAN verhält sich da anders als USB. Das ist allerdings kein großes Problem, dann du kannst einfach alle paar Sekunden einen Getter aufrufen (und die Timeout Exception natürlich fangen). Dann bekommst du ein Disconnect sobald die WIFI Extension wieder da ist. Hier mein Code mit dem ich getestet hab (Aufbau: Master <-> WIFI <-> IMU): #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "192.168.178.108" PORT = 4223 UID = "631cHu" # Change to your UID import time import traceback from tinkerforge.ip_connection import IPConnection from tinkerforge.brick_imu import IMU imu = None def quaternion_cb(x, y, z, w): print("x: " + str(x) + "\ny: " + str(y) + "\nz: " + str(z) + "\nw: " + str(w) + "\n") def cb_enumerate(uid, connected_uid, position, hardware_version, firmware_version, device_identifier, enumeration_type): print "cb_enumerate", uid, enumeration_type if enumeration_type == IPConnection.ENUMERATION_TYPE_CONNECTED or \ enumeration_type == IPConnection.ENUMERATION_TYPE_AVAILABLE: if device_identifier == IMU.DEVICE_IDENTIFIER: global imu imu = IMU(UID, ipcon) imu.set_quaternion_period(1000) imu.register_callback(imu.CALLBACK_QUATERNION, quaternion_cb) def cb_connected(connected_reason): print "cb_connected", connected_reason ipcon.enumerate() if __name__ == "__main__": ipcon = IPConnection() ipcon.connect(HOST, PORT) ipcon.enumerate() ipcon.register_callback(IPConnection.CALLBACK_ENUMERATE, cb_enumerate) ipcon.register_callback(IPConnection.CALLBACK_CONNECTED, cb_connected) while True: time.sleep(1) if imu != None: try: imu.get_imu_temperature() except: pass Wenn ich hier jetzt den Stack neustarte läuft das Programm automatisch weiter, sobald das WLAN Modul sich wieder mit dem AP verbunden hat. Die Ausgabe sieht dann wie folgt aus: Wir sollten das Rugged Example diesbezüglich anpassen. Alternativ sollten wir den Bindings vielleicht doch eine automatische "Ping Funktionalität" hinzufügen, die man aktivieren kann, die genau dieses Verhalten automatisch erzeugt. Dies wurde auch hier im Forum schon öfter vorgeschlagen. Mhhhhhhh

Das Problem sind hier die Sockets. Der Connection State wird geändert wenn sich der Zustand des Sockets ändert. Zum einen kann dies Lange dauern (länger als Minuten) und zum anderen kann es sein, dass man dies gar nicht mitbekommt wenn nur Callbacks verwendet werden. Da können wir aber auch nichts gegen machen, befürchte ich. Du könntest versuchen zusätzlich einmal pro Sekunde einen getter Aufzurufen, um damit Timeouts zu provozieren und darüber mitzubekommen, dass die Gegenseite nicht mehr da ist. Spätestens wenn der Brick wieder da ist wird die Verbindung allerdings neu aufgebaut, das sollte funktionieren! Das ist korrekt. Es gibt nur eine Callback Periode und ein Callback Thershold etc. Einstellungen sind nicht pro Verbindung, das wäre technisch auch gar nicht möglich. Wenn mehrere Verbindungen über Brickd hergestellt werden (über USB), bekommen die Bricks da gar nichts von mit. Für die Bricks selbst gibt es immer nur einen Teilnehmer.

So, es gibt jetzt die erste beta von Master Brick Firmware 2.0.2: http://download.tinkerforge.com/_stuff/brick_master_firmware_2_0_2_beta1.bin Das ist definitiv noch nicht die finale Version 2.0.2, es fehlen noch ein paar Kleinigkeiten die ich heute nicht mehr geschafft hab. Desweiteren hab ich bisher nur mit WPA und noch nicht ausführlich im AdHoc/AP Modus getestet. Hab ziemlich viel umgerissen, hauptsächlich um bessere Fehlerbehandlung und besseres Debugging/Logging zu erlauben: https://github.com/Tinkerforge/master-brick/commit/510e9350b2c7769222bbbd839254809baafafe2c Wer Lust und Zeit hat: Bitte testen ob die Firmware einen Unterschied bringt .

Im Stack flashen geht.

Sorry, wird noch ein wenig dauern . Die anderen Probleme die ich gerade am versuche zu fixen lassen sich leider nicht so gut reproduzieren, dadurch dauert es so lange.

Komisch. D.h. es läuft einfach weiter nach einem Timeout und funktioniert dann auch wieder? Ist das Python Skript groß, kann ich das hier evtl ausführen zum reproduzieren?

Erstaunlich wie gut das mit DC Motoren funktioniert . Ich hätte gedacht, dass die Positioniergenauigkeit nach ein paar cm dahin ist.

Kannst du einmal den Teil des Source Codes der nicht funktioniert hier posten?