C/C++ Binding für Mikrocontroller (PIO Setup & SPI remapping & HAT Zero UID)

[stif]

Hallo Leute,

ich habe mir vor kurzem ein paar Bricklets bestellt und versuche nun sie über das C/C++ Binding und PlatformIO mit VS Code in Betrieb zu nehmen. (Mir gefällt die Arudino IDE nicht)

Habe mit dem Master Brick mal die Funktion der Bricklets getestet und versuche nun mit einem HAT Zero und einem ESP32 das Binding zu testen.

 

Die aktuelle Projekt-Struktur kann zumindest mal kompiliert werden: https://github.com/stif/tf-mcu-bindings-demo 😀

Doch ich habe vorerst mal 2 Probleme (und kann nicht weitermachen, bis sie gelöst sind):

1. ich verwende einen Olimex ESP32-Poe: bei diesem Board sind die Standard ESP32 GPIOs für VSPI bzw HSPI nicht vollständig herausgeführt. Wie kann ich die SPI Pins remappen? muss dafür das HAL umgeschrieben werden?
2. Wie finde ich die UID des HAT Zero heraus? muss ich dafür eine SD Karte aufsetzten und den BrickViewer auf einem RaspberryPiZero installieren oder geht das auch irgendwie anders?

Und hat sonst noch wer Tipps und Tricks wie ich meine Code Struktur verbessern kann?

Vielen Dank,

Stefan

[rtrbt]

Moin Stefan,

13 hours ago, stif said:

ich verwende einen Olimex ESP32-Poe: bei diesem Board sind die Standard ESP32 GPIOs für VSPI bzw HSPI nicht vollständig herausgeführt. Wie kann ich die SPI Pins remappen? muss dafür das HAL umgeschrieben werden?

Du meinst die Pins die nicht Chip-Select sind? Die musst du im HAL selbst umbiegen, ja. Du kannst dir in hal_arduino_esp32.cpp in folgendem Block:

if (uses_hspi) {
	hal->hspi = SPIClass(HSPI);
	hal->hspi.begin();
}
if (uses_vspi) {
	hal->vspi = SPIClass(VSPI);
	hal->vspi.begin();
}

die Pins in den Begin-Aufruf reinpatchen, z.B. so:

hal->hspi.begin(CLK_PIN, MISO_PIN, MOSI_PIN);

wenn du nur HSPI oder VSPI umbiegst, musst du dann in deiner ports.h alle Ports auf das entsprechende SPI setzen.

 

13 hours ago, stif said:

Wie finde ich die UID des HAT Zero heraus? muss ich dafür eine SD Karte aufsetzten und den BrickViewer auf einem RaspberryPiZero installieren oder geht das auch irgendwie anders?

Das HAT Zero (übrigens auch das große HAT) sind im Endeffekt eine Schaltung + ein Bricklet. Es gibt einen Select-Pin am HAT-Stecker mit dem du mit dem Microcontroller auf dem HAT reden kannst (B-CS4 im Schematic, das ist Pin 22 bzw. GPIO 25 am Pi). Wenn du diesen Pin als normalen Port in deine ports.h packst, funktioniert das alles automagisch, du kannst dann also über tf_hal_get_device_info u.A. die UID abfragen.

 

13 hours ago, stif said:

Und hat sonst noch wer Tipps und Tricks wie ich meine Code Struktur verbessern kann?

Weniger zur Codestruktur und mehr ein allgemeiner Hinweis: Du kannst dir die esp32-lib mal ansehen, da sind noch ein paar hilfreiche Konstrukte enthalten, wenn du z.B. Devices nach der Device-(Typ)-ID suchen willst oder Firmwares flashen o.Ä.. Die Lib ist aber darauf ausgelegt in einer Firmware wie der für unsere Wallbox eingesetzt zu werden, da musst du eventuell Zeug rauspatchen für Konstrukte die du nicht hast.

Grüße,
Erik

[stif]

Hallo Erik,

Vielen Dank für die rasche Rückmeldung!

Ich habe die Datei hal_arduino_esp32.cpp wie vorgeschlagen umgeschrieben, die Ports angepasst und die tf_hal_get_device_info Funktion eingefügt (schamlos kopiert von der esp32-lib 😊). Ist alles im Github Repository aktualisiert: https://github.com/stif/tf-mcu-bindings-demo

Leider bekomme ich als Ausgabe nur:

Hello World!
Get Device Info:
 Є�?␏

Es ist auch so das bei keiner von den Tinkerforge Komponenten eine Status LED leuchtet, was mich zur Frage bringt: reicht es wenn ich am HAT Zero Pin1 mit 3,3V versorge und Pin 6 auf GND lege? Oder braucht das HAT Zero 5V Versorgungsspannung?

Bzw gibt es sonst noch offensichtliche Fehler warum die Kommunikation noch nicht klappt?

Vielen Dank,

Stefan

[photron]

Pin 1 ist auf dem HAT Zero Brick nicht angeschlossen. Siehe Schaltplan:

https://github.com/Tinkerforge/hat-zero-brick/raw/master/hardware/hat-zero-schematic.pdf

Du musst Pin 2 mit 5V versorgen. Daraus macht sich der HAT Zero Brick dann selbst 3,3V.

Deine getDeviceInfo Funktion gibt Wortschrott aus, weil du dem tf_hal_printf Aufruf für %s eine String Instanz mit gibst. Die tf_hal_printf Funktion erwartet aber für %s einen char Pointer. Du musst also von der String Instanz mit der c_str Methode deren internen char Pointer abfragen:

tf_hal_printf("Get Device Info:\n %s", result.c_str());

 

[stif]

Vielen Dank für den erstklassigen Support! Muss mich erst daran gewöhnen, dass die Schaltpläne auch OpenSource sind 👏😊.

Leider klappt die Kommunikation nach wie vor nicht 😓

Ich habe die hal_arduino_esp32.cpp wieder auf den original Stand zurückgesetzt und mit einem Lolin32 getestet (mit Standard HSPI Pins 13,12,14,15).

MISO und MOSI Pins habe ich am Board auch mal normal und mal getauscht getestet.

Die serielle Ausgabe ist leider wie folgt:

Get Device Info:
 {"devices": []}

Ich werde mal mit dem Logic Analyzer die SPI Kommunikation mitschneiden, vielleicht finde ich so den Fehler..

bearbeitet August 19, 2021 at 10:43 von stif

[rtrbt]

Die Verkabelung sieht soweit ich das erkennen konnte richtig aus. Falls du einen Saleae Logic Analyzer hast kannst du dir unseren HLA ansehen:

https://www.tinkerforge.com/de/doc/Low_Level_Protocols/Saleae_High_Level_Analyzer.html

Ich habe nochmal in deinen HAL gesehen: Es fehlt auf jeden Fall die Zeile

hal->hspi = SPIClass(HSPI);

vor

hal->hspi.begin(CLK_PIN, MISO_PIN, MOSI_PIN);

Ich bin mir gerade nicht mehr sicher, ob der SPIClass-Konstruktor außer dem Pin-Mapping noch mehr tut, eventuell war die Zeile wichtig ;)

[stif]

Es ist definitiv noch was faul mit der SPI Initialsierung.

Mit dem aktuellen Github Projekt und laut Sigrok Logic Analyzer ist MISO und MOSI immer LOW und CLK immer High (siehe Bild Sigrok-SPI-Tinkerforge).

Mit einem Arduino Demo SPI Projekt:

#include <Arduino.h>

// inslude the SPI library:
#include <SPI.h>

#define MOSI_PIN 13
#define MISO_PIN 16
#define CLK_PIN 14

// set pin 10 as the slave select for the digital pot:
const int slaveSelectPin = 10;

void digitalPotWrite(int address, int value) {
  // take the SS pin low to select the chip:
  digitalWrite(slaveSelectPin, LOW);
  delay(100);
  //  send in the address and value via SPI:
  SPI.transfer(address);
  SPI.transfer(value);
  delay(100);
  // take the SS pin high to de-select the chip:
  digitalWrite(slaveSelectPin, HIGH);
}

void setup() {
  // set the slaveSelectPin as an output:
  pinMode(slaveSelectPin, OUTPUT);
  // initialize SPI:
  SPI.begin(CLK_PIN, MISO_PIN, MOSI_PIN);
}

void loop() {
  // go through the six channels of the digital pot:
  for (int channel = 0; channel < 6; channel++) {
    // change the resistance on this channel from min to max:
    for (int level = 0; level < 255; level++) {
      digitalPotWrite(channel, level);
      delay(10);
    }
    // wait a second at the top:
    delay(100);
    // change the resistance on this channel from max to min:
    for (int level = 0; level < 255; level++) {
      digitalPotWrite(channel, 255 - level);
      delay(10);
    }
  }
}

kann ich am gleichen Board (bin wieder am Olimex-ESP32) und auf den gleichen Pins die SPI Kommunikation belauschen (Bild Sigrok-SPI-test)

der Tipp mit

hal->hspi = SPIClass(HSPI);

im HAL war schon mal in die richtige Richtung, aber leider noch nicht ausreichend 😓

 

Edit:

Ganz Komisch: nach einem neuen upload hatte ich kurz eine Kommunikation: (es sollten eigentlich 3 Bricklets und 1 HAT gefunden werden..)

{"devices": [ {"UID":"RJH", "DID":2109, "port":"E"}]}

aber nach einem Reset vom ESP32 Board war es sofort wieder vorbei..

bearbeitet August 19, 2021 at 13:49 von stif

[rtrbt]

Liest du SPI zwischen dem ESP und dem HAT oder zwischen HAT und Bricklet?

Noch eine Sache die mir auffällt: Dein Beispiel schreibt Daten per SPI an einen Slave, vom Logic-Analyzer-Bild her ist das Pinmapping

D0 MISO
D1 MOSI
D2 CLK
D3 CS

Jetzt sehe ich da aber Daten auf MISO, nicht auf MOSI. Das scheint falsch herum zu sein. Oder hast du das nur in Sigrok falsch zugeordnet?

 

[stif]

Ich lese zwischen ESP und HAT ja.

Und ja stimmt, die Zuordnung in Sigrok falsch. Was mich aber stutzig macht ist, dass ich mit dem meinem Tinkerforge Programm gar keine Kommunikation lesen kann.

Bzw einmal kurz da war und ohne etwas um zustecken oder einen neuen upload zu machen nach dem reset vom ESP wieder weg war. (hatte leider nicht mit Sigrok mitgelesen wie die Kommunikation kurz da war)

Klingt nach einem Wackelkontakt, aber das andere Testprogramm funktioniert immer..

Kann es sein dass der Bus Speed zu hoch ist? Bzw bin ich gerade ziemlich ratlos 🤔

 

[rtrbt]

Ich habe den Code so wie du ihn hast mal mit einem NodeMCU getestet. Musste dafür nur im HAL den MISO_PIN von 16 auf 12 setzen. Damit funktioniert es aber. Die Bilder sind die Anfrage der Bindings, mit dem sie abfragen was an dem Port angeschlossen ist und die Antwort des One Wire Bricklets. Wenn das funktioniert müsstest du die Ausgabe auf der seriellen Konsole sehen:

Hello World!
Found device GGU of type 2123 at port A
Get Device Info:
 {"devices": [ {"UID":"GGU", "DID":2123, "port":"A"}]}

So wie dein Code da steht, gibt es nur kurz Kommunikation, wenn du die Bindings startest, du könntest aber in die Loop noch tf_hal_callback_tick aufrufen, dann prüfen die Bindings permanent, ob die Bricklets Daten schicken wollen.

Der Bus sollte mit 1,4 MHz laufen. Alles bis 2 MHz verstehen die Bricklets.

Edit: Bilder als Anhang, damit man sie auch lesen kann.

Edit2: Das Forum wehrt sich. Klickst du hier: https://imgur.com/a/6mQ0OYF

 

 

[stif]

Mit welchem Commit läuft dein NodeMCU? Im Commit Simplified main.cpp and updated hal-arduino-esp32 habe ich den getDeviceInfo Aufruf schon in die loop gegeben, damit ich regelmäßige Kommunikation habe..

Ausserdem habe ich die Bricklet Includes weggegeben, damit das Programm so einfach wie möglich ist und nur via SPI die Device Infos abgefragt werden.

Bzw sind die Bricklet Inludes notwendig, damit die Bricklets im getDeviceInfo antworten können? Das würde zumindest erklären, warum sich nur 1 Device (HAT?) gemeldet hat, wie die Kommunikation kurzfristig funktioniert hat.

Und wie hast du das Programm gebaut und hochgeladen? Mit einem eigenem Makefile, oder über PlatformIO? 

Hier ist der Output von meinem Build Vorgang:

[stif@stif-laptop TinkerForgeESP32]$ pio run -v
Processing esp32-poe (platform: espressif32; board: esp32-poe; framework: arduino; monitor_speed: 115200)
---------------------------------------------------------------------------------------------------------------------------------
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32-poe.html
PLATFORM: Espressif 32 (3.3.1) > OLIMEX ESP32-PoE
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES: 
 - framework-arduinoespressif32 3.10006.210326 (1.0.6) 
 - tool-esptoolpy 1.30100.210531 (3.1.0) 
 - toolchain-xtensa32 2.50200.97 (5.2.0)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 31 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <bindings> (/home/stif/workspace/arduino/TinkerForgeESP32/lib/bindings)
|-- <hal-arduino-esp32> (/home/stif/workspace/arduino/TinkerForgeESP32/lib/hal-arduino-esp32)
|   |-- <bindings> (/home/stif/workspace/arduino/TinkerForgeESP32/lib/bindings)
|   |-- <SPI> 1.0 (/home/stif/.platformio/packages/framework-arduinoespressif32/libraries/SPI)
Building in release mode
xtensa-esp32-elf-g++ -o .pio/build/esp32-poe/src/main.cpp.o -c -fno-rtti -fno-exceptions -std=gnu++11 -Os -g3 -Wall -nostdlib -Wpointer-arith -Wno-error=unused-but-set-variable -Wno-error=unused-variable -mlongcalls -ffunction-sections -fdata-sections -fstrict-volatile-bitfields -Wno-error=deprecated-declarations -Wno-error=unused-function -Wno-unused-parameter -Wno-sign-compare -fstack-protector -fexceptions -Werror=reorder -DPLATFORMIO=50101 -DARDUINO_ESP32_POE -DESP32 -DESP_PLATFORM -DF_CPU=240000000L -DHAVE_CONFIG_H -DMBEDTLS_CONFIG_FILE=\"mbedtls/esp_config.h\" -DARDUINO=10805 -DARDUINO_ARCH_ESP32 -DARDUINO_VARIANT=\"esp32-poe\" "-DARDUINO_BOARD=\"OLIMEX ESP32-PoE\"" -Iinclude -Isrc -Ilib/hal-arduino-esp32 -I/home/stif/.platformio/packages/framework-arduinoespressif32/libraries/SPI/src -Ilib/bindings -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/config -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/app_trace -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/app_update -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/asio -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/bootloader_support -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/bt -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/coap -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/console -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/driver -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/efuse -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp-tls -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp32 -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp_adc_cal -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp_event -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp_http_client -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp_http_server -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp_https_ota -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp_https_server -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp_ringbuf -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp_websocket_client -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/espcoredump -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/ethernet -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/expat -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/fatfs -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/freemodbus -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/freertos -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/heap -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/idf_test -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/jsmn -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/json -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/libsodium -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/log -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/lwip -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/mbedtls -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/mdns -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/micro-ecc -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/mqtt -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/newlib -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/nghttp -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/nvs_flash -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/openssl -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/protobuf-c -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/protocomm -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/pthread -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/sdmmc -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/smartconfig_ack -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/soc -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/spi_flash -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/spiffs -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/tcp_transport -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/tcpip_adapter -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/ulp -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/unity -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/vfs -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/wear_levelling -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/wifi_provisioning -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/wpa_supplicant -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/xtensa-debug-module -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp-face -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp32-camera -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/esp-face -I/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/include/fb_gfx -I/home/stif/.platformio/packages/framework-arduinoespressif32/cores/esp32 -I/home/stif/.platformio/packages/framework-arduinoespressif32/variants/esp32-poe src/main.cpp
xtensa-esp32-elf-g++ -o .pio/build/esp32-poe/firmware.elf -T esp32_out.ld -nostdlib -Wl,-static -u call_user_start_cpu0 -Wl,--undefined=uxTopUsedPriority -Wl,--gc-sections -Wl,-EL -T esp32.project.ld -T esp32.rom.ld -T esp32.peripherals.ld -T esp32.rom.libgcc.ld -T esp32.rom.spiram_incompatible_fns.ld -u ld_include_panic_highint_hdl -u __cxa_guard_dummy -u __cxx_fatal_exception .pio/build/esp32-poe/src/main.cpp.o .pio/build/esp32-poe/src/tf_hat_zero.c.o .pio/build/esp32-poe/src/tf_thermocouple.c.o -L.pio/build/esp32-poe -L/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/lib -L/home/stif/.platformio/packages/framework-arduinoespressif32/tools/sdk/ld -Wl,--start-group .pio/build/esp32-poe/lib58b/libbindings.a .pio/build/esp32-poe/libe81/libSPI.a .pio/build/esp32-poe/lib033/libhal-arduino-esp32.a .pio/build/esp32-poe/libFrameworkArduinoVariant.a .pio/build/esp32-poe/libFrameworkArduino.a -lgcc -lesp_websocket_client -lwpa2 -ldetection -lesp_https_server -lwps -lhal -lconsole -lpe -lsoc -lsdmmc -lpthread -llog -lesp_http_client -ljson -lmesh -lesp32-camera -lnet80211 -lwpa_supplicant -lc -lmqtt -lcxx -lesp_https_ota -lulp -lefuse -lpp -lmdns -lbt -lwpa -lspiffs -lheap -limage_util -lunity -lrtc -lmbedtls -lface_recognition -lnghttp -ljsmn -lopenssl -lcore -lfatfs -lm -lprotocomm -lsmartconfig -lxtensa-debug-module -ldl -lesp_event -lesp-tls -lfd -lespcoredump -lesp_http_server -lfr -lsmartconfig_ack -lwear_levelling -ltcp_transport -llwip -lphy -lvfs -lcoap -lesp32 -llibsodium -lbootloader_support -ldriver -lcoexist -lasio -lod -lmicro-ecc -lesp_ringbuf -ldetection_cat_face -lapp_update -lespnow -lface_detection -lapp_trace -lnewlib -lbtdm_app -lwifi_provisioning -lfreertos -lfreemodbus -lethernet -lnvs_flash -lspi_flash -lc_nano -lexpat -lfb_gfx -lprotobuf-c -lesp_adc_cal -ltcpip_adapter -lstdc++ -Wl,--end-group
<lambda>(["checkprogsize"], [".pio/build/esp32-poe/firmware.elf"])
MethodWrapper(["checkprogsize"], [".pio/build/esp32-poe/firmware.elf"])
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   4.2% (used 13872 bytes from 327680 bytes)
Flash: [==        ]  17.0% (used 223102 bytes from 1310720 bytes)
.pio/build/esp32-poe/firmware.elf  :
section                                                size         addr
.rtc.text                                                 0   1074528256
.rtc.dummy                                                0   1073217536
.rtc.force_fast                                           0   1073217536
.rtc_noinit                                               0   1342177792
.rtc.force_slow                                           0   1342177792
.iram0.vectors                                         1024   1074266112
.iram0.text                                           43980   1074267136
.dram0.data                                            9000   1073470304
.noinit                                                   0   1073479304
.dram0.bss                                             4872   1073479304
.flash.rodata                                         55860   1061158944
.flash.text                                          113238   1074593816
.debug_frame                                          91144            0
.debug_info                                         1589891            0
.debug_abbrev                                        197967            0
.debug_loc                                           584324            0
.debug_aranges                                        35616            0
.debug_ranges                                         45904            0
.debug_macro                                         181247            0
.debug_line                                          785607            0
.debug_str                                           966365            0
.comment                                                418            0
.xtensa.info                                             56            0
.xt.lit._ZN14HardwareSerialD5Ev                           0            0
.xt.prop._ZN14HardwareSerialD5Ev                          0            0
.xt.prop._ZN6Stream9readBytesEPhj                        36            0
.xt.prop._ZN14HardwareSerialD2Ev                         36            0
.xt.prop._ZN14HardwareSerialD0Ev                         36            0
.xt.prop._ZTV14HardwareSerial                            12            0
.xt.lit._ZN9IPAddressD5Ev                                 0            0
.xt.prop._ZN9IPAddressD5Ev                                0            0
.xt.prop._ZN9IPAddressD2Ev                               36            0
.xt.prop._ZN9IPAddressD0Ev                               36            0
.xt.prop._ZTV9IPAddress                                  12            0
.xt.lit._ZN5Print5writeEPKc                               0            0
.xt.prop._ZN5Print5writeEPKc                             48            0
.xt.lit._ZN6String6setLenEi                               8            0
.xt.lit._ZN6String4initEv                                 0            0
.xt.prop._ZN6String6setLenEi                             84            0
.xt.prop._ZN6String4initEv                               36            0
.xt.prop._ZNK6String3lenEv                               60            0
.xt.prop._ZNK6String7wbufferEv                           48            0
.xt.prop._ZTISt9exception                                12            0
.xt.prop._ZTISt9bad_alloc                                12            0
.xt.prop._ZTVN10__cxxabiv120__si_class_type_infoE        12            0
.xt.prop._ZTVN10__cxxabiv117__class_type_infoE           12            0
Total                                               4707049
"/home/stif/.platformio/penv/bin/python" "/home/stif/.platformio/packages/tool-esptoolpy/esptool.py" --chip esp32 elf2image --flash_mode dio --flash_freq 40m --flash_size 4MB -o .pio/build/esp32-poe/firmware.bin .pio/build/esp32-poe/firmware.elf
esptool.py v3.1
Merged 1 ELF section
================================================== [SUCCESS] Took 5.75 seconds ==================================================

Ich werde morgen wenn ich wieder Zugang zur Hardware habe, noch einmal mit dem Lolin32 testen..

[rtrbt]

13 hours ago, stif said:

Mit welchem Commit läuft dein NodeMCU? Im Commit Simplified main.cpp and updated hal-arduino-esp32 habe ich den getDeviceInfo Aufruf schon in die loop gegeben, damit ich regelmäßige Kommunikation habe..

Mit genau dem Commit, ja.

Jetzt verstehe ich aber die Verwirrung: getDeviceInfo() ruft tf_hal_get_device_info auf, das erzeugt aber keine Kommunikation, sondern fragt nur die Informationen ab, die der HAL ganz am Anfang gesammelt hat. Was in tf_hal_create bzw. tf_hal_common_prepare (was von _create aufgerufen wird) passiert, ist dass der HAL an allen verfügbaren Ports abfragt, welche Devices angeschlossen sind. Mit tf_hal_get_device_info kannst du die abgefragten Daten dann auslesen.

Wenn du permanent Kommunikation auf allen Ports erzeugen willst, kannst du entweder tf_hal_callback_tick verwenden, dann ist es aber nur unidirektional, weil die Bricklets vermutlich nichts antworten werden (es sei denn du hast eins der Bricklets mit nicht deaktivierbaren Callbacks die auslösen z.B. ein RGB LED Button den du immer mal drückst) oder du baust dir etwas in die Richtung:

TF_Unknown unknown;

for(int i = 0; i < port_count; ++i) {
    tf_unknown_create(&unknown, "1", hal, (uint8_t)i, 0);

    int rc = tf_unknown_get_identity(&unknown, nullptr, nullptr, nullptr, nullptr, nullptr, nullptr);
    
    tf_unknown_destroy(&unknown);
}

(ungefähr geklaut aus tf_hal_common_prepare)

Das gute am Unknown Bricklet ist, dass es einen Konstruktor hat, bei dem du explizit den Port angeben kannst. UID "1" ist Broadcast.

13 hours ago, stif said:

Ausserdem habe ich die Bricklet Includes weggegeben, damit das Programm so einfach wie möglich ist und nur via SPI die Device Infos abgefragt werden.

Bzw sind die Bricklet Inludes notwendig, damit die Bricklets im getDeviceInfo antworten können? Das würde zumindest erklären, warum sich nur 1 Device (HAT?) gemeldet hat, wie die Kommunikation kurzfristig funktioniert hat.

Nein die includes brauchst du nur, wenn du mit dem Bricklet kommunizieren willst, der HAL verwendet intern nur bricklet_unknown und includet das selbst.

13 hours ago, stif said:

Und wie hast du das Programm gebaut und hochgeladen? Mit einem eigenem Makefile, oder über PlatformIO? 

Mit PlatformIO:

pio run -e esp32-poe -t upload -t monitor

Das benutze ich sowieso für die Wallbox-Firmware (falls du spionieren willst: https://github.com/Tinkerforge/warp-charger/tree/master/software)

 

Wenn das HAT bei dir aufschlägt, funktioniert die Kommunikation prinzipiell. Siehst du auf der seriellen Konsole dann auch folgendes?

Found device XYZ of type 112 at port E

[stif]

Vielen Dank für die Geduld!

Zitat

getDeviceInfo() ruft tf_hal_get_device_info auf, das erzeugt aber keine Kommunikation

Ah ok, das erklärt natürlich warum ich keine Kommunikation über SPI mitlauschen konnte 🙃

Ich habe jetzt die vorgeschlagene Routine eingebaut und konnte auch den Traffic auf SPI mitsniffen:

 

Ich hatte auch zeitweise wieder Rückmeldungen von den Bricklets: (das mit dem Olimex ESP32-PoE)

Found device RJH of type 2109 at port C
Get Device Info:
 {"devices": [ {"UID":"RJH", "DID":2109, "port":"E"}]}
RC 0: -1
RC 1: -1
RC 2: 0
RC 3: 0
RC 4: 0

Aber meistens sah es so aus: (mit dem Olimex und dem Lolin32 Board)

Hello World!
Get Device Info:
 {"devices": []}
RC 0: -1
RC 1: -1
RC 2: -1
RC 3: -1
RC 4: -1

 

Dann habe ich mal das Thermocouple Bricklet abgesteckt (war auf Port C) und auch auf ein anderes Olimex ESP32-PoE Board gewechselt:

RC 0: -1
RC 1: -1
RC 2: -1
RC 3: -1
Found device V7o of type 112 at port E
RC 4: -1
Get Device Info:
 {"devices": [ {"UID":"Sfw", "DID":2121, "port":"A"},{"UID":"TMC", "DID":2164, "port":"B"},{"UID":"V7o", "DID":112, "port":"E"}]}
RC 0: -1
RC 1: -1
RC 2: -1
RC 3: -1
RC 4: 0

Also bis auf die -1 Rückgabewerte bei RC0 und RC1 genau so wie es sein soll.

Hat aber leider wieder einen Reset vom ESP Board nicht überlebt und danach nur mehr {"devices": []} ausgegeben 😖

Schaut also für mich so aus wie wenn eigentlich alles korrekt ist (Software und Verkabelung), ich aber keine stabile SPI Kommunikation aufbauen kann. Aus welchen Grund auch immer.

Weiß nicht mehr was ich machen soll.. 😒

bearbeitet August 20, 2021 at 10:36 von stif

[stif]

Juhu, ich glaub ich weiß wo das Problem war 🎉😅

Ich hatte alle 5 Ports definiert, auch wenn nicht alle belegt gewesen sind.

Nachdem ich die Ports ohne Bricklet rausgelöscht habe, klappt auch die Verbindung stabil:

Hello World!
Found device Sfw of type 2121 at port A
Found device TMC of type 2164 at port B
Found device V7o of type 112 at port E
Get Device Info:
 {"devices": [ {"UID":"Sfw", "DID":2121, "port":"A"},{"UID":"TMC", "DID":2164, "port":"B"},{"UID":"V7o", "DID":112, "port":"E"}]}
RC 0: 0
RC 1: 0
RC 2: 0

Vermutlich kommt das Timing durcheinander, wenn versucht wird mit einem Port zu kommunizieren wo keine Bricklets dran sind..

Wie auch immer, ich kann jetzt endlich experimentieren mit den Komponenten 👏

[stif]

zu früh gefreut 😭

Vorhin hat es mindestens 10x Reset überstanden und immer die Devices erkannt. Einmal vom Strom genommen und wieder angesteckt, ist wieder das alte Muster erkennbar:

Hello World!
Get Device Info:
 {"devices": []}
RC 0: -1
RC 1: -1
RC 2: -1

Edit: scheinbar ist das Steckboard, die Kabel oder die HAT Buchse sehr empfindlich: Nachdem ich die Kabel bei der HAT Buchse etwas bewegt habe, ist die Kommunikation wieder da.

Also einfach ein Wackelkontakt bzw schlechte Verbindung gepaart mit hohem Datenaufkommen.. 🙈

Sorry für die vielen Posts wegen eines Wackelkontaktes 😇

bearbeitet August 20, 2021 at 11:36 von stif

[rtrbt]

Hm kaputte Jumperkabel hatte ich bei der Binding-Entwicklung auch. (Mein Aufbau sah übrigens sehr ähnlich aus ;) )

Wegen der Robustheit solltest du die Ports, die du nicht benutzt wieder in die Konfiguration aufnehmen, zumindest wenn du Bricklets angeschlossen hast: Das HAT hat Trennerchips, die sicherstellen, dass SPI nur an das selektierte Bricklet geht. Wenn du dann die Enable-Leitung der Chips floating lässt (das ist einfach das Chip-Select-Signal) könnten sich komische Effekte ergeben.

[stif]

Hallo,

ich habe die Jumperkabel direkt auf das ESP32 Board gesteckt, jetzt funktioniert die Kommunikation stabil (scheinbar hatte das Steckboard Kontaktschwierigkeiten..)

Was mir aber aufgefallen ist: Es gibt kein Binding für das Industrial PTC Bricklet.. Ich dachte mir ich verwende das Binding vom PTC V2 Bricklet, da sie sehr ähnlich sind. Funktioniert aber leider nicht, ich bekomme  beim Setup (tf_ptc_v2_create) folgende Fehlermeldung:

Failed to create device object: the device with the given UID is of unexpected device type (error code -11)

Lg,

Stefan

PS: Hier ist der aktuelle Code: https://github.com/stif/tf-mcu-bindings-demo

[rtrbt]

Das Industrial PTC Bricklet ist neuer als die letzte Bindings-Beta. Wirf mal die beiden Dateien im Anhang in den bindings-Ordner.

bricklet_industrial_ptc.c bricklet_industrial_ptc.h

[stif]

Vielen Dank für die rasche Rückmeldung. Hat geklappt! 👏

[stif]

Hallo Liebes TF Team,

mir ist gerade aufgefallen, dass Bricklet Industrial_Dual_AC_Relais fehlt auch im C++ Binding für Mikrocontroller..

[photron]

rtrbt ist gerade im Urlaub. Ich habe aber mal den Generator durchlaufen lassen, kann aber nicht garantieren ob das auch zu deiner Version passt. Probier die beiden Dateien mal aus.

bricklet_industrial_dual_ac_relay.c bricklet_industrial_dual_ac_relay.h

[stif]

Hallo photron,

ja hat funktioniert, vielen Dank!