photron

Dein angehängtes Programm funktioniert prinzipiell, du bist da aber in eine Falle mit dem Linker geraten. Das Problem ist, dass du eine Funktion namens send hast und es schon in der libc eine Funktion namens send gibt die die IPConnection inter verwendet. Der Linker nimmt jetzt aber deine send Funktion anstatt der aus der libc (weil die gleich heißen). Der Segfault kommt dann daher dass die falsche send Funktion aufgerufen. Die Lösung ist, deine send Funktion in sendString umzubenennen. Zusätzlich machst du am besten alle deine Funktionen (außer main) static, dann sind sie nur innerhalb der main.c sichtbar. Also statt sendByte (char c) { ... } void send(char *c) { ... } dann static void sendByte (char c) { ... } static void sendString(char *c) { ... }

Kann ich hier nicht reproduzieren. Funktioniert es denn wenn beide Master die neuste Firmware haben?

Ich habe das gerade nochmal hier getestet mit aktuellem Raspbian Image und das funktioniert alles so wie beschrieben. Am Ende habe ich im Menu von LXDE unter Other bzw. Sonstiges einen funktionierenden Brick Viewer Eintrag. Es dauert allerdings einen Moment bis brickv nach dem Klick startet, das Raspberry Pi ist nicht das schnellste Was steht denn bei dir in /usr/share/applications/brickv.desktop? Die sollte so aussehen: [Desktop Entry] Encoding=UTF-8 Name=Brick Viewer Version=1.0 Comment=Viewer for Bricks and Bricklets GenericName=Brick Viewer Terminal=false Icon=brickv-icon.png Type=Application Exec=python /usr/share/brickv/main.py Categories=Electronics;

Es reichen diese beiden Dateien plus die Pakete python-argparse und python-serial. Welche Abhängigkeiten meinst du? RouvenE fehlte python-serial, weil das in unserer Installationsanleitung nicht aufgelistet war, das ist behoben. Im brickv.deb selbst sind aber alle Abhängigkeiten richtig angegeben. Man könnte argumentieren, dass da python-argparse fehlt, wenn man flash-brick-cli.py als Teil des Pakets ansieht. Was nicht direkt so beabsichtigt war. Es wird dann ja auch noch ein eigenes .deb dafür geben, das dann python-argparse und python-serial als Abhängigkeiten haben wird.

Das brickv.deb ist natürlich nicht für Systeme ohne GUI gedacht, wie auch flash-brick-cli.py ist eigentlich so gedacht dass du dass zusammen mit samba.py dir irgendwohin kopiert un dann von da ausführst. Dass das im brickv.deb drin ist ist ehr unserer einfachen Art das .deb zu bauen geschuldet, und weniger einer Absicht. Ich gebe dir aber Recht, dass es natürlich hübscher wäre ein eigenes .deb für flash-brick-cli.py zu haben. Ich setze das mal auf die TODO Liste. Sorry, für die gestiftete Verwirrung und die späte Antwort.

Das "Problem" an PHP ist so ein bisschen, dass es eigentlich nicht als General Purpose Programmiersprache gedacht ist/war, sondern zur Programmierung von Webseiten gemacht ist. Wir empfehlen typischerweise Python als Sprache für Anfänger/Einsteiger.

Zu python-serial: Das fehlte in der Anleitung für brickv auf Raspberry Pi installieren, ist jetzt korrigiert. Zu brickd: Wenn du den aus dem .deb installiert hast, wird der automatisch beim Hochfahren mitgestartet. Zum Wetterstations Democode: Auf der Seite ist im ersten Abschnitt die Anleitung zur Installation der benötigten Python Bindings verlinkt. In Kurz: Das Zip für Python von der Downloadseite herunterladen und das .egg darin mit easy_install installieren. wget http://download.tinkerforge.com/bindings/python/tinkerforge_python_bindings_latest.zip unzip tinkerforge_python_bindings_latest.zip -d tinkerforge_python_bindings sudo easy_install tinkerforge_python_bindings/tinkerforge.egg Danach kannst du dann den Democode der am Ende der Seite verlinkt ist herunterladen und ausführen: wget https://raw.github.com/Tinkerforge/weather-station/master/write_to_lcd/python/weather_station.py python weather_station.py

Ah, ich hatte im Test-Compile-Script -O2 nicht an und dann gibt GCC diese Warning nicht aus. Ist jetzt im git korrigiert.

Unsere Wetterstation hier in Labor an der Wand ist über eine WIFI Extension angebunden und die läuft seit 7 Wochen durch.

Laut borg ist das normal. Die ResetException() ist das was als erstes ausgeführt wird. main() wird von ResetException() ausgerufen. Du musst dann einfach im Debugger auf Continue oder so klicken denke ich.

Hm, gcc_struct kennt GCC nur für x86. Und ja, gcc_struct sollte auch im Header gesetzt werden, das ist aber nicht kritisch, da das Problem für das ich gcc_struct eingefügt hatte nur die .c Datei betrifft. Als kurzfristigen Workaround kannst du für nicht-Windows Systeme das gcc_struct einfach streichen. In der nächsten Bindingsversion ist dass dann behoben. Welche Warning macht denn die "length = ((PacketHeader *)pending_data)->length;" Zeile?

Temperature und Barometer Bricklet verwenden I2C Sensoren und brauchen daher keinen externen A/D Wandler, sondern Anschluss an einen I2C Bus. Ambient Light und Humidity Bricklet verwenden Analog Sensoren und brauchen einen externen A/D Wandler. Wie das ganze anzuschließen und zu verwenden ist solltest du den Schaltplänen und dem Source Code entnehmen können. Ansonsten einfach fragen

Das Breakout Bricklet ist eigentlich dazu gedacht an die Bricklet Pins eines Bricks zu kommen, es spricht aber nichts dagegen es an ein Bricklet anzuschließen um an dessen Pins zu kommen. Für Bricklets wie das Linear Poti oder das Ambient Light sitzt der A/D Wandler auf dem Brick, nicht auf dem Bricklet selbst. Wenn du diese per GPIO anschließen willst musst du dich schon an deren Pinbelegung halten, z.B. auch einen A/D Wandler bereitstellen. Um welches Bricklet geht es dir denn im speziellen?

Die Leiterplatten und Bauteile liegen jetzt beim Bestücker, der sie in Kürze produzieren wird.

Beide Schaltzustände aktive zu treiben ist ein guter Hinweis, Loetkolben. Alternativ kann statt einem IO-4 Bricklet auch ein Industrial Digital In 4 Bricklet verwenden. Durch die Optokopplung ist das stromgesteuert, was robuster gegen Störungen ist, als die Spannungssteuerung des IO-4 Bricklets.

Es gibt genau dafür IPConnection::getConnectionState().

Plugins: IO-16 Bricklet 2.0.2 Apply debounce period on port b again Downloads: IO-16 Bricklet

Plugins: IO-16 Bricklet 2.0.2 Entprellperiode wird wieder richtig für Port B angewendet Downloads: IO-16 Bricklet

Der Port Extension Chip auf der IO-16 reagiert auf Interrupts und speichert sich diese. Das Bricklet fragt dann den Zustand des Interruptregisters des Port Extension Chip periodisch ab und sendet entsprechende Callbacks. Da sollte eigentlich kein Interrupt verloren gehen. Die Standard Debounce Period sind 100ms. Zwei Interrupts zwischen denen weniger als 100ms liegen werden als einer gewertet. Wenn du schnelle Interruptfolgen mit weniger als 100ms Zeit zwischen den Interrupts erkennen willst musst du die Debounce Period kleiner stellen.

Callbacks werden von einem eigenen Thread abgearbeitet. Unter normalen Umständen sollten Callbacks ohne weitere Verzögerung abgearbeitet werden.

Dass das bei dir so funktioniert liegt daran dass a) du da gerade einen Bug im Plugin des LCD 20x4 Bricklets gefunden hast. 8 als index ist eigentlich nicht zulässig, der Bug führt aber dazu dass das als 0 interpretiert wird und damit den ersten Custom Character wählt. b) in PHP "\10" als oktal interpretiert wird und damit das gleiche meint wie "\x08" nämlich ASCII Code 8. Auf diesem ASCII Code liegt der erste Custom Character. Wie borg schon sagt können wir den ASCII Code 0 nicht nehmen, da der String-Ende bedeutet. Deswegen das Offset von 8 zwischen dem setCustomCharacter index (0-7) und den ASCII Codes (8-15) für die Custom Characters. Du kannst also bei $lcd->writeLine(0, 0, "\10"); bleiben, solltest aber doch $lcd->setCustomCharacter(0,$CC); nehmen, damit dass mit der korrigierten Version des Plugins dann auch noch funktioniert.

Wie sieht denn dein writeLine Aufruf aus? So schreibst du den Custom Character 0: $lcd->writeLine(0, 0, "\x08"); Wobei '\x08' nicht das gleich wie "\x08" ist, denn in '' interpretiert PHP das nicht wie gewünscht.

Hast du den Brick Daemon normal installiert? Dann läuft er schon längst als Service im Hintergrund und du solltest den Brick Daemon gar nicht manuell aus dem Explorer heraus starten. Wenn du den manuell startest werden sich die beiden Instanzen in die Haare komme. Ich denke der "Could not open USB Device" kommt daher, dass der brickd Service diese Gerät schon geöffnet hat und dein manuell gestarteter dass dann nicht mehr darf. Zusammengefasst du musst und sollst im Normalfall den Brick Daemon nicht manuell starten. Der brickd Installer hat sich schon um alles gekümmert. Du musst nur in brickv auf connect klicken. Ich nehme das mal als Hinweis, das brickd meckern sollte wenn man versucht ihn zweimal zu starten

Mechanisch ist das einfach ein 2x Umschalter. Das kann man leicht mit einem Dual Relay Bricklet nachbauen, da ist die Last/Audioseite elektrisch vollständig von der Schaltseite getrennt und man muss sich keine weiteren Sorgen machen. Problematischer wird es mit 2 Quellen auf 3 Zielen. Pluto, ich denke du solltest dir als erstes einmal Gedanken machen wie du eine Satz von Schaltern verbinden musst damit das richtig schaltbar ist, bevor du dir Gedanken über die elektrische Umsetzung machst.

Fragst du das Enumerate mit ipcon.enumerate() an?