AuronX

Die gelben Haushaltsgeräte heißen ja Multimeter ^^ MultimeterBricklet VoltageCurrentBricklet nicht CurrentVoltageBricklet (das klingt nach aktueller Spannung )

Jop... man sollte da definitiv mehr teilen Für Java fällt mir auf Anhieb keine Gute Erweiterungsmöglichkeit ein, abgesehen von Vererbung. Also sowas wie ExtendedBrickStepper extends BrickStepper. Ansonsten wäre ein Decorator gut, aber der braucht ein Interface, also in dieser Art: public class DecoratedBrickStepper implements IBrickStepper { ... public DecoratedBrickStepper(IBrickStepper realStepper) { this.RealStepper = realStepper; } public void setSteps(int i) { RealStepper.setSteps(i); } ... }

Das hat er ja geschrieben, dass es den Callback gibt. Was thunderbird möchte ist sowas: xStepper.setStepsAndWait(10); yStepper.setStepsAndWait(10); xStepper.setStepsAndWait(10); Das würde semantisch jetzt bedeuten, dass erst 10 Steps auf der x-achse laufen. SObald die dann fertig sind laufen 10 auf der y, danach dann wieder 10 auf der x. Würde man diesen Code "nur" mit setSteps ausführen, dann würde sich alles diagonal bewegen (x und y gleichzeitig). Er wünscht sich also nur eine bequeme Variante für das was anders schon geht.

Obwohl ich noch nicht ganz verstehe wie du diese Funktion nutzen willst, wenn du mehr als eine Achse zur gleichen Zeit bewegst (diagonale Bewegung). In welcher Sprache implementierst du das ganze eigentlich? Denke die Bindings lassen sich da auf einfache Weise erweitern. Das Problem an den aktuellen Bindings ist halt, dass du für alle Bricks/Bricklets im wesentlichen nur beschränkte Funktionen anbieten kannst (da ja alles aus Config-Dateien automatisch erzeugt wird): - Funktionsrufe ohne Rückgabewert - Funktionsrufe mit Rückgabewert - Callbacks Die Funktionsrufe kehren alle so schnell wie sie können zurück, warten aber auch nur maximal ~2 Sekunden. Das heißt also so eine Funktion ist meines Erachtens nicht ohne weiteres für alle Sprachen implementierbar, sondern würde viel (strukturelle) Arbeit erfordern. Je nachdem welche Sprache du nutzt könnte ich anbieten mal eine "erweiterte" TF-Bibliothek dafür zusammenzustellen. Da könnte dieser Vorschlag drin umgesetzt werden, aber auch sowas wie die LCD-Umlaut Geschichte besser verpackt werden.

Jop... du wirst auch experimentieren müssen wie lange du leuchten willst und wie lange nciht, also wie groß deine Pulse sind. Da du ja alles in Software (und ncihtmal als Betriebssystem-Treiber) realisierst, könnte ich mir vorstellen, dass du sehr konservativ sein musst. Das findest du aber dann heraus, wenn du den ersten Code hast und schaust wie hoch die Fehlerrate wird.

Ah gut, das habe ich falsch verstanden. Denke auch, dass der SW-Anteil höher ist. Vermute für richtig hohe Übertragungsraten könnte man sich ein eigenes Plugin fürs AnalogIn und Out schreiben...

Hardwareseitig habe ich keine Ahnung, ich vermute aber wenn man die Übertragungsrate gering genug auslegt sollte alles möglich sein Was ich auf jeden Fall vorsehen wüde wäre eine Prüfsumme, zur Kontrolle der korrekten Datenübertragung. Da Pluto bisher nur von einem Analog Out und einem Analog In gesprochen hat, vermute ich, dass er nur in eine Richtung senden kann. Ansonsten würde ich villt sogar mit Quittierung arbeiten. Beispiel: Ich sende immer Pakete von x Byte, diese x Byte sind auch per Prüfsumme gesichert. Wenn ich das korrekt empfangen habe, sende ich eine Bestätigung an den Sender zurück, dass er weitermachen kann. Ich würde mich da vermutlich bei TCP inspirieren lassen und schauen was für meine Anwendung sinnvoll wäre...

Weil ich wildes Spekulieren auch cool finde habe ich mal die FW-Änderungen gelesen. Aber ob ich es verstanden habe ist eine andere Frage, ich leg mal los: Ich vermute, dass beim Master 1.0 die Kalibrierung der A-D-Wandler im Flashspeicher gespeichert wurde, der neue Master scheint das bei jedem Start selbst zu kalibrieren. *Vermutung ende* Ob und warum das toller ist als die alte Variante weiß ich nicht ^^ Aber offenbar doch "nur" eine neue Revision ^^

Habe gerade im Changelog was davon gelesen. Hat sich irgendwas von der Spezifikation her geändert oder bleibt mit der neuen HW-Version alles beim alten? (anders gefragt: gibt es spannende Änderungen ^^)

Also für alle nicht-Nutzer der WLAN-Extension hilft es ja schon den Reconnect abschalten zu können. Dann kann ich mich da selsbt drum kümmern. Ansonsten teile ich Holys Vorschlag, dass es zumindest in der API signalisiert werden sollte. Exceptions, Status-Flags, Events... Ich habe gestern abend schon drüber nachgedacht, da kam mir aber die Idee des Events (Callbacks) nicht. Möglicherweise wäre das die Beste Lösung. Weil Exceptions scheren sich nicht darum, ob es den Nutzer interessiert und das Status-Flag ist zu passiv... Man müsste es pollen. Callbacks könnte es zwei geben: ConnectionLost und Reconnected. Der erste wird nach Verlust der Verbindung ausgelöst, der zweite wenn sie wieder da ist. LG Jan

Krass... da gebe ich Holy vollkommen recht, das ist furchtbar. Insbesondere weil die Bindings den reconnect ja transparent gestalten. Ich bemerke nichtmal, dass es ab jetzt kaputt ist.

Das klingt ja alles sehr schade ^^ Das mit dem float habe ich mir fast schon gedacht, das mit den einzelnen Gettern habe ich tatsächlich nicht erwartet.

Bei mir gehts im VLC... @thunderbird: Habe den Endschalter erst für ein Distance-IR gehalten und dachte "boah, der geht aber nah dran". Dementsprechend schockiert war ich auch beim Aufprall Gehörte das Anhalten 5 cm nach dem ersten Endschalter zum Programm oder war das etwas ungewolltes?

Zumindest wäre gaghag inzwischen der nächste, der den Wunsch nach Zugriffsbeschränkung äußert (der erste war glaube ich Loeti ^^). Ich bin mir ziemlich sicher, dass das im aktuellen Protokoll nicht implementierbar ist.

Mein letzter Post war etwas wirr glaube ich, deswegen jetzt nochmal mit Struktur: Thema: Erweiterbarkeit Motivation Das neue Protokoll wird besser als das alte, aber auch inkompatibel dazu sein. Deswegen kommen jetzt bestimmt noch einige Wünsche für das neue Protokoll auf. Viele dieser Wünsche werden sicherlich erfüllt, andere möglicherweise nicht. Wenn dann etwas Zeit vergeht wird man merken, dass auch am neuen Protokoll noch etwas fehlt. Aus diesem Grund sollte man bereits jetzt darüber nachdenken, wie man das Protokoll kompatibel erweitern kann. Wenn man es richtig anstellt erhält man 2 Gewinne: 1. Das Protokoll ist ein wenig zukunftssicherer, weil es "nachrüstbar" wird 2. Spezialwünsche einiger Nutzer, die nicht für die allgemeinheit geeignet sind, lassen sich auch über Protokollerweiterungen realisieren Mein Minimalvorschlag Das neue Protokoll wird ja denke ich wie das alte "Paketorientiert" sein, das heißt ich schicke eine Binärnachricht mit bestimmter Größe durch die Gegend. Mein Vorschlag: Am Ende des regulären Paketes kommt ein Byte (im Folgenden EXT_SIZE genannt). Dieses Byte bestimmt die Größe der folgenden Protokollerweiterung. Wenn die EXT_SIZE gleich 0 ist, dann bedeutet das, dass das Paket abgeschlossen ist und nichts mehr folgt. Wenn der Wert von EXT_SIZE größer 0 ist, dann folgen noch eben so viele Bytes wie von EXT_SIZE angegeben, sowie ein weiteres EXT_SIZE. Dieses ist nun wiederum 0, wenn keine weitere Erweiterung folgt oder gibt die Größe der nächsten Erweiterung an. Behandlung Ein Brick/Bricklet/Teilnehmer der gar keine Extensions kennt oder versteht kann diese einfach überlesen und sich nicht selbst um sie kümmern. Er kann sie sogar weiterleiten, ohne sie zu verstehen (z.B. ein Master-Brick per Extension). Das gewährleistet grundsätzlich abwärtskompatibilität. Beispiel Zum besseren Verständnis ein Beispiel: Später möchte man CRC-Prüfungen des Paketinhaltes durchführen. Das heißt der Sender soll eine Prüfsumme für eine Nachricht berechnen, damit der Empfänger prüfen kann, ob die Nachricht unverfälscht ankam. Der Sender fügt hierzu eine Extension an seine Nachricht, in dieser Extension legt er die Prüfsumme des Paketinhaltes ab. Der Empfänger kann diese Prüfsumme mit der selbst berechneten Prüfsumme vergleichen. Auslassungen Mein Vorschlag lässt absichtlich einen Teil aus: Der Inhalt der Extension. Man muss sich (später) zumindest auf eine grobe Struktur einigen. zum Beispiel: Am Anfang der Extension kommt ein Byte das anzeigt, um was für eine Art von Extension es sich handelt (CRC, Passwort, Krypto, was-auch-immer), erst danach der eigentliche Inhalt. Hoffe das ist jetzt nochmal etwas klarer als mein letzter Post. ^^

In der Gefahr den Hinweis darauf übersehen zu haben: Warum sind lat/lon jeweils arrays? Was bedeuten sie? Erwartet hätte ich double ^^ edit: Ansonsten wäre ich schon noch dafür, dass es Getter für Einzelwerte gibt. Also auch GetSpeed, GetAltitude usw. GetStatus als "Sammelgetter" finde ich zwar auch gut, aber halt unpraktisch wenn man nicht alles braucht ^^

Hmmm... mir fällt auch gerade nix geschicktes für das Umstiegsproblem ein. Ich bin aber auch stark für die Überarbeitung des Protokolls, da ich auch das Gefühl hatte ihr tragt schon viele "Altlasten" mit euch rum. Außerdem habe ich einmal den brickd anpassen wollen und mich vor lauter Routing-Tabellen-Magie ängstlich zusammengekauert. Was toll wäre, ist wenn das Protokoll erweiterbar wäre. Die einfachste Form ist halt ein Byte am Ende das angibt wie viele Bytes noch für die kommende Extension folgen. Aber das ist jetzt villt schon zu weit gedacht, deswegen führe ich das nicht weiter aus ^^

danke ^^ Deswegen ja auch mein Light-Vorschlag. Der ermöglicht es jedem der einen test schreiben möchte, den relevanten Teil selbst zu bauen (z.B. mit einem Mocking-Framework oder per Hand). Die Luxus-Variante (simulierter brickd) setzt natürlich viel mehr Arbeit vorraus.

Stimmt, die Plattformübergreifende Lösung dafür wäre ja ein am Brickd simuliertes Gerät ^^ Bzw. ein Simulationskit das nen brickd enthält. Die Light-Variante wäre, dass in Sprachen wie C# und Java erstmal Interfaces für alle Devices erzeugt werden. Dann kann ich meinen Code gegen die Interfaces bauen und beliebige Bricklets durch Mocks austauschen (die dann auch nur das Interface implementieren müssen). Möglicherweise mache ich da demnächst mal nen Pull Request draus

Es wäre vielleicht wirklich eine gute Idee an einem gewissen Punkt zu sagen "das ist die API, was sagt ihr?" Dann bleibt bis zur Veröffentlichung der Hardware sogar noch Zeit inkompatible Änderungen vorzunehmen (z.B. was letztens beim Barometer-Bricklet in letzter Minute geschah).

Das wäre ja zumindest insofern kein Problem, da das Master-Brick ja auch das einzige ist, das die API für Voltage und Current anbietet oder täusche ich mich da?

Bitte Doku updaten (habe gerade C# geschaut und die ist alt)

Analog In ist die eine Variante, ansonsten eben nicht per USB sondern per Step-Down versorgen, dann sollten auch die Werte für Voltage und Current angezeigt werden.

Aus diesem Grund eben auch mein Hinweis es nciht negativ, sondern positiv zu formulieren. VOn meinem Standpunkt aus ist nciht ersichtlich warum ein sepzieller Hinweis in Richtung PayPal notwendig ist. genausogut könntest du auch eine Abneigung gegenüber einem anderen willkürlichen Dienstleister haben (wegen schlechter Vorerfahrung).

Da manche Leute villt nicht mit Fackeln hinter PayPal herlaufen wäre ich vielleicht dafür es andersherum zu formulieren: "Lastschrift wird über Heidelpay abgewickelt". Das ist toll, weil jetzt weiß Loeti, dass es nciht PayPal ist UND alle Feinde von Dienstleistern deren Namen mit H beginnen, wissen, dass sie PayPal wählen sollten.