weixin_62851550的博客

原创 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为例说明）

原创 cherryusb 使用cdc_acm串口+ringbuffer接收bmp图片，并在线程中读取ringbuffer并一行一行的发送到lcd屏显示

整个的效果非常好，非常丝滑。为了提高速度，我把CHUNCK_SIZE设置为16384（最大65536,但是ram容量受不了）。用magick产生一些图片，然后通过sscom串口助手发送文件到单片机接收。

原创 基于cherryusb，实现cdc_acm串口用作rtt console

【代码】基于cherryusb，实现cdc_acm串口用作rtt console。

原创 cherryusb usbd_core.c中枚举过程（ep0端点）的3个关键处理函数详细分析

【代码】cherryusb usbd_core.c中枚举过程（ep0端点）的3个关键处理函数详细分析。

原创 cherryusb中usb_dc_dwc2.c代码中断处理USBD_IRQHandler分析和感悟

在ep0_setup_complete_handler 中发的。在ep0_out_complete_handler中发的。

原创 cherryusb usb_dc_dwc2.c 源码超详细中文注释版

原创 cherryusb usbd_core.c 源码超详细中文注释版

本文对cherryusb device模式的协议栈核心文件usbd_core.c源码进行了详细中文注释。注释详细程度，精确到了几乎每一行。这样方便cherryusb爱好者学习，和理解底层的运作。本人学识有限，不是cherryusb作者，只能按照自己的理解来解读（虽然很多地方也经过了很长时间的思考）。有不正确的地方，往指正。

原创 cherryusb协议栈思维导图（device模式，以dwc2 ip为例说明）

本文分析并给出了cherryusb协议栈的完整思维导图，以方便usb爱好者学习和理解cherryusb的运行原理。本文以device为例，并结合synopsys dwc2 ip为例说明。未来会给出cherryusb host模式的思维导图。

原创 cherryusb的初始化流程思维导图（以cdc_acm_msc_init为例）

本文描绘了cherryusb的初始化流程的思维导图，以cdc_acm为例绘制。

原创 cherryusb dwc2 cdc_acm_template trace分析笔记

USB协议复杂，很难。USB又非常重要，是单片机最常用的接口之一，用途极其广泛。很多工程师和爱好者，非常想搞懂usb底层的运行细节，但是无奈面对庞大复杂的协议栈，一筹莫展。本文独辟蹊径，采用了新的分析方法，基于cherryusb+dwc2 usb ip，以cdc_acm_template代码为例，进行了运行过程的trace分析。本文对trace到的log文件，结合代码细节，进行了详细的解读。通过trace分析，完整呈现出了usb的枚举过程和通信过程的细节，抓出了所有关键的中断处理流程。甚至可以毫不夸张的说，