Continuing the excellent discussion cited below and the associated links:
https://forum.lazarus.freepascal.org/index.php/topic,52996.0.htmlhttps://wiki.freepascal.org/ARM_Embedded_Tutorial_-_Installing_Lazarus_and_Free_Pascalhttps://wiki.freepascal.org/ARM_Embedded_Tutorial_-_FPC_and_the_Raspberry_Pi_PicoI've got a pukka Pico sitting on a demo board
https://www.cytron.io/p-maker-pi-pico, and a "postage stamp" Waveshare RP2040 Zero running Picoprobe with its UART pins also brought out. Running a Debian Linux host, I can load a "Hello, World!" written in C, capture the output from /dev/ttyACM0, and single-step using gdb connected via OpenOCD.
I have not yet worked through the "Using Visual Studio Code" chapter of the "Getting started with Raspberry Pi Pico" document, but it appears to provide adequate automation of OpenOCD hence gdb to allow debugging to be done: the only thing that needs to be done manually is to start a terminal emulator (minicom in the example) to capture UART traffic.
I've built Lazarus/FPC targeting the Pico using FPCUpdate. I was impressed at how well that went, but I must add that I was concerned at the idea of running a downloaded binary without a published hash/checksum against which I could verify it.
Noting
https://github.com/michael-ring/pico-fpcexamples and again the "ARM Embedded Tutorial - FPC and the Raspberry Pi Pico" wiki page, I can see that it provides e.g. uartdemo.lpi and uartdemo.lpr and can verify that the copy of Lazarus described above opens and builds the project without error.
Now, from my POV the object of the exercise is to explain to a technical (but non-programmer) journalist the extent to which the RP2040+Picoprobe could be a gamechanger by making it far easier for lower-echelon developers to access a debugger on an embedded system. I've already gone to some amount of trouble to "educate" him regarding the roles of a traditional logic analyser and ICE although I haven't yet introduced him to the "shock hairstyle" that hooking up a target board often resembled.
For that reason, I've taken a fair amount of care to build a neat probe, with a ribbon cable for the SWD+power pins and a reversible three-way strip for the UART.
FPCUpdate and Lazarus acquit themselves honourably when it comes to building a .elf file for debugging.
But the description of starting OpenOCD at the bottom of
https://wiki.freepascal.org/ARM_Embedded_Tutorial_-_Raspberry_Pi_Pico_Setting_up_for_Development is incomplete:
$ sudo /usr/local/share/fpcupdeluxed/ccr/develtools4fpc/bin/openocd-rp2040 -f board/pico.cfg
[sudo] password for markMLl:
Open On-Chip Debugger 0.10.0+dev-geb22ace (2021-03-09-20:09)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
Warn : Transport "swd" was already selected
/usr/local/share/fpcupdeluxed/ccr/develtools4fpc/bin/../share/openocd/scripts/board/pico.cfg:2: Error: Can't find target/RP2040.cfg
in procedure 'script'
at file "embedded:startup.tcl", line 26
at file "/usr/local/share/fpcupdeluxed/ccr/develtools4fpc/bin/../share/openocd/scripts/board/pico.cfg", line 2
...and while I'm sure I could work this out from the C stuff I was doing yesterday I thought it was better to raise this with the community.
So:
* What can be done to automate the startup of OpenOCD, since Visual Studio Code apparently does this?
* What can be done about automating the capture of UART output (USB or Serial, but in either case arriving on a /dev/ttyACM* device) to make Lazarus look better than Visual Studio Code?
* Once one has OpenOCD running and UART traffic captured (to a terminal emulator or, better, the console window) what is the crucial next step to load and start the binary?
MarkMLl