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