Black Magic Probe für PC (hosted) in WSL kompilieren

[Johannes S. (Gast)]

Die BMP nutze ich schon eine ganze Weile auf STLink Clones, das 
funktioniert sehr gut. Jetzt gibt es ja noch zusätzlich die Möglichkeit 
BMP auf dem PC als Host laufen zu lassen und dann per STLink oder 
anderen probes an das target zu verbinden. Das würde ich gerne auf einem 
Raspberry oder PC laufen lassen um remote per LAN zu debuggen. Über 
einen F407 wäre auch schön, ein Discovery board wird ja auch schon als 
Host unterstützt.
Da ich Windows benutze habe ich jetzt das Nötige für BMP in WSL 
installiert und ein 'make' liefert auch ein binary blackmagic.bin. Für 
die hosted version soll 'make PROBE_HOST=hosted' gestartet werden, das 
meckert aber.
Es fehlten pkg-config und libftdi, da habe ich -dev packages installiert 
und jetzt kommt:

jojo@sn-1:~/blackmagic/blackmagic$ make PROBE_HOST=hosted
 GIT include/version.h
Package libftdi1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libftdi1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libftdi1' found
  CC      command.c
In file included from include/general.h:37:0,
                 from command.c:25:
platforms/hosted/platform.h:4:10: fatal error: libusb-1.0/libusb.h: No such file or directory
 #include <libusb-1.0/libusb.h>
          ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Makefile:95: recipe for target 'command.o' failed
make[1]: *** [command.o] Error 1
Makefile:30: recipe for target 'all' failed
make: *** [all] Error 2

Das libftdi1.pc lasse ich gerade mit 'find -name libftdi1.pc' suchen, 
aber das läuft schon ein paar Minuten ohne Ergebnis. Muss da nochwas 
anderes installiert werden als libftdi-dev? Es kann allerdings auch sein 
das es unter WSL2 gar nicht geht weil USB Unterstützung noch fehlt 
soweit ich weiss.
Das ganze müsste ich dann ja auf dem Raspberry nochmal kompilieren damit 
es auch dort läuft, hat das hier mal jemand probiert ob es funktioniert?

[Jim M. (turboj)]

LibUSB kann in WSL nicht korrekt funktionieren IMHO, da Linux und 
Windows unterschliedliche Treiber Architektur für USB haben.

Die Linux version von LibFTDI setzt auf LibUSB auf, die Windows Version 
nutzt den FTDI Treiber IIRC.

>  Muss da nochwas anderes installiert werden als libftdi-dev?

Vermutlich libusb1.0-dev o.ä. Vorsicht: Von LibUSB gäbe es eine ältere, 
inkompatible Variante.

Johannes S. schrieb:
> Das ganze müsste ich dann ja auf dem Raspberry nochmal kompilieren

Jup und da fängt man u.U. von vorne an, weil ARM Architektur.

[Johannes S. (Gast)]

danke, bin auch einen Schritt weiter gekommen.
mit 'sudo apt-get install libftdi1-dev' wurde die fehlende Abhängigkeit 
installiert und blackmagic wird erstellt. Es startet auch und man kann 
die Hilfe mit 'blackmagic -h' anzeigen, wird aber wg. fehlendem USB 
nicht funktionieren.
Damit war das kompilieren unter Windows zumindest nicht schwierig, jetzt 
nochmal auf dem RPi.

[Uwe Bonnes (Gast)]

Warum in WSL laufen lassen? Kompiliere mit mingw direkt unter Windows, 
gebe mit Zadig deine(n) Dongel(s) frei und dann sollte es auch 
funktionieren. Hast Du vor, ggf. einen PR fuer Raspbery zu machen?

[Uwe Bonnes (Gast)]

Jim M. schrieb:
...
> Die Linux version von LibFTDI setzt auf LibUSB auf, die Windows Version
> nutzt den FTDI Treiber IIRC.

Nein, libftdi auf windows setzt auf libusb fuer windows auf.

[Johannes S. (Gast)]

in WSL ist das kompilieren einfacher, zumindest für die STLink Clone und 
Co. Hardware.
Ziel ist jetzt eine debug probe per Ethernet anzuklemmen. Ich habe in 
meinem Werkraum mehrere Plätze mit Netzwerkanschluss, aber kein USB.
Als HW ist mir ein PC zu aufwändig, auch beim RPi braucht man relativ 
viel und noch einen STLink o.ä. Darum versuche ich gerade BMP auf MBed 
statt libopencm3 als Basis umzubauen, in MBed habe ich einen IP Stack 
für z.B. einen F407 schon drin.
Dazu hatte ich auch schon in discord gefragt. Kompilieren mit dummy 
platform geht, aber die target stubs werden angemeckert weil z.b. EFM32 
und lmi doppelt vorhanden sind. Wofür diese stubs sind habe ich noch 
nicht verstanden.
TCP statt USB sollte einfach sein, wie ich verstehe werden einfach die 
Ein/Ausgaben an gdb weitergeleitet?

[Uwe Bonnes (Gast)]

Johannes S. schrieb:
> in WSL ist das kompilieren einfacher, zumindest für die STLink Clone und
> Co. Hardware.
> Ziel ist jetzt eine debug probe per Ethernet anzuklemmen. Ich habe in
> meinem Werkraum mehrere Plätze mit Netzwerkanschluss, aber kein USB.
> Als HW ist mir ein PC zu aufwändig, auch beim RPi braucht man relativ
> viel und noch einen STLink o.ä.

Huch, embedded Entwicklung ohne PC in der Naehe? Debugging aus der 
Ferne?

> Darum versuche ich gerade BMP auf MBed
> statt libopencm3 als Basis umzubauen, in MBed habe ich einen IP Stack
> für z.B. einen F407 schon drin.
> Dazu hatte ich auch schon in discord gefragt. Kompilieren mit dummy
> platform geht, aber die target stubs werden angemeckert weil z.b. EFM32
> und lmi doppelt vorhanden sind. Wofür diese stubs sind habe ich noch
> nicht verstanden.

Siehe Discord.

> TCP statt USB sollte einfach sein, wie ich verstehe werden einfach die
> Ein/Ausgaben an gdb weitergeleitet?

[Johannes S. (Gast)]

Uwe Bonnes schrieb:
> Huch, embedded Entwicklung ohne PC in der Naehe? Debugging aus der
> Ferne?

zumindest in Sichtweite, aber USB Kabel quer durch die Bude sind auch 
nicht so prickelnd und die RJ45 Dosen sind vorhanden.

Und in BMP ist im Prinzip alles drin, das ist schon ein sehr cooles 
Projekt.

Die Hürden sind nur das Buildsystem in Mbed das erstmal alles 
compilieren und linken will (lässt sich aber mit .mbedignore steuern) 
und es ist C++. Da sind Wrapper nötig wenn ich das 'minimal invasiv' 
einbauen will. Hat den Vorteil das Änderungen im Original einfacher 
übernommen werden können, sieht nur etwas komplizierter aus. Aber es 
muss auch nicht an einem Nachmittag fertig werden.

[Johannes S. (Gast)]

Uwe Bonnes schrieb:
> Hast Du vor, ggf. einen PR fuer Raspbery zu machen?

eine Implementierung für Pi/Pi2 gab es tatsächlich vor Jahren schon:
https://github.com/emlid/blackmagic/tree/master/src/platforms
Das wurde aber wohl als Kopie und nicht als Fork angelegt.

aber jetzt habe ich trotzdem den Ehrgeiz das auf dem F407 zum Laufen zu 
bekommen, die Ethernetseite läuft ja schon.

[Johannes S. (Gast)]

Hurra, es funktioniert! BMP über Ethernet statt USB/seriell. Dank des 
genialen BMP Projektes auf Github und der Hilfe von Uwe 'Mr. BMP' Bonnes 
war das einigermassen einfach umzusetzen. Selbst im Debugbuild mit den 
C++ DigitalIO von Mbed toggelt der SWCLK mit ca. 6 MHz.
Hardware ist ein Devebox F407 Board mit Adapterplatine für einen LAN8720 
Phy, kostet zusammen keine 20 €.
https://github.com/mcauser/MCUDEV_DEVEBOX_F407VGT6

[bdi2k (Gast)]

Johannes S. schrieb:
> Hurra, es funktioniert!

Super!

Läuft das jetzt so ähnlich wie BMP auf einem esp32?

[Johannes S. (Gast)]

Hört sich so an. Hast du einen Link?
Ich habe nur Probleme mit dem H743, wäre interessant ob es mit der ESP 
Variante funktioniert.
Das hier ?
https://github.com/Ebiroll/esp32_blackmagic