Wumpus

Hi, hat jemand eine Weg gefunden, unter Linux-3.5 Bricks/Bricklets zu flashen? Die (mir bekannten) sam-ba Treiber funktionieren dort offenbar nicht...

16 Relays an einem IO16? Reicht denn da der Strom?

Full Ack, mir fehlen auch immer Schrauben...

Aus meiner Sicht wären der Stromverbrauch und die Response-Time noch interessante Parameter. Aber diese liegen offnebar für beide Modelle recht nah bei einander. Die Response-Time wäre wichtig, wenn man mit dem Sensor einen Druckschalter realisieren wollte. Insgesamt sind die Tinkerforge-Produkte zwar preiswert (und eigentlich würde ich sagen, dass es auf einen Euro mehr oder weniger nicht angekommt), allerdings summieren sich die Kosten für ein Projekt ganz schön. Daher tendiere ich zur preisgünstigeren Variante.

Und was ist, wenn man zwei Master in einem Stack hat die Extensions jeweils auf beide Master verteilt?

Ich hab emir mittlerweile die Bindings umgeschrieben, so dass die UID immer beim Callback-Aufruf mit übergeben wird. Bei Interesse kann ich ja mal ein Diff zu den originalen C-Bindungs posten.

Was bedeutet "ja"?

Du hattest ja vor einem Monat schonmal einen Thread aufgemacht, weil die LEDs an deinem Master nicht mehr leuchteten. Ist das soweit schon behoben? Treiber installiert und neu geflasht?

Um welches Bauteil handelt es sich bei dem schwarzen Etwas direkt über dem Erase-Button/Schriftzug am Master-Brick? Aus den Schaltplänen kann ich das leider nicht zuordnen...

Hast du schonmal das Kabel ausgetauscht? Ansonsten kann man ja auch eine UID neu setzen im brickv.

Wann sind die Stepper Bricks wieder verfügbar?

Wäre es generell möglich im Shop die Verfügbarkeiten zu aktualisieren? Aktuell sind ja einige Module nicht verfügbar (z.B. Humidity Bricklet). Leider ist auch nicht ersichtlich, wann sie wieder verfügbar sein werden. Eine Bestellung hängt ja solange in der Queue, bis alle Komponenten wieder am Lager sind. Ausserdem wäre es schon, wenn man bereits auf der Shop-Übersichtsseite sehen könnte, welche Komponenten nur aktuell nicht lieferbar sind und welche Komponenten abgekündigt sind. Aktuell werden nur die abgekündigten als "out of stock" angezeigt.

Immer noch kämpfe ich mit dem Humidity Bricklet, das sich an einem Master mit Chibi nach einer Weile weghängt (timeout, brickv zeigt Null-Linie). Ein DistanceIR am selben Master zeigt ähnliche Tendenzen (Werte müssen mehrfach ausgelesen werden), aber ein IO-16 funktioniert zur selben Zeit einwandfrei. Gibt es in der Firmware irgendwelche Stellen, an denen ich bezüglich Robustness/Stabilität etwas pimpen kann?

Ich gehe mal davon aus, dass du den Brickd schon installiert und gestartet hast (wie unter http://www.tinkerforge.com/doc/Software/Brickd.html beschrieben), und dass auch der brickv richtig funktioniert (wie unter http://www.tinkerforge.com/doc/Software/Brickv.html beschrieben). Unter http://www.tinkerforge.com/doc/index.html gibt es für jede Programmiersprache super Beispiele. Dort wird immer eine einzelne Funktion ausgeführt (z.B. Auslesen der Temperatur eines Temperature-Bricklets), so dass man am Code sehr gut sehen kann, welche Schritte notwendig sind. Und man sieht auch, wie jede Sprache so aussieht. Das sollte dir vielleicht schon einen Anhaltspunkt geben, mit welcher Sprache du am besten zurecht kommst. Anschließend holst du dir dann die Bindungs für die Programmiersprache deiner Wahl (unter http://www.tinkerforge.com/doc/Software/API_Bindings.html). Und dort steht dann auch beschrieben, wie man den Quellcode ggf. übersetzt und ausführen kann.

Hier mein Vorschlag für eine Anpassung der Firmware (Bricklet): diff --git a/software/src/config.h b/software/src/config.h index 531eaa3..71a3b9f 100644 --- a/software/src/config.h +++ b/software/src/config.h @@ -10,7 +10,7 @@ #define BRICKLET_HARDWARE_NAME "Distance IR Bricklet 1.0" #define BRICKLET_FIRMWARE_VERSION_MAJOR 1 #define BRICKLET_FIRMWARE_VERSION_MINOR 1 -#define BRICKLET_FIRMWARE_VERSION_REVISION 1 +#define BRICKLET_FIRMWARE_VERSION_REVISION 2 #define LOGGING_LEVEL LOGGING_DEBUG #define DEBUG_BRICKLET 0 @@ -28,8 +28,8 @@ typedef struct { uint32_t signal_period[NUM_SIMPLE_VALUES]; uint32_t signal_period_counter[NUM_SIMPLE_VALUES]; - uint32_t threshold_debounce; - uint32_t threshold_period_current[NUM_SIMPLE_VALUES]; + int32_t threshold_debounce; + int32_t threshold_period_current[NUM_SIMPLE_VALUES]; int32_t threshold_min[NUM_SIMPLE_VALUES]; int32_t threshold_max[NUM_SIMPLE_VALUES]; char threshold_option[NUM_SIMPLE_VALUES]; und für die Brickletlib: diff --git a/bricklet_simple.c b/bricklet_simple.c index 3574134..80e1890 100644 --- a/bricklet_simple.c +++ b/bricklet_simple.c @@ -276,7 +276,19 @@ void simple_tick(uint8_t tick_type) { BA->send_blocking_with_timeout(&sgvr, sizeof(SimpleGetValueReturn), *BA->com_current); - BC->threshold_period_current[i] = 0; + + // Toggle threshold trigger if debounce has been set to -1 + if(BC->threshold_debounce == -1) { + switch(BC->threshold_option[i]) { + case 'o': BC->threshold_option[i] = 'i'; + break; + case 'i': BC->threshold_option[i] = 'o'; + break; + } + BC->threshold_period_current[i] = -500; + } else { + BC->threshold_period_current[i] = 0; + } logbli("threshold value: %d\n\r", BC->value[i]); }

Unter SSR würde ich einen Optokoppler mit Triac-Leistungsstufe verstehen. Sowas wie Sharp S202S02 (http://www.datasheetarchive.com/S202S02%20sharp-datasheet.html). Ich habe mit dem Vorgänger mal etwas gemacht. Da musste ich auch große Lasten über TTL-Ausgänge schalten. Der S202S02 hat allerdings einen Eingangsstrom laut Datenblatt) von immerhin 50mA. Aber vielleicht gibt es ja genügsamere Varianten. Von der Idee her würde ich sagen, dass SSR der richtige Ansatz ist.

Eigentlich meinte ich nicht, dass andere Bricklets ersetzt werden sollten. Vielmehr hat das IMU-Brick ja auch verschiedene Sensoren onboard um seine Aufgabe zu erfüllen. Ein "Wetter-Bricklet" sehe ich als eines der Standard-Anwendungsfälle und es wäre primär aus Kosteneffizienzgründen getrieben (weniger benötigte Brickletports, und generelle Einsparungen bei der Hardware). Jedes bisherige Bricklet hat auch für sich seine Darseinsberechtigung...

Noch eine Idee: Multibricklet Die Bricklet-Anschlüsse sind von der Zahl her immer knapp und die "Umwelt"-Bricklets (Temperatur, Feuchte, Licht, etc.) benötigt man meistens sowieso zusammen. Daher wäre es toll, wenn es ein kombinertes Bricklet (mindestens Temperatur und Feuchte, am besten auch gleich Licht, evtl. Luftdruck) auf einem Bricklet gäbe.

Folgendes Problem: Es soll ein Callback-Event ausgelöst werden, wenn beim Distance IR Bricklet die gemessene Entfernung einen Schwellwert unterschreitet. Allerdings soll der Callback dann nicht periodisch aufgerufen werden, sondern erst wieder, wenn der Schwellwert wieder überschritten wird (quasi Gut- und Schlecht-Alarm). Vermutlich gibt das bisher die API nicht her. Ich stelle mir vor, dass dieses Verhalten durch eine "-1" bei der debounce_period dargestellt werden könnte: distance_ir_set_debounce_period(&dist, -1); distance_ir_register_callback(&dist, DISTANCE_IR_CALLBACK_DISTANCE_REACHED, cb_distance_ir); distance_ir_set_distance_callback_threshold(&dist, '<', 1000, 0; In der Bricklet Library müsste dann in simple_tick() der Part von "Handle threshold signals" so angepasst werden, dass if (BC->signal_period[i] == -1) { switch(BC->threshold_option[i]) { case 'o': BC->threshold_option[i] = 'i'; break; case 'i': BC->threshold_option[i] = 'o'; break; case '<': BC->threshold_option[i] = '>'; break; case '>': BC->threshold_option[i] = '<'; break; } } Auf diese Weise würde man dann jeweils beim Überschreiten der Thresholds in beide Richtungen einen Event bekommen.Supertoll wäre es noch, wenn die Art des Events (Alarm true/false) auch beim Callback-Aufruf aus einem Parameter hervorgehen würde, aber das ging zu Not auch ohne. @TF: Liesse sich das einbauen?

Bei mir tritt es auf, ohne dass ein DualRelay Bricklet beteiligt ist. Ich lasse das ganze einfach permanent laufen und irgendwann ist das LCD "tot". Der Joystick am selben Master funktioniert dann noch.

Bin ebenfalls betroffen (LCD hängt, keine Hintergrundbeleuchtung schaltbar). Auch hier würde es wieder helfen, wenn man zumindest die Master per Softwarereset durchstarten könnte.

Irgendwie kommt mir deine Schilderung bekannt vor. Kannst du den Master selbst noch abfragen (z.B. master_get_chibi_signal_strength)? Bei mir hängen häufig die Humidity Bricklets und ich bekomme beim Auslesen ein Timeout. Erstaunlicherweise kann der brickv dann, wenn man ihn länger laufen lässt, irgend wann (nach ca. 40 Sekunden) wieder Werte lesen. Bei mir hat als Workaround geholfen, dass ich alle Werte im Fehlerfall wiederholt auslese. Dabei benötige ich dann so 3 bis 4 Versuche ehe mal ein Wert kommt. Das ist nicht schön, aber liefert mit dem Workaround zumindest noch Werte.

Zuspruch von meiner Seite für ein Software-Reset per API. Bei mir hängt sich häufig das Humidity Bricklet über Chibi auf, so dass es vielfach gepollt werden muss, bis es einen Wert zurückliefert. Die ständige Lauferei zum Master ist schon lästig. Ausserdem muss man ja auch immer resetten, wenn man am Stack gefummelt hat und die Chibis neu angemeldet werden müssen. Vor allen Dingen könnte man automatisiert reagieren, wenn mal irgendetwas hängt.

Alle Programme wurden beendet, die auf den Stack zugreifen. Ich hatte auch noch den SheevaPlug unter verdacht und habe deshalb noch mit einem anderen Rechner getestet, aber gleiches Problem. Der Stack besteht aus drei Mastern, jeweils mit Chibi Extension. Geflasht habe ich jeweils Bricklets, die an einem Master mit direkter USB-Verbindung hingen. Für mich sieht das so aus, dass das Flashen häufig fehlschlägt, wenn der Chibi-Stack aktiv verbunden ist. Sobald das Chibi abgezogen ist, bzw. wieder draufgesteckt, aber noch nicht aktiv ist, treten keine Fehler beim Flashen mehr auf.

Wäre es nicht einfacher und zuverlässiger, die Kamera direkt per USB fernzusteuern?