AuronX

wie gesagt: den gemeinsamen ober-ordner! also der drivers-ordner hat bei mir funktioniert... ist eh die sicherste wahl, wenn du "unterordner einbeziehen" aktiv hast

Was noch gut zu wissen wäre, wären Preisdimensionen (Anzahl der Stellen vor dem Komma), weil Radar klingt schon ziemlich nett, wenns dann aber 250 Euro kostet wäre es natürlich doch nicht meine Hauptpriorität ^^ Ich suche ja noch immer nach Abstandsmessung über 50m und mehr ^^ (gerne auch bis 250)

Es sollte möglich sein noch während das Ding als GPS Camera erkannt installiert wurde einfach auf "Treiber aktualisieren" zu gehen und dann die Files händisch auszuwählen. Ich habe dazu den Ordner "C:\Program Files (x86)\Tinkerforge\Brickd\drivers" genommen. Zunächst hatte ich den Ordner amd64 ausgewählt, das ist aber falsch, weil die inf-datei ja im ordner darüber liegt.

Schau dir mal das Servo-Brick an, das klingt nach genau deinem Anwendungsfall.

Ist es nicht möglich den Zeichensatz transparent mappen zu lassen? Ich müsste mir das mal anschauen, aber beispielsweise bieten ja die OutputStreamWriter an nen zeichensatz zu spezifizieren... Ergänzung: Im Moment sieht der Code zum Schreiben des Strings so aus: for(int i = 0; i < 20; i++) { try { bb.put((byte)text.charAt(i)); } catch(Exception e) { bb.put((byte)0); } } Also vollkommen frei von Encoding-Gedanken. String definiert auch die Methode public byte[] getBytes(String charsetName). Da gibt es dann ein Array von Bytes das nach einem spezifischen Zeichensatz dargestellt wird. Dieses byte-array ließe sich dann in den ByteBuffer schieben. Für den Fall, dass das CharSet schlecht unterstützt wird kann man wohl auch einen eigenen CharsetEncoder schreiben, habe ich aber noch nie gemacht ^^ P.S.: Habe noch nicht geprüft wie gut sich eine solche Ändeurng mit dem Code-Generator verträgt.

Allgemein wäre ein Barometer bestimmt auch für alle Wetterfreunde was schönes, das sollte man ja soweit ich weiß für beides nutzen können. Möglicherweise hat der gute Thunderbird da auch schon erfahrung, glaube er betreibt schon ein Barometer...

Oh, das hab ich auch nciht gesehen. Sag mal, hat Java wenigstens eine Warnung oder sowas geworfen? Hätte nicht erwartet, dass man eine Methode so nennen darf wie den Klassen-konstruktor.

Auf jeden Fall schonmal Danke für den Hinweis... da werde ich an meinem Schreibtisch ein wenig aufpassen müssen, da es hier täglich ein kleines Gewitter gibt wenn ich über den Teppich rolle

Es ist definitiv nicht für einen Anfänger empfehlenswert selbst an der Firmware rumzufummeln... würde ich behaupten wollen... Wegen Power over Ethernet: Das wäre dann eine Alternative, wenn du irgendwo anders nen PC zu stehen hättest der villt doch schon läuft oder wenn deine Dachfenster so weit auseinander sind, dass du ansonsten zwei Rechner bräuchtest. Dann würde der PC die Bricks über Netzwerk ansteuern und die Bricks hätten nur ein Kabel nötig, nämlich das Netzwerkkabel. Aber klar, wenn du den PC direkt am Brick hast, dann ist USB sinnvoller. P.S.: PC meint hier auch sowas wie den Raspberry Pi ^^

Verstehe noch nicht ganz was dein Wunsch ist. Du könntest jeden Brick direkt an den Raspberry anschließen (per USB) und es sollte laufen (weil der brickd ja auch auf dem Pi installiert werden kann). Ansonsten ist auch noch eine Master Extension geplant die WLAN/Ethernet hat. Diese soll dann wohl den Daemon quasi selbst ausführen, man kann sie also direkt per IP ansprechen. Dazu habe ich auch schon den Wunsch nach Power-over-Ethernet gelesen, aber kA ob das auch umgesetzt wird, es wäre aber sehr geil, um das mal so zu sagen ^^

Ja die Doku macht darüber soweit ich weiß keine Aussage. Das sollte geändert werden.

Sehr gut Mein Vorschlag wäre es erstmal nur den Namen zu prüfen und dann wenn ihr das nächste mal eine Änderung am Protokoll vornehmt die inkompatibel zum alten ist (kommt bestimmt irgendwann ^^) gleichzeitig eine Device-Class mit einführt. Viele Grüße

Also die Klasse in der das Problem auftritt wurde nur gebaut um .NET 2.0 kompatibel zu bleiben. Also würde ich erstmal denken, dass das angestrebte Ziel alles >= .NET 2.0 ist. Alles unter 2.0 macht denke ich auch keinen Sinn.

Optional Arguments gibt es erst ab C# 4.0, ich werde mal auf Github nen Patch dafür vorschlagen. Den kannst du auch einfach selbst machen: //das ist neu public bool TryDequeue(out byte[] value) { return TryDequeue(value, Timeout.Infinite); } //beim parameter das "= foo" weglassen public bool TryDequeue(out byte[] value, int timeout) { //hier alles wie immer } LG Jan

Hallo, eine Frage die mir schonmal beim durchstöbern des C#-Codes aufkam und jetzt auch in einem anderen Thread sichtbar wurde: Wenn ich mir in meinen Bindings ein Device erstelle und einer IPConnection zuweise, dann wird geschaut, ob ein Device mit der korrekten UID auch gerade im Stack vorhanden ist. Soweit so gut. Allerdings scheint es nicht vorgesehen zu sein auch den Device-Typ zu überprüfen, zumindest konnte ich nichts derartiges entdecken. Dadurch ist es im Moment möglich, dass ich mir (versehentlich) ein BrickletAmbientLight erstelle und damit dann meinen Temperatursensor auslese (GET_TEMPERATURE und GET_ILLUMINANCE haben beide die ID 1). Wäre hierzu nicht eine Device-Class o.ä. sinnvoll, die beispielsweise beim addDevice zusammen mit der Firmware-Version übertragen wird? Vermutlich könnte man auch den Name vergleichen, aber das ist denke ich die weniger schöne Lösung. Ziel wäre es am Ende des Tages sicherzustellen, dass das verwendete Binding auch zum Device passt. LG Jan

Wenn ich dich richtig verstehe schließt du an den Servo-Brick nur den ESC an (nur Signal). Der ESC wird dann ganz alleine von der Batterie gespeist. Sofern ich dich richtig verstehe, besteht keine Gefahr, da du über den Servo-Brick keine Last laufen lässt. Die Last trägt der ESC, auch da musst du natürlich aufpassen, dass du dessen Kapazität nciht mit dem Motor überschreitest, aber das hast du vermutlich bereits getan ^^ Ich würde denken es sollte recht sicher sein, wenn du einfach mal im Viewer nen Motor langsam anlaufen lässt und den Strom im Blick behälst (wird ja z.B. vom Master-Brick überwacht). Dann kannst du langsam schneller drehen und mal schauen welche Auswirkungen das auf die Stromstärke hat. Möglicherweise hat aber jemand anders einen noch sichereren Tipp... P.S.: Ich bin auch nur ein schlechter Elektrotechniker und deutlich besser auf der Software-seite

Je nachdem wie sehr du anfänger bist solltest du möglicherweise lieber mit einer Konsolenanwendung anfangen... WinForms bürdet dir gleich nen ziemlich fettes Framework auf, das du dir villt erst anschauen willst wenn du die ersten Meter C# hinter dir hast.

@Master: Wichtig sollte nur sein, dass sich die Spannung der Batterie im Normbereich befindet, dann kann die Batterie ja schonmal nix kaputt machen. Auf Verbraucherseite musst du dann sicherstellen, dass insgesamt nicht mehr als die 3A zusammenkommen. Die 45 Ah heißen Amperestunden, sie könnte also theretisch 45 Stunden lang ein Ampere Strom liefern. oder eine Stunde lang 45 (obwohl die maximale Belastung nochmal irgendwo steht). Ich merk mir das immer so: Die Spannung bestimmt der Versorger, die Stromstärke der Verbraucher.

Hab die Brick-Doku zu TCP/IP nciht gesehen Mein Vorschlag war es quasi nur, dass man ja genau diese TCP/IP-Doku machen könnte ^^

Wenn ich das im Generator richtig sehe, dann wird das implizit durch die Position der Funktion in der Config gegeben. Also die zuerst angegebene Methode ist die eins, dann die zwei usw. Da mit diesen Configs auch die Dokus erstellt werden, könnte man beispielsweise die IDs einfach bei den einzelnen Dokus mit einbringen oder daraus eine "Low-Level" (der Begriff wird woanders auch noch benutzt oder?) Doku erstellen. LG Jan

Der patch war übrigens von mir (große vielfalt an Nicknames ^^) Ich denke das nächste Mal werde ich dann aktiv wenn ich das erste bisschen gebastelt habe, da fallen mir dann bestimmt wieder irgendwelche Sachen auf. Auf jeden Fall schonmal großen Dank für eure offene Arbeitsweise (Blogging über Fortschritt, Open-Source), so macht das ganze deutlich mehr Spaß ^^

Das mit der 2. Baustelle ist schon richtig... deswegen meinte ich auch nur bei "beliebten" Bindings... naja mal schauen... irgendwas werde ich mir auf jeden Fall einfallen lassen für das Zeug woran ich arbeite... entweder ich Kapsel die Original-Lib oder ich bau auf deren Quellcode neu. Mal gucken ^^ Bis bald Jan

@Nic: Ich bin auch kein Fan von Out ^^ Andererseits bin ich es gewöhnt fremde Interfaces durch eigene wegzukapseln. Möglicherweise macht es aber auch Sinn eigene Bindings für beliebte Sprachen zu entwickeln (innerhalb der Community). Weil die default bindings halt immer nen Kompromiss zwischen gutem Generator-code und gutem Binding-Code darstellen müssen. Es würde zum Beispiel den Generator ziemlich aufblasen, wenn man überall korrekte Range-Checks einbaut. Dennoch wären diese schon sinnvoll. Selbst geschriebener Code kann sich da deutlich besser "anpassen". Allerdings weiß ich nicht ob es im oder entgegen dem Interesse von TF wäre, wenn man soetwas entwickeln würde. P.S.: Ich finds schon ganz Okay. Bei C# geht man von einem verantwortungsbewussten Entwickler aus, während Java eher den Ansatz verfolgt alles was missbraucht werden könnte nicht zu unterstützen. (mein Empfinden)

Okay, die mehrfach-rückgaben habe ich nicht berücksichtigt. Mein persönlicher Favorit wären zwar wahrscheinlich eigene Typen, aber der gewählte Ansatz ist zumindest konsistent (und gut generierbar). Danke für die Antwort^^ LG Jan

Hiho, ich habe festgestellt, dass die Getter in den C#-Bindings alle diese Form haben (Beispiel aus dem BrickletHumidity): public void GetHumidity(out ushort humidity) { //Anfrage bauen ipcon.Write(this, data_, TYPE_GET_HUMIDITY, true); //senden, hierbei wird das writeEvent aquired byte[] answer; //antwort in answer speichern humidity = LEConverter.UShortFrom(4, answer); writeEvent.Set(); //writeEvent wird released } Insbesondere wundert mich, dass dadurch alle Getter über out-parameter funktionieren und nicht über Rückgabewerte. Im Prinzip wäre ja die Zeile humidity = LEConverter.UShortFrom(4, answer); auch durch return LEConverter.UShortFrom(4, answer); ersetzbar. Das einzige was sich ändern würde ist, dass jetzt das writeEvent schon vor dem return released werden müsste. Das ist aber eh sinnvoll, da ja der kritische Teil der Zugriff auf die TCP-Connection ist. Die Benutzung des LEConverter muss nicht synchronisiert werden. Insofern würde mich interessieren, was die Motivation hinter der Benutzung der out-paramter ist und ob es nicht sinnvoll wäre, Rückgabewerte zu nutzen. Viele Grüße Jan