photron

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.

noatime,nodiratime steht auf der TODO Liste.

Hm, in BrickletNFCRFID.java Zeile 290 steht bb.put((byte)data[i]); wobei bb nicht null sein kann, dann gäbe es schon in Zeile 288 eine NPE. Bliebt also noch data das null dein könnte. writePage(int page, short[] data) Übergibst du da vielleicht null als data für Pages größer 30?

Nach dem ersten WritePage, einfach weitere WritePage aufrufe machen. Also Schritt 4 und 5 wiederholen. Das unterliegende Protokoll verwendet Pakete mit fester Länger und daher haben alle Array Parameter auch immer feste Länge. Arrays beliebiger Länge sind nicht mögliche. Die Dokumentation war da missverständlich und ist jetzt verbessert. Der GetTagID Aufruf ist optional und nur in dem Fall interessant, wenn du nur mit einem bestimmten Tag arbeiten und diesen an seiner Tag ID erkennen willst.

Was bekommst du denn für Fehler beim compilieren?

Richtig, die Funktionalität ist schon da, sie muss nur etwas umorganisiert werden, damit sie von zwei Programmen aus genutzt werden kann. Wenn das getan ist ist es einfacher brick-flash-cmd zu erweitern, als erst brickv noch ein Kommandozeilen Interface zu geben.

Das Image Buildsystem findest du hier: https://github.com/Tinkerforge/red-brick/tree/master/image Der Bootloader (U-Boot) und der Kernel sind nicht im Dateisystem, sondern liegen an festen Adressen in den ersten 10MB des Images.

Loetkolben, ohne das jetzt genauer durchdacht zu haben denke ich, dass es aufwändiger ist brickv ein Kommandozeilen Interface zu geben, als ein dediziertes Tool wie brick-flash-cmd zu erweitern.

Well, we're not going to selling longer Bricklet cables now. And we still recommend using the shortest possible Bricklet cables. The statement about the maximum I2C bus length was just documenting the fact that you could connect 4x 2m Bricklet cables to one Master Brick and end up with an 8m I2C bus, which is quite long. I doubt that an 8m long Bricklet cable will work at all, because of the resulting voltage drop.

Dein Aufbau wäre also Master Brick mit Temperature Bricklet und Remote Switch Bricklet per USB an einem Raspberry Pi. Dafür wird die Stromversorgung über den Raspberry Pi USB Anschluss sicherlich reichen; keine weitere Stromversorgung über eine Step-Down Power Supply notwendig.