weixin_62851550的博客

原创 基于cherryusb自制daplink，并对stm32u575进行烧录过程，daplink的执行流进行trace分析

原创 hpm6750evkmini的rt-thread环境下，spi2+dma或polling模式驱动st7789， 并移植lvgl，结果对比， 并进行trace分析

【代码】hpm6750evkmini的rt-thread环境下，spi2+dma或polling模式驱动st7789， 并移植lvgl，结果对比， 并进行trace分析。

原创 hpm6750evkmini的rt-thread环境下，手搓drv_qspi.c，并驱动st77916， 并上lvgl

将framebuffer定义在sdram中，注意hpm的flash_rtt.ld文件有bug。最初导致定义到sdram中的东西，没有真正放进去。修改分频比，初始化用低频。修改flash_rtt.ld。

原创 hpm6750evkmini的rt-thread环境下，手搓drv_qspi.c，并挂载外部qspi-flash

【代码】hpm6750evkmini的rt-thread环境下，手搓drv_qspi.c，并挂载外部qspi-flash。

原创 深入理解drv_qspi.c后，完全正向亲手移植rt-thread的drv_qspi.c驱动 (基于stm32h750 artpi）

【代码】深入理解drv_qspi.c后，完全正向亲手移植rt-thread的drv_qspi.c驱动 (基于stm32h750 artpi）

原创 深入理解drv_spi.c后，完全正向亲手移植rt-thread的drv_spi.c驱动 (基于stm32h750 artpi）

【代码】深入理解drv_spi.c后，完全正向亲手移植rt-thread的drv_spi.c驱动 (基于stm32h750 artpi）

原创 stm32 hal库spi dma_tx_rx的几个关键函数执行过程jlink trace分析

=1UL。

原创 rt-thread使用sfud挂载qspi flash的trace分析

trace log先贴在这里，待分析完成后，完善文章。

原创 rt-thread使用sfud挂载spi flash, 并使用spi驱动st7789 lcd的trace分析（使用spi dma）

应用层需要调用rt_hw_spi_device_attach, rt_spi_configure函数来注册spi总线和初始化spi设备注意！rt_spi_configure函数实现spi设备初始化。底层需要实现spi_configure和spixfer这2个函数。如果是自己的板子移植，可以不用rt-thread的设备结构体, 直接在这2个函数中初始化外设, 并基于hal库函数实现收发即可.

原创 （附录）rt-thread audio框架移植stm32 adc+dac，用wavplayer录音和播放，完整的tracelog

原创 rt-thread audio框架移植stm32 adc+dac，用wavplayer录音和播放，代码执行流trace分析

【代码】rt-thread audio框架移植stm32 adc+dac，用wavplayer录音和播放，代码执行流trace分析。

原创 rt-thread audio框架移植stm32 adc+dac，对接cherryusb uac，进行录音和播放

rt-thread官方sdk中，正点原子stm32f429-atk-appollo的board中有audio文件夹，包括了mic/play的程序，wm8978的库文件因为我们基于stm32h750内置adc+dac设计，所以不需要wm8978.c/h。只需要移植drv_sound.c和drv_mic.cD5 drv_mic.c所作修改简单说明总的内容与前一篇文章完全一样，这里只说不同的地方定义了一个录音线程，用于与cherryusb uac交互。通过rt_device_read函数，从mic0设

原创 rt-thread audio框架移植stm32 adc+dac，用wavplayer录音和播放

rt-thread官方sdk中，正点原子stm32f429-atk-appollo的board中有audio文件夹，包括了mic/play的程序，wm8978的库文件因为我们基于stm32h750内置adc+dac设计，所以不需要wm8978.c/h。只需要移植drv_sound.c和drv_mic.c播放要实现的几个dev_audio设备驱动框架的几个函数包括：stm32_player_getcaps，stm32_player_configure， stm32_player_init， stm32_

原创 针对前面2篇文章的一个细节的修订（UAC ADC/DAC录音播放，以及UAC ADC/PWM录音播放）

本文主要是为了修正前面2篇文章的一个bug, 就是从ADC采集并填充数据的时候，左/右声道没有填充相同的数据。从UAC接收数据并发送给DAC/PWM的时候，把左右声道的数据全部扔给了一个DAC/PWM来播放, 没有从中只抽出一个声道的数据来播放。从原理上说，这样是不好的。

原创 Cherryusb UAC例程对接STM32 SAI播放音乐和录音(下)=＞USB+SAI+TX+RX+DMA控制WM8978播放和录音实验

整个程序框架, 与之前的一篇文章《Cherryusb UAC例程对接STM32内置ADC和DAC播放音乐和录音(中)=>UAC+STM32 ADC+DAC实现录音和播放》基本一致, 只是这次将DAC替换成了PWM。因此这里不再赘述了。Kconfig中对i2c3的定义定义了5个操作函数, 用于wm8978的控制和SAI的控制。代码比较简单。关于wm8978的操作函数，我们是直接调用了一个rt-thread工程中现成的库。这个库文件的路径为https://gitee.com/rtthread/r

原创 Cherryusb UAC例程对接STM32 SAI播放音乐和录音(上)=＞SAI+TX+RX+DMA的配置与音频回环测试

STM32H750-ARTPI的SAI接口通过P1排针引出, 使用的是SAI2开启SAI2，配置A通道为TX(带MCLK输出)，B通道为同步RX。所谓同步的意思是B通道自己不产生时钟, 而是来自A通道的时钟, 与A通道同步。勾选I2S/PCM模式配置A通道，每一项要仔细检查。A通道为异步，因为它是要输出时钟源的，它是发起者，不需要与其它时钟同步。基本参数是：16kHz采样率，2个slot(左右声道)，每个slot 16bits。Mclk不要分频，不要过采样。对于这样一个配置，FS=16kHz, MCLK=

原创 Cherryusb UAC例程对接STM32内置ADC和PWM播放音乐和录音(下)=＞UAC+STM32 ADC+PWM实现录音和播放

整个程序框架, 与之前的一篇文章《Cherryusb UAC例程对接STM32内置ADC和DAC播放音乐和录音(中)=>UAC+STM32 ADC+DAC实现录音和播放》基本一致, 只是这次将DAC替换成了PWM。因此这里不再赘述了。

原创 Cherryusb UAC例程对接STM32内置ADC和PWM播放音乐和录音(上)=＞TIM12(TRGO)+TIM5(PWM)+DMA的配置与测试

TIM5选择内部时钟, 使能CH3-PWM(ARTPI-P2排针上PA2)TIM5参数配置, Period配置1499(对应PWM频率=240MHz/1500=160kHz, 也就是载波频率)，开启Auto-Reload功能，Pulse（也就是占空比）配置为750(50%占空比)。关于为什么选160kHz载波频率，后面有详细说明。配置DMA后DMA中断使能默认开启。开启TIM5中断，虽然不确定是否需要，但是为了保险起见，还是开启了。(事实上从后面对HAL_TIM_PWM_Start_DMA函数的Trac

原创 Cherryusb UAC例程对接STM32内置ADC和DAC播放音乐和录音(下)=＞UAC+STM32 ADC+DAC实现录音和播放的代码执行过程Trace分析

【代码】Cherryusb UAC例程对接STM32内置ADC和DAC播放音乐和录音(下)=＞UAC+STM32 ADC+DAC实现录音和播放的代码执行过程Trace分析。

原创 Cherryusb UAC例程对接STM32内置ADC和DAC播放音乐和录音(中)=＞UAC+STM32 ADC+DAC实现录音和播放

3. tim_adc_dac_dma_usb.c主程序的实现说明首先定义了2个ringbuffer, 一个是usb_to_dac_ring, 一个是adc_to_usb_ring. 分别用于存储usb接收的数据, 以及adc采集的数据.然后定义了2个信号量, 一个是adc_data_ready_sem, 一个是dac_data_req_sem.其中adc_data_ready_sem用于控制adc线程的运行, 当ringbuffer中的数据不足时, 就会阻塞线程, 等待数据的到来.而dac_dat

原创 Cherryusb UAC例程对接STM32内置ADC和DAC播放音乐和录音(上)=＞TIM+DAC+ADC+DMA正弦波回环关键函数Trace分析

【代码】Cherryusb UAC例程对接STM32内置ADC和DAC播放音乐和录音(上)=＞TIM+DAC+ADC+DMA正弦波回环关键函数Trace分析。

原创 Cherryusb UAC例程对接STM32内置ADC和DAC播放音乐和录音(上)=＞TIM+DAC+ADC+DMA正弦波回环测试

以STM32H7来说，有些外设支持定时器Trigger功能（比如ADC/DAC），这种可以直接使用TIM的溢出Event来进行触发，控制DMA速率。这种传输模式如下所示。这种方式相当于直接控制的源头。但大部分外设都不支持定时器Trigger功能（比如SPI/UART/I2C/GPIO等），这种在STM32H7里面，也可以利用定时器进行控制DMA速率。在STM32H7中引入DMA请求生成器，可软件或硬件触发DMA请求，无需外设直接请求。

原创 cherryusb device代码执行trace分析之九 (device模式之uac_v1.0_mic_speaker例程)

这是cherryusb代码trace分析系列文章之九。本文主要分析cherryusb uac v1.0运行流程. 所采用的demo是audio_v1_mic_speaker_multichan_template.c. 本文对trace到的log文件，结合代码细节，进行了详细的解读。通过trace分析，完整呈现出了usb device模式的枚举过程和通信过程的细节，抓出了所有关键的中断处理流程。本文为嵌入式USB开发提供了可复用的技术参考和调试方法论。

原创 cherryusb device代码执行trace分析之八 (device模式之uvc_mjpeg例程)

这是cherryusb代码trace分析系列文章之八。本文主要分析cherryusb uvc运行流程. 所采用的demo是video_static_mjpeg_template.c. 本文对trace到的log文件，结合代码细节，进行了详细的解读。通过trace分析，完整呈现出了usb device模式的枚举过程和通信过程的细节，抓出了所有关键的中断处理流程。通过实时日志记录和深入解析，展示了从硬件初始化、设备检测到最终挂载的完整流程，重点包括：本文为嵌入式USB开发提供了可复用的技术参考和调试方法论。从v

原创 gdb print设置技巧，离线查看复杂结构体和数组变量内容，展开多层嵌套的结构体的方法

通过gdb打印复杂结构体，可以完全展开结构体，从而清晰的看到结构体的嵌套层次关系。可以看到，在usbh_core.c中，有一个全局结构体数组变量struct usbh_bus g_usbhost_bus[1]，正是我们需要的。其实不用这样，更简单的方式，是直接用arm-none-eabi-gdb对elf文件进行调试，直接print这个结构体变量（全局变量）。cherryusb的uac/uvc配置描述符，用宏定义了，嵌套了多层宏，非常难以展开，看出其真实的内容是什么。首先用gdb调试elf文件。

原创 深入剖析RT-Thread串口驱动：基于STM32H750的FinSH Shell全链路Trace分析与实战解密(下)

原创 深入剖析RT-Thread串口驱动：基于STM32H750的FinSH Shell全链路Trace分析与实战解密(上)

假设我们要让自己的某个接口(比如usb cdc_acm) 作为rt-thread的console, 如何修改代码实现呢？我们的想法是尽量模仿uart串口的行为, 只要把底层的收发char的功能用我们自己的接口来替换. 来看看stm32_uart定义了那些操作函数吧.首先我们观察stm32_uart_ops, 在rt_hw_usart_init中需要调用rt_hw_serial_register注册串口设备. 一共有5个操作函数.

原创 关于cherryusb的in/out完成条件

因此，如果设置接收长度=256，但主机cdc只发送了64或128，那么将会死等，不能结束。因此，对于主机发送不定长度的情况，建议设置device的接收长度为mps，确保要么长度相等结束（拆分为一个一个mps，最后一个包是mps），要么是短包结束。4）对于cdc，接收也可以设置的长度非常大，比如32768，因为这样硬件自动分包效率高。2）但是需要注意，如果长度是mps倍数（长度=mps也算），需要在回调函数中额外发送zlp。1）对于接收，长度一定要设置为mps整数倍，不能设置为比如193这种。

原创 cherryusb device代码执行trace分析之六 (device模式之cdc_acm_template, 非DMA模式)

这是cherryusb代码trace分析系列文章之五。虽然是再次对cdc_acm_template进行trace分析，所不同的是，之前的文章都是基于dwc2 ip的DMA模式（无论device还是host，都是DMA)。这一次，使用的是dwc2 ip的非DMA模式，也就是中断模式。许多低档的32系列使用的dwc2 ip的USB，可能不支持DMA模式，只有中断模式（比如STM32F401)。这些低档32系列可能用的非常广泛，因此有必要搞清楚基于中断模式的运行细节。本文对trace到的log文件，结合代码细节

原创 cherryusb device代码执行trace分析之五（下集） (device模式之cdc_acm_hid_msc_template复合设备)

这是cherryusb代码trace分析系列文章之五, 针对复合设备进行分析。本文基于cherryusb+dwc2 usb ip，针对cherryusb device模式之cdc_acm_hid_msc_template复合设备例子，进行了运行过程的trace分析。本文对trace到的log文件，结合代码细节，进行了详细的解读。通过trace分析，完整呈现出了usb device模式的枚举过程和通信过程的细节，抓出了所有关键的中断处理流程。本文为嵌入式USB开发提供了可复用的技术参考和调试方法论。

原创 cherryusb device代码执行trace分析之五（上集） (device模式之cdc_acm_hid_msc_template复合设备)

这是cherryusb代码trace分析系列文章之五, 针对复合设备进行分析。本文基于cherryusb+dwc2 usb ip，针对cherryusb device模式之cdc_acm_hid_msc_template复合设备例子，进行了运行过程的trace分析。本文对trace到的log文件，结合代码细节，进行了详细的解读。通过trace分析，完整呈现出了usb device模式的枚举过程和通信过程的细节，抓出了所有关键的中断处理流程。通过实时日志记录和深入解析，展示了从硬件初始化、设备检测到最终挂载的

原创 cherryusb device代码执行trace分析之四 (device模式之cdc_acm_template)

这是cherryusb代码trace分析系列文章之四。也是对前面一篇文章按照新的方法重新整理。USB协议复杂，很难。USB又非常重要，是单片机最常用的接口之一，用途极其广泛。很多工程师和爱好者，非常想搞懂usb底层的运行细节，但是无奈面对庞大复杂的协议栈，一筹莫展。本文独辟蹊径，采用了新的分析方法，基于cherryusb+dwc2 usb ip，针对cherryusb device模式之cdc_acm_template例子，进行了运行过程的trace分析。本文对trace到的log文件，结合代码细节，进行了

原创 cherryusb host代码执行trace分析之三（下集） (主机通过外部hub挂载msc)

本文是前面的续集，文章太长了，不得不分成3部分讲解。本文主要讲的是msc设备的枚举过程, msc class的加载过程, 空闲状态时hub_int_timeout的处理过程，以及msc设备连接断开的处理过程。不停的发生hub_int_timeout中断，在中断回调中检测hub的状态。检测到了hub状态的改变，执行处理流程3.26 接下来一段空闲过程不停的发生hub_int_timeout中断，在中断回调中检测hub的状态。因为没有数据传输发生，因此无事可做。在hub_int_complete_ca

原创 cherryusb host代码执行trace分析之三（中集） (主机通过外部hub挂载msc)

本文是前面的续集，文章太长了，不得不分成2部分讲解。本文主要讲的是msc设备的枚举过程, msc class的加载过程, 空闲状态时hub_int_timeout的处理过程，以及msc设备连接断开的处理过程。3.14 在usbh_hub_thread主循环中, 第2次执行run in loop，并执行第2轮usbh_hub_eventsusbh_hub_events的操作包括了3.15 枚举第1步: read device desc3.16 枚举第2步: 分配设备地址, 执行设置device a

原创 cherryusb host代码执行trace分析之三（上集） (主机通过外部hub挂载msc)

这是cherryusb代码trace分析系列文章之四（文章比较长，分成了2篇)。本文基于cherryusb+dwc2 usb ip，针对usb host模式挂载MSC（大容量存储）设备进行了运行过程的trace分析。与前面文章所不同的是，通过hub挂载msc设备。hub的引入，使得枚举过程变得更为复杂。需要经过2轮枚举，才能对msc设备进行识别和配置。第一轮枚举是针对外部hub的枚举。第二轮枚举是针对msc设备的枚举。本文对trace到的log文件，结合代码细节，进行了详细的解读。通过trace分析，

原创 cherryusb host代码执行trace分析之二 (主机直接挂载hid mouse)

| /[0m。

原创 cherryusb host代码执行trace分析之一续(主机直接挂载msc)

ReceivedTofile-COM20-2025_7_23_8-40-44–msc_without_hub.DAT

原创 cherryusb host代码执行trace分析之一 (主机直接挂载msc)

这是cherryusb代码trace分析系列文章之二。USB协议复杂，很难。USB又非常重要，是单片机最常用的接口之一，用途极其广泛。很多工程师和爱好者，非常想搞懂usb底层的运行细节，但是无奈面对庞大复杂的协议栈，一筹莫展。本文独辟蹊径，采用了新的分析方法，基于cherryusb+dwc2 usb ip，再次针对usb host模式挂载MSC（大容量存储）设备进行了运行过程的trace分析。本文对trace到的log文件，结合代码细节，进行了详细的解读。通过trace分析，完整呈现出了usb host模式

原创 cherryusb host模式结构体完全展开, 用于更方面的阅读源码

cherryusb host模式比较复杂，尤其是设备结构体，套的层次非常之多。主要原因是，host模式相比device模式，多了hub这个东西，hub有时候还有套hub形成多层hub。本人在阅读源码的时候，发现经常要跳转到去看结构体的定义，结果发现结构体是一层套一层，很容易忘记他们之间的层级关系。这对源码阅读造成困扰。为了解决这个问题，我花了一点时间，把cherryusb host的顶层结构体struct usbh_bus进行了完整的展开。结果一下子，变得异常清晰。

原创 cherryusb 主机模式中断处理流程思维导图，以及usb_hc_dwc2.c源码分析（以dwc2 ip为例说明）