photron

Go bindings 2.0.13 published. Those will just work now, without modification. You can also remove the replace line from your go.mod file again. 100 FPS is too low, you should be able to send 500 FPS and receive 1000 FPS. This example sends about 500 FPS with two CAN Bricklet 2.0 connected to form a CAN bus: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID1 = "Er1" # Change XYZ to the UID of your CAN Bricklet 2.0 UID2 = "Gj8" # Change XYZ to the UID of your CAN Bricklet 2.0 from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_can_v2 import BrickletCANV2 # Callback function for frame read callback def cb_frame_read(frame_type, identifier, data): if frame_type == BrickletCANV2.FRAME_TYPE_STANDARD_DATA: print("Frame Type: Standard Data") elif frame_type == BrickletCANV2.FRAME_TYPE_STANDARD_REMOTE: print("Frame Type: Standard Remote") elif frame_type == BrickletCANV2.FRAME_TYPE_EXTENDED_DATA: print("Frame Type: Extended Data") elif frame_type == BrickletCANV2.FRAME_TYPE_EXTENDED_REMOTE: print("Frame Type: Extended Remote") print("Identifier: " + str(identifier)) print("Data (Length: " + str(len(data)) + "): " + ", ".join(map(str, data[:min(len(data), 8)]))) print("") if __name__ == "__main__": ipcon = IPConnection() # Create IP connection can1 = BrickletCANV2(UID1, ipcon) # Create device object can2 = BrickletCANV2(UID2, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected # Configure transceiver for loopback mode can1.set_transceiver_configuration(1000000, 625, can1.TRANSCEIVER_MODE_NORMAL) can2.set_transceiver_configuration(1000000, 625, can2.TRANSCEIVER_MODE_NORMAL) # Register frame read callback to function cb_frame_read #can2.register_callback(can2.CALLBACK_FRAME_READ, cb_frame_read) # Enable frame read callback can2.set_frame_read_callback_configuration(True) # Write standard data frame with identifier 1742 and 3 bytes of data import time c = 0 s = time.monotonic() f = 0 while True: time.sleep(0.0001) if not can1.write_frame(can1.FRAME_TYPE_STANDARD_DATA, 1742, [42, 23, 17]): f += 1 if f % 100 == 0: print('fails', f) continue c += 1 if c % 100 == 0: n = time.monotonic() d = n - s #print('c', c, d, d / c, c / d) print('fps', c / d) input("Press key to exit\n") # Use raw_input() in Python 2 can2.set_frame_read_callback_configuration(False) ipcon.disconnect()

Bindings: Go 2.0.13 Fix streaming setter payload length calculation Convert to Go module Download: Go

Bindings: Go 2.0.13 Streaming-Setter-Payload-Längenberechnung korrigiert In Go Module umgeandelt Download: Go

Okay, the Go bindings are not yet adapted to go.mod, but you can do that yourself for now. Unpack the ZIP file to somwhere, doesn't matter where. Run "go mod init github.com/Tinkerforge/go-api-bindings" in the github.com/Tinkerforge/go-api-bindings directory from the unpacked ZIP file. To your go.mod file add a line like this, to tell Go where to find the module locally: replace github.com/Tinkerforge/go-api-bindings => /path/to/your/github.com/Tinkerforge/go-api-bindings

"pio run -e prepare" fällt jetzt auch weg. Wir haben einen Weg gefunden zusammen mit der symlinks diesen Schritt automatisch auszuführen.

Wie schon gesagt ist es richtig, dass das include Verzeichnis fehlt. Ich habe dennoch ein leeres hinzugefügt, damit VSCode darüber nicht unnötig warnt.

Ich habe der Dokumentation jetzt noch hinzugefügt, dass Node.js und Git nicht als VSCode Extensions zu installieren sind. Die npm Warnung kannst du ignorieren. Das ist nur eine Warnung, die nicht relevant ist für die Funktion von npm. Das scheint ein internes Problem zu sein das nur die 16.16 Version betrifft. Mit 18.6 kommt die Warnung nicht. Du kannst auf 18.6 wechseln, das ist aber nicht zwingend notwendig. Wenn ich das richtig sehe musst du allerdings den Code hier runterladen: https://github.com/mattsches1/esp32-firmware/tree/phase_switcher Das was du heruntergeladen hast beinhaltet die Phasenumschatung nicht. Danke für eure Gedult.

Mal bitte alle Füße stillhalten... Sorry, dass das alles nicht direkt zu laufen scheint. Das funktioniert hier auch alles unter Windows 10. Das Problem ist leider, dass ich das auf einem Windows 10 getestet habe das schon verschiedene Dinge installiert hatte und daher in der Anleitung Dinge fehlen, z.B. git. Warum gerade npm fehlt ist mit unklar. Das wird mit Node.js mit installiert. Muss ich rausbekommen. Wird nachgeliefert. Ich gehe den Installationsprozess jetzt noch mal auf einem nackten Windows 10 durch. @Andreas_Mainz Deine Probleme mit der EVSE Bricklet 2.0 Firmware spielen für die ESP32 Firmware keine Rolle. Bei den Bricklets ist das etwas anders gelagert, der Entwicklungsprozess für die Bricklets war nie für Windows gedacht, funktioniert dort aber auch, ist nur schwerer einzurichten. Daher bist du da mehr gestolpert. Bei der ESP32 Firmware ist das anders gelagert. Das soll eigentlich Out-of-the-Box funktionieren. Ich arbeite daran das zu verbessern. @ThomKa Kein Grund auf Linux zu wechseln. Gib mir einen Moment, wir bekommen das hin.

Es fehlt dir Git. Installier mal dies hier und am besten danach Windows einmal neustarten. https://github.com/git-for-windows/git/releases/download/v2.37.1.windows.1/Git-2.37.1-64-bit.exe Das fehlte in unserer Anleitung, ich habe das korrigiert.

Kannst du die Bricklets einzeln an einem einzelnen Master Brick (per USB am PC) testen?

Wie sieht der gesammte Aufbau aus? Oder sind es einfach nur Segment Display 4x7 Bricklet 2.0 und Thermal Imaging Bricklet an einem Master Brick, per USB am PC? Tritt das Problem mit der zeitweisen Auftauchen im Brick Viewer auch auf, wenn du nur jeweils ein Bricklet angeschlossen hast? Sitzt beim Thermal Imaging Bricklet das Kameramodul richtig im Sockel? Ohne Strom drauf, mal leicht das Modul in den Sockel drücken.

Das hat dir auch keiner gesagt, sorry. Das Script gibt das jetzt als Hinweis aus.

Hast du das Bricklet am Master Brick an Port D angeschlossen?

Bindings: C/C++ for Microcontrollers 2.0.3 Fix ESP32 HAL compatibility with Arduino-ESP32 2.0.4 Download: C/C++ for Microcontrollers

Bindings: C/C++ for Microcontrollers 2.0.3 ESP32 HAL Kompatibilität mit Arduino-ESP32 2.0.4 verbessert Download: C/C++ for Microcontrollers

Da gibt es nichts zu verlinken. Es geht hier um /home/andreas/git/evse-v2-bricklet/software/src/configs/config.h, das muss automatisch gefunden werden. Ist die Datei bei dir gelöscht? Hast du /home/andreas/git/configs angelegt? Oder den aus dem evse-v2-bricklet Clone dahin verschoben? Prüf mal bitte in allen Repositories, dass du da keine lokalen Änderungen oder gelöscht Dateien hast.

In deinen CMake Logs taucht arm-none-eabi-gcc 10.3.1 auf. Im Docker Container ist aber 5.4.1 drin. Lösch bei dir mal von Hand das /home/andreas/git/evse-v2-bricklet/software/build Verzeichnis. Das sollte eigentlich "make clean" machen. Villeicht hat sich CMake falsche Pfade gemerkt. So richtig Sinn macht das dennoch nicht. Falls das auch nicht hilft, dann ersetz mal /home/andreas/git/bricklib2/cmake/makefiles/Makefile_Bricklet_CoMCU.mk durch die angehängt Datei, die gibt mehr Information aus. Dann nochmal /home/andreas/git/evse-v2-bricklet/software/build löschen, make ausführen und die ganze Ausgabe von make vorzeigen. Makefile_Bricklet_CoMCU.mk

Gibt es bei dir das Verzeichnis /home/andreas/git/evse-v2-bricklet/software/build/CMakeFiles/CMakeTmp nach dem make Aufruf?

CMake testet den C Compiler im Docker Container, da ist mir gerade unklar warum das fehlschlagen kann. Das hat jetzt nichts mehr mit Programm auf deinem PC zu tun. Mach mal ein "make clean" und dann wieder make. Vielleicht liegen da von vorherigen Versuchen noch alte Dateien im Weg.

Stimmt, sorry. https://dave.infineon.com/Libraries/XMCLib/XMC_Peripheral_Library_v2.1.16.zip Das ist die besagte xmclib. Irgendwohin entpacken und nach bricklib2/xmclib symlinken.

Ja, wie es dort beschrieben steht. Das passiert alles automatisch. Ich habe keine neue Information hinzugefügt, sondern nur das was da schon vorher textuell stand noch mal anders dagestellt.

Ich nehme an du bist diesen Schritten hier gefolgt: https://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Build_Environment/Tutorial.html Zu Docker steht dort "Wenn der tinkerforge/build_environment_c Docker-Container installiert ist, wird dies von den Makefiles der Firmwares automatisch erkannt und die Kompilierung findet über den Docker-Container statt." Im Abschnitt "Bricklet mit Co-Prozessor Firmwares" ist beschrieben wie die Verzeichnisstruktur aussehen muss. Mir ist unklar wo du weg hast, dass alle diese gits nach evse-v2-bricklet/softwre/src/ müssen. Das ist nie der Fall.

Das ist absolut nicht normal. Schick uns daher bitte den defekten Brick wieder zurück, damit wir verstehen können was passiert ist. Mein Kollege wird das mit dir absprechen.

Ich fürchte da ist der ESP32 Chip auf dem Brick gestorben. Das soll natürlich so nicht sein, sorry. Wende dich bitte an sales@tinkerforge.com mit Verweis auf diesen Forum-Thread. Wir tauschen den Brick gegen einen neuen aus.

Der IO0 Knopf ist Teil um den ESP32 in den Bootloader zu zwingen, es ist im Normalfall aber nie notwenidig diesen zu drücken, da das automatisch passiert. Ein Druck auf den EN Knopf löst einen Neustart aus. Das die serielle Schnittstelle da ist, aber so gar keine Ausgabe kommt, auch beim Drücken des EN Knopfs, ist ein schlechtes Zeichen. Blinkt auf dem ESP32 Ethernet Brick die blaue Status LED neben dem USB-C Anschluss? Ich würde erwarten, dass die LED aus bleibt. Das beim Klick auf Connect in Brick Viewer ein Fehler kommt, ist in diesem Fall erwartet. Versuch mal den ESP32 Ethernet Brick neu zu flashen. Da warst du schon auf dem richtigen Pfad, du musst allerding in der Liste der Firmwares dazu nicht "ESP32 Ethernet" auswählen, sondern "WARP2 Charger". Schritt für Schritt Anweisungen dazu in der WARP2 Charger Anleitung: https://www.warp-charger.com/documents/WARP2_Betriebsanleitung.pdf (4.7 Zurucksetzen auf Werkszustand)