photron

Welche Fehlermeldung bekommst du denn? Du musst das Problem schon genauer beschreiben. Meine Glaskugel ist gerade zur Inspektion

ln -s: Das ist okay. Das build_environment_setup.sh Skript legt das exemplarisch schon für eine Firmware an. Ich habe das in der Dokumentation jetzt zu ln -sf geändert, das überschreibt dann den existierenden Symlink einfach. make: Das ist auch genau richtig so. Wenn du make das zweite mal aufrufst ohne Änderungen am Code gemacht zu haben, dann erkennt make, dass nichts zu tun ist weil du nichts geändert hast. Statt alles zu löschen kannst du aber einfach "make clean" aufrufen, damit make alle erzeugen Dateien löscht. Wenn du dann wieder make aufrufst wird die Firmware wieder neu kompiliert da make clean sie zuvor gelöscht hat.

Ups, die Dokumentation ist veraltet und sollte es eigentlich nicht mehr geben. Da muss ich gleich mal aufräumen. Sorry für die Verwirrung. Der aktuelle offizielle Weg ist der hier: http://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Build_Environment/Tutorial.html

13 (0-12) characters by 6 (0-5) lines is correct. I'll fix the documentation.

Okay, hier für dich eine Version des LED Strip Bricklet Plugins 2.0.5 ohne den Frame Rendered Callback. Die in Kürze erscheinende neue Version des Plugins wird wahrscheinlich erst mit Master Brick Firmware 2.4.1 funktionieren, wegen des Bugs der in 2.4.1 behoben wurde. Die neue Version wird dann aber auch eine Option haben den Frame Rendered Callback abzustellen. led-strip-bricklet-no-callback.bin

Okay hier eine neue Version der C# Bindings. Im source/Tinkeforge Verzeichnis gibt jetzt es ein TinkerforgeUWP.csproj Datei. Diese in Visual Studio 2015 öffnen und kompilieren. Dabei kommt dann eine TinkerforgeUWP.dll heraus die in einer UWP App funktioniert. tinkerforge_csharp_bindings_2_1_11_rc1.zip

Also nach der Anleitung da treten bei mir Fehler auf z.B. weil der Treiber annimmt es gäbe einen PCI Bus den der RED Brick aber nicht hat. Folgendes funktioniert bei mir: sudo apt-get install libpopt-dev wget http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver-8.1.tar.gz tar xf peak-linux-driver-8.1.tar.gz cd peak-linux-driver-8.1/ make PCI=NO_PCI_SUPPORT sudo make install Damit sollte der Treiber jetzt installiert sein. Dann musst du noch in /etc/udev/rules.d/45-pcan.rules einige Zeilen bearbeiten. Laut Kommentar in dieser Datei müssen für Kernel älter als 3.11 (RED Brick hat 3.4) einige Zeilen einkommentiert werden. Du muss in der Datei das Kommentarzeichen (#) vor allen Zeilen löschen in denen WAIT_FOR steht. Jetzt den RED Brick neustarten und den USB-to-CAN Adapter anschließen. Wenn ich es richtig verstehe sollte das jetzt funktionieren.

Das kannst du so leider nicht abfragen. Wenn sich Brick Viewer noch verbinden kann über WLAN, dann hast du noch nicht alle WLAN Verbindungen aufgebraucht. Denn sonst könnte sich Brick Viewer auch nicht mehr verbinden. Wie setze du denn in deinem Programm die LEDs? Setzt du vielleicht ganze viele LEDs ohne Pause hintereinander weg? Vielleicht versucht du mehr Aufrufe pro Sekunde zu machen als die WIFI Extension schafft. Test mal ob es was bringt zwischen dein einzelnen setRGBValues() aufrufen ein paar Millisekunden zu warten. Kannst du den Code vorzeigen, der das Setzen der LEDs macht?

Hast du das Makefile, so abgeändert, dass es "Pedal_Test1" als Programm erzeugt? Wenn ja dann muss du in Schritt 3 "Pedal_Test1" statt "Test" als Executable angeben.

Dein ursprüngliches Problem war doch, dass dein kleiner Linux PC nicht mit der Menge an Frame Rendered Callbacks parat kommt, wenn du das Bricklet "normal" benutzt, oder nicht? Das hast du versucht zu umgehen, in dem du die Frame Duration passend änderst in der richtigen zeitlichen Abfolge. Das können wir verbessern indem wir z.B. den Frame Rendered Callback abstellbar machen oder eine Render Frame Funktion hinzufügen. Wir haben das gerade noch mal besprochen und denken, das ein abstellbarere Frame Rendered Callback die einfachere und bessere Lösung ist. Dein Skript würde einfach den Chip Type setzen, den Frame Rendered Callback abstellen und die zu setzenden LEDs setzen. Dein Server A/B Problem kann ich nicht nachvollziehen, weder mit abschaltbarem Frame Rendered Callback noch mit extra Render Frame Funktion. Das Bricklet speichert sich welche Farben du für die LEDs gesetzt hast und rendert diese dann jede Frame Duration auf die LEDs, sofern seit dem letzten Rendern die Farben geändert wurden. Es spielt also keine Rolle in welcher Reihenfolge das Rendern und das Setzen passieren, solange nicht Server A und B versuchen die gleiche LED zu setzen. Ablauf 1: 1. Server A setzt LED 1 auf grün -> Bricklet Speicher [grün, schwarz, ...] 2. Frame Duration abgelaufen / Server A ruft Render Frame auf -> LEDs [grün, schwarz, ...] 3. Server B setzt LED 2 auf rot -> Bricklet Speicher [grün, rot, ...] 4. Frame Duration abgelaufen / Server B ruft Render Frame auf -> LEDs [grün, rot, ...] Ablauf 2: 1. Server A setzt LED 1 auf grün -> Bricklet Speicher [grün, schwarz, ...] 2. Server B setzt LED 2 auf rot -> Bricklet Speicher [grün, rot, ...] 3. Frame Duration abgelaufen / Server A ruft Render Frame auf -> LEDs [grün, rot, ...] 4. Frame Duration abgelaufen / Server B ruft Render Frame auf -> keine Änderung Beides führt zum gleichen Ergebnis. Was übersehe ich?

Loetkolben, du willst eigentlich einen Single-Shot Modus haben oder nicht? Die API des LED Strip Bricklets ist im Moment auf Animationen ausgelegt. Sprich, du stellst über die Frame Duration die Frame Rate ein. Dann wird alle X ms der Frame auf die LEDs geschrieben und der Frame Rendered Callback ausgelöst. Auf den Callback hin hat dein Programm dann bis zu X ms Zeit den nächsten Frame an das Bricklet zu schicken. Wenn ich dich aber richtig verstehe dann willst du die LEDs nicht in dem Sinne animieren. Sondern nur einmal setzen. Du brauchst also keine Frame Duration, die ist dir nur im Weg. Du willst eigentlich Frame Duration auf 0 setzen, aber dann wird nichts angezeigt. Wie wäre es hier mit: Setup: - set_frame_duration(0), weil sie initial 100 ms ist LEDs setzen: - set_rgb_values(...) - render_frame(), neue Funktion, erzwingt das sofortige Senden der Daten an die LEDs Damit hättest du dann volle Kontrolle wann die Daten anzeigt werden. Das ist es was du eigentlich haben möchtest, oder?

Oh, the OLED Bricklets were completely missing in the proxy. I've fixed that now!

Okay, du hast also nur Test.cpp und sonst Dateien aus den C/C++ Bindings. Dann speicher folgendes mal als Datei namens "Makefile" und lad es zusammen mit deiner Test.cpp Datei also C/C++ Programm auf den RED Brick: # Defines CC=g++ CFLAGS=-c -Wall -I/usr/include/tinkerforge LIBS=-ltinkerforge -lpthread EXE=Test SOURCES=Test.cpp OBJECTS=$(SOURCES:.cpp=.o) # Build Rules all: $(SOURCES) $(EXE) .cpp.o: $(CC) $(CFLAGS) $< -o $@ $(EXE): $(OBJECTS) $(CC) $(OBJECTS) -o $(EXE) $(LIBS) clean: rm -f *.o $(EXE) Die Bindings Dateien kannst du weglassen, die sind schon auf dem RED Brick. Im Programm Uplaod Wizard wählst du dann in Schritt 3 "Test" als Executable und aktiviert die "Compile From Source" Option. Den rest des Wizards kann du auf den Standardwerten lassen.

Auf dem RED Brick ist standardmäßig das Python3 Development Package nicht installiert. Du musst also zuerst über die Console python3-dev nachinstallieren. Am einfachsten geht das wenn der RED Brick Internetverbindung hat: sudo apt-get install python3-dev Dann kannst du das python3-config Tool nutzen, das dir sagt wo die Header und Libs sind und welche C- und LD-Flags zu setzen sind. Dazu einfach die CFLAGS und LIBS Zeilen in deinem Makefile so abändern: CFLAGS=-c -Wall -I/usr/include/tinkerforge $(shell python3-config --cflags) LIBS=-ltinkerforge -lpthread $(shell python3-config --ldflags) Auf dem RED Brick wirst du allerdings Python 3.4 haben, nicht 3.5.

Von suspend/resume/stop wird abgeraten, weil du keine Kontrolle hast in welchem Zustand du den Thread anhältst. Der Thread könnte gerade etwas tun wobei du ihn nicht unterbrechen willst. Es gibt verschiedene Alternativen das zu erreichen. Aber meine erste Frage wäre, warum willst du dein Programm so strukturieren? Was ist der Hintergedanke?

Ich hab versucht mit GCC für ARM und Dev-C++ ein Programm zu cross-compilen. Aber ich bekomme es auf die Schnelle nicht hin. Das Kompilieren an sich funktioniert. Aber das Programm wird auf dem RED Brick immer sofort gekillt. Alternativ, kannst du das Programm auch auf dem RED Brick kompilieren. Dafür musst du aber ein passendes Makefile beilegen. Zeigt doch mal das Makefile.win, das Dev-C++ für dein Projekt erzeugt. Dann kann ich dir weiterhelfen, das Makefile für den RED Brick zu erstellen.

Du kannst das Bricklet als Breakout Board für den INA226 verwenden. Über die SDA/SCL Pins des Bricklets erreichst du direkt die I2C Schnittstelle des INA226. Auf dem Bricklet ist keine weiterer Mikrocontroller, sondern nur noch ein EEPROM, das du aber ignorieren kannst. Den 5V Pin brauchst du nicht, auf dem Bricklet verwendet nichts 5V. Den ADDR Pin musst du anschließen. Der bestimmt welche I2C Address der INA226 hat. Siehe INA226 Datenblatt Seite 23: Serial Bus Address. Pin A1 ist auf dem Bricklet fest an GND angeschlossen. Du kannst also über den A0 (ADDR) Pin die letzten 2 Bit der I2C Address bestimmen, indem du A0 an GND, 3V3, SDA oder SCL anschließt.

I've added those getters now. Sorry, for the late response.

Dev C++ wird GCC einsetzen. Du musst also eigentlich nur GCC für ARM nehmen und das Dev C++ als Compiler unterschieben. Wie das genau geht müsste ich mir selbst erst ansehen. https://launchpad.net/gcc-arm-embedded Eine einfachere Alternative ist es dein Projekt auf dem RED Brick zu kompilieren. Wie hier beschrieben: http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick_Program_Tab.html#c-c Kannst du die Dateistruktur deines Dev C++ Projekts hier zeigen? Dann kann ich dir helfen das Makefile zu erstellen.

Das geht leider nicht so einfach. Das muss auch unter Windows und Mac OS X funktionieren und dort wird diese python2/python3 Namenskonvention nicht verwendet. Ich fürchte da gibt es keine einfache Lösung für.

Du musst den Java Code erstmal kompilieren auf deinem PC. Also aus den .java Dateien .class Dateien erstellen und die dann hochladen.

Es kann in jedem Stack maximal einen RED Brick geben. Du kannst aber einen USB Hub verwenden, wie z.B. den LogiLink UA0139.

Der RED Brick muss der Master des Stack sein. Er muss also der unterste Brick im Stapel sein. Er kann an keine andere Stelle als der untersten sein. Unter dem RED brick kann nur noch die Step-Down Power Supply kommen. Der RED Brick kann die WIFI Extension leider nicht verwenden, sondern nur die Ethernet Extension und die RS485 Extension. Für eine WLAN Verbindung zum RED Brick haben wir einen WLAN USB Stick im Sortiment.

It's not work in progress. You can use it without the getter. The documentation for the setter is missing by accident. I'll fix that. As the documentation for the set_custom_character function says, you need to provide the custom character shape as a bitmask. The documentation has an example for a capital H. Here's setting the first custom character (index 0) to an arrow-up shape: mosquitto_pub -t tinkerforge/bricklet/lcd_20x4/SCD32/custom_character/set -m '{"index":0, "character":[4,14,21,4,4,4,4,4]}' Now to write this custom character (index 0) to the display you need to write a character with byte representation 8. This can be done with the Unicode escape sequence \u0008 in JSON: mosquitto_pub -t tinkerforge/bricklet/lcd_20x4/SCD32/write_line/set -m '{"line":0, "position":0, "text":"\u0008"}' I'll add to my TODO list to add a custom character example to the API bindings.

Die servo Variable ist an der Stelle nicht bekannt, da sie nicht im Scope ist. Du solltest dich mal über Scopes und Gültigkeitsbereiche in C informieren. Damit du das Beispiel erstmal in Gang bekommst musst du folgendes tun: Bei rotary_poti_register_callback als letztes Parameter einen Pointer zum Servo Objekt übergeben: rotary_poti_register_callback(&rp, ROTARY_POTI_CALLBACK_POSITION, (void *)cb_position, &servo); Diese Parameter kommt dann als user_data beim Callback an. Dort kannst du dann daraus wieder den Pointer zum Servo Objekt zurück casten und nutzen: void cb_position(int16_t position,void *user_data) { Servo *servo = (Servo *)user_data; servo_position = 9000*position/150; servo_set_position(servo, 1, servo_position); }