borg

Der Low Power Mode sollte jetzt zurückgesetzt werden bei einem Disassociate (in 2.0.5).

Am einfachsten ist es wahrscheinlich wenn ihr eine weitere VM aufsetzt die einen Mutex implementiert (einfach über Sockets oder so). Das über einen Setter/Getter bei uns im System zu machen ist definitiv nicht sicher. Es könnte ja folgende Abrufreihenfolge passieren VM A: Get -> Ergebnis: Unlocked VM B: Get -> Ergebnis: Unlocked VM A: Set -> Lock VM B: Set -> Lock (kein Fehler) Um schon greifen beide VMs gleichzeitig drauf zu. D.h. ihr braucht eine TryLock Funktionalität, die einen Fehler zurückgibt wenn das Lock schon gesetzt ist. Es ist möglich das auf dem Master Brick zu implementieren, es gibt aber aktuell keinen Setter oder Getter bei uns im System der sowas leisten könnte.

Firmwares: Master Brick 2.0.5 Low-Power-Mode wieder anschalten nach Disassociation API hinzugefügt für: SetWifiHostname GetWifiHostname SetCurrentCallbackPeriod GetCurrentCallbackPeriod SetVoltageCallbackPeriod GetVoltageCallbackPeriod SetUSBVoltageCallbackPeriod GetUSBVoltageCallbackPeriod SetCurrentCallbackThreshold GetCurrentCallbackThreshold SetVoltageCallbackThreshold GetVoltageCallbackThreshold SetUSBVoltageCallbackThreshold GetUSBVoltageCallbackThreshold SetDebouncePeriod GetDebouncePeriod Current (Callback) Voltage (Callback) USBVoltage (Callback) CurrentReached (Callback) VoltageReached (Callback) USBVoltageReached (Callback) Download Firmwares: Master Brick

Firmwares: Master Brick 2.0.5 Reissue Low-Power-Mode after disassociate Add API for: SetWifiHostname GetWifiHostname SetCurrentCallbackPeriod GetCurrentCallbackPeriod SetVoltageCallbackPeriod GetVoltageCallbackPeriod SetUSBVoltageCallbackPeriod GetUSBVoltageCallbackPeriod SetCurrentCallbackThreshold GetCurrentCallbackThreshold SetVoltageCallbackThreshold GetVoltageCallbackThreshold SetUSBVoltageCallbackThreshold GetUSBVoltageCallbackThreshold SetDebouncePeriod GetDebouncePeriod Current (Callback) Voltage (Callback) USBVoltage (Callback) CurrentReached (Callback) VoltageReached (Callback) USBVoltageReached (Callback) Download Firmwares: Master Brick

So you are using stock debian? We currently don't have armel builds, our .deb is for armhf. The difference is described here: http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/ You can either switch to Raspbian or you can build brickd yourself from source (https://github.com/Tinkerforge/brickd): sudo apt-get install libusb-1.0-0-dev libudev-dev build-essential cd src/brickd make

Something around 1W seems reasonable, yes .

Es ist abhängig von Master v2 + Extension im Stack. Er schreibt: Ich denke also, es war das gleiche Problem .

Das hat nichts mit API Anfragen und Antworten zu tun. Wir kommunizieren mit dem WIFI Modul über SPI und bei SPI ist es so, dass bei jeder Flanke auf der Clock ein Bit von Slave zum Master und ein Bit vom Master zum Slave übertragen wird. Dadurch kann es passieren, dass ich Daten empfange während ich Daten sende. Dadurch brauchen wir den zusätzlichen Buffer. Ist ein reines Implementierungsdetail.

Do you have an example for such a picture? I am not sure what kind of API we could describe with pictures.

There is a marking in the sensor itself, you can see it here: http://www.inmotion.pt/store/images/3522.jpg

Naja, ein "Connection Refused" kann man laut WIFI Modul Datenblatt nur bekommen wenn alle 15 Sockets belegt sind. Warum dies nach einem Dis-/Reassociation passiert wenn bestimmte APs verwendet werden, kann ich einfach nicht rausfinden. Ein resetten des WIFI Moduls scheint es auf jedenfall aus dem komischen Zustand zu bringen. Bzgl des Low-Power-Modes: Beim starten eines großen Stacks kann es im Low-Power-Mode zu Timeouts beim Enumerierungsprozess kommen, daher erlauben wir den Low-Power-Mode nicht beim starten. Nach einem Reset Aufgrund eines Disassociation Events spricht aber nichts dagegen den Low-Power-Mode direkt wieder zu setzen .

Für die automatische ADC Kalibrierung vom Master 2.0 haben wir ein paar Leitungen im Stack auf andere Prozessorpinne gelegt. Dadurch scheint der Prozessor jetzt zu glauben er würde über JTAG angesprochen wenn er im Bootloader ist eine Extension auf dem Stack ist. Das ist definitiv ein ungewollter Nebeneffekt (ist auch nicht Dokumentiert im Datenblatt des Prozessors). Können wir jetzt aber nichts mehr gegen machen. Ich glaube The_Real_Black hatte in dem anderen Thread das gleiche Problem, wir sollten das mal genau durchprobieren und dokumentieren wann es die Probleme gibt.

Um den internen WIFI Buffer zu füllen, musst du viele Callbacks aktivieren (damit der Sendebuffer immer voll ist) und gleichzeitig viele Setter oder Getter aufrufen (damit es passieren kann, dass der Empfangsbuffer voll ist während ich etwas senden möchte). Die Kommunikation von dem WIFI Modul ist so gebaut, dass ich immer gleichzeitig Daten empfange wenn ich welche sende. Dadurch kann es sein, dass ich Daten bekomme während mein Eingangsbuffer voll ist (weil ich gerade einen Callback sende). Dazu brauche ich den zusätzlichen Buffer wofür du dir die lowWatermark holen kannst. Eigentlich hat das WIFI Modul selbst intern genug Buffer. Wenn die das Kommunikationsprotokoll ein wenig cleverer gebaut hätten, hätte ich den zusätzlichen Buffer gar nicht gebraucht...

Ich kann das Problem mit deinem Code nachstellen, allerdings nicht mit einem Minimalbeispiel: import com.tinkerforge.BrickMaster; import com.tinkerforge.IPConnection; public class ExampleStackStatus { private static final String host = "192.168.178.108"; private static final int port = 4223; private static final String UID = "68daHU"; // Change to your UID // Note: To make the example code cleaner we do not handle exceptions. Exceptions you // might normally want to catch are described in the documentation public static void main(String args[]) throws Exception { IPConnection ipcon = new IPConnection(); // Create IP connection BrickMaster master = new BrickMaster(UID, ipcon); // Create device object ipcon.connect(host, port); // Connect to brickd // Don't use device before ipcon is connected for(int i = 0; i < 10; i++) { // Get voltage and current from stack (in mV/mA) int voltage = master.getStackVoltage(); int current = master.getStackCurrent(); System.out.println("Stack Voltage: " + voltage/1000.0 + " V"); System.out.println("Stack Current: " + current/1000.0 + " A"); Thread.sleep(1950); } System.console().readLine("Press key to exit\n"); ipcon.disconnect(); } } Sag Bescheid wenn du herausfindest woran es genau liegt . Das ist OK, du musst nur neu initialisieren wenn der Stack aus war und seine Konfiguration vergessen hat.

Das ist komisch. Wenn ich hier auf meinem PC und Laptop einen Brickv starte und die beide mit einem WIFI Extension verbinde und den Master Tab aufmache, klappt das einwandfrei. Der Brick Viewer macht in dem Fall nichts anderes als alle 100ms GetStackVoltage/GetStackCurrent aufzurufen. Machst du irgendwas besonderes? Womit ich das vielleicht reproduzieren kann?

Du meinst von mehreren PCs per WLAN drauf zugreifen? Das geht, klar. Die WIFI Extension sollte sich da wie brickd verhalten. Brickd weiß zum Beispiel auch nicht für wen ein Callback bestimmt ist und schickt ihn überall hin. Bei WIFI können bis zu 15 IP Verbindungen gleichzeitig benutzt werden (das ist auch durchgetestet). Deine Problembeschreibung klingt so, als würdest du über einen PC per USB verbinden und über den anderen per WIFI: Das geht leider nicht und ist auch technisch nicht möglich. Wenn du zwei Schnittstellen gleichzeitig benutzt gehen Nachrichten immer an die Schnittstelle, die zuletzt etwas angefragt hat (das gilt sowohl für Getter als auch für Callbacks). Also wenn du z.B. per WIFI einen Stackteilnehmer abfragst und bevor der die Antwort zurück schickt fragst du etwas per USB ab, geht die Antwort der ersten Anfrage per USB zurück.

Firmwares: Joystick Bricklet 2.0.2 Integrationszeit für Analogwert erhöht und Durchschnittsbildung verringert. Dadurch sollten Werte stabiler werden wenn das Joystick Bricklet über WLAN verwendet wird Download Firmwares: Joystick Bricklet

Firmwares: Joystick Bricklet 2.0.2 Increase analog value integration time and decrease averaging to allow more stable joystick values if Joystick is used over WiFi Download Firmwares: Joystick Bricklet

Da fehlt die Konfiguration der X/Y-Pinne auf Output: ... Pin pins_bricklet_a[] = {PINS_BRICKLET_A}; pins_bricklet_a[0].type = PIO_INPUT; pins_bricklet_a[1].type = PIO_INPUT; pins_bricklet_a[2].type = PIO_OUTPUT_1; pins_bricklet_a[3].type = PIO_OUTPUT_0; ...

Der Treiber für den Bootloader liegt im brickv Verzeichnis, der Treiber für den Master Brick (wenn eine Firmware drauf geflasht wird) liegt im brickd Verzeichnis. Ich denke du hast den falschen Treiber installiert. Das müssen wir unbedingt mal besser Dokumentieren oder irgendwie anders offensichtlicher gestalten.

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.