Hallo, nun wollte ich mal ein Picoprojct mit VSCode machen. Da mußte ich aber feststellen, dass sich seit letzten Jahr einiges geändert hat. Also hab ich alles neu installiert. Dabei bin ich auf die VSCode-Erweiterung für den Pico gestoßen.
Es kamen zwar Fehermeldungen, die mir nichts sagten, aber irgenwie hats funktioniert. Projekterstellung und compilieren geht. Aber Debuggen stürzt ab.
[Failed to launch GDB: Truncated register 16 in remote 'g' packet (from target-select extended-remote localhost:50000)]
Sagt mir nix und weiß auch nicht wie zu fixen. In der Doku (Starting with Pico) ist dazu nichts zu finden. In der vorherigen Version waren die .json Files noch beschrieben. Jetzt gibt es weitere und erweiterte.
Das alles scheint neu zu sein und ich hoffe es kennt sich jemand damit schon besser aus.
Gruß Rudi
Danke für den Link. Ich muß noch mal genauer durchschauen, aber im Prinzip hab ich alles gemacht, Und auf der Kommandozeile geht ja alles. VSCode habe ich mit dem .vsix Download eingerichtet. VSCode compiliert und läd das Programm in den TestPico über einen Pico als Debuggprobeprobe. Nur debuggen geht nicht.
Kann sein das .vsix das offizielle Pico-Probe-Modul oder den Rasperry-Pi einrichtet. Aber wie und wo umgeschaltet wird find ich nicht.
jetzt bin ich einen Schritt weiter, oder aber auch in die falsche Richtung.
Also: ich will meinen Pico mit einem Pico über SWD debuggen. VSCode läuft bei mir über Linux Mind PC mit AMD Prozessor. Die meisten Anleitungen beschreiben die Konfig mit VSCode auf dem Raspberry PI mit der Debugprobe für SWD. Das macht Unterschiede im Aufbau der launch.json Datei.
// Give restart the same functionality as runToEntryPoint - main
19
"postRestartCommands": [
20
"break main",
21
"continue"
22
],
23
"openOCDLaunchCommands": [
24
"adapter speed 5000"
25
]
26
},
Wenn ich nun debuggen aufrufe, wird compiliert, gestartet und im Terminal gemeldet:
1
{Waiting for gdb server to start...[2024-05-25T09:29:31.839Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
Please check TERMINAL tab (gdb-server) for output from /home/rs/.pico-sdk/openocd/v0.12.0-2/bin/openocd
3
Finished reading symbols from objdump: Time: 50 ms
4
/home/rs/.pico-sdk/toolchain/13_2_Rel1/bin/arm-none-eabi-gdb: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory
5
Error: Unable to start GDB even after 5 seconds or it couldn't even start Make sure you can start gdb from the command-line and run any command like "echo hello".
6
If you cannot, it is most likely because "libncurses" or "python" is not installed. Some GDBs require these
7
GDB session ended unexpectedly. exit-code: 127
8
GDB could not start as expected. Bad installation or version mismatch. See if you can start gdb from a shell prompt and check its version (Must be >= 9)
/home/rs/.pico-sdk/toolchain/13_2_Rel1/bin/arm-none-eabi-gdb: error
while loading shared libraries: libncursesw.so.5: cannot open shared
object file: No such file or directory
Und was passiert, wenn du dieses Problem behebst?
Tja, die "DLL-hell" gibt's (entgegen der Aussagen der einschlägigen Linux-Fanboys) halt nicht nur unter Windows. Na gut, unter Linux würde sie natürlich "so-hell" heißen müssen.
Der Rest ist aber exakt dieselbe Soße. Abhängigkeiten, Versionskonflikte, Kompitibilitätsprobleme, völlig unzureichende Dokumentation.
Tja, die "DLL-hell" gibt's (entgegen der Aussagen der einschlägigen
Linux-Fanboys) halt nicht nur unter Windows.
Tut mir leid deinen Vorurteilen widersprechen zu muessen aber ich sage
oft, regelmaessig und laut das das ganze Libarie Handling die GROSSE
Leiche im Keller von Linux ist und auch Linus T. hat sich da IMHO
schon negativ drueber geaeussert.
Allerdings mit einem jlink unter Linux geht alles, das muss ich dann mal loben...
Tja, die "DLL-hell" gibt's (entgegen der Aussagen der einschlägigen
Linux-Fanboys) halt nicht nur unter Windows.
Erstens ist die "DLL-hell" seit etwa 25 Jahren kein Thema mehr. Zweitens wüsste ich gerne, welche konkreten Aussagen von welchen Linux-Fanboys du meinst. Ich glaube, du hast das frei erfunden.
Tut mir leid deinen Vorurteilen widersprechen zu muessen aber ich sage
oft, regelmaessig und laut das das ganze Libarie Handling die GROSSE
Leiche im Keller von Linux ist
Das beweist nur, dass du eben kein Fanboy bist. Das sind die, die Linux unkritisch hochjubeln, aber im Prinzip überhaupt keine Ahnung haben, wie es im Detail funktioniert.
Erstens ist die "DLL-hell" seit etwa 25 Jahren kein Thema mehr.
Unsinn, ist natürlich nach wie vor Thema. Das einzige, was sich geändert hat: es gibt (inzwischen seit Langem) Mechanismen, mit denen man Konflikte auflösen kann.
Übrigens sowohl für Windows als auch für Linux. Es sind halt nur nicht dieselben.
Und perfekt sind sie ebenfalls weder da noch dort.
/home/rs/.pico-sdk/toolchain/13_2_Rel1/bin/arm-none-eabi-gdb: error
while loading shared libraries: libncursesw.so.5: cannot open shared
object file: No such file or directory
Please check TERMINAL tab (gdb-server) for output from /home/rs/.pico-sdk/openocd/v0.12.0-2/bin/openocd
5
Finished reading symbols from objdump: Time: 47 ms
6
Error: Unable to start GDB even after 5 seconds or it couldn't even start Make sure you can start gdb from the command-line and run any command like "echo hello".
7
If you cannot, it is most likely because "libncurses" or "python" is not installed. Some GDBs require these
8
GDB session ended unexpectedly. exit-code: 1
9
Could not find platform independent libraries <prefix>
10
Could not find platform dependent libraries <exec_prefix>
11
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
12
Python path configuration:
13
PYTHONHOME = (not set)
14
PYTHONPATH = (not set)
15
program name = '/usr/local/bld-tools/bld-tools-virtual-env/bin/python'
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
32
Python runtime state: core initialized
33
ModuleNotFoundError: No module named 'encodings'
34
35
Current thread 0x00007f7a3c693c00 (most recent call first):
36
<no Python frame>
37
Finished reading symbols from nm: Time: 73 ms
38
GDB could not start as expected. Bad installation or version mismatch. See if you can start gdb from a shell prompt and check its version (Must be >= 9)
Sehe ich völlig anders. Man behebt einfach die Fehler schrittweise.
Ob man sie nun selber gemacht hat oder andere, lassen wir mal dahin
gestellt.
Hallo, ich wollte damit nicht dich in Verbindung bringen. Ich ackere nun schon langen damit herum und meistens gehts halt eher eher 2 Schritte zurück als einen vorwärts. Ich blicke jetzt auch nicht mehr, welche Schritte mich weiterbrachten.
Sehe ich völlig anders. Man behebt einfach die Fehler schrittweise.
Genau so funktioniert das.
Error: unable to find a matching CMSIS-DAP device
Dafür wäre wohl als nächstes die Frage zu stellen, was er nun genau als Debug-Hardware verwendet. Das ist mir aus dem bisherigen Verlauf des Threads nicht klar.
Benutzt er einen als PicoProbe Firmware geflashten PiPico oder eventuell ein "Raspberry Pi Debug Probe"?
Nur einer der beiden benutzt tatsächlich CMSIS-DAP.
Hallo, ich wollte damit nicht dich in Verbindung bringen.
Kein Problem, niemand zu Schaden gekommen. ;-)
Ich ackere nun
schon langen damit herum und meistens gehts halt eher eher 2 Schritte
zurück als einen vorwärts. Ich blicke jetzt auch nicht mehr, welche
Schritte mich weiterbrachten.
Zurücklehnen. Verschnaufen. Lesen. LESEN.
Dann immer den zu erst auftretenden Fehler (samt Hinweisen) beheben.
Fatal Python error: init_fs_encoding: failed to get the Python codec of
the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encoding
Irgendwas stimmt mit dem python nicht. Sieht für mich so aus, als ob Du nicht das bei deiner Distri beiliegende Python sondern irgendwas eigenes benutzt:
Sieht für mich so aus, als ob da in Deinem System so einiges kaputt ist.Der gdb von "/home/rs/.pico-sdk/toolchain/13_2_Rel1/bin/arm-none-eabi-gdb" versucht ein python von '/usr/local/bld-tools/bld-tools-virtual-env/bin/python' zu verwenden, die Pfade passen jedoch hinten und vorne nicht.
Ich habe mich an "Getting started with Raspberry Pi Pico" gehalten.
Mit 2 Picos und "debugprobe_on_pico.uf2".
Dan Chapter 7.2 install mit VSCode Pico Extension
dann 7.2.2 Create Projekt wobei dann in VS die lauch.json vier verschiedene Debug Versionen enthielt, von den keine beim Debuggen funktionierte.
Compilieren und das Testprogramm hochladen auf den Testpico tut er.
Ich habe mich an "Getting started with Raspberry Pi Pico" gehalten.
Mit 2 Picos und "debugprobe_on_pico.uf2".
Dan Chapter 7.2 install mit VSCode Pico Extension
dann 7.2.2 Create Projekt wobei dann in VS die lauch.json vier
verschiedene Debug Versionen enthielt, von den keine beim Debuggen
funktionierte.
Compilieren und das Testprogramm hochladen auf den Testpico tut er.
Liest du auch mal, was andere Leute hier schreiben? Zwei haben dir gezeigt, wo das aktuelle Problem liegt. Dazu von dir: keinerlei Feedback.
Das ist schade. Leider bin nach Wochen auch bald soweit. Dann muß ich halt im Terminal debuggen, was natürlich nicht so schön ist. Das ging schon mal. Das Problem ist, dass erst am 2.4.2024 eine neue fimware für debugprobe rauskam, und noch kaum Posts in der Community zu finden sind.
Auch das mit der VSCode Extension ist wohl zu neu. Meine Probleme begannen mit dem was auch hier ist: https://github.com/raspberrypi/pico-vscode/releases/download/0.13.1/raspberry-pi-pico-0.13.1.vsix.
Ich glaube aber, das hat mich erst recht in Bockshorn gejagt, als ich versuchte das zu beachten.
Leute ich steh' echt aufn schlauch. Ich tät ja auch alles mal neu aufsetzen, aber ich wüßte immer noch nicht was ich bei der Installation von Pyton anders machen könnte.
Bei meinem neuesten Projekt benutze ich auch einen Pico und VSCode. Ich hatte am Anfang auch echt Probleme und hab lange rumgesucht, aber jetzt läuft es zuverlässig. Ich benutze Ubuntu 22.04 und das VSCode aus dem Microsoft Repository (also nicht als Snap oder so, das fügt meiner Erfahrung nach, eine komplett neue Dimension an Fehlermöglichkeiten hinzu).
Hier die Schritte, die bei mir zum Erfolg führten:
VSCode Deb-Paket von Microsoft herunterladen und installieren wie dort beschrieben.
Das ist der richtige GDB:
1
sudo apt install gdb-multiarch
Falls /openocd/ aus den Ubuntu-Repos installiert ist:
1
sudo apt remove openocd
Installation des pico-sdk nach Anleitung in der "Getting started with Pico" Pdf (https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf) Appendix A, Seite 61. Einfach genau diese Befehle eingeben. Auch das "sudo make install" von Seite 62. :) Funktioniert auch unter Ubuntu.
Bei meinem neuesten Projekt benutze ich auch einen Pico und VSCode. Ich
hatte am Anfang auch echt Probleme und hab lange rumgesucht, aber jetzt
läuft es zuverlässig. Ich benutze Ubuntu 22.04 und das VSCode aus dem
Microsoft Repository (also nicht als Snap oder so, das fügt meiner
Erfahrung nach, eine komplett neue Dimension an Fehlermöglichkeiten
hinzu).
Darauf bin ich auch schon reingefallsen
Hier die Schritte, die bei mir zum Erfolg führten:
VSCode Deb-Paket von Microsoft herunterladen und installieren wie dort
beschrieben.
Bei sudo apt update kommt bei mir:
1
Fehl:1 http://repo.mysql.com/apt/ubuntu disco InRelease
2
Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY B7B3B788A8D3785C
W: GPG-Fehler: http://repo.mysql.com/apt/ubuntu disco InRelease: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY B7B3B788A8D3785C
7
E: Das Depot »http://repo.mysql.com/apt/ubuntu disco InRelease« ist nicht signiert.
8
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
9
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
install cmake.... ist aktuell
Das ist der richtige GDB:
1
sudo apt install gdb-multiarch
ist aktuell
Falls /openocd/ aus den Ubuntu-Repos installiert ist:
1
sudo apt remove openocd
Installation des pico-sdk nach Anleitung in der "Getting started with
Pico" Pdf
(https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf)
Appendix A, Seite 61. Einfach genau diese Befehle eingeben. Auch das
"sudo make install" von Seite 62. :) Funktioniert auch unter Ubuntu.
Appendix A ist in getting-started-with-pico.pdf Version 2.4 auf Seite 67
Bei mir nicht ganz. 2 Fehler bei make (lange Liste), ich mach trotzdem weiter
In VSCode die Extensions: "Cortex-Debug" und "Serial Monitor"
installieren.
hab ich schon
Im .vscode im Projektverzeichnis eine Datei launch.json mit folgendem
Inhalt anlegen:
Hab ich
Hurrah...Debuggen geht nun.
Jetzt muß ich nur noch herausfinden wie ein printf() über USB angeszeigt wird. Der serialmonitor tuts nicht. Ich versuch mal eine 2.USB an dem Test-pico.
Die Fehler bei apt update kommen davon, dass das mysql-Repo, das du irgendwann mal eingerichtet hast, nicht mehr funktioniert. Hat nichts mit VSCode zu tun und ist auch nicht weiter schlimm, nur unschön und falls du mysql von da noch installiert hast, wird es nicht mehr aktualisiert.
Das mit dem Terminal und dem printf funktioniert bei mir reibungslos von VSCode aus. Wie gesagt, das Serial Monitor Plugin in VSCode installieren, das Terminal mit öffnen und auf den Serial Monitor Tab gehen. Dort muss /dev/ttyACM0 als Device ausgewählt sein. Und dann muss noch die Verkabelung stimmen... :) Siehe auch angehängtes Bild.
jetzt geht Terminal auch. Ich hatte vorher die Ports umgekehrt in cmakelist stehen:
1
pico_enable_stdio_usb(fbg 0)
2
pico_enable_stdio_uart(fbg 1)
Im endgültigen Projekt will ich aber, dass alles über die USB-Buchse rausgeht.
Als abschließende Erkenntnis bleibt, dass die VSCode-Extension zur Erstellung eines Pico Projektes, die Raspberry neu anbietet und erst Beta ist, auf Linux Mind noch nicht funtioniert.
