Wumpus

"Read Error" und "Verification Error" habe ich bekommen...

@photron: Gerade nochmals Bricklet Föashing probiert. Einmal "Successsful", einmal "Could not flash Bricklet" (ohne weitere Angaben)...

@mikrolinux: Den MacOs Brickv kenne ich nicht. Falls das auch skriptbasiert sein sollte, such doch einfach nach "localhost" in den Dateien. Falls das nicht skriptbasiert ist, keine Ahnung...

Sorry, habe mich da wohl etwas ungenau ausgedrückt. Konnte nur die Firmware auf die Bricklets hochladen (mit mehreren Versuchen, ausprobiert mit Temperature Firmware). Flashen der Bricks habe ich nicht gekonnt, da alle Felder ausgegraut sind. Jetzt schließe ich mal aus deiner Antwort, dass man erst das Knöpfchen drücken muss, damit die Felder aktiv werden.

@mikrolinux: Ich trage meine Server-IP immer in ui_mainwindow.py ein. Dort einfach "localhost" gegen die gewünschte Adresse austauschen.

Das mit dem automatischen Firmware-Download ist cool. Beim Flashen von Bricklets hatte ich relativ viele Fehlversuche (Linux), aber letztendlich konnte ich sowohl per Download, als auch mit Firmware von der lokalen Platte flashen. Bei "Brick" ist bei mir alles ausgegraut. Dort lässt sich aktuell nichts auswählen. Die verwendete Version habe ich aus dem GIT ausgecheckt.

Danke für die Antwort, dann muss ich mir mal die ganze Konfiguration (Einstellungen und Callbacks) in einer Datenstruktur ablegen, damit die dann von cb_enumeration entsprechend für jedes Device wieder eingerichtet werden kann. Das Thema Enumeration ist noch wieder eine Sache für sich. Für mein Empfinden kommen viel zu viele Callbackaufrufe an. Die "New Device" Calls kommen eigentlich ständig, obwohl nichts hinzugefügt oder resetet wird. Liegt's am Chibi?

Insbesondere, um Callback-Events wegzuloggen oder um darauf zu reagieren, lasse ich mein Programm als Daemon laufen, entsprechend mit einem ipcon_join_thread() Aufruf. Leider funktioniert das ganze nur, bis der Master-Brick resetet wird. Danach läuft mein Daemon zwar noch weiter, zeigt aber keine Funktion mehr. Werden die Callbacks beim Reset gelöscht? Was muss man tun bzw. auch, wie kann man erkennen, dass man etwas tun muss?

Nach der Änderung von borg ist die neue Implementierung, so, dass 'neu' und 'o' einen Trigger bilden. Neuer Vorschlag, war ein zusätzlicher Trigger um die Ecken separat zu halten. Das kann ich aber auch innerhalb der Callback-Funktion regeln. Ich habe die neue Firmware gerade getestet, und sie tut jetzt so, wie ich das erwartet hätte. Vielen Dank an euch beide!

Mir hilft das erst einmal. Eine Frage wäre noch, ob es sinnvoll ist, einen zusätzlichen Trigger zu definieren. Ich habe mal eine Grafik anghängt, die die drei Triggertypen darstellt. PS: Danke für's Ändern!

Aktuell werden die Postionen detektiert, die am Ende eines "X" stehen (Ecken des Joysticks/diagonale Punkte). Typischerweise möchte man aber den Joystick als Steuerkreuz nutzen "+". Mit der aktuellen Logik ist es nicht Möglich, Callbacks auf (0,100),(-100,0),(100,,0),(0,-100) einzurichten, also nur ein Wert liegt ausserhalb. Die aktuelle Logik kann man auch gebrauchen. Ich wäre eher für eine zusätzliche Triggerart, bei der das Mittlere "&&" gegen ein "||" ausgetauscht wird. So wie AuronX das richtig beschreiben hat.

Danke für die Antwort. Genau mit diesem Callback bin ich gestartet, aber das führt dazu, dass nur die Ecken detektiert werden, da 'outside' bedeutet, dass sowohl die X als auch die Y Werte ausserhalb liegen müssen. Gestern habe ich mit dem callback_position gespielt, was in Intervallen und wenn sich der Wert verändert hat einen Callbvack-Aufruf startet. Das sind zwar deutlich mehr Events, aber es hält sich doch mehr in Grenzen, als ich angenommen hatte. Dann muss die Logik für das Triggern auf Schwellwertüberschreitung (links,rechts,oben,unten,center) in der CallbackLogik erfolgen. Mal schauen, wie stabil das funktioniert...

Hat niemand eine Idee? Wie verwendet ihr den Joystick? Ohne Callbacks und nur Polling?

Vermutlich muss man ein per Funk angebundenes Brickl pollen (z.B. auch mit GetChibiSignalStrength() auf den Slave-Master-Brick), um sicher zu sein, dass die Verbindung steht. Ich würde mich nicht auf die Signal-Strength vom Master-Master-Brick verlassen. Wenn ein entferntes Brick oder Bricklet antwortet, dann steht die Verbindung.

Prinzipiell kann es ja bis zu 256 device_callbacks geben. Man muss die Firmware der Bricklets anpassen, wenn man bisher nicht bekannte Typen hinzufügen möchte, oder? Vermutlich würden mir folgende Callbacks helfen: JOYSTICK_CALLBACK_POSITION_REACHED_X JOYSTICK_CALLBACK_POSITION_REACHED_Y Und dann entsprechende Funktionen zum Definieren der Schwellwerte (für 'o'utside trigger): FUNCTION_GET_POSITION_CALLBACK_THRESHOLD_X FUNCTION_SET_POSITION_CALLBACK_THRESHOLD_X FUNCTION_GET_POSITION_CALLBACK_THRESHOLD_Y FUNCTION_SET_POSITION_CALLBACK_THRESHOLD_Y Eine andere Alternative wäre, gleich mehrere generische POSITION_CALLBACK vorzusehen. Dann könnte man alle x und y, sowie min und max Schwellwerte einzeln aufrufen und separate Trigger setzen. Das wäre besonders charmant, weil man damit auch z.B. zweistufig beim Joystick reagieren könnte. Z.B.: Stufe 1 = halbe Stellung bzw. >50 Stufe 2 = volle Stellung bzw. >99 Hba eich eine Chance das so oder anderweitig hinzubekommen?

Wie kann ich beim Joystick und den C-Bindings darauf einen Callback-Aufruf triggern, dass entweder einer der Min-Schwellwerte unterschritten oder Max-Schwellwerte überschritten wurde? Für die Steuerung des LCD würde ich gerne den Joystick in digitaler Art zur Steuerung nutzen (links/rechts/oben/unten). Mit den vorhandenen Triggern ('o'utside) schaffe ich es aber nur (wie in dem Beispiel), dass die Ansteuerung der Ecken detektiert wird, oder aber nur in einer Richtung ('>' oder '<') die Bewegung auf der Achse erkannt wird. Irgendwie fehlt mir diese Triggerart: (v<minX) || (v>maxX) || (v<minY) || (v>maxY)

Da braucht man doch nur ein zusätzliches getState() mit dem man den aktuellen Relais-Zustand ausliest und dann das Ergebnis für das nicht zu verändernde Relais damit wieder setzt.

Sehr gute Frage, vor allen Dingen da es jetzt keine Chibis mehr gibt...

So, jetzt habe ich meinen Code soweit runtergestrippt, dass er immer noch die NO_ACK Fehler hochzählt: #include <stdio.h> #include "ip_connection.h" #include "brick_master.h" #define HOST "localhost" #define PORT 4223 void cb_enumerate(char *uid, char *name, uint8_t stack_id, bool is_new) { } int main(int argc, char **argv) { char *uid = argv[1]; IPConnection ipcon; if(ipcon_create(&ipcon, HOST, PORT) < 0) { fprintf(stderr, "Could not create connection\n"); exit(1); } usleep(50000); ipcon_enumerate(&ipcon, cb_enumerate); usleep(75000); Master m; master_create(&m, uid); if(ipcon_add_device(&ipcon, &m) < 0) { fprintf(stderr, "Could not connect to Brick\n"); exit(1); } uint16_t ret_underrun, ret_crc_error, ret_no_ack, ret_overflow; master_get_chibi_error_log(&m, &ret_underrun, &ret_crc_error, &ret_no_ack, &ret_overflow); printf("Chibi: Underrun %4d CRC_error %4d No_ACK %4d Overflow %4d\n", ret_underrun, ret_crc_error, ret_no_ack, ret_overflow); } Kommentiert man das enumerate aus, dann gibt es keine Fehler mehr. Der Aufruf erfolgt unter Linux aus zwei Terminal jeweils für den Slave und eins für den Master über die Schleife while(true); do ./tinker <Master|Slave-UID> ; sleep 5 ; done Auf dem Master zählen die NO_ACKs hoch. Hat jemand eine Idee?

Jetzt schließe ich das hier erstmal ab. Vermutlich ist es ein Softwareproblem.

Ich benutze es um sauber das Programm zu beenden. Weglassen hat leider nichts gebracht. Aber Danke für den Tipp!

Sobald ich ein enumerate aufrufe, auch wenn die Callback-Funktion nichts tut, treten die Chibi NO_ACKs auf... Was kann man tun? (C-Bindings)

Ich verzweifle langsam. Kann das auch programmiertechnische Ursachen haben? Z.B. ipcon_destroy() zu früh aufgerufen?

Danke für den Tipp! Hat leider nichts gebracht. Konnte gerade empirisch feststellen, dass die Anzahl der NO_ACKs drastisch von der Anzahl der sich im Stack befindlichen Elemente abhängt. 8 Elemente (2x Master+Chibi, 4 Master/2 Slave Bricklets) verglichen mit (1xMaster+Chibi mit 4 Bricklets und Slave 2xMaster+Chibi mit 6 Bricklets, macht 5 Elemente mehr im zweiten Aufbau. Dieses führt bei ansonsten gleichen Bedingungen zu 4,5 mal mehr NO_ACKs auf der Master-Seite.

Ja, das wäre gut. Es zählen bei mir die No_ACK counter auf der Master-Chibi-Seite hoch, selten Overflows. Die Slave-Seite ist sauberer, deutlich weniger No_ACK. Master (5 Sekunden Abstand, ein Wert abgefragt): Chibi: Sig 12 dbm Freq 0 Underrun 0 CRC_error 0 No_ACK 5264 Overflow 122 Chibi: Sig 12 dbm Freq 0 Underrun 0 CRC_error 0 No_ACK 5266 Overflow 122 Slave: Chibi: Sig 11 dbm Freq 0 Underrun 0 CRC_error 0 No_ACK 1770 Overflow 0 Bei reinen Problemen mit der Luftschnittstelle würde ich eher auch mal CRC Fehler erwarten. Was kann das sein?