Wumpus

Hatte ich übersehen, aber wird ja auch im Brickv angezeigt. Gibt es Erfahrungswerte bei welcher Stärke es grenzwertig wird?

Habt ihr eigentlich die Möglichkeit, die Signalempfangsstärke am Chibi irgendwie auszulesen? Ich kämpfe hier mit Chibis in Verbindung mit Humidity Bricklets. Alle andere Bricklets sind weniger anfällig, aber die Humidities hängen sich ganz häufig an den Chibis auf. Enumerate findet das Bricklet noch und ein get_version geht dann auch immer noch, aber ein get_humidity liefert ein Timeout bis der Stack resetet wird. Andere Bricklets (z.B. Joystick) an dem Slave-Chibi laufen weiterhin. Habe schon alles mögliche ausgetauscht (Humidity Bricklet, Master Brick, Chibi, etc.). Und das Slave Chibi steht nur im Nachbarzimmer, sollte doch trotz kleiner Antenne eigentlich kein Problem sein, oder? Hier würde es zumindest mal helfen, wenn ich wüsste, wie die Empfangsstärke ist.

Worauf legst du denn am meisten Wert? Die Bestückung mit Bricklets sollte sich ja nicht allzu häufig ändern. Ist mehr oder minder semistatisch, man muss Geld in die Hand nehmen. Auf der anderen Seite kann es natürlich immer mal wieder vorkommen, dass irgendwelche Bestandteile gerade den Geist aufgeben und resetet werden wollen. Für den ersteren Fall läuft bei mir Quasi im Hintergrund (alle 10 Minuten) ein Enumerate als separater Prozess und überschreibt die Datenbank. Ich setze dabei auch Zeitstempel pro Bricklet. Dann weiss man welche Bricklets wie lange nicht mehr gesehen wurden. Das ganze kann man noch ergänzen, wenn z.B. eine Abfrage eines Wertes mit GET fehlerhaft (z.B. timeout) ist markiert man den Eintrag in der DB entsprechend und nutzt den Eintrag nicht.

Ich bin dazu übergegangen, die Ergebnisse vom Enumerate in einer Datenbank abzulegen. Beim Programmstart kann ich dann entweder die Daten aus der DB wieder einlesen oder doch noch ein Enumerate erzwingen. Eigentlich wäre es schöner gewesen, wenn der brickd die Information schon cachen würde.

So würde das für mich tun: --- bricklet_io16.c.old 2012-05-09 22:22:28.000000000 +0200 +++ bricklet_io16.c.new 2012-05-10 08:48:08.000000000 +0200 @@ -20,7 +20,11 @@ #define TYPE_GET_PORT_INTERRUPT 8 #define TYPE_INTERRUPT 9 -typedef void (*interrupt_func_t)(char, uint8_t, uint8_t); +#ifndef MAX_BASE58_STR_SIZE + #define MAX_BASE58_STR_SIZE 13 +#endif + +typedef void (*interrupt_func_t)(char*, char, uint8_t, uint8_t); #ifdef _MSC_VER #pragma pack(push) @@ -353,8 +357,10 @@ } int io16_callback_interrupt(IO16 *io16, const unsigned char *buffer) { + char str_uid[MAX_BASE58_STR_SIZE]; + ipcon_base58encode(io16->uid, str_uid); InterruptCallback_ *ic = (InterruptCallback_ *)buffer; - ((interrupt_func_t)io16->callbacks[ic->type])(ic->port, ic->interrupt_mask, ic->value_mask); + ((interrupt_func_t)io16->callbacks[ic->type])(str_uid, ic->port, ic->interrupt_mask, ic->value_mask); return sizeof(InterruptCallback_); } Besteht Hoffnung, dass ihr das in die offiziellen C-Bindings übernehmen könnt?

Weiß wäre noch wichtig, da das an manchen Stellen, wo man die Kabel herführen muss (aber eigentlich nicht so gerne möchte) einigermaßen neutral oder unauffälliger wäre.

Wie wäre es mit einem Bricklet zur Frequenzmessung? So, dass man z.B. ein Tachosignal von einem Lüfter auslesen kann.

Danke für die schnelle Antwort. Da ich die IO16 Bricklets aber automatisch erkenne und Callbacks anlege, ist das etwas ungünstig. Vielleicht ist es ja ein Vorschlag für eine API-Erweiterung...

Im Falle von mehreren IO16 Bricklets im Stack würde ich in der Callback-Funktion gerne die UID des auslösenden Bricklets auslesen. Gibt es dazu eine Möglichkeit (C-Bindings)?