Fabien Chouteau's PicoProbe PCB Turns a Raspberry Pi Pico Into an Easy-to-Use SWD Debugger

树莓派官方提供的Picoprobe的固件

Picoprobe的PCB设计

ShawnHymel发布的Raspberry Pi Pico and RP2040 - C/C++ Part 2: Debugging with VS Code

基于树莓派Pico和ESP32制作的基于网页的示波器：

• Pi Pico ADC input using DMA and MicroPython
• Pi Pico wireless Web server using ESP32 and MicroPython
• Web display for Pi Pico oscilloscope

关于ADC采样和FFT：

• Raspberry Pi Pico: ADC Sampling and FFT
  • 在Github上的C代码

用树莓派Pico制作一个USB麦克风

树莓派和OpenOCD， 可用于制作下载器的参考

HTML5 X Y Oscilloscope

用树莓派Pico/RP2040制作逻辑分析仪的资源

来源：https://learn.adafruit.com/pip-boy-2040 

硬件构成：

安装CircuitPython： Install CircuitPython

编程Pip-Boy：Code the Pip-Boy 2040

# SPDX-FileCopyrightText: 2021 john park for Adafruit Industries
# SPDX-License-Identifier: MIT
import time
import board
from adafruit_simplemath import map_range
import displayio
from adafruit_seesaw.seesaw import Seesaw
import adafruit_imageload
from adafruit_st7789 import ST7789

displayio.release_displays()

i2c_bus = board.I2C()
ss = Seesaw(i2c_bus)

spi = board.SPI()  # setup for display over SPI
tft_cs = board.D5
tft_dc = board.D6
display_bus = displayio.FourWire(
    spi, command=tft_dc, chip_select=tft_cs, reset=board.D9
)

display = ST7789(display_bus, width=280, height=240, rowstart=20, rotation=270)

screen = displayio.Group()  # Create a Group to hold content
display.show(screen)  # Add it to the Display

# display image
image = displayio.OnDiskBitmap("/img/bootpip0.bmp")
palette = image.pixel_shader
background = displayio.TileGrid(image, pixel_shader=palette)
screen.append(background)

# load cursor on top
cursor_on = True
if cursor_on:
    image, palette = adafruit_imageload.load("/img/cursor_green.bmp")
    palette.make_transparent(0)
    cursor = displayio.TileGrid(image, pixel_shader=palette)
    screen.append(cursor)

    cursor.x = 0  # hide cursor during bootup
    cursor.y = 0

display.show(screen)

boot_file_names = [
    "/img/bootpip0.bmp",
    "/img/bootpip1.bmp",
    "/img/bootpip2.bmp",
    "/img/bootpip3.bmp",
    "/img/bootpip4.bmp",
    "/img/bootpip5.bmp",
    "/img/statpip0.bmp",
]

screenmap = {
    (0): (
        "/img/statpip0.bmp",
        "/img/statpip1.bmp",
        "/img/statpip2.bmp",
        "/img/statpip3.bmp",
        "/img/statpip4.bmp",
        "/img/statpip2.bmp",
        "/img/statpip6.bmp",
        "/img/statpip7.bmp",
        "/img/statpip8.bmp",
    ),
    (1): ("/img/invpip0.bmp", "/img/invpip1.bmp"),
    (2): ("/img/datapip0.bmp", "/img/datapip1.bmp", "/img/datapip2.bmp"),
    (3): ("/img/mappip0.bmp", "/img/mappip1.bmp", "/img/mappip2.bmp"),
    (4): ("/img/radiopip0.bmp", "/img/radiopip1.bmp"),
    (5): ("/img/holopip0.bmp", "/img/holopip1.bmp"),
}

BUTTON_UP = 6  # A is UP
BUTTON_RIGHT = 7  # B is RIGHT
BUTTON_DOWN = 9  # Y is DOWN
BUTTON_LEFT = 10  # X is LEFT
BUTTON_SEL = 14  # SEL button is unused
button_mask = (
    (1 << BUTTON_UP)
    | (1 << BUTTON_RIGHT)
    | (1 << BUTTON_DOWN)
    | (1 << BUTTON_LEFT)
    | (1 << BUTTON_SEL)
)

ss.pin_mode_bulk(button_mask, ss.INPUT_PULLUP)

tab_number = 0
sub_number = 0

def image_switch(direction):  # advance or go back through image list
    # pylint: disable=global-statement
    global tab_number
    # pylint: disable=global-statement
    global sub_number
    # pylint: disable=global-statement
    global image
    # pylint: disable=global-statement
    global palette
    if direction == 0:  # right
        tab_number = (tab_number + 1) % len(screenmap)
    if direction == 1:  # left
        tab_number = (tab_number - 1) % len(screenmap)
    if direction == 2:  # down
        sub_number = (sub_number + 1) % len((screenmap[tab_number]))
    if direction == 3:  # up
        sub_number = (sub_number - 1) % len((screenmap[tab_number]))

    image = displayio.OnDiskBitmap(screenmap[tab_number][sub_number])
    palette = image.pixel_shader
    screen[0] = displayio.TileGrid(image, pixel_shader=palette)


last_joy_x = 0
last_joy_y = 0

#  bootup images
for i in range(len(boot_file_names)):
    image = displayio.OnDiskBitmap(boot_file_names[i])
    palette = image.pixel_shader
    screen[0] = displayio.TileGrid(image, pixel_shader=palette)
    time.sleep(0.1)

while True:
    time.sleep(0.01)
    joy_x = ss.analog_read(2)
    joy_y = ss.analog_read(3)
    if (abs(joy_x - last_joy_x) > 3) or (abs(joy_y - last_joy_y) > 3):
        if cursor_on:
            cursor.x = int(map_range(joy_x, 10, 1023, 0, 264))
            cursor.y = int(map_range(joy_y, 10, 1023, 224, 0))
        last_joy_x = joy_x
        last_joy_y = joy_y

    buttons = ss.digital_read_bulk(button_mask)

    if not buttons & (1 << BUTTON_UP):
        image_switch(3)
        time.sleep(0.15)

    if not buttons & (1 << BUTTON_RIGHT):
        sub_number = 0  # go back to top level screen of tab grouping
        image_switch(0)
        time.sleep(0.15)

    if not buttons & (1 << BUTTON_DOWN):
        image_switch(2)
        time.sleep(0.15)

    if not buttons & (1 << BUTTON_LEFT):
        sub_number = 0
        image_switch(1)
        time.sleep(0.15)

    if not buttons & (1 << BUTTON_SEL):
        print("unused select button")

来源：

1. Pico PWM MP3
2. MacroPad MP3

Github上的资源：MP3_Playback_RP2040

完整的项目文件：Project Bundle

硬件部分：使用了PAM8302放大器

• PAM8302 A+ to Pico GP0
• PAM8302 A- to Pico GND
• PAM8302 VIN to Pico 3.3v
• PAM8302 GND to Pico GND
• PAM8302 screw terminal + to speaker +
• PAM8302 screw terminal - to speaker -

CircuitPython兼容的MP3文件：

"""
CircuitPython single MP3 playback example for Raspberry Pi Pico.
Plays a single MP3 once.
"""
import board
import audiomp3
import audiopwmio

audio = audiopwmio.PWMAudioOut(board.GP0)

decoder = audiomp3.MP3Decoder(open("slow.mp3", "rb"))

audio.play(decoder)
while audio.playing:
    pass

print("Done playing!")

Raspberry Pi Pico featuring MEGA game compilation

Github上的资源

Tinyjoypad.com

为树莓派Pico和其它支持任天堂Switch, XInput和DirectInput的RP2040微控制器设计的手柄固件

GP2040官网地址

Github资源链接地址

GP2040 Firmware

GP2040 is a gamepad firmware for the Raspberry Pi Pico and other boards based on the RP2040 microcontroller, and provides high performance with a rich feature set across multiple platforms. GP2040 is compatible with PC, MiSTer, Android, Raspberry Pi, Nintendo Switch, PS3 and PS4 (legacy controller support).

Full documentation can be found at https://gp2040.info.（这个链接会出现404错误，不过可以访问页面上的其它菜单）

Features

• Selectable input modes (XInput, DirectInput and Nintendo Switch)
• Overclocked polling rate to 1000 Hz (1 ms) in all modes, with less than 1 ms of input latency
• Multiple SOCD cleaning modes - Neutral, Up Priority (a.k.a. Hitbox), Second Input Priority
• Left and Right stick emulation via D-pad inputs
• Per-button RGB LED support
• PWM and RGB player indicator LED support (XInput only)
• Saves options to internal memory
• Support for 128x64 monochrome I2C displays using SSD1306, SH1106 or SH1107 display drivers.
• Built-in configuration app hosted via embedded webserver...no downloading a separate app!

Take a look at the GP2040 Usage page for more details.

Performance

Input latency is tested using the methodology outlined at WydD's inputlag.science website, using the default 1000 Hz (1 ms) polling rate in the firmware.

Full results can be found in the GP2040 Firmware Latency Test Results Google Sheet.

Installation

Prebuilt uf2 files are available in the Releases section for the following boards and controllers:

• Raspberry Pi Pico and other pin-compatible boards such as the Pimoroni Pico Lipo (wiring diagram)
• Pico Fighting Board
• Crush Counter (formerly the OSFRD)
• DURAL

Several other working example configurations are located in the configs folder.

The instructions will slightly vary based on your device. These instructions are for a Raspberry Pi Pico.

If the device has been previously used for something other than GP2040, please flash this file first to clear the on-board storage: flash_nuke.uf2. After flashing the nuke file, waiting a minute for the clear program to run and the RPI-RP2 drive to reappear.

1. Download the latest GP2040.uf2 file from the Releases section for your board (e.g. GP2040-PiPico.uf2 for the Raspberry Pi Pico).
2. Unplug your Pico.
3. Hold the BOOTSEL button on the Pico and plug into your computer. A new removable drive named RPI-RP2should appear in your file explorer.
4. Drag and drop the GP2040.uf2 file into the removable drive. This will flash the board.
5. The board is now running the GP2040 firmware and will appear as a controller on your computer.

Support

If you would like to discuss features, issues or anything else related to GP2040 please create an issue or join the OpenStick GP2040 Discord channel.

Frequently Asked Questions Which input mode should I use?

Generally speaking, XInput will be the mode of choice for everything except Nintendo Switch and PlayStation 3. XInput mode is the most fully-featured, has the best compatibility with PC games and is compatible with console adapters like the Brook Wingman product line. All things being equal, performance is the same in all modes.

What is the extent of PS4 support in GP2040?

GP2040 will work on PS4 games that implement support for legacy PS3 controllers. Many of the popular PS4 fighting games have this support.

Does/can/will GP2040 natively support the PS4, PS5, Xbox One or Xbox Series consoles?

These consoles implement security to prevent unauthorized accessories from being used. The process of cracking or bypassing that security may not be legal everywhere. These consoles could be supported in the future if a user-friendly and completely legal implementation method is found.

Can I use multiple controllers with GP2040 on the same system?

Yes! Each board with GP2040 is treated as a separate controller. The one thing to keep in mind would be to only run the web configurator for one controller at a time.

Does GP2040 really have less than 1 ms of latency?

Yes...if your platform supports 1000 Hz USB polling. GP2040 is configured for 1000 Hz / 1 ms polling by default in all modes, however some systems override or ignore the polling rate the controller requests. PC and MiSTer are confirmed to work with 1000 Hz polling. Even if your system doesn't support a USB polling rate that high, you can feel comfortable knowing GP2040 is still reading and processing your inputs as fast as the target system will allow.

Do the additional features like RGB LEDs, Player LEDs and OLED displays affect performance?

No! The RP2040 chip contains two processing cores. GP2040 dedicates one core to reading inputs and sending them via USB, while the second core is used to handle any auxiliary modules like LEDs and display support. No matter how crazy the feature set of GP2040 becomes, it's unlikely your controller's input latency will be affected.

Why do the buttons have weird labels like B3, A1, S2, etc.?

GP2040 uses a generic system for handling button inputs that most closely maps to a traditional PlayStation controller layout with a few extra buttons. This means 4 face buttons (B1-B4), 4 shoulder buttons (L1, L2, R1, R2), Select and Start (S1, S2), 2 stick buttons (L3, R3) and 2 auxiliary buttons for things like Home and Capture (A1, A2) on the Switch. The GP2040 documentation and web configurator have a dropdown to change the labels to more familiar controller layouts. You can also refer to the button mapping table on the GP2040 Usage page.

Why use PlatformIO instead of <insert favorite project setup>?

Setting up a development environment to build Pico SDK projects is a manual process which requires several components to be installed and configured. Using PlatformIO allows easy installation and updating of build and project dependencies, and makes for a less confusing experience for new developers and people that just want to make a few tweaks for a custom build.

What kind of voodoo is that built-in web configurator?

There's no magic here, just some useful libraries working together:

• Single page application using React and Bootstrap is embedded in the GP2040 firmware
• TinyUSB library provides virtual network connection over USB via RNDIS
• lwIP library provides an HTTP server for the embedded React app and the web configuration API
• ArduinoJson library is used for serialization and deserialization of web API requests

Acknowledgements

• Ha Thach's excellent TinyUSB library examples
• fluffymadness's tinyusb-xinput sample
• Kevin Boone's blog post on using RP2040 flash memory as emulated EEPROM
• bitbank2 for the OneBitDisplay and BitBang_I2C libraries, which were ported for use with the Pico SDK

文章链接：在Pico和RP2040上实现机器学习

这是美国康奈尔大学的学生项目，探索RP2040的功能和性能，值得我们学习和借鉴。

Cornell University ECE4760
RP2040 testing

Introduction

The RP2040 is a dual-core Cortex M0 produced by Raspberry Pi. It is attractive for this course because it is programmed bare-metal, supports C, inline ssembler, and MicroPython, and has an interesting set of hardware co-processors. In addition to the two M0 cores, and the usual peripheral hardware devices (ADC, UART, I2C, SPI, USB, PWM, timer), there are several heavy-weight hardware state-machine co-processors. These include:

• an extensive DMA system, 12 channels, 32-bits/clock cycle (register programmed)
• very high-speed, 8-way parallel, programmable, i/o processor (custom assembly language programmed)
• a set of 4-way parallel, interpolator pipelines with adders, shifters, and a variety of feedback (register programmed)
• two integer dividers (one per core, transport triggered)
• intercore hardware 32 bit x 8 word FIFOs and 32 simple spinlocks

For more information:

• RP2040 chip datasheet
• RP2040 PICO board datasheet
• PICO C SDK and Setting up for C (Hunter 2/14/2021)
• Micropython SDK
• PICO code examples

The following is organized by date for now.
Later there will be topics.

Testing in C (Hunter Adams)

Setting up for C (Hunter 2/14/2021)

Chained-DMA signal generator thru SPI DAC on RP2040 (Hunter 3/9/2021

Dual-core Direct Digital Synthesis (DDS) on RP2040 (Raspberry Pi Pico)(3/20/2021)

Testing in MicroPython (Bruce Land)

Setup for MicroPython (1/28/21)
Getting the system running requires the micropython image UF2 file to be downloaded to the board. Follow the simple directions on the linked page. Once you have installed micropython (MP) you can connect to the board with a terminal program, but Thonny is a simple IDE which includes an editor, downloader, file handler, and console.
After installing Thonny, setup the connection to the board with:

1. in Tools > Options > Interpreter Tab
   Choose: micropython(raspberry Pi PICO)
   Choose: USB serial device (with appropriate device name)
2. in Run menu choose: Stop/restart
   at this point you should see a python >>> prompt near the bottom of the window.
3. In the edit pane paste in:

       
     from machine import Pin, Timer
     led=Pin(25,Pin.OUT)
     tim=Timer()
     def tick(timer):
        led.toggle()
     tim.init(freq=2.5,mode=Timer.PERIODIC,callback=tick)

4. In Run menu choose: Run current script
   The LED should blink if everything is correctly connected.
5. <cntl>c normally stops a program, but the test program starts a interrupt-service-routine.
   <cntl>d will force a soft reset and kill the ISR.
   The command tim.deinit() also stops the timer-triggered routine
6. The ISR runs at 10KHz, but fails at 100KHz and HANGS the system!
   You have to unplug/plug the PICO to restart! My guess is that the ISR takes more than 10 microseconds and never actually exits if the ISR rate is too high. To test this hypothesis paste in:

       
       from machine import Pin, Timer
       led=Pin(15,Pin.OUT)
       x=0
       while (x<300000):
          led.toggle()
          x += 1

   This produces 24.6 KHz square wave with around 5% jitter=> loop at ~50 KHz or around 20 microsec/per loop.
7. Thonny can save a script directly to the MCU flash drive and can erase a file. If you save test.py, then at the command line type: import test it will run form the local file system.
8. Choosing Tools>Open system shell opens a console directly to the >>> prompt.
   To reconnect Thonny, you will have to close the console and restart the connection to the PICO.

The need for speed (2/2/21)
To get faster i/o you need to use hardware and not python loops. A very interesting feature of this chip is an 8-way parallel, hardware, state machine dedicated to fast i/o processing. Each of the 8 processors can run simple, deterministic, assembler programs (NOT ARM assembler, although that is also available). I stripped down the simplest example program to see how fast it would toggle a pin. The original example blinks the LED at a human rate. The folowing toggles a pin at 25 MHz! The clock frequency of the state machine can be set as high as 125 MHz (the system clock frequency). In the blink routine, the wrap statements act as a zero time, unconditional jump. The set commands set/clear a pin, while the [1] represents a delay parameter. The result is one state machine cycle for each set, followed by a one cycle delay after each set, for a loop-time of 4 cycles. At 100 MHz, that is a 25 MHz squarewave. The main program just turns on the statemachine for 3 seconds. If you delete the two [1] delays, the frequency will be 50 MHz.

  import time
  from rp2 import PIO, asm_pio
  from machine import Pin
  #
  @asm_pio(set_init=rp2.PIO.OUT_LOW)
  def blink():
     wrap_target()
     set(pins, 1)   [1] 
     set(pins, 0)   [1] 
     wrap()
# Instantiate a state machine with the blink program, at 100MHz, with set bound to Pin(15) 
  sm = rp2.StateMachine(0, blink, freq=100000000, set_base=Pin(15))
# Run the state machine for 3 seconds and scope pin 15.
  sm.active(1)
  time.sleep(3)
  sm.active(0)
  

High speed interface: DVI from RP2040

The ARM assembler (2/2/21)
Micropython supports the ARM-Thumb assembler instructions. CPU registers R0-R7 can be used by the assembler, with function inputs in R0-R2 and function results being returned in R0. Also, when you name an array as an input parameter to an assembler funciton, python actually passes in the address to the array. To test this, I coded up a single instruction assembler function which returns the absolute memory address of an array. Python does not really want you to know about addresses, but DMA controllers need pointers to arrays to move data. The following routine just takes the input in R0, copies to itself, and exits, returning the address of the input array name. (formatted code)

# test assembler and
# implement 'addressof'
a=array.array('i',[ 1, 2, 3])
# invoke assembler
@micropython.asm_thumb
# passing an array name to the assembler
# actually passes in the address
def addressof(r0):
    # r0 is the output register, so address beomes output
    mov(r0, r0)
# now use the assembler routine  
addr_a = addressof(a)
print(addr_a)
print(machine.mem32[addressof(a)+8]) # returns '3'

The complete two-assemblers (PIO and ARM_thumb) test code: code.
Note that some browsers do not like to see python code! You will need to rename the *.txt file.
Right-click the link and choose save link as...
(An image of the code.)

Code generation options in micropython (2/11/21)
Micropython (MP) generates a bytecode executable by default. Bytecode is compact, but slow compared to inline code. There are a least three other code generators. (see maximizing speed). The native code generator takes unmodified MP and generates a mix of inline and MP calls. The viper code generator requires some modifications/simplifications of MP source, including variable typing in some cases. It can generate inline assembler in some cases, but cannlot optimize across function calls. The assembler code generator allows you to enter ARM-M0 Thumb assembly code, linked by a simple memory map to the rest of the MP code.
I wrote a program to start testing these options, as well as other timing in MP.
( As usual, Windoze does not like to download Python, so you will need to rename it. )

• Function calls seem slow, so I wrote a null function which simply returns, and timed it. It turns out that function calls get faster over several invocations. The code imports the time utilities and the array functionality, the invokes the null function three times. The times vary, but the first, second, and third invocations typically have times of 35, 12, and 10 uSec. The array type packs elements in the same way that C does and is used to communicate with assembler.
• Any real program is going to put functions into a loop, so I tested the call time in the simplest possible functions, which call the null functions a few housand times. The same function was coded as default, native, and viper to compare how the call times change. The following times in uSec show that there is aa slight improvment when not using the default bytecode. This is because the bulk of the time is spent actually calling the function. But 5-6 microseconds is not too bad, about 780 cycles.
  multiple fun_loop_time= 6.5367
  multiple fun_native_time= 5.0878
  multiple fun_viper_time= 5.0746
• This made me wonder how simple calculations would scale using the different code generators. I wrote four different versions of a simple increment loop and used default bytecode, native, viper, and assembler directives to compile them. The times below show a dramatic speed-up for viper-compiled code, but of course, hand coded assembler is faster. By cycle-counting the assembler code you can show that it is raw machine code.
  bytecode_loop_time= 7.29907 usec
  native_loop_time= 2.66444
  viper_loop_time= 0.248029
  asm_loop_time= 0.040052
• As a prototype for IIR filters, I wrote a looping multiply-store assembler function to see how fast it would execute. Again, cycle-counting shows that it is compiled to pure machine code. The load, multiply, store, increment, and branch took 8 machine cycles and measured ~64 nSec. If you do:
  >>> import machine
  >>> machine.freq()
  the frequency reported is 125 MHz, so 8 cycles should take 64 microseconds.

Micropython co-routines (cooperative scheduling) and threading (multicore) (2/12/2021)

-- Cooperative scheduling
Cooperative scheduling on the rp2040 is similar to Protothreads on the PIC32. Asyncio is a stackless, non-premptive, light-weight task handler. Some descriptive material:
Cooperative scheduling Tutorial (uasyncio module) and demo code
Documentation for version 3
Async version 3 overview

--True threading is currently very limited. From the command line (import _thread, then help(_thread)) you can see that the functionality is a subset of Cpython thread. According to the pico python SDK manual, section 3.5, You can start just one thread on the second core. However the cpu manual indicates that there is hardware support for core-to-core communication in the form of two unidirectional FIFOs, and up to 32 hardware spin locks.

The first example starts two cooperative tasks on core0 using the asyncio library and one separate thread on core1. Programs on each core can determine which core they are running on by reading a memory address. The first part of the code defines the SIO base address, which happens to be the cpu id, and defines the core1 functions. Core1 just toggles an LED and prints out the core id. The second part defines the two asyncio, cooperative tasks running on core0. One task handles i/o to UART0, and the other blinks the onboard LED. The third part starts the two syncio tasks on core0 and the thread on core1, and allows for stopping the program with cntl-c on the REPL console. On both cores, the print command prints on the REPL (USB connection), and the streamwriter on core1 prints to UART0.

The second example tests the inter-core FIFO communication and inter-core spinlock hardware. Each core can write to one FIFO and read from the other FIFO. Each core has a FIFO read address, FIFO write address, and FIFO status, with bits to indicate that space is available to write, and that data is available to read. We need at least five functions, FIFO_read, FIFO_write (both bolcking), FIFO_read_status, FIFO_write_status, and FIFO_purge. FIFO_purge insures that there are no items in the FIFO left over from another program. The spinlocks require two functions, spin_acquire and spin_release. The spin_acquire function takes a lock number, 0 to 31, and can be either blocking or nonblocking. The code uses spin locks to protect a varialbe incremented by both cores. The FIFOs send the variable back and forth between the two cores. The overall effect is to increment the variable by two every time it is printed to the REPL console in CORE1 (CORE1 code). One of two tasks on CORE0 bounces the variable back to CORE1. To avoid deadlock after another program runs, the task initially clears the spinlock and checks to see if there is data in the FIFO.

The third example (3/15/2021) looks at communication between cores using shared memory. There are at least three ways to share memory. You can define an array in a task on one core, then pass the pointer (ctypes module; addressof()) via FIFO. You can define an array outside of a task, then jus use its name and index on both cores. You can declare a variable global, then use it on both cores.

The SIO Hardware divider (2/28/2021)
The SIO contains a 8-cycle hardware divider for each core. I wrote test code for it in micropython, then coded it again as a assembler program to test speed. If you stick to python, it is faster to just use the integer divide operator, //, than to invoke the hardware divider directly. The code shows how to directly touch hardware registers. Every time you load a divisor or dividend into the hardware divide inputs, a calculation is started. You can check a done-bit, or just wait 8 cycles. One test result is below. Dividing 37/6 give 5, with remainder 1. The assembler loop time is 168 nSec, of which 72 nSec is the actual divide.
HW div 7 36 5 1
asm_divloop_time = 0.16851 count= 100000
asm div 7 36 5 1

DMA direct memory access (3/5/2021)
Python does not really want you to know about addresses, but DMA controllers need pointers to arrays to move data. The array data type packs data sequentially, like C, and is adressable. A one line assembler program(see above) extracts the address of the zeroth element of an array, and the other elements can be accessed from this base pointer by addition.The DMA system has LOTs of options, including ability to loop on a section of memory, send one address repeatedly (perhaps from a peripherial), chain channels, start a transfer triggered by one of about 60 events, and transmit 8, 16 or 32-bit wide data. The data rate is very high, approaching one transfer per clock cycle.
-- The first example just copies one array to another. The code just sets up the options for channel control. First the addresses of the control registers, then the configuration bits. Then, Two arrays are defined, their addresses determined, and channel zero configured for no-interrupt, permanent trigger, read and write increment, and a data width of 32-bits.

DMA_src_addr = addressof(DMA_src)
machine.mem32[DMA_RD_ADDR0] = DMA_src_addr
DMA_dst_addr = addressof(DMA_dst)
machine.mem32[DMA_WR_ADDR0] = DMA_dst_addr
machine.mem32[DMA_TR_CNT0] = len(DMA_src)
# this writ starts the transfer
perm_trig = 0x3f # alwas go
data_32 = 0x02 # 32 bit
# set up control and start the DMA
machine.mem32[DMA_CTRL0] = (DMA_IRQ_QUIET | DMA_TREQ(perm_trig) |
                    DMA_WR_INC | DMA_RD_INC |
                    DMA_DATA_WIDTH(data_32) |
                    DMA_EN )

DMA-to-PWM sinewave synthesis (3/10/2021)
Using more features of the DMA channels allows us to trigger a DMA transfer form a peripherial, in this case, the overflow of the counter on a PWM channel. All of the channel trigger sources (except for permanent trigger and timers) are in the table below. Note that the numbers are decimal, not hex. The timer triggers (in hex) are:
0x3b → Select Timer 0 as TREQ
0x3c →Select Timer 1 as TREQ
0x3f → Permanent request, for unpaced transfers

For this example, we will use TREQ source 25 (DREQ_PWM_WRAP1) to trigger DMA channel zero.The source address for channel zero will be the adddress of the sine buffer memory. The destination address will be fixed at the PWM slice one compare register. The transfer count will be the length of the sine buffer. DMA channel zero will chain to DMA channel 1 after the entire sine buffer is sent. DMA channel 1 will have a source address equal to the address, of the address, of the sine buffer. It will have a destination address of the DMA channel zero source address register, and a tranfer count of one word. DMA channel 1 will reload the source address of channel zero, then chain back to channel zero. The effect is that the sine waveform buffer will be sent continuously to the PWM. Running the PWM at full cpu frequency, with a top-count of 256 (8-bit resolution), works out to a PWM frequency of 500 KHz. With a sine buffer of length 256, we can generate a very low distortion (better than -40db) sine at 1900 Hz. Making the table shorter, to length 32, means that we can generate sine waves of about 15 KHz, with distortion still below -30 db.
The code is rather lengthy because of all the low-level setup. There is currently no direct python support of DMA so all configuration is at the big-bang level. I did not like the python PWM abstraction, so I wrote my own to more easily set the PWM period. After setting up all of the bit-twiddling, I turned on DMA channel 1, then DMA channel zero, and finally the PWM to start everything (with the first overflow trigger).

DMA-to-PWM sinewave with settable frequency (3/16/2021)
For this example, we will use TREQ source DREQ_TIMER0 = 0x3b to trigger DMA channel zero. The timer refered to is DMA timer 0, which has settable frequency as X/Y<1 where X is the top 16 bits of a register, and Y is the bottom 16 bits. It is easy to show that the settability of the frequency is very good at audio frequencies, with a useful range of 7 Hz to 15 KHz. The rest of the DMA setup is the same as the last example. The algorithm for going from a desired output frequency, F_out, to the values of X and Y is slightly involved. For a sine table of length L, and cpu clock frequency of F_clk:
F_out = (F_clk/L)*(X/Y)
The two settable variables are X and Y, but they are not independent, and must be integers. The solution I used is to set Y to maximum value (0xFFFF), then solve for the integer X₀, which will systemmatically cause F_out to be a little low. The next step is to lower Y slightly to set the closest possible frequency. To do that we are going to Taylor expand:
1/(0xFFFF - ΔY) as (2^-16)/(1 -(2^-16* ΔY)) yielding (2^-16)*(1 +(2^-16 * ΔY))
As long as ΔY<2¹¹ the approximation is good to 0.1%.
Now the output frequency can be written as
F_out = (F_clk/L)*X* (2^-16)*(1 +(2^-16 * ΔY))
The steps are: solve for X to give lower bound frequency, then compute a small correction.
X₀ = F_out/F_clk * L * 2¹⁶
ΔY =( F_out - F_out(int(X₀)))/F_clk * L * 2³²/int(X₀)

So the python code looks like:
#get exact X
X0 = (Fout/Fclk) * Ltable * 2**16
# compute actual freq using integer part of X
Fx = Fclk*int(X0)/(Ltable * 2**16)
# Taylor expanson for delta Y
dY = (Fout-Fx) * Ltable * 2**32 /(Fclk * int(X0))
machine.mem32[DMA_TIMER0] = (0xffff-int(dY)) | (int(X0)<<16)

A slight rearrangement of the PWM setup allows both the A and B outputs from PWM slice 1 to produce separate signals, in this case, sine waves in quadrature.

DMA-to-PWM sinewave looped to ADC-to-DMA-to-PWM (4/20/20)
The settable frequency sine wave described in the previous example was used as a source to drive an ADC input. The ADC was set up as the trigger for a DMA channel which transfered the measurement to a PWM channel. In the process of doing this, it was necessary to re-factor the hardware register definitions for better use of the hardware. The code has explicit functions for write, set, clear, and XOR of any IO register. GPIO registers, DMA registers, and PWM registers are named so that any channel/slice can be set up. An external circuit was built to lowpass filter two PWM channels and to connect the sinewave PWM filtered output to ADC channel 0 (GPIO 26). A comment in the code describes the circuit. Another comment summarizes the cpu-asynchronous hardware used. The only function of the main python program, after setting up all the async hardware, is to ask the user what frequency the sinewave should be. The image below shows the sine wave output in blue and the ADC-to-DMA-to-PWM loop back in yellow.

DMA inline arithmetic functions (3/27/2021)
-- The data sniff function can monitor a channel and perform operations on the data flowing by. The intention is to allow fast calcuation of check-sums, but the sniffer can also do 2's complement addition on the data flow. The sniff data register can be zeroed between DMA bursts, or can be preloaded with a value to be added. The sniff control register can be set to perform CCITT CRC in four forms, summation, and XOR reduction. The register can be read normal or bit-inverted. In addition, like all i/o block registers, the sniff data registers supports transport-triggered operations which can clear, set, or XOR bits when written. Using this allows AND, OR and XOR functions on single data words. The example code uses a DMA transfer to add three numbers, after first initilizing the sniff data register using transport-triggered logic operations. As usual there is a ton of setup, to get all the control bits in the right place, but then the actual implementation is short.
-- Refactoring the DMA setup code makes the code easier to read and allows use of DMA channels 0 to 11.

Interrupts in Micropython (4/29/2021)
Python only knows about i/o pin IRQs (nad maybe timers). We could set up an i/o pin as an output, then use a DMA channel triggered from any TREQ source (see table above) to set/clear the pin and trigger the pin ISR. The first test code uses direct control of the GPIO registers to trigger an ISR. This is a first step in using register loads from a DMA channel. The first part of the program just sets up the i/o register definitions. The second part sets up the python interrupt, then uses low-level register writes to trigger it. In real code, the DMA channel would do the register write to trigger the IRQ.

SIO Interpolator module (2/29/2021)
The SIO has two interpolation units for each CPU. The interpolators are register-programmed, single-cycle, arithmetic devices with a number of bewildering modes. One of the easiest to understand is the BLEND mode which computes

where Interpolator0 registers store the three input values, and one cycle later the output is ready. Note that alpha is actuall specified as an integer 0<=alpha<=255, understanding that the hardware treats it as divided by 256. The test code has a bulky register naming section, but a short implementation. The BLEND mode would not usually be used directly from python, but could used from assembler, or an ISR.

Interrupts and DMA transfers (4/27/2021)
There is one block of addresses for the SIO (0xd000_0000) which have a bus address only for the CPUs, but which do not appear on the system bus. It is therefore impossible for the DMA system to reach the SIO. While trying to understand this, I caused a lot of DMA bus errors. A DMA channel with set error bits is locked from execution, and Python soft-reset does not clear the bits. The bits have to be cleared by writing ones to the positions in the channel control register.

My goal for using the SIO interpolator module is to low-pass filter the ADC readings, then output them to a PWM channel. So how to get to the SIO? One possibiity is to trigger an ISR on the cpu. A DMA channel triggering on the ADC trigger request could cause an interrupt, but Python only knows about i/o pin IRQs. We could set up an i/o pin as an output, then use a DMA channel triggered from the ADC to set/clear the pin and trigger the pin ISR. A test code showing that this works.

MicroPython Notes (mostly for myself) (started 1/28/21)

1. PICO micropython examples
2. Micropython libraries/applications/projects --
   1. awesome micropython
   2. Paul Sokolovsky
   3. libraries -- may be a copy of 1
   4. projects -- hackster
   5. projects -- hackaday
3. Typng help('modules') gives a list of available modules
   (but excluding any modules you may have put into flash memory)
4. Once you have the module names, typing help(module) gives contents of the module
   BUT you need to import it first!
   example:
   >>> help(machine)
   object <module 'umachine'> is of type module
   __name__ -- umachine
   reset -- <function>
   reset_cause -- <function>
   bootloader -- <function>
   freq -- <function>
   mem8 -- <8-bit memory>
   mem16 -- <16-bit memory>
   mem32 -- <32-bit memory>
   ADC -- <class 'ADC'>
   I2C -- <class 'I2C'>
   SoftI2C -- <class 'SoftI2C'>
   Pin -- <class 'Pin'>
   PWM -- <class 'PWM'>
   SPI -- <class 'SPI'>
   SoftSPI -- <class 'SoftSPI'>
   Timer -- <class 'Timer'>
   UART -- <class 'UART'>
   WDT -- <class 'WDT'>
   PWRON_RESET -- 1
   WDT_RESET -- 3
5. Wait! What is mem8, mem16, mem32?
   Mostly useful for read/write control registers
   read: machine.mem32[address]
   write: machine.mem32[address] = integer
6. The contents of the RP2 module (PIO assembler functions)
   is not well explained yet. Your best bet is to go to the examples,
   because in the end, only the source matters.
7. The experimental 2 core _thread
   >>> import _thread
   >>> help(_thread)
   object <module '_thread'> is of type module
   __name__ -- _thread
   LockType -- <class 'lock'>
   get_ident -- <function>
   stack_size -- <function>
   start_new_thread -- <function>
   exit -- <function>
   allocate_lock -- <function>
   The Locktype has the methods:
   >>> help(_thread.LockType)
   object <class 'lock'> is of type type
   acquire -- <function>
   release -- <function>
   locked -- <function>

来源：Raspberry Pico: Simple Debugging with just one Device

更多关于制作调试器的文章：设计MCU/FPGA下载器的一些资源链接

The Raspberry Pico is a new microcontroller launched in February 2021. The community was excited about this new board, and several people started amazing projects. I grabbed two boards early on, and while still working on my Arduino based robot, did the usual blinking led and potentiometer tutorials. For simplicity, I used the MicroPython SDK. It is setup in minutes, simple sketches are easy, and you can live-connect to the Pico and execute your program.

If you want to use the C SDK, you have a lot to do: Install build tools, CMake, download the SDK, define an SDK path, then add CMake files for your projects, adding all the required libraries etc. And the comfort level at which you arrive is ok — you still need to compile and manually upload the UF2 file to the Pico.

Can it be better and simpler? Yes! Thanks to the great wizio-pico project, VS Code integration can be achieved, including direct upload to your Pico. And when you consider the pico-debug project, you can also integrate full debugging capabilities for your programs.

This blog pot continues the Pico setup series and will detail how to setup a fully working debugger in VS Studio Code. Keep in mind that ultimately the steps are based on explanations from pico-debug project, and wizio-pico, but the setup is complex so I wrote a summarizing blog article. Follow along and you will be debugging your Pico C programs with the press of a simple launch button.

This article originally appeared at my blog.

Tool Overview

Before we arrive at the fully integrated debugging solution, it’s important to understand the tools that will do the heavy lifting for us.

The JTAG standard describes how to debug integrated circuits. The standard defines the communication protocol how the registers and bus systems on the circuits can be accessed. And it also describes the electrical interface, e.g. a serial port, to access the circuit. Instead of using a dedicated port, the SWD (Serial Wire Debug) protocol can use just two pins to interface with an ARM chip for debugging purposes. This standard is used by the tool OpenOCD, which is an acronym for On-Chip-Debugger. It uses the JTAG standard to establish a debugging session to an integrated circuit. Finally, the GNU Project Debugger GDB is an Open-Source workhorse for debugging applications, supporting C, C++ and others. GDB can connect to an OpenOCD session to start debugging. GDB itself is ultimately a CLI application, offering a dedicated language to load a program, set breakpoints and variables. Modern IDEs will interface with GDB and provide a powerful, visual debugging experience.

To use these tools, we need to setup a compiler that produces ARM code, GDB and OpenOCD. Let’s start!

Compiler & GDB

We need to install a cross-compiler that can produce ARM code: The gcc-arm-none-eabi. Execute the following command to install this compiler and other required tools.

$> sudo apt update
$> sudo apt install cmake gcc-arm-none-eabi libnewlib-arm-none-eabi build-essential

Test that these tools are installed correctly:

$> arm-none-eabi-gcc -vUsing built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/9.2.1/lto-wrapper
Target: arm-none-eabi

To install GDB:

apt install gdb-multiarch

And also, shortly test that it is correctly installed:

$> db-multiarch -vGNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

OpenOCD

Following the pico-debug project explanations, we will install a special version of OCD that support the Raspberry Pico.

First we install regular Linux packages …

$> sudo apt install automake autoconf texinfo libtool libhidapi-dev libusb-1.0-0-dev

…and then we will clone a Git repository to compile and make the custom OCD version.

$> git clone https://github.com/majbthrd/openocd.git --recursive --branch rp2040_cmsisdap_demo --depth=1
$ cd openocd
$ ./bootstrap
$ ./configure --enable-cmsis-dap
$ make -j4
$ sudo make install

Again, we test that the installation is successful:

$> openocd -hOpen On-Chip Debugger 0.10.0+dev-gb4af1af-dirty (2021-03-21-10:40)
Licensed under GNU GPL v2

Preparing the Pico

With the toolchain installed and tested, we can continue to prepare the Pico itself. Again, two tasks need to be done:

1. The Pico needs to be booted with a special UF2 image so that it can be used as a debugging device
2. The target program needs to be compiled with a special debug compiler flag

Install the Debugging UF2 Image

First, grab the latest UF2 image from https://github.com/majbthrd/pico-debug/releases, then drag’n drop the file onto your mass storage mode mounted Pico. It will boot your raspberry Pico as a CMSIS-DAP device. This acronym stands for Cortex Microcontroller Software Interface Standard — Debug Access Port, which is both a protocol specification and a concrete firmware. Technically, it wraps the Picos’ Serial-Wire-Debug Interface and emulates a Debug Access Port (DAP) via USB. This standardized interface can be used by a connected host computer running a debugger.

Lets see if the image is processed correctly. When executing dmesg, you should see the following output:

[50852.541543] usb 1-2: new full-speed USB device number 70 using xhci_hcd
[50852.690691] usb 1-2: New USB device found, idVendor=1209, idProduct=2488, bcdDevice=10.02
[50852.690696] usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[50852.690698] usb 1-2: Product: CMSIS-DAP

The Pico is ready. Now, we compile the program to be available for debugging.

Compile the target program

When i began to write the article, I hoped that you just needed to make a small switch in the plattform.ini file, compile and have a debug able version of your program. However, this is not the case yet. If you want to use just one Pico for debugging, you need to use a special SDK for compiling your program. This SDK fixes some issues with USB system initialization that otherwise interferes with debugging. You can read the details at the github thread.

Until a better solution is available, we need to add special CMake compilation files.

Lets picture the final directory layout that we will obtain:

.
├── debug
│   ├── build
│   ├── CMakeLists.txt
│   ├── pico-debug.uf2
│   ├── pico_sdk_import.cmake
│   └── src -> /home/work/development/pico2/src/
├── include
│   ├── pico
│   │   └── config_autogen.h
│   └── README
├── lib
│   └── README
├── LICENSE.txt
├── platformio.ini
├── README.md
├── src
│   ├── CMakeLists.txt
│   └── main.c
└── test
    └── README

The concrete steps are

1. Create the directories build and debug
2. In debug, copy the special uf2 files, and add a symbolic link to the src directory
3. In debug, put this CMakeLists.txt file into it.

cmake_minimum_required(VERSION 3.12)# Pull in SDK (must be before project)
include(pico_sdk_import.cmake)project(pico_examples C CXX ASM)
set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)set(PICO_EXAMPLES_PATH ${pwd})# Initialize the SDK
pico_sdk_init()add_subdirectory(src)

1. In src/ folder, add this CMakeLists.txt file.

add_executable(main
        main.c
        )# Pull in our pico_stdlib which pulls in commonly used features
target_link_libraries(main pico_stdlib)# create map/bin/hex file etc.
pico_add_extra_outputs(main)

Now we can compile the program.

1. Set the environment variable PICO_SDK_PATH to point to the special SDK

export PICO_SDK_PATH=/home/work/development/pico-debug-sdk/

1. Go to the debug/build folder, and run the following commands:

cmake -DCMAKE_BUILD_TYPE=Debug -g0 ..

The compilation process should start and show an output like follows:

Using PICO_SDK_PATH from environment ('/home/work/development/pico-debug-sdk/')
PICO_SDK_PATH is /home/work/development/pico-debug-sdk
Defaulting PICO_PLATFORM to rp2040 since not specified.
Defaulting PICO platform compiler to pico_arm_gcc since not specified.
PICO compiler is pico_arm_gcc
PICO_GCC_TRIPLE defaulted to arm-none-eabi
-- The C compiler identification is GNU 9.2.1
-- The CXX compiler identification is GNU 9.2.1
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/arm-none-eabi-gcc
Using regular optimized debug build (set PICO_DEOPTIMIZED_DEBUG=1 to de-optimize)
Defaulting PICO target board to pico since not specified.
Using board configuration from /home/work/development/pico-debug-sdk/src/boards/include/boards/pico.h
-- Found Python3: /usr/bin/python3.8 (found version "3.8.5") found components: Interpreter
TinyUSB available at /home/work/development/pico-debug-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; adding USB support.
Compiling TinyUSB with CFG_TUSB_DEBUG=1
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.17") found components: doxygen dot
ELF2UF2 will need to be built
-- Configuring done
-- Generating done
-- Build files have been written to: /home/work/development/pico2/debug/build

1. In the build folder, you will now see src - change into this directory, and execute make

cd src/
make

You should see this output:

Scanning dependencies of target ELF2UF2Build
[  1%] Creating directories for 'ELF2UF2Build'
[  3%] No download step for 'ELF2UF2Build'
[  5%] No patch step for 'ELF2UF2Build'
[  6%] No update step for 'ELF2UF2Build'
[  8%] Performing configure step for 'ELF2UF2Build'
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
...
-- Build files have been written to: /home/work/development/pico2/debug/build/elf2uf2
[ 10%] Performing build step for 'ELF2UF2Build'
Scanning dependencies of target elf2uf2
[ 50%] Building CXX object CMakeFiles/elf2uf2.dir/main.cpp.o
[100%] Linking CXX executable elf2uf2
[100%] Built target elf2uf2
[ 11%] No install step for 'ELF2UF2Build'
[ 13%] Completed 'ELF2UF2Build'
[ 13%] Built target ELF2UF2Build
Scanning dependencies of target bs2_default
[ 15%] Building ASM object pico-sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/boot2_w25q080.S.obj
[ 16%] Linking ASM executable bs2_default.elf
...
[100%] Linking CXX executable main.elf
[100%] Built target main

Done! You now have a debugable version of you program that can run on just one connected Pico.

Debugging on the CLI

We have installed the toolchain. We have prepared the Pico. Now, we can start the debugging process. In this section, we will directly use the CLI tools. In the next section, we will integrate these tools into Visual Studio Code.

OpenOCD: Executing as Normal User

In order to run OpenOCD as a normal user, we need to create an OpenOCD launch file, and add your normal user to a special group. The reference for these steps is this stackexchange post.

Create the file /etc/udev/rules.d/98-openocd.rules and add this content:

ACTION!="add|change", GOTO="openocd_rules_end"
SUBSYSTEM!="usb|tty|hidraw", GOTO="openocd_rules_end"
ATTRS{product}=="*CMSIS-DAP*", MODE="664" GROUP="plugdev"
LABEL="openocd_rules_end"

Then, create a new Linux group, and add your personal user to that group.

$> sudo groupadd plugedev
$> sudo gpasswd -a devcon plugdev
$> sudo udevadm control --reload

Like before, we test this. See that your user is a member of the newly created group

$> groups
devcon adm dialout cdrom sudo dip plugdev lpadmin lxd sambashare

Start OpenOCD

Now we manually start the OpenOCD server. In the same directory in which you build it, execute this command:

$> cd openocd/tcl
$> openocd -f interface/cmsis-dap.cfg -f target/rp2040-core0.cfg -c "transport select swd" -c "adapter speed 4000"

If you are as curious as me about what this command means:

• The two -f flags indicate loading of configuration files, here we load the Debug Access Port (DAP) config and a config for the Pico board (RP2040)
• The two -c flags indicate additional commands that are run, we will connect via serial wire debug and set the connection speed in kHz between the host and the Pico.

You should see this output:

Open On-Chip Debugger 0.10.0+dev-gb4af1af-dirty (2021-03-21-10:40)
Licensed under GNU GPL v2
For bug reports, read
 http://openocd.org/doc/doxygen/bugs.html
swd
adapter speed: 4000 kHz

Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialized (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 4000 kHz
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections

Open a second terminal window, and navigate to the directory in which you compiled your Pico project. Then we will launch a GDB session.

$> cd debug/build/src
$> gdb-multiarch main.elf

You should see this output:

gdb-multiarch main.elf
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from src/main.elf...

With the GDB session open, we can now execute commands to perform the debugging. GDB has an elaborate language, we will focus on the main commands to drive a simple console-based debugging session.

(gdb) target remote localhost:3333
Remote debugging using localhost:3333
main () at /home/work/development/pico2/debug/src/main.c:37
37 int main() {
(gdb) load
Loading section .boot2, size 0x100 lma 0x10000000
Loading section .text, size 0x4b10 lma 0x10000100
Loading section .rodata, size 0xd84 lma 0x10004c10
Loading section .binary_info, size 0x20 lma 0x10005994
Loading section .data, size 0xa04 lma 0x100059b4
Start address 0x100001e8, load size 25528
Transfer rate: 8 KB/sec, 4254 bytes/write.
(gdb) monitor reset init
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
(gdb) b main
Breakpoint 1 at 0x100003d8: file /home/work/development/pico2/debug/src/main.c, line 37.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at /home/work/development/pico2/debug/src/main.c:37
37 int main() {
(gdb) n
38     setup();
(gdb) n
40     printf("Hello World\n");
(gdb) n
43         printf(".");
(gdb) n
44         blink();
(gdb) n
42     while (true) {
(gdb) p LED_GREEN
$1 = 15
(gdb)

If you came this far, it’s only a few steps more to setup debugging with your IDE.

Install additional VsCode extensions

C/C++ Extension Pack (by Microsoft)
Cortex-Debug (by marus25)
CMake Tools (by Microsoft)

Create the file .vscode/launch.json, and enter this content:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Pico Debug",
      "device": "RP2040",
      "gdbPath": "gdb-multiarch",
      "cwd": "${workspaceRoot}",
      "executable": "${workspaceRoot}/debug/build/src/main.elf",
      "request": "launch",
      "type": "cortex-debug",
      "servertype": "openocd",
      "configFiles": ["interface/cmsis-dap.cfg", "target/rp2040-core0.cfg"],
      "openOCDLaunchCommands": ["transport select swd", "adapter speed 4000"],
      "svdFile": "${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd",
      "searchDir": ["/home/work/development/openocd/tcl"],
      "runToMain": true,
      "postRestartCommands": ["break main", "continue"]
    }
  ]
}

The important things to change are:

• executable: Needs to point to the debug-ready compiled file
• svdFile: SVD is a file format containing the specifics of a microcontroller, this file is used by openocd to provide hardware related debugging information like registers etc.
• serachDir: Configure this to your OpenOCD installations tcl path

And now comes the final moment. in VS Code, click on Run/Start Debugging, and a few seconds later you should see the following window:

With all the comfort of your IDE, you can now debug.

Conclusion

This blog post took out way longer in several aspects: The time to write it, the time to test all the options, and the length of this article. With all the setup done, you can write your Pico programs in an integrated IDE, have all the comfort of code highlighting, browsing library functions, and refactoring options. Also, with the one-click-and-upload feature, you can program almost like with an Arduino. And on top of that, you can compile a Debug version of your program and run the debugger from within Visual Studio Code. This should greatly enhance your development effectiveness.

To help you get started with future projects, check out my pico-project-setup repo on Github.

关于PulseView：PulseView

The PulseView Open Source Project on Open Hub

参考文章：Using the USB Logic Analyzer with sigrok PulseView

整理了一些与红外遥控接收和发射相关的技术资源，供做遥控器项目的同学做参考：

红外遥控原理及实现