photron

Naja, Standard FPC ist es eh nicht, weil's Object Pascal ist und -Mobjfpc braucht Aber du hast mich überzeugt.

Richtig, das geht, sieht dann aber in den Examples recht hässlich aus Ich würde dem daher fpc -Mdelphi vorziehen wollen.

Ein Brick kann per USB miximal 1000 Nachrichten pro Sekunden mit dem PC austauschen. Eine Nachricht hat 4 Byte Header und einen variablen Payload von 0 bis so ca. 20 Byte. Müsste man mal genau nachsehen was die größte Nachricht ist im Moment. Sagen wir mal durchschnittlich 4 Byte Payload. Also 8 Byte pro Nachrichten, macht 64kbit/s bei maximaler Nachrichten rate plus TCP/IP Overhead. Im Allgemeinen aber deutlich weniger da je nach Anwendung die 1000 Nachrichten pro Sekunden längst nicht ausgereizt werden. Falls du das fragst, weil du über ein schmallbandiges Medium arbeiten möchtest, dann ist wahrscheinlich die Latenz das größere Problem. Nachtrag: Was Nifty sagt

Auch select ist eine Art poll Auf Getter Aufrufe muss eh explizit gewartet werden. Was du da tust ist im Prinzip das was in ich PHP getan habe. Ist also legitim, wenn man keine Threads hat oder verwenden will. Allerdings sehe ich das ausgewählte Warten von brick::wait nicht als nützlich an, da dies nicht der Normalfall sondern ein Sonderfall ist. Dazu kann man mehrere IPConnection Objekte verwenden. Wir ändern das brickd Konzept nicht. Ich hatte mit da nicht ausführlich genug ausgedrückt. brickd als Programm auf dem PC bleibt wie es ist. Es wird aber demnächst die WIFI Extension geben. Und bei der läuft brickd dann im Prinzip auf dem Master Brick. Dass heißt du stellst eine TCP/IP Verbindung direkt mit dem Master Brick her ohne einen brickd auf dem PC dazwischen. Dieser spezielle brickd auf dem Master wird bedingt durch Hardwarebeschräkungen wahrscheinlich nur eine TCP/IP Verbindung unterstützen. Dies funktioniert mit unseren bisherigen Bindings, da sich hier Bricks eine TCP/IP Verbindungs teilen können. Mit deinen Perl Bindings könnte man pro Stack mit WIFI Extension nur einen Brick oder Bricklet ansprechen.

Jetzt hab ich ein Problem. Mit -Mobjfpc muss ich den @-Operator verwenden um die Adresse einer Methode zu bekommen: stepper.OnPositionReached := @ReachedSteps; Mit -Mdelphi darf ich den @-Operator nicht verwenden. Weiss da jemand eine elegante Lösung für? Nachtrag: Wahrscheinlich ist die einfachste Lösung einfach fpc -Mdelphi zu benutzen.

Das darfst du ruhig tun, wir haben da kein Problem mit

Das sieht viel besser aus als die Perl Bindings die hier letzten vorgestellt wurden, die mit XS aus den C Bindings gewrappt wurden Zwei Verbesserungsvorschläge hab ich allerdings für Dinge bei denen du vom allgemeinen Konzept der bisherigen Bindings abgewichen bist: 1) Du verwendest pro Brick(let) eine eigenen Socket. Mit dem jetzigen brickd funktioniert das, da der mehrere TCP/IP Verbindungen verwenden kann. Die WIFI Extension wird aber wahrscheinlich nur eine einzige TCP/IP Verbindungen unterstützen. Dann funktionieren deine Bindings nur noch für einen Brick im Stack. Unsere bisherigen Bindings haben eine IPConnection, die einen Socket hat den sich alle Brick(let)s teilen. 2) Du pollst die Callbacks mit brick::wait. Ja, die PHP Bindings tun das auch, aber nur weil es in PHP keine Threads gibt. Die übliche Vorgehensweise ist es, dass die IPConnection zwei Threads hat. Einen der eingehende Daten vom Socket ließt und einen der sich um die Ausführung von Callbacks kümmert. Dadurch passiert das ganze im Hintergrund und der Benutzer muss sich nicht explizit darum kümmern. Oder hast du spezielle Gründe für diese Abweichungen, die mir entgangen sind?

Auch neue Firmwares und Plugins werden in dem Thread aufgeführt werden. Ich hab da gerade mal einen Eintrag für das neue Joystick Plugin 1.1.4 von letzer Woche gemacht.

Joystick Bricklet Plugin 1.1.4 Fix threshold period logic. Since version 1.1.3 the Position Reached callback was triggered despite a Threshold Period of 0 (Callback disabled). Download: Plugin

Joystick Bricklet Plugin 1.1.4 Threshold Period Logik korrigiert. Seit Version 1.1.3 wurden trotz einer Threshold Period von 0 (Callback deaktiviert) Position Reached Callbacks ausgelöst. Download: Plugin

pluto, ich bin gerade noch am rumreißen, morgen oder so hab ich wahrscheinlich was das ich dir zum Testen geben kann. Bezüglich Delphi/Lazarus/FPC: Wir wollen da eine breite Abdeckung auf Basis von Object Pascal haben. Im Moment verwendet ich FPC mit -Mobjfpc Option. Derzeitiges Ziel ist, dass die Bindings mit der kommerziellen Delphi IDE von Embarcadero funktionieren sowie mit FPC auf Linux, Windows und Mac OS (unter der Annahme das es FPC für Mac OS gibt).

ArcaneDraconum, das brickd nicht in der Softwareliste in der Systemsteuerung auftaucht, ist ein Bug der in Version 1.0.8 jetzt behoben ist. Auch haben diese Einträge für brickd und brickv jetzt eine Versionsnummer. Loetkolben, ich hab hier einen Thread dafür begonnen: http://www.tinkerunity.org/forum/index.php/topic,673.0.html

Brick Viewer 1.1.2 Use correct write_line signature in LCD 16x2 plugin Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.1 Improve flashing error messages File dialogs remember the last directory "Show this message again" checkbox in error messages work Store host and port information across brickv restarts Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.2 LCD 16x2 Plugin verwendet jetzt richtige write_line Signatur Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.1 Verbesserte Flashing Fehlermeldungen Datei-Öffnen Dialoge merken sich das zuletzt verwendete Verzeichnis "Show this message again" Checkbox in Fehlermeldungen funktionieren Host und Port Einstellung werden gespeichert Downloads: Windows, Linux, Mac OS X

Brick Daemon 1.0.8 Break a reference cycle between USBDevice and USBTransfer objects Add date to log output Fix stack ID routing for enumerate with multiple connected stacks Add --version commandline argument Downloads: Windows, Linux, Mac OS X

Brick Daemon 1.0.8 Reference Cycle zwischen USBDevice und USBTransfer Objekten gebrochen Datum in Logeinträgen Stack ID Routing für Enumerate mit mehreren verbundenen Stacks korrigiert Kommandozeilenparameter --version hinzugefügt Downloads: Windows, Linux, Mac OS X

There was no central place for announcements about new versions of Brick Daemon and Viewer, the different programming language bindings as well as firmwares and plugins. This thread is going to improve this. New software and hardware will be announced here

Bisher gab es keine zentrale Stelle an der auf neue Versionen von Brick Daemon und Viewer, der verschiedenen Programmiersprachen Bindings sowie Firmwares und Plugins hingewiesen wurde. Dieser Thread soll dem nun Abhilfe schaffen. Hier wird zukünftig auf die Veröffentlichung neuer Software und Hardware aufmerksam gemacht

Seit einer Weile steht die Brickv Version in der Titelleiste des Hauptfensters. Brickd hat heute mit Version 1.0.8 ein --version Kommandozeilenparameter bekommen. Darüber hinaus haben jetzt auch Brickd und Brickv im Programmefenster der Systemsteuerung unter Windows ihre Versionsnummer im Namen des Eintrags.

Vom Log her sieht das Problem exakt so aus wie beim letzten Mal. Der Read Callback ist fehlgeschlagen und dann ging nix mehr. Das ein Neustart von brickd reicht um das Problem zu beheben deutet darauf hin, dass brickd da möglicherweise zu pessimistisch ist. Mich interessiert sehr ob meine vorgeschlagene Änderung in usb_device.py ('self.alive = False' in Zeile 304 auskommentieren) nicht schon reicht um einen Teil es Problems zu beheben. Nämlich den Teil bei dem in brickd Neustart alleine hilft. Das ist möglich, es gibt hier im Forum in paar Leute die definitiv mit EMV Probleme haben. Wir denken da im Moment über Lösungen nach wie man das längerfristig hardware- und softwaremäßig robuster machen kann im Hinblick auf EMV. Das ist allerdings nichts was eben auf die Schnelle geht. Du könntest mal Xennas Lösung testen. Da hat es geholfen die Bricks und Bricklets in eine Keksdose aus Metal zu stecken und so zu schirmen: http://www.tinkerunity.org/forum/index.php/topic,601.msg4008.html#msg4008 Das mag für deine Temperaturmessung nicht die idealste Lösung sein Ansonsten kann ich nur nochmal raten die 100kHz Firmware für das Temperature Bricklet bei Gelegenheit zu testen.

Nifty, danke für den Hinweis. Das Problem ist in Version 1.1.2 behoben.

pluto, das ist ja mal ganz schön von hinten durch die Brust in's Auge Ich sehe aber gerade gar nicht warum du das so tust. Ich bin gerade mit den Delphi Bindings beschäftigt und das läuft wunderbar unter Lazarus Die Timeline setzt Delphi Bindings für nächste Woche an. Ich denke das kann ich einhalten.

Brick Viewer 1.1.1 merkt sich jetzt was du für Host und Port eingestellt hast.