AuronX

Historisch ist die korrekte Antwort:

Am Anfang war der brickv mitsamt samba.py. Als ich also das Flash-Tool geschrieben habe, habe ich es zum brickv geschoben, um diese Datei nicht kopieren zu müssen (Code-Duplikation vermeiden).

Wenn man es ganz genau nimmt müsste mit den einzelnen Komponenten folgendes passieren (aus einer modularen Sicht):

- samba.py wandert in eine flash-library, also eine eigenständige Bibliothek um flashen zu können. Möglicherweise  auch eine TFLib, für alles mögliche das mit TF zu tun hat

- brickv bleibt alleine und hängt von der FlashLib/TFLib ab

- flash-cli wandert in eigenes Paket und hängt ebenfalls von der FlashLib/TFLib ab (man könnte auch argumentieren, dass die flash-cli zum brickd wandert und dieser von der Lib abhängt, allerdings würde dann der neue C-brickd von Python abhängen)

Es ist zweiteilig:

Das tatsächliche Bricklet (also die Hardware) sendet dann die Callbacks aus, wenn beispielsweise bei der Temperatur die CallbackPeriod gesetzt ist. Alles weitere interessiert das Bricklet nicht.

Deine Bindings hingegen merken sich nun welche Listener jeweils registriert sind und stellen das jeweils zu sobald eine Nachricht vom Bricklet kommt.

Methoden zum einzelnen Entfernen sollten meiner Erinnerung nach gut möglich sein. Bei den Is*-Methoden würdest du halt abfragen ob gerade ein Listener registriert ist, aber NICHT ob auch die entsprechende Period einen Wert > 0 hat. Das müsstest du dann in zwei Abfragen erledigen wenn du beides wissen willst.

Also alle anderen genannten deckten auch beide Welten ab ^^ Bei Ruby bin ich mir auf dem RaspPi nicht so sicher.

@Editor für python: Für den Anfang sollte ein normaler Editor mit Syntax-Highlighting reichen. Mit Pyhton mitgeliefert ist auch IDLE, den kann man auch nutzen, habe ich aber persönlich nciht ausprobiert... viele lieben ihn aber.

Es wird dann ja auch noch ein eigenes .deb dafür geben, das dann python-argparse und python-serial als Abhängigkeiten haben wird.

Ich glaube genau das war es was Loeti meinte. So war das CLI-Tool zwar enthalten aber das deb hat nicht alles installiert was nötig war.

Zur Orientierung:

Plattformunabhängigkeit

Python, C#, Java und PHP sind alle plattformunabhängig. Das heißt für alle gängigen Plattformen sind Laufzeitumgebungen verfügbar.

Zukunftssicherheit

Python, C# und Java sind derzeit weit verbreitet und sie werden noch immer aktiv gepflegt und weiterentwickelt. Beides sind recht gute Kriterien, um die Zukunftssicherheit zu bewerten. Bei PHP habe ich das Gefühl, dass die Verbreitung inzwischen stark zurückgegangen ist. Es gibt natürlich noch viele große Projekte in PHP, aber ich glaube wenn heute auf der Web-Schiene etwas neues entwickelt wird, dann eher mit Ruby on Rails (Ruby) oder Django (Python). Nichts-desto-trotz wird PHP wohl noch immer weiterentwickelt. Aber dort sehe ich die geringsten Zukunftsaussichten.

Anfängerfreundlichkeit

Hier weiß ich nicht wirklich wie ich das objektiv bewerten kann. Ich halte Python für etwas Anfängerfreundlicher, weil es dich zwingt deinen Code korrekt einzurücken... Andererseits finde ich die statische Typisierung von C# und Java auch gut. Wie finden Anfänger das? kA...

edit: ich habe mal noch PHP ergänzt, weil das ja auch öfter erwähnt wurde

Ich würde von PHP abraten...

C#, Java, Python sind alle cool (meine Meinung)

Python ist meiner Ansicht nach für blutige Anfänger am Besten geeignet.

Ich denke mal immer an oder?

Ansonsten musst du dein IO4 in den Stack verbinden... dann ist die ganze Ästhetik wieder dahin ^^

Das ganze nennt sich Graycode.

Du hast mich gerade ins erste Semester zurück versetzt! Cool ^^ Wenn ich mich nur erinnern könnte was das gute am Gray Code war... Fehlertoleranz? Keine Ahnung ^^

*geht wieder*

Naja es geht doch um Stacks mit DC-Brick.

Wenn dort der Lüfter das lauteste ist, dann bin ich enttäuscht ^^

Welches arme Brick musste denn dafür sterben? ^^

Du möchtest damit dann ein DC-Brick oder Stepper-Brick kühlen oder?

Kann der Lüfter auch noch seine Arbeit leisten wenn ein anderes Brick drüber montiert wurde?

So ist das auch nicht gedacht. Du nutzt nur SetMonoflop mit true und SetState mit false. Das bedeutet wenn die Verbindung nach einem SetState(false) abbricht, dann bleibt es aus. Wenn sie nach einem SetMonoflop(true) abbricht, dann geht es von alleine aus, wegen des Monoflop-Counters.

Sehr einfaches Beispiel:

while(true)
{
  if(temp < minimumTemp)
  {
    relay.SetMonoflop(1, true, 12000);
  }
  Thread.Sleep(10000); //etwas kürzer schlafen als das Monoflop dauert, sonst schaltet sich das Gerät zwischendurch jedes mal kurz aus
}

Ja das wird auch passieren. Aber dein Programm wird bestenfalls mitbekommen, dass die verbindung getrennt wurde, aber nicht wann der Counter das Relay zurücksetzt.

Vollkommen korrekt, du brauchst dafür dann zwingend den Server. Mir fällt auch gerade keine passende Fallback-Lösung für so einen Ausfall ein (außer irgendwo einen Ersatzschalter zu platzieren der das Dual-Relay-Bricklet umgeht)

http://www.tinkerforge.com/de/doc/Software/IPConnection_CSharp.html#callbacks

Mögliche Enumerierungsarten sind:

IPConnection.ENUMERATION_TYPE_AVAILABLE (0): Gerät ist verfügbar (Enumerierung vom Benutzer ausgelöst).

IPConnection.ENUMERATION_TYPE_CONNECTED (1): Gerät ist neu verfügbar (Automatisch vom Brick gesendet nachdem die Kommunikation aufgebaut wurde). Dies kann bedeuten, dass das Gerät die vorher eingestellte Konfiguration verloren hat und neu konfiguriert werden muss.

IPConnection.ENUMERATION_TYPE_DISCONNECTED (2): Gerät wurde getrennt (Nur bei USB-Verbindungen möglich). In diesem Fall haben nur uid und enumerationType einen gültigen Wert.

Das Ende der Enumeration ist nicht explizit feststellbar, weil das der Stack auch nicht "weiß". Aber es gilt die Regel wenn du 2500ms keine Antwort erhältst, dann ists wohl fertig. (weil 2500ms default timeout ist)

Naja... du bist halt mit dem Brickd verbunden. Ob dort ein Brick/Bricklet angeschlossen ist findest du nur raus indem du eine Anfrage rausschickst und schaust ob es klappt. Also genau so wie du es tust ^^

Bei der WiFi-Extension könntest du natürlich davon ausgehen, dass auch etwas da ist wenn du eine Verbindung hast.

Ich denke das IO16 kannst du sogar knapper beschalten, zumindest wenn ich deinen Schalter richtig verstehe:

Mitte des Schalters mit dem 5V-Ausgang des IO16 verbinden (der ist immer High),

die anderen beiden enden wie gehabt. Insbesondere verstehe ich im aktuellen Design nicht, warum du den mittleren Kontakt des Schalters zweimal mit dem IO16 verbindest.

Aber vorsicht: So viel Ahnung habe ich gar nicht von Elektronik

Meinst du das MonoflopDone event?

Das kommt definitiv nur dann, wenn du auch verbunden bist.

Callbacks werden von einem eigenen Thread abgearbeitet. Unter normalen Umständen sollten Callbacks ohne weitere Verzögerung abgearbeitet werden.

Noch ein kurzer Disclaimer, weil Plenz seine Schwierigkeiten mit Threads angedeutet hat: Während du einen Callback verarbeitest läuft dein Code im einzigen Thread der Callbacks ausliefert. Das heißt wenn du dort lange rechnest, dann verzögert das schon die folgenden Callbacks. Wenn deine Hauptarbeit im Main-Thread läuft und deine Callback-Verarbeitung schnell geht, dann ist das aber alles kein Problem ^^

Genau. Durch Monoflop kann die verbindung wegfallen und er schaltet trotzdem ab.

Durch das Mono-flopping wird der heizer von alleine wieder ausgehen. Allerdings musst du nach dem Starten der Erhitzung selbst die Zeit A+B abwarten, um dann den Heizer wieder erneut einzuschalten.

Insbesondere: Mit der Einschränkung "nur LAN oder WLAN" kann man auch einfach eine unabhängige IP-Kamera dranhängen die auch nichts mit TF zu tun haben muss...

Server 2008 gehört wenn cih mcih nciht total täusche noch zur Vista oder Win7-Linie... auf jeden Fall ist erst Server 2012 aus der Windows 8-Linie.

Dem Durchstreichen entnehme ich, dass du das Problem mit deinem DualRelay schon selbst gelöst hast ^^

Möchtest du noch kurz mitteilen, woran es lag? (einfach, damit ich ein besseres Gefühl für "Standardprobleme" bekomme )

@FlyingDoc: Danke für die Erklärung, aber so war das nicht gemeint ^^ Mir war nicht klar wo er ein Array erwartet ^^

Und noch als Ergänzung: In C# (und auch in allen anderen Sprachen die mir gerade einfallen) haben Arrays immer eine feste Größe. Für dynamisches Resizen gibt es dann üblicherweise verschiedene Klassen, die meist entweder auf Arrays aufbauen (und beim Vergrößern alles von einem ins nächste kopieren) oder als verkettete Listen arbeiten.

@CChris: schön zu sehen, dass es geholfen hat und du schonmal anfangen konntest

Im Anhang findest du ein Programm, dass für deine Tests ausreichen sollte ^^ Das simuliert einen Stack, du kannst es also nutzen bis deine echte Hardware da ist.

Starten und dann auf localhost:4224 verbinden.

Enumerate-Callback und einige Basis-Funktionen funktionieren.

Was du mit dem Array meintest habe ich nicht verstanden...

TFStackEmulator.zip