AuronX

Ich würde auch empfehlen entweder direkt PHP-Bindings zu nutzen. Ansonsten ist die unnötige Rechenarbeit riesig: - Prozess erzeugen - Programm vom Speicher (SD/HDD) laden - TCP-Verbindung aufbauen Die beiden letzten Punkte bedeuten jeweils unnötigen IO. IO ist immer langsam ^^

Ob Gerät dran ist und funzt sollte egal sein für die Verbindung... Schau mal ob der Brickd-Service bei den Windows-Diensten auftaucht und auch läuft. Falls nciht liegt es daran, ansonsten könnte noch eine zu aggressive Firewall (auf dem Rechner installiert) stören...

Du nutzt ja win32com. Steht da etwas in der Doku zum Thema initialisierung? Es sieht so aus als wurde die COM-Bibliothek nicht initialisiert, das sollte dir vermutlich die Bibliothek win32com abnehmen, ich vermute dir wird ein methodenaufruf fehlen. Ein kurzes google führt mich zu diesem Tipp: iTunes.initialize() (ich kenne die bibliothek win32com nciht)

Ich will hier nciht den Glaubenskrieg im FOrum anzetteln, der wird im restlichen Internet genug geführt... In C ist auch Speicherverwaltung nötig, die einen machen sie nicht und haben deswegen Mem-leaks, die anderen machen es und kommen bei großen Anwendungen auf die Idee "kluge Pointer" zu nutzen, das ist auch nur nen verkleideter GC. Das mit dem Late Binding ist ein Punkt der auch C/C++ trifft. In C# beispielsweise ist es genau wie dort: Nur virtual/abstract kann überschrieben werden (während in java alles überschrieben werden kann was nciht final ist, also nur umgekehrte Logik).

P.S.: Beide Brillen existieren noch nicht oO

kurzer Ausflug: Wenn du deinen C Code kompilierst, dann wird daraus durch den Compiler Maschinencode erzeugt, also Code der unmittelbar durch den Prozessor ausgeführt werden kann. Wenn du deinen Java-Code kompilierst, dann wird daraus Byte-Code, dieser kann nicht von der CPU ausgeführt werden, bei Java gibt es den Just-In-Time-Compiler (JIT) der den Bytecode während der ausführung zu Maschinencode umwandelt, deswegen sind Java-Programme auch grundsätzlich Plattformunabhängig. Wenn du C-Code kompiliert hast wirst du soetwas wie Optimierungen kennen. Dabei verändert der Compiler den Maschinencode so, dass er schneller ausgeführt werden kann, aber äquivalent zur Eingabe ist. EInfaches Beispiel: for(int i=0;i<3;i++) rufeMethode(); daraus kann der Compiler dann auch das machen (dargestellt als C-Code): rufeMethode(); rufeMethode(); rufeMethode(); Der Prozessor muss gar keine Sprünge mehr ausführen (wie es bei der Schleife nötig wäre) und der Code ist schneller. Der JIT kann das auch machen, aber es dauert halt länger solche Stellen zu finden. Für den C-Compiler ist es egal, der hat Zeit. Der JIT soll halt "in-time" arbeiten, deswegen wird er hin und wieder den Code nur "einfach kompilieren", dann wird dieser langsamer ausgeführt als äquivalenter (und optimierter!) C-Code. Auf der anderen Seite kann der JIT bei Methoden die schnell sein müssen sich auch später nochmal "Mühe geben" und sie dann halt optimiert kompilieren. Der JIT hat sogar einen Vorteil gegenüber dem C-Compiler: Er kennt die Laufzeitcharakteristik deines Programms, er kann wissen welche Methoden wie oft gerufen werden und dadurch besser optimieren. Bei C# sieht das alles übrigens ähnlich aus, es gibt auch Zwischencode der live zu Maschinencode wird. Selbstverständlich war das alles jetzt ziemlich kurz dargestellt, aber das Fazit sollte ungefähr dieses sein: Java-Code ist nicht per se langsamer, er wird es an manchen Stellen aufgrund schlechter JIT-Entscheidungen sein, an anderen kann er aber auch schneller sein als der meiste C-Code. Letztendlich mact den größten Performance-Unterschied die Wahld er richtigen Algorithmen aus, nicht die Wahl der richtigen Programmiersprache.

Java kann btw. locker genauso schnell wie C sein. Prinzipiell liegt es am Ende nur daran, dass der JIT guten Code erzeugt ^^ Man kann mir gerne erzählen, dass Java ein anderen Speicherverhalten hat als C (klar, weil C nicht managed ist), aber irgendwann sollte man mal damit aufräumen, dass C "automagisch" schneller ist weil es eben C ist.

@Flo: Nachdem ich gerade diesen Tweet gelesen habe wollte ich hier als Retter in der Not auftauchen ^^ Jetzt hast du meinen Auftritt versaut

Ich denke auch subdomains sind der schönste weg. Gut wäre es wenn zwischen den Sprachversionen verlinkt wird wie in der Wikipedia. Also, dass es auf der deutschen ServoBrick-Seite irgendwo Links zur Englischen (und anderen) Versionen gibt.

@TF: Gibt es bei Digital irgendwelche Standard-Protokolle? Mir war nciht bewusst, dass ihr auch Digital sprecht, deswegen die Frage...

Interessant... das wusste ich nicht! Dachte TF kann nur Analog ^^

Sieht gut aus... einzige Gegenanzeige wäre wenn es eienr der Digitalservos von robbe wäre, aber darauf konnte ich keinen Hinweis in der Beschreibung entdecken ^^

Ich befürchte nicht, hier wäre dann doch wieder ein spezieller Linux-treiber gefragt falls es nicht möglich ist die Kalibrierung an einem anderen Gerät (mit Windows) durchzuführen...

Ich bin kein Treiber-Entwickler, deswegen erschießt mich bei Fehlern: H.I.D. ist meines Erachtens ein Standard für Hardware-Interoperabilität. Das heißt wenn ich eine HID-Konforme Maus habe, dann kann ein Betriebssystem, dass über einen HID-Treiber verfügt mit dieser umgehen. Der Trick dabei ist ja genau, dass der Hersteller der Maus keinen eigenen Treiber beilegen muss, weil er "weiß" wie der Treiber aussieht der benutzt werden wird. Deswegen sind m.E. HID-konforme Geräte per se Linux-kompatibel, weil Linux HID-Treiber mitbringt. Das sollte analog zu "Wechseldatenträgern"/"Massenspeichern" sein, auch für diese gibt es inzwischen Standard-Treibermodelle, wodurch diese ohne Installations-CD auskommen. Soweit zu meinem Verständis (Kurz: HID-konform -> Linux-kompatibel)

Klingt für mich nach einem guten Kandidaten... @frankie: laufen auf dem gerät andere OpenGL-Anwendungen? @borg: kriegst du eine brickv-version ohne OpenGL-Abhängigkeit zusammengehackt? Auf diese Weise könnte man sicherstellen, dass es daran liegt...

Was passiert beim IMU anderes als bei den anderen Bricks? Rendert ihr das Teil nicht in 3D, wegen der Rotation? Ich würde vermuten, dass irgendeine Lib abschmiert... oder kann man in python (ohne C-Zugabe) ohne weiteres Seg-Faults provozieren? Ich würde versuchen zu überlegen was das IMU im Viewer vom Rest unterscheidet, mir fällt (nur aus Screenshotwissen) als einziges ein, dass dort villt andere Grafikfunktionen genutzt werden könnten.

Touchscreens sollten auf jeden Fall dann gehen wenn sie per USB verbunden werden und einen normalen HID (Human Interface Device) Treiber mitbringen, also quasi eine Maus simulieren.

Um nochmal auf das Englisch vs. Deutsch zu kommen: Wenn ich das richtig sehe, hat ja Nic die Annahme, dass die Kapazitäten von TF nur für eine Doku-Sprache reichen. Unter dieser Annahme gebe ich ihm zu 100% recht, dass diese Sprache dann Englisch sein sollte, weil sie universell nutzbar ist. Sollte jedoch TF in der Lage sein zwei Doku-Sprachen zu pflegen, dann wäre ich auch dafür den (sich vermutlich in der Mehrzahl befindlichen) deutschen Nutzern auch eine deutsche Doku zu bieten, einfach um dort die Einstiegsschwelle so gering wie möglich zu halten. (Bisweilen helfen wir ja auch im FOrum denen weiter, die offenkundig noch nie in ihrem Leben programmiert haben, solange wir das tun sollten wir auch nicht zu viel englisch vorraussetzen). Ich geh dann mal wieder... denkt daran, dass ihr euch eigentlich alle lieb habt

Auch wenn das jetzt ein wenig von TF weggeht, aber bedeutet das, dass ich die gatekeeper-geschichte schon umgehen kann, indem ich die Datei nicht mit einem normalen Browser herunterlade? Ist Gatekeeper nicht ein Sicherheitsfeature? Ist das dann nicht eine Sicherheitslücke? Aber ich schweife vermutlich zu sehr ab...

Frage an Threadersteller: Problem dadurch gelöst? Frage an photron (wahlweise TF): Mindestens in den C#-Bindings besteht der gleiche Fehler... unabhängig davon ob es in diesem Foren-Thread die Ursache ist, sollte er denke ich überall gefixed werden.

drin heißt es gibt die entsprechenden Klassen und Strukturen, aber es wurde nichts am bisherigen Produktivcode geändert? Oder sind schon einige Sachen aus der WiFi-Unterstützung in die Firmware "geleaked"? (Ich gehe davon aus, dass die WiFi-Unterstützung nicht nur ein Plugin ist das ihr reinsteckt und fertig, sondern, dass es auch im alt-Code zu Änderungen kommen wird; deswegen die Frage)

Ich muss zugeben, dass ich alle wirklichw ichtigen Anwendungen immer doppelt absichern würde, mit oder ohne Watchdog-Timer. Bedenke, dass es sich hier nciht um sicherheitsequipment handelt (es gibt im professionellen Umfeld zum Teil sehr viel teurere Steuerungen die "Sicherheit" mit eingebaut haben). EIne Sache die mir einfällt, ist den Heizstrahler von zwei unabhängigen Schaltungen steuern zu lassen, dabei schalten beide Steuerungen einen eigenen Schalter, das bedeutet sobald eine das AUS-Signal rausbringt, ist der Heizer aus, auch wenn ein Schalter "klemmt". Nichtsdestotrotz wäre ein Watchdog natürlich ebenso sinnvoll, ich bin mir aber nicht sicher wie komplex es wäre. Möglicherweise ist es eher ein "Spezial-Feature", dass nicht in die allgemeine FW gehört. Aber das kann ich nciht abschließend bewerten.

Sagen wir es so, Sleeps yields usw wild einfügen und entfernen sind typische Methoden um Threading-Fehler im eigenen Code zu entlarven. Vielleicht ist der neue Code noch fehlerhaft? Ich habe noch nicht reingeschaut, deswegen ist das eine böse Unterstellung von mir. Aber beispielsweise sind nahezu alle heutigen Desktop PCs Multi-Core, der RPi bestimmt nicht. Insofern würde es mcih nciht wundern, wenn der Threading-Fehler findet die vorher keiner gesehen hat. Ich tauche nachher mal in den Code, falls jemand schneller ist kann er ja mal folgendes Testen: Im Windows-Task-Manager (Linux kann sowas bestimmt auch) die CPU-Affinität des Java-Prozesses auf nur eine CPU einschränken, damit wird das Programm Single-Core ausgeführt. Dazu sollte das Programm auf eine Nutzereingabe oder so warten bevor es mit addDevice beginnt um genug zeit zu verschaffen die Affinität zu verändern. edit: Ich sehe auf den ersten Blick auch keine Fehler im Locking (angenommen die SychronousQueue wird von jeder Standardbibliothek korrekt implementiert) Okay, eine Sache ist mir aufgefallen, diese kann zu dem Verhalten führen, dass bei zwei hintereinander kommenden AddDevice das zweite fehlschlägt. handleAddDevice endet so: try { pendingAddDevice.responseQueue.put(packet); } catch(InterruptedException e) { e.printStackTrace(); } pendingAddDevice = null; und der gelockte block von adddevice beginnt so: synchronized(addDeviceMutex) { pendingAddDevice = device; Ich führe den Code jetzt mal böse aus: AddDevice #1 wartet auf response HandleAddDevice #1 wird abgearbeitet und nach dem putten in die resp-queue dessen Thread unterbrochen AddDevice #1 wird fertig (resp-queue gefüllt) AddDevice #2 beginnt, setzt pendingDevice und wartet auf Antwort HandleAddDevice #1 beendet sich, setzt pendingDevice auf null HandleAddDevice #2 wird ausgeführt, aber das pendingDevice ist null, also wird nix getan. Ich denke eine sinnvolle Lösung wäre es, das pendingAddDevice im sync-block der Methode AddDevice zu nullen.

Hallo alle, für die C#-Entwickler habe ich vor einiger Zeit ein Pull Request an Tinkerforge gestellt, dass die Callback-behandlung auf Events umstellt, so wie es in .NET üblich ist. Bisher wurden die Änderungen nicht von TF übernommen, was ich verstehen kann, da ich die Delegates alle umbenannt habe und es dadurch etwas inkompatibel zu den aktuellen Bindings ist. Um meine Motivation zu erhöhen (ich muss im Moment bei allen Änderungen am Original ja auch meine Bindings aktualisieren) dachte ich mir ich poste meine Bindings hier einfach mal. Falls jemand Interesse daran hat oder Feedback geben möchte höre ich es gerne ^^ Die Binding gibt es hier: https://github.com/downloads/NobodysNightmare/generators/TF-with-Events_1.1.9.zip Das ganze github-project: https://github.com/NobodysNightmare/generators Warum eigentlich Ich hatte zweieinhalb Motivationsgründe ^^ 1. Mehr als ein Listener pro Callback (siehe Code unten) 2. Typ-Prüfung zur Compilezeit (falls man einen falschen Delegate angibt knallt es nicht erst beim Ausführen) 2,5. In .NET wird es halt einfach so gemacht, ich finde es "sauberer" Noch schnell Beispielcode und dann bin ich auch schon fertig: servoBrick.PositionReached += firstHandler; servoBrick.PositionReached += secondHandler; ... public void firstHandler(byte servoNum, short position) { if(servoNum != 0) return; //Do something with servo 0 } public void secondHandler(byte servoNum, short position) { if(servoNum != 1) return; //Do something with servo 1 }

Es ist halt wirklich schade, dass es kein enum über Bricks/Bricklets gibt ^^ (Typ-Sicherheit und so ^^)