photron

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.

In dem Sinne unser Fehler Im Zuge der Versuches die USB Hotplug Erkennung in Master Brick Hardware Version 2.1 stabiler zu machen ist dieses Feature leider verloren gegangen. Die USB Spannungsmessung auf den Bricks ist leider ein kompliziertes Thema. Das haben wir nicht ordentlich kommuniziert, sorry.

Die rote LED bleibt an, wenn von der SD Karte nicht gebootet werden kann. Das kann daran liegen, dass auf der SD Karte kein Image ist oder das Image nicht richtig auf die SD Karte geschrieben wurde. Oder es kann ein Kontaktproblem im SD Karten Slot sein.

Die Callback Period auf 0 setzen.

Hm, weiss ich nicht so recht was ich davon halten soll. Im Prinzip hast du alles richtig gemacht. Was du noch versuchen kannst: Gib mal bei der manuellen Treiberinstallation im Geräte Manager den brick Unterordner an: C:\Program Files (x86)\Tinkerforge\Brickd\drivers\brick Hast du den Brick mal an einen anderen USB Port angeschlossen?

Auf welchem Betriebssystem? Unter Linux hier muss es ein großes M sein, ein kleines m gibt einen Fehler.

Funktioniert es denn, wenn du statt des RED Bricks einen Master Brick als RS485 Master verwendest? Hast du mal 500000 statt 125000 als Baudrate getestet? Hast du mal ohne Ethernet Extension auf dem RED Brick getestet, also RS485 alleine?

Problem gefunden und gelöst. Es kann passieren, dass brickd schon anfängt Callbacks über den WebSocket rauszuschicken, bevor der Handshake mit dem Browser fertig ist. Dies sieht dann für den Browser nach einem fehlerhaften Handshake aus und der er bricht die Verbindung ab. Voraussichtlich Ende der Woche gibt es eine neue Version es Images, die dann auch diesen Fix beinhaltet. Bis dahin kannst du über den Console Tab im Brick Viewer von Hand eine korrigierte Version einspielen. Dazu einfach folgende Befehle eingeben: sudo wget -O /usr/bin/brickd_new "http://www.tinkerunity.org/forum/index.php?action=dlattach;topic=2788.0;attach=2071" sudo mv /usr/bin/brickd_new /usr/bin/brickd als Password tf eingeben und nach dem Download oben rechts über den System Knopf Brick Daemon neustarten. Edit: wget Befehl korrigiert. brickd