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.
[[https://github.com/raspberrypi/pico-vscode/releases/download/0.13.1/raspberry-pi-pico-0.13.1.vsix]]
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
Rudi schrieb:> Es kamen zwar Fehermeldungen, die mir nichts sagten, aber irgenwie hats> funktioniert.
Dann muss man sich ja auch nicht mit den Fehlermeldungen beschäftigen,
wie?
Vielleicht hat ja eine der Fehlermeldungen etwas mit dem von Dir
beschriebenen Folgefehler zu tun, aber wer will das schon wissen?
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.
Hallo
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.
Das ist meine aktuelle:
// 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)
Rudi schrieb:> /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...
Vanye
Ob S. schrieb:> Tja, die "DLL-hell" gibt's> halt nicht nur unter Windows.Ob S. schrieb:> 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.
Vanye R. schrieb:> 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.
Steve van de Grens schrieb:> 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.
Rudi schrieb:> /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
aptitude install libncursesw5
Rudi schrieb:> Das ganze sieht hier nach einem Pilgerschrittverfahren aus.
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.
> Error: unable to find a matching CMSIS-DAP device
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)
Norbert schrieb:> 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.
Norbert schrieb:> 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.
Rudi schrieb:> 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.
Rudi schrieb:
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Python path configuration:
PYTHONHOME = (not set)
Problem steht doch im Klartext da. Musst du bloß lösen.
Rudi schrieb:> 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.
Rudi schrieb:> 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.
Ich hab' kein Lust mehr.
Ob S. schrieb:> Ich hab' kein Lust mehr.
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:
- Im Serial Monitor des Terminalfensters als Device /dev/ttyACM0
auswählen, um eventuelle Debugmeldungen zu sehen.
Übrigens, falls diese Meldung (vom Debugger, nicht vom Serial Terminal)
kommt:
1
Error: unable to find a matching CMSIS-DAP device
Dann hat er zwar die Debugprobe gefunden, diese aber kein Device. Dann
stimmt meist etwas mit der Verkabelung nicht.
Bernd S. schrieb:> 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
> - Von hier> https://github.com/raspberrypi/debugprobe/releases/tag/debugprobe-v2.0.1> die Datei debugprobe_on_pico.uf2 und auf dem als Debugprobe zu verwenden> Pico installieren.> - Verkabelung wie hier:> https://www.digikey.de/en/maker/projects/raspberry-pi-pico-and-rp2040-cc-part-2-debugging-with-vs-code/470abc7efb07432b82c95f6f67f184c0> (Achtung, diese Seite ist recht veraltet, hat mir aber sehr geholfen)
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.
Danke Bernd
Freut mich, dass ich ein bisschen helfen konnte.
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.
So, lieber Bernd
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.
Thread beobachten
Seitenaufteilung abschalten