Jump to content

AuronX

Members
  • Gesamte Inhalte

    886
  • Benutzer seit

  • Letzter Besuch

Posts erstellt von AuronX

  1. Ich habe tatsächlich nciht wirklich viel Ahnung von Treiberentwicklung, aber folgendes scheint für Windows genau das richtige zu sein:

     

    https://code.google.com/p/vmulti/

     

    Wenn ich es richtig verstehe ist es ein HID-Treiber, mit dem du alle Geräteklassen emulieren kannst. Der Ordner test (im Quellcode) scheint dann diesen Treiber anzusprechen, um irgendwelche Pseudo-Inputs zu senden. An dieser Stelle müsstest du also deine TF-Interaktion einbinden können. Oder ein C-Interface schaffen und dann aus einer cooleren Sprache darauf zugreifen. Aber wie gesagt, ich habs auch nur überflogen.

     

    Unter 64 Bit Windows wirst du allerdings Probleme haben, weil dort (aus Sicherheitsgründen) nur signierte Treiber geladen werden dürfen. Eine schnelle Google Suche nach "Win 64 unsigned drivers" hat aber auch Ergebnisse zu Tage gefördert... Allerdings scheint man nicht selektiv nur einem Treiber vertrauen zu können, du kannst den Signaturcheck dann also unr komplett ausschalten. (Oder viel Geld in die Hand nehmen und deinen Treiber signieren ^^)

  2. Ich gehe gleich schlafen, aber ich versuche in Kürze die wichtigsten Links zu sammeln.

     

    Im wesentlichen sieht es wie das obere Beispiel hier aus:

    http://www.tinkerforge.com/de/doc/Software/IPConnection_CSharp.html#ipcon-csharp

     

    ipcon.EnumerateCallback += EnumerateCB;
    ipcon.Enumerate();

     

    Dieser Teil kann irgendwo rein wo es dir bequem ist, ich würde zum Beispiel das FormLoad-Event empfehlen.

     

    Im Callback (hier EnumerateCB) musst du beachten, dass dieser in einem neuen Thread läuft, du kannst also nicht ohne weiteres die GUI verändern. Dazu musst du Code Invoken, etwa so:

    Invoke(new Action(() =>
                    {
                        MyTextBox.Text = "some data from my callback";
                    }));

    (dieser Code wurde schnell von mir Zusammenkopiert)

     

    Mehr Details zu Invoke: http://msdn.microsoft.com/de-de/library/zyzhdc6b(v=vs.110).aspx

     

    Ich hoffe ich konnte dir einige Anhaltspunkte liefern. Ansonsten schreibe einfach was dich derzeit blockiert und am besten auch den Code den du nutzen wolltest um das Problem zu lösen.

  3. Zu Frage 3: Hier ist meine persönliche Meinung, dass Einheiten nicht auf allen Sprachen implementiert werden sollten, weil sie nicht überall Sinn machen.

     

    Ich würde sie nur in den Sprachen unterstützen, die es leicht machen sie auch bequem zu benutzen. Damit verzichtet man natürlich auf Einheitlichkeit zwischen den Bindings, aber ich habe die Befürchtung, dass diese Einheitlichkeit mehr kostet, als dass sie etwas nützt.

     

    Zu Frage 4: Für mich ja!

     

    Frage 2 muss Je nach Einheit diskutiert werden und bei Frage 1 würde ich auch lieber Feedback abwarten bevor ich mich äußere :D

  4. Ich versuche mal die Diskussion über API-Änderungen zu strukturieren, indem ich für dieses Thema einen eigenen Thread eröffne.

     

    Idee

    Die Tinkerforge-API sollte Einheiten nativ unterstützen, um so die Arbeit zu erleichtern und die Selbstdokumentation des Codes zu verbessern.

     

    Beispiel

    (dient nur dazu die Idee zu verdeutlichen, kann vom Endergebnis abweichen)

     

    Distance distance = myBricklet.GetDistance();
    if(distance > 20.Millimeters() && distance <= 2.Meters())
    {
      Console.WriteLine("Die Distanz beträgt {0} Zentimeter", distance.InCentimeters);
    }

     

    Überlegungen

    Um soetwas zu unterstützen müssen verschiedene Dinge getan werden:

    • Die Konfigurationen der Bricklets müssen die Einheiten der Werte kennen (Hat nur etwas mit den Bindings zu tun, keine Auswirkungen auf Speicherplatz o.ä. auf den Bricklets)
    • Die unterstützten Einheiten müssen in allen (vorgesehenen) Sprachen einen eigenen Typ (Klasse/Struct) haben

     

    Frage 1: Generieren oder selber bauen?

     

    Die erste Frage die ich mir stellen würde:

    Werden die Typen der Einheiten generiert oder manuell erstellt?

     

    Beim Generieren sehe ich den Vorteil darin, dass es vermutlich einfacher umzusetzen ist. TF definiert einmal (ähnlich wie bisher für Bricklets) einen Satz an Einheiten und dann werden dafür Typen erzeugt. Das funktioniert vermutlich deswegen leicht, weil Einheiten immer gleich sind:

     1 km = 1000 m
    1000 mm = 1 m
    
    1 kV = 1000 V
    1000 mV = 1 V

     

    Allerdings denke ich, dass man bei händischen Implementierungen Korrelationen zwischen Einheiten besser abbilden kann. Also dass man beispielsweise Volt und Ampere multiplizieren kann. Ich wüsste nicht, wie ich das in eine generische Konfiguration schreiben wollte.

     

    Frage 2: Was ist die Basiseinheit?

     

    Wie auch immer diese Klasse (z.B. Distance) erzeugt wird, sie muss den aktuellen Wert (etwa die Entfernung) speichern. Ich habe mich dafür entschieden (in meiner Bibliothek), dass ich die Entfernung als Integer speichere und damit die Länge in Millimetern zähle.

     

    Die Folgen dieser Entscheidung:

    • Ich werde niemals genauere Auflösungen als mm unterstützen
    • Die maximale Distanz beträgt ca. 2000 km (das Maximum von Int32 in Millimetern)
    • Alle Distanzen (unabhängig von der Sensorauflösung) belegen 4 Byte Arbeitsspeicher (Kritisch bei embedded Anwendungen?)

     

    Für mich ist das nicht kritisch, notfalls ändere ich diesen Typ so wie ich es brauche. Wenn TF das in die API einbaut, dann ist das in Stein gemeißelt... Choose wisely!

     

    Frage 3: Alle Sprachen unterstützen?

     

    Sollen die Bindings für alle Sprachen solche Dinge unterstützen? Ich weiß es nicht... Ich kann mir nicht vorstellen, dass es in den C-Bindings mehr Spaß macht mit solchen nativen Typen zu arbeiten...

     

    Andererseits waren bisher alle Bindings möglichst identisch... würden dadurch Unterschiede eingeführt die schlecht sind?

     

    Es gibt halt Sprachen, bei denen sich Einheiten wirklich gut lesbar einbauen lassen (C#-Beispiel siehe oben... noch besser: Ruby) und es gibt Sprachen, bei denen ich befürchte, dass es einfach alles nur schlimmer machen würde ©.

     

    Frage 4: Besteht überhaupt Bedarf/Nachfrage?

     

    Wichtige Frage... Vielleicht will das auch gar keiner...

     

    Das sind die Diskussionspunkte die mir unmittelbar eingefallen sind. Bestimmt gibt es noch mehr Diskussionspunkte zu diesem Thema.

     

    Meine persönliche Meinung werde ich (sofern es mir gelingt) aus diesem Posting heraushalten und nur in einer Antwort präsentieren.

  5. Soetwas habe ich tatsächlich bisher nur in einer eigenen Bibliothek implementiert. Wäre natürlich eine coole Idee sowas direkt in den Bindings zu haben...

     

    Distance dist = myBricklet.GetDistance();
    if(dist > 20.Millimeters() && dist <= 2.Meters())
    {
      //do something awesome
    }

     

    Ich denke da mal drüber nach... Aber bevor man sowas überall einbaut gibt es glaube ich verschiedene Einzelpunkte, über die man mit vielen Leuten sprechen möchte :D Ich versuche mal eine Liste zu machen ^^

  6. Ja klar, abgesehen davon, dass es jeder selbst machen muss.

     

    Grundsätzlich gestehe ich ja auch ein, dass es Dinge gibt die nicht in die Bindings gehören. Aber von mir oben genannte Punkte sind alle sehr einfach generierbar und ich halte es für eine Altlast, dass sie so sind wie sie sind.

     

    edit: Gerade habe ich noch borgs Kommentar im anderen Thread gelesen. Den Teil mit dem "wenig Code aufzwingen" verstehe ich quasi schon. Allerdings sehe ich auch, dass Abweichungen von Sprachkonventionen einem Entwickler dort ebenfalls "Schmerzen" verursachen.

     

    Ich habe mich inzwischen damit abgefunden, dass manche Dinge nicht mehr verändert werden... Aber wenn sich herausstellt, dass ich nicht der einzige bin der sich daran stört, dann würde ich einige Änderungen gerne nochmal zur Diskussion stellen ^^

  7. Allgemein

    Wenn du nur für dich die Bindings verbessern möchtest (wäre legitim), dann kannst du alles tun was du willst. Bedenke jedoch, dass Verbesserungen für alle (aka. TF übernimmt diese Änderungen) bestimmten Einschränkungen unterliegen:

     

    [*]Die Bindings werden automatisch generiert (aus Informationen die für alle Sprachen genutzt werden

    [*]Die Methoden eines Brick/Bricklet sind 1:1 Abbildungen dessen was die Hardware bietet, manche Abstraktion bleibt dabei auf der Strecke

    [*]TF versucht bei allen Änderungen Abwärtskompatibilität beizubehalten

     

    Die Abwärtskompatibilität wird natürlich bei vielen guten Vorschlägen gebrochen. Da muss man schauen ob man TF (und die Nutzer) davon überzeugen kann, dass es das Wert ist. Da ich bereits festgestellt habe, dass auch andere sich Verbesserungen wünschen könnte es ja durchaus eine kritische Masse geben, um einen solchen "Umbruch" zu ermöglichen.

     

    Die Frage ist also, ob genügend Leute sich an den Problemen stören, dass ein inkompatibler Umbruch möglich wäre. Ich weiß nicht wie TF dazu steht und wie sehr sich andere an der derzeitigen API stören...

     

    Um welche Änderungen geht es?

     

    Wenn du nichts dagegen hast würde ich deinen Thread für eine Anforderungsliste missbrauchen (die du gerne auch an die Spitze stellen darfst wenn sie dir gefällt/du sie vervollständigen willst):

    • Alles ist ein Interface
    • enums nutzen anstatt kommentierter ints
    • Version in eigenen Typ auslagern
    • UID in eigenen Typ auslagern
    • ...

     

    Ich habe diese Liste auch um einen eigenen Vorschlag ergänzt... (auch älter ^^)

     

    Enums statt ints

     

    Ich hatte hier tatsächlich schon vor Ewigkeiten mal einen Branch rumzufliegen der DeviceIdentifier in den C#-Bindings einführt (hier ist er). Aber ich weiß nicht mehr warum ich aufgehört habe das zu verfolgen.

     

    Alles ist ein Interface

     

    Für alles interfaces zu erstellen hatte ich auch schonmal im Sinn, habe mich dann aber nicht dazu durchgerungen den Vorschlag einzubringen, weil er hoch inkompatibel wäre, ich wusste damals dass dies so nicht umgesetzt würde...

     

    Viele Grüße

    Jan

  8. Ich würde mich sehr über etwas konstruktivere Kritik freuen. Also der Teil mit "Kritik" war schon da, jetzt noch der Teil mit "konstruktiv"...

     

    Wo war die Doku schlecht? (das war bisher nie ein Mangel für mich)

     

    Dass an manchen Stellen die Bindings nicht optimal sind, weiß ich... mich würde da interessieren wo bei dir der Schuh drückt, da ich gerade bei den C#-Bindings ein wenig zur Qualitätssteigerung beigetragen habe.

     

    Vielleicht noch zum Verständnis: Die meisten API-Funktionen werden bei TF generiert, damit die Vielzahl an Bricklets und Sprachen unterstützt werden kann. Ich finde es aber nciht vollkommen abseits der Objekt-Orientierung was hier passiert, da würde mich deine Kritik am meisten interessieren.

     

    Viele Grüße

    Jan

  9. Aber wenn du schon einen Bestücker mit sowas beauftragst... ist es dann nicht ein leichtes die Einzelteile selbst zusammen zu suchen?

     

    Oder ist das nicht so leicht möglich? (ich würde nichtmal den Bestücker finden ^^)

  10. Ich würde Wikipedia-Artikel (oder andere Quellen) zu den Begriffen HSV und HSL empfehlen. (Hue, Saturation, Lightness/Brightness)

     

    Das sind Farbmodelle die genau das von dir beschriebene Problem addressieren. Da kannst du einmal die Umrechnung implementieren (wenn deine Standardbibliothek nicht schon soetwas bietet) und dann einfach die Umrechnung nutzen.

×
×
  • Neu erstellen...