photron

Yes.

Okay, das prepare-host.sh Script fügt jetzt automatisch i386 als Architektur hinzu. Die i386 Pakete sind für den armhf Cross-Compiler, darunter fällt auch das zlib1g Pakete. Das habe ich jetzt zur Liste der benötigen Pakete hinzugefügt. Node.js und NPM ist etwas problematisch. Das ist zu verschieden zwischen Ubuntu und Debian und den einzelnen Debian Versionen. Daher habe ich das jetzt aus der Liste der benötigen Pakete entfernt und in der readme.txt erklärt, dass man das bitte manuell installieren möge, plus Anleitung wie das für Ubuntu und Debian geht. Danke für das Finden dieser ganzen Probleme. Wenn du noch mehr findest immer nur her damit

raphael_vogel, auch eine gute Idee, hat aber den gleichen Nachteil wie die Shell Bindings als Proxy: es braucht einen weiteren PC für den Webserver. doehlma, beschreibe doch mal bitte genauer was deine Rahmenbedingungen sind: Soll es mit iPhone und Stack alleine gehen, oder darf die Kommunikation über einen zusätzlichen PC gehen? Du sagtest du hast schon Verschiedenes probiert. Beschreibe doch mal was das im einzelnen war und was die Probleme waren, dann können wir hier gezielter weiterhelfen.

Maybe the Master Brick itself get's restarted if you reboot the Linux, which doesn't happen if you just restart brickd. You could test to manually reset the Master Brick with its reset button if the problem occurs again to check this. Does the problem occur when you switch the Dual Relay Bricklet?

Das ist keine Variante, denn das ist der Standard und die einzige Möglichkeit. Auf dem RED Brick läuft immer ein eigener brickd. Es ist in diesem Zusammenhang mit dem RED Brick genau das gleiche wie mit dem Master Brick. Wenn du eine Brick per USB anschließt, dann muss auf dem PC an dem der Brick per USB angeschlossen ist brickd laufen. Denn brickd ist für die Übersetzung von USB nach TCP/IP zuständig. Die API Bindings und brickv nutzen immer TCP/IP. Wenn du aber einen RED ober Master Brick nicht per USB anschließt, sondern ihnen z.B. der Ethernet Extension direkt Netzwerkzugang gibts, dann brauchst du keinen brickd auf dem PC mehr. Denn dann können die API Bindings und brickv direkt mit dem Brick über TCP/IP sprechen, ohne den Umweg über USB. Um auf deine Frage zurückzukommen: Da müssen wir nicht mehr für tun, denn genau das kannst du schon lägst tun

Brick und Bricklets sprechen auf der untersten Ebene ein binäres packetbasiertes Protokoll, das hier beschrieben ist: http://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html Unsere API Bindings nutzen diese Protokoll um mit den Brick und Bricklets zu sprechen. NetIO ist an sich erstmal für Textbefehle ausgelegt. Die Shell Bindings können als Proxy zwischen NetIO und Brick und Bricklets fungieren, so dass du direkt Textbefehle von NetIO aus schicken kannst: http://www.tinkerforge.com/de/doc/Software/NetIO_Setup.html Das setzt allerdings voraus, das die Shell Bindings auf einem Rechner laufen. Wenn du direkt aus NetIO über eine WIFI Extension Brick und Bricklets ansprechen willst ist da kein Raum für die Shell Bindings. In diesem Fall kannst du das Format der NetIO Connection von string auf hex zu stellen und dann direkt die Binärpakete zu schicken. Als kurzes Beispiel müsstet du diese Bytesequenz senden, um beide Relais des Dual Relay Bricklets mit UID a5N einzuschalten: 0x5a 0x77 0x00 0x00 0x0a 0x01 0xb0 0x00 0x01 0x01 Wie diese für dein Bricklet aussieht hängt von dessen UID ab. Wie du das in NetIO exakt hinschreiben musst musst du in der NetIO Dokumentation nachschlagen.

Mit getListLength() und getListItem() kannst du die Einträge der Programmliste abfragen, dir durch programs_list_id repräsentiert wird. Mit den program_ids aus der Liste kannst du dann wiederum startProgram() aufrufen. Um in der Programmliste das Programm zu finden, dass du suchst kannst du mit getProgramIdentifier() von einem Program dessen Identifier abfragen. Über getProgramIdentifier() erhälst du die identifier_string_id mit der du dann über getStringLength() und getStringChunk() den Inhalt des Strings abfragen kannst.

Die LEDs am RED Brick und am Master Brick leuchten aber normal, oder? Also am RED Brick blinkt grün, blau leuchtet und rot ist aus (unter der Annahme du hast das nicht umgestellt). Am Master Brick leuchtet die eine blaue LED und die 4 am Rand machen das übliche Muster beim Anstecken an USB.

npm ist der Node.js Package Manager, denn scheint es wohl nur bei Ubuntu direkt als Package zu geben. Das müssen wir wohl behandeln. Bis dahin gibt es hier für Debian eine Anleitung: https://github.com/joyent/node/wiki/installing-node.js-via-package-manager libstdc++6 ist nicht libc6, sondern die C++ Standard Library. Villeicht ist das Problem, dass die für i386 installiert werden soll. Was gibt das hier bei dir aus? dpkg --print-foreign-architectures Wenn da i386 nicht bei ist kannst du es so hinzufügen: dpkg --add-architecture i386 Dann sollte es gehen.

Du hast recht wir setzen etwas Basiswissen voraus, z.B. das du weißt wie man ein Debian Package installiert oder die gewählte Programmiersprach grundsätzlich verwendest. Der Link im Tutorial zeigt jetzt direkt auf den API Bindings Abschnitt der Download Seite. Die readme.txt in den ZIPs der API Bindings beinhaltete früher eine Installationsanleitung. Im Zuge der Überarbeitung der Anleitungen steht in den readme.txt jetzt ein Verweis auf die Dokumentation auf tinkerforge.com. Ich habe die readme.txt jetzt so erweitert, dass sich explizit auch auf die Installationsanleitung auf tinkerforge.com hinweist. Dass das Tutorial auf die readme.txt für eine Installationsanleitung verweist war früher richtig. Das haben wir wohl vergessen im Zuge der Überarbeitung der Anleitungen zu ändern, sorry. Das habe ich jetzt nachgeholt, danke für den Hinweis. sudo python setup.py install ist hier als Kommando der Wahl zur Installation dokumentiert: http://www.tinkerforge.com/de/doc/Software/API_Bindings_Python.html#vom-quelltext setuptools wird von setup.py verwendet und ist nicht teil des ZIPs. Ich habe die Anleitung umformuliert, um dass besser herauszustellen. Für die Installation ist das Working Direktory belanglos, die Setuptools sorgen dafür, dass es an der richtigen Stelle landet. Bezüglich ./example_beep.py: line 1: #!/usr/bin/env: No such file or directory Da ist was wirklich Faul mit deinem Linux. env ist teil der coreutils zu denen auch Dinge wie cp und mv gehören. Die sind eigentlich immer installiert. Alle anderen Fehler danach sind Folgefehler und verschwinden sobald der erste Fehler behoben ist. Versuch mal "python example_beep.py" statt "./example_beep.py" auszuführen. Wir wollen keinen mit der Art und Weise der Dokumentation ausgrenzen. Aber irgendwo müssen wir den Schnitt setzen zwischen dem was wir erklären und dem was wir voraussetzen. In diesem Fall setzen wir voraus, dass du grundsätzlich mit dem verwendeten Betriebssystem und der verwendeten Programmiersprache vertraut bist. Falls du noch weitere Verbesserungsvorschläge hast bitte immer her damit und danke dass du dir die Zeit genommen hast das hier so ausführlich aufzuschreiben.

Ja, das geht über die API des RED Bricks: http://www.tinkerforge.com/de/doc/Software/Bricks/RED_Brick_PHP.html Die Dokumentation ist derzeit noch unvollständig. Was du tun muss hier sehr grob skizziert: - mit createSession eine Session erzeugen - mit getPrograms(session_id) die Liste der Programs erhalten - aus der Liste der Programs das entsprechende heraussuchen - startProgram mit der herausgesuchten program_id aufrufen

FlyingDoc, wenn du Qt verwendest dann bietet es sich an auch das ganze String Handling mit QString zu erschlagen.

Eigentlich sollte keine extra sources.list Einträge nötig sein. Welcher Fehler tritt denn bei prepare_host.sh auf?

Das ist ein Bug, wird in der nächsten Brick Viewer Version behoben sein, danke für den Hinweis.

nrg007, prinzipiell spricht nichts dagegen das Display auf dem Bricklet zu tauschen. Du muss halt nur darauf achten es richtig anzuschließen Datenblätter für das verbaute Display und den Treiber IC, sowie den Schaltplan des Bricklets findest du hier: http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Segment_Display_4x7.html#ressourcen Das verbaute Display hat die 4 Digits als Matrix verschaltet. Pro Digit hat es eine gemeinsame Anode (COMx) und 7 Kathoden (A-G), das Datenblatt des Display hat einen Schaltplan über den internen Aufbau. Wenn du da jetzt 4 einzelnen Digits anschließen willst muss du die so anschließen, dass das der bisherigen Schaltung entspricht und dann sollte das funktionieren.

Das PWM Signal des Servo Bricks hat fest 5V. Damit kannst du also nicht direkt 10V erreichen.

Richtig nur die U-Boot Position ist fix, der Rest der Offsets ist von uns gewählt. Das U-Boot Offset ist 8 Kilobyte (= 16 x 512 Byte Blocks). Dazu kannst du hier mehr finden: http://rhombus-tech.net/allwinner_a10/a10_boot_process/ Zu den Allwinner Prozessoren allgemein kannst hier noch mehr finden: http://linux-sunxi.org/

Keine Idee was da passiert. Wenn du den Fehler einfach reproduzieren kannst kannst du mal in /usr/bin/brick-flash-cmd diese Zeile print('\r{0}: {1:>3} %'.format(self.message, int(100.0 * self.value / self.maximum))) durch diese print('{0}: {1} / {2}'.format(self.message, self.value, self.maximum)) ersetzen. Dann wird nicht mehr eine Zeile mit dem Prozentwert überschrieben sondern die Flash Page Nummer mit History ausgegeben, die dann in +1 Schritten hochzählt. Wenn die Flash Page Nummer springt ist irgendwas richtig faul. RAM sollte eigentlich kein Problem sein. Der Bootloader des Bricks ist über eine serielle Schnittstelle über USB (CDC ACM) erreichbar. Darüber spricht brick-flash-cmd mit dem Brick das SAM-BA Protokoll. Der Reset am Ende wird durch Setzen eine speziellen Registers des Mikrocontrollers ausgelöst. USB an sich ist da nie direkt involviert.

Derzeit sind es Python 2.7.3 und Python 3.2.3, siehe http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick_Installed_Versions.html#python Python 3.4 wurde schon an anderer Stelle angefragt, mal sehen was sich da machen lässt.

Wahrscheinlich ist nicht nur der Kondensator explodiert, sondern es hat auch die Spannungsregler, die Mikrocontroller, etc. zerlegt. Wenn du sehr viel Glück hast ist da noch was zu Retten, aber wahrscheinlich nicht. Es ist geplant den 5V Ausgang der Step-Down in der nächsten Version mit einer Diode gegen Einspeisung zu sichern, weil dieses Missgeschick doch schon ein paar Leuten passiert ist.

Okay, in /var/messages sehe ich dass Master Brick 6JKUui zwischen 22:08 und 22:15 19mal an USB gefunden wurde. Bei dreien davon kommt wenige Sekunden danach ein Calltrace in dem der cdc_acm Treiber vorkommt, der erzeugt das /dev/ttyACMx Device für den Brick. Das riecht als ob das mit deinem Problem zusammenhängt, aber was mir das wirklich sagen will weiss ich nicht, dafür bin ich zuwenig Kernel Entwickler. Ich weiss nicht so recht was ich die da raten, soll bin etwas überfragt, sorry.

Siehe dd Aufrufe in image/update-kernel-on-sd-card.sh und *_DD_SEEK Werte in image/config/image.conf. Detaillierte Dokumentation in dem Sinne existiert in dem Sinne (noch) nicht. Schau dir die Scripte an und stell deine Fragen hier.

Das kannst du innerhalb der Callback Funktion machen, das ist okay und kein Problem. Als alternative Möglichkeit kannst du dir die write_message Funktion (Zeile 260) im Python Beispiel ansehen (sorry, das Beispiel ist derzeit nur in Python vorhanden): http://www.tinkerforge.com/de/doc/Software/Bricklets/NFCRFID_Bricklet_Python.html#write-ndef-message Dort werden die StateChange Callbacks in eine Queue gepackt und die write_message wartet dann nach den jeweiligen Schritten bis der entsprechende StateChange aus der Queue genommen werden kann. Das ist jetzt prinzipiell nicht besser oder schlechter als dein Vorgehen, sonder einfach eine gleichwertige Alternative.

Die Berechnungen die die IMU anstellen muss sind zu aufwändig für ein Bricklet.

Das False in "Executing make False" sollte da nicht sein. Du hast da einen Bug gefunden. Der betrifft den C/C++ und Delphi Compile Dialog. Das Kompilieren beim Hochladen ist nicht betroffen. Wird in der nächsten Version gefixt sein. Unter Linux kannst du das bis dahin selbst beheben. In /usr/share/brickv/plugin_system/plugins/red/program_info_c_compile.py Zeile 41 von self.button_make.clicked.connect(self.execute_make) zu self.button_make.clicked.connect(lambda: self.execute_make(None)) abändern.