photron

First of all, you don't need brickboot, it's obsolete. It seems that you're not using the latest master-brick.git content. Please check that your ~/tf/master-brick/software/generate_makefile looks like this #!/bin/bash mkdir -p build cmake -E chdir build/ cmake -DCMAKE_TOOLCHAIN_FILE=../src/bricklib/toolchains/arm-none-eabi.cmake ../ # Because of a bug in cmake we have to call it two times... For the second # execution the toolchain files are already defined cmake -E chdir build/ cmake ../ Now delete this directory ~/tf/master-brick/software/build/ and run generate_makefile again: cd ~/tf/master-brick/software/ ./generate_makefile It runs cmake twice. The first run is expected to fail, the second should succeed like this: -- The C compiler identification is GNU 4.9.3 -- The CXX compiler identification is GNU 4.9.3 -- Check for working C compiler: /home/matthias/gcc-arm-none-eabi-4_9-2015q2/bin/arm-none-eabi-gcc -- Check for working C compiler: /home/matthias/gcc-arm-none-eabi-4_9-2015q2/bin/arm-none-eabi-gcc -- broken CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "/home/matthias/gcc-arm-none-eabi-4_9-2015q2/bin/arm-none-eabi-gcc" is not able to compile a simple test program. It fails with the following output: Change Dir: /home/matthias/tf/dev/master-brick/software/build/CMakeFiles/CMakeTmp Run Build Command:/usr/bin/make "cmTryCompileExec1785423513/fast" /usr/bin/make -f CMakeFiles/cmTryCompileExec1785423513.dir/build.make CMakeFiles/cmTryCompileExec1785423513.dir/build make[1]: Verzeichnis »/home/matthias/tf/dev/master-brick/software/build/CMakeFiles/CMakeTmp« wird betreten /usr/bin/cmake -E cmake_progress_report /home/matthias/tf/dev/master-brick/software/build/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec1785423513.dir/testCCompiler.c.obj /home/matthias/gcc-arm-none-eabi-4_9-2015q2/bin/arm-none-eabi-gcc -o CMakeFiles/cmTryCompileExec1785423513.dir/testCCompiler.c.obj -c /home/matthias/tf/dev/master-brick/software/build/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTryCompileExec1785423513 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec1785423513.dir/link.txt --verbose=1 /home/matthias/gcc-arm-none-eabi-4_9-2015q2/bin/arm-none-eabi-gcc CMakeFiles/cmTryCompileExec1785423513.dir/testCCompiler.c.obj -o cmTryCompileExec1785423513 /home/matthias/gcc-arm-none-eabi-4_9-2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/libc.a(lib_a-exit.o): In function `exit': exit.c:(.text.exit+0x2c): undefined reference to `_exit' collect2: error: ld returned 1 exit status make[1]: *** [cmTryCompileExec1785423513] Fehler 1 make[1]: Verzeichnis »/home/matthias/tf/dev/master-brick/software/build/CMakeFiles/CMakeTmp« wird verlassen make: *** [cmTryCompileExec1785423513/fast] Fehler 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:6 (PROJECT) -- Configuring incomplete, errors occurred! See also "/home/matthias/tf/dev/master-brick/software/build/CMakeFiles/CMakeOutput.log". See also "/home/matthias/tf/dev/master-brick/software/build/CMakeFiles/CMakeError.log". -- The C compiler identification is GNU 4.9.3 -- Check for working C compiler: /home/matthias/gcc-arm-none-eabi-4_9-2015q2/bin/arm-none-eabi-gcc -- Check for working C compiler: /home/matthias/gcc-arm-none-eabi-4_9-2015q2/bin/arm-none-eabi-gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Found following source files: /home/matthias/tf/dev/master-brick/software/src/communication.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/logging/logging.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/crc/crc.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/dacc/dacc.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/pwmc/pwmc.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/usart/uart_console.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/usart/usart.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/twi/twid.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/twi/twi.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/adc/adc.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/pio/pio.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/pio/pio_it.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/efc/efc.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/wdt/wdt.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/flash/flashd.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/board/board_cstartup_gnu.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/board/board_lowlevel.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/board/exceptions.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/tc/tc.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/usb/USBD.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/usb/USBDescriptors.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/usb/USBRequests.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/usb/USBDCallbacks.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/usb/USBD_HAL.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/usb/USBDDriver.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/usb/USBDDriverCallbacks.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/pmc/pmc.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/spi/spi.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/drivers/uid/uid.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/free_rtos/croutine.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/free_rtos/tasks.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/free_rtos/portable/MemMang/heap_tf.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/free_rtos/portable/GCC/ARM_CM3/port.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/free_rtos/queue.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/free_rtos/list.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/utility/pearson_hash.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/utility/rand.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/utility/init.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/utility/led.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/utility/syscalls.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/utility/profiling.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/utility/trace.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/utility/sqrt.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/utility/mutex.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/utility/sha_1.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/utility/base64_encode.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/com_messages.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/i2c/i2c_eeprom/i2c_eeprom_common.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/i2c/i2c_eeprom/i2c_eeprom_slave.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/i2c/i2c_eeprom/i2c_eeprom_master.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/none/none.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/com.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/usb/usb_descriptors.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/usb/usb_callbacks.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/usb/usb.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/com_common.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/i2c/i2c_clear_bus.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/bricklet/bricklet_communication.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/bricklet/bricklet_init.c;/home/matthias/tf/dev/master-brick/software/src/extensions/extension_init.c;/home/matthias/tf/dev/master-brick/software/src/extensions/extension_i2c.c;/home/matthias/tf/dev/master-brick/software/src/extensions/brickd.c;/home/matthias/tf/dev/master-brick/software/src/extensions/websocket.c;/home/matthias/tf/dev/master-brick/software/src/extensions/chibi/chibi_low_level.c;/home/matthias/tf/dev/master-brick/software/src/extensions/chibi/chibi_master.c;/home/matthias/tf/dev/master-brick/software/src/extensions/chibi/chibi_slave.c;/home/matthias/tf/dev/master-brick/software/src/extensions/chibi/chibi_init.c;/home/matthias/tf/dev/master-brick/software/src/extensions/chibi/chibi.c;/home/matthias/tf/dev/master-brick/software/src/extensions/rs485/rs485_low_level.c;/home/matthias/tf/dev/master-brick/software/src/extensions/rs485/rs485_slave.c;/home/matthias/tf/dev/master-brick/software/src/extensions/rs485/rs485_master.c;/home/matthias/tf/dev/master-brick/software/src/extensions/rs485/rs485.c;/home/matthias/tf/dev/master-brick/software/src/extensions/wifi/wifi_low_level.c;/home/matthias/tf/dev/master-brick/software/src/extensions/wifi/wifi_command.c;/home/matthias/tf/dev/master-brick/software/src/extensions/wifi/wifi_data.c;/home/matthias/tf/dev/master-brick/software/src/extensions/wifi/wifi_ringbuffer.c;/home/matthias/tf/dev/master-brick/software/src/extensions/wifi/wifi.c;/home/matthias/tf/dev/master-brick/software/src/extensions/wifi2/wifi2.c;/home/matthias/tf/dev/master-brick/software/src/extensions/wifi2/wifi2_uart.c;/home/matthias/tf/dev/master-brick/software/src/extensions/wifi2/wifi2_bootloader.c;/home/matthias/tf/dev/master-brick/software/src/extensions/ethernet/ethernet_websocket.c;/home/matthias/tf/dev/master-brick/software/src/extensions/ethernet/ethernet_low_level.c;/home/matthias/tf/dev/master-brick/software/src/extensions/ethernet/ethernet_dhcp.c;/home/matthias/tf/dev/master-brick/software/src/extensions/ethernet/ethernet.c;/home/matthias/tf/dev/master-brick/software/src/extensions/ethernet/ethernet_w5200.c;/home/matthias/tf/dev/master-brick/software/src/extensions/ethernet/ethernet_w5500.c;/home/matthias/tf/dev/master-brick/software/src/main.c;/home/matthias/tf/dev/master-brick/software/src/master.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/spi/spi_stack/spi_stack_select_dma.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/spi/spi_stack/spi_stack_common_dma.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/spi/spi_stack/spi_stack_slave_dma.c;/home/matthias/tf/dev/master-brick/software/src/bricklib/com/spi/spi_stack/spi_stack_master_dma.c;/home/matthias/tf/dev/master-brick/software/src/routing_dma.c -- Configuring done -- Generating done -- Build files have been written to: /home/matthias/tf/dev/master-brick/software/build Now you can run make cd cd ~/tf/master-brick/software/build/ make

Die Anzahl der möglichen gleichzeitigen TCP/IP Verbindungen ist grundsätzliche durch den verfügbaren Speicher für den nötigen Eingangs- und Ausgangsbuffer pro Verbindung und durch die maximale Anzahl an Ports (64k) im TCP/IP Protokoll beschränkt. Die Ethernet und WIFI Extensions haben im Verhältnis zu einem PC viel weniger Speicher für Eingangs- und Ausgangsbuffer. Daher die niedrige Anzahl an möglichen gleichzeitigen TCP/IP Verbindungen. Für den Brick Daemon gelten die gleichen Regeln, aber ein PC hat normalerweise genug Speicher, dass du für alle normalen Anwendungsfälle niemals an die Speichergrenze kommst. Brick Daemon unter Linux wird eher an die 1024 File Descriptor Grenze kommen. Unter Linux kann ein Prozess standardmäßig nur 1024 File Descriptor öffnen und ein Socket ist unter Linux auch ein File Descriptor. Daher kann Brick Daemon unter Linux theoretisch maximal 1024 TCP/IP Verbindungen gleichzeitig annehmen. Eigentlich sind es ein paar weniger, weil Brick Daemon noch ein paar andere File Descriptoren braucht. An diese 1000er Grenze solltes du aber unter normalen Umständen nie herankommen. Darüberhinaus kann diese Grenze unter Linux auch hochgestellt werden. Sprich, für alle normalen Anwendungsfälle kann Brick Daemon mehr als genügend Verbindungen gleichzeitig annehmen. Bezüglich USB: Die 1000 Nachrichten/Sekunde sind pro USB Verbindung.

reinweb, receivedResponse ist entweder NULL oder ein Array, es ist niemals 0, die Änderung zu === ist unnötig schadet aber auch nicht. Das ist aber PHP spezifisch und hat mit dem eigentlichen Problem dieses Threads nichts zu tun.

Ah! Hilft es, wenn du den schwarzen Bereich anklickst und Enter drückst?

get_value() gibt dir einen Wert zurück den du binär betrachten musst. In Python ist das einfach: print(bin(iqr.get_value())) könnte z.B. 0b11 ausgeben. Von Links mit 0 auf 4 Stellen (wegen der 4 Relais) aufgefüllt: 0b0011 Das niederwertigest Bit (hier 1) stellt den Zustand Relais 1 dar; das höchstwertige Bit (hier 0) den von Relais 4. Du musst also den get_value Wert nehmen und ihn binäre von rechts nach links lesen um den Zustand der Relais 1 bis 4 zu erhalten. Eine 1 steht für Relais ist geschlossen, eine 0 für Relais ist offen. Wenn du das im Programm prüfen willst kannst du das mit dem binären Und Operator: if iqr.get_value() & 0b0001 != 0: print('Relay 1 is closed') else: print('Relay 1 is open') Wenn get_value 0b0011 liefert, ergibt das binär mit 0b0001 verundet 0b0001 also != 0. Wenn get_value 0b0010 liefert, ergibt das binär mit 0b0000 verundet 0b0000 also == 0.

Moment! Meinst du, dass der ganze Console Tab in Brick Viewer komplett fehlt? Kannst du mal einen Screenshot zeigen?

Ohne brickd auf dem RED Brick würde dieser gar nicht im Brick Viewer auftauchen. Oder meinst du das mit "keine Konsole mehr"? Oder meinst du, das der Console Tab auf dem RED Brick Tab nicht mehr richtig funktioniert? Bzw. vom RED Brick kein serielles Device mehr auftaucht?

Auch für dich eine Version mit aktueller libusb zum Testen. brickd_macos_2_2_2_libusb1.dmg

Du muss die Temperatur nehmen und sie in ihre Stellen zerlegen nach dem Muster ($temperatur geteilt durch 10 hoch Stelle) modulo 10 Hier ein kombiniertes Beispiel dafür mit Temperature Bricklet: https://github.com/Tinkerforge/segment-display-4x7-bricklet/blob/master/software/examples/php/ExampleTemperature.php

Um welche Mac OS X Version geht es hier?

Okay, teste mal bitte die angehängt brickd Version. Diese verwendet jetzt die neuste libusb Version. brickd_windows_2_2_2_libusb1.exe

Mit usb_modeswitch hat das nicht zu tun. Der RED Brick ist ein USB Composite Device mit einem Vendor Specific Interface (Tinkerforge API) und einem CDC-ACM Interface (serielle Schnittstelle). Der RED Brick sollte als zwei Devices im Geräte Manager auftauchen: "RED Brick" und "RED Brick Serial Console". Taucht der problematische RED Brick nur als ein unbekanntes Gerät auf, oder taucht das "RED Brick" Gerät, aber das "RED Brick Serial Console" nicht auf? Ich würde auf ersteres tippen, das würde zu einem Hardwäredefekt passen. Da kannst du softwaremäßig nichts machen und nichts debuggen. Das zweite Log vom RED Brick sieht normal aus

Nicht so einfach. Über die R, G und B Leitungen wird höchstwahrscheinlich der Strom für die LEDs übertragen. Dabei wird die Helligkeit der 3 Farbkanäle über PWM geregelt. Das kann man auch über eine Leitung weniger machen. Dazu könnte man auf der einen Seite die 3 PWM Signale messen und digital (z.B. UART/Seriell) über eine Leitung an die andere Seite übertragen und dort das PWM für die LEDs wieder erzeugen. +-------------------+ +---------------------------+ +-------------------------+ +--------+ | R|----|R | | R|----| | | Steuergerät G|----|G PWM->Digital Daten|------------L--------|Daten Digital->PWM G|----| | | B|----|B Masse|------------N--------|Masse B|----| LEDs | | Masse|----|Masse Versorgung | +------E--------|Versorgung Masse|----| | +-------------------+ +---------------+-----------+ | +-------------------------+ +--------+ | | ---------------------+-----------------+ Ob's dafür allerdings schon was fertiges gibt weiss ich nicht.

Was man testen könnte, wäre die libusb Version die brickd mitbringt zu aktualisieren. Die Version die beiliegt ist relative alt. Ich habe mich bisher vor einem Update gescheut, weil es mit der Version bisher keine Problem gab und es in letzter Zeit viele Änderungen in libusb gab. Die Chance ist also halbwegs hoch sich mit der neuen Version auch neue Probleme einzufangen. Gerade gibt es aber auch einen Thread auf der libusb Mailing über Windows 10 und Transfer Stalls. Möglicherweise ist da was dran. Wenn ich heute noch dazu kommen baue ich eine neue brickd Version mit einer aktualisierten libusb Version zum Testen.

Virtualisierung ist eine Option, bringt aber auch einen weiteren Layer an möglichen Problemen mit sich.

Das gibt brickd aus, wenn ein USB Bulk Read Transfer (um Daten vom Brick zu lesen) mit dem libusb Fehlercode LIBUSB_TRANSFER_STALL endet. libusb gibt diesen Fehlercode zurück wenn WinUsb_ReadPipe mit dem Windows Fehlercode ERROR_GEN_FAILURE scheitert, siehe: https://msdn.microsoft.com/de-de/library/Windows/Hardware/ff540297(v=vs.85).aspx

Mit Windows 10 haben wir noch keine großen Erfahrungen, es sind mir aber auch keine aktuellen Probleme bekannt. Dennoch wäre das mein erster Ansatzpunkt. Besteht die Möglichkeit, dass du das auf einer älteren Windows Version testen kannst?

Richtig, das kleinste Fenster, das du setzen kannst ist 1x8 Pixel. Das liegt aber an der API des OLED selbst. Das ist keine künstliche Beschränkung unsererseits.

Den Fehler habe ich noch nie gesehen. Beschreibe mal deinen Aufbau genauer: - welche Windows Version? - wie ist dein Stack aufgebaut? - wie ist der Stack angeschlossen (USB2, USB3, Hub dazwischen etc.)? - wie häufig kommunizierst du mit dem Stack?

Das wird es.

Du hast also folgendes vor: 230V <---> Steuergerät <--- 3-adrige Leitung ---> 3 LED Strips parallel Die LED Strips haben aber 4 Anschlüsse (R, G, B und Masse, nehmen ich an), dir fehlt also die 4. Ader. Was spricht geben diese Anordnung? Ist das Steuergerät dafür zu groß? 230V <--- 3-adrige Leitung ---> Steuergerät <---> 3 LED Strips parallel

Das aktuelle Beispiel kann das nicht, das stimmt. Teste mal bitte diese verbesserten Beispiele. ExampleScribble_v2.php ExamplePixelMatrix_v2.php

Ich denke es handelt sich um diesen Debian Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568550#27 Ich sehe das auf meinem RED Brick hier auch. Folgende Package Installation sollte das beheben: sudo apt-get install snmp-mibs-downloader

Das ist Absicht. write() und clearDisplay() arbeiten immer auf dem zuletzt gesetzten Fenster. Die Dokumentation sagt das leider noch nicht, das werde ich gleich korrigieren. Danke für den Hinweis.

Das ist komisch. Anyway, wegen Rücksendung melde dich bitte bei info@tinkerforge.com und verweiß auf diesen Thread hier.