简介：面向使用 Nordic nRF52832 与 SDK15.2 开发 BLE 5.0、2.4GHz 无线 SoC 的工程师和入门读者，这是一套以艾克姆 IK-52832DK 开发套件为平台的硬件外设教程上册，帮助读者从最简单的裸机工程起步，逐个跑通片上外设。内容先交代开发板的功能特点与硬件原理，再依次展开电源与低功耗模式、指示灯、轻触与触摸按键、蜂鸣器、电位器采样、红外接收、USB 转 UART、I2S 音频接口、显示模块接口等模块的电路分析与程序实现；每个实验都说明对应工程在哪个工程上修改、需新增哪些源文件、头文件如何引用和包含，并延伸到 WiFi、NFC 天线、温湿度与 PM2.5、运动传感器、TF 卡座、调试接口等板载资源。资源为 1 个 PDF 文件，压缩包约 18.57MB，按章节编排便于对照查阅，已有 2514 人学习。读者可据此建立 SDK15.2 软件框架认知，掌握外设配置与调试思路，并迁移到物联网、健康监测、智能家居等项目。

1. 低功耗蓝牙SoC开发指南上册：先打通裸机链路，再碰BLE 5.0

这份《低功耗蓝牙SoC开发指南·上册》把BLE 5.0、2.4GHz无线SoC和配套SDK的入门路径拆成了一条很实的线：从开发板硬件、电源与调试接口讲起，先建裸机工程，再点LED、驱蜂鸣器、读按键，最后才把协议栈烧录和广播链路接上。最反直觉的地方在于，很多人一上来就找蓝牙例程，结果卡在烧录顺序、工程宏和串口无输出上；这份资料的价值是把“板子先跑起来”当成第一目标，适合刚接手低功耗蓝牙项目、需要照着实验复现外设配置的从业者，也适合熟手拿来对照硬件原理和分区烧录顺序。

2. 开发环境与工程骨架：从IDE配置到协议栈烧录顺序

2.1 工具链选型：先用裸机工程验证板级硬件

拿到一块带BLE 5.0和2.4GHz无线SoC的开发套件，我一般不会先跑蓝牙广播例程。原因很现实：广播搜不到时，问题可能出在天线、电源、协议栈分区、应用镜像地址、手机端缓存，甚至调试器复位方式上。先用裸机工程点灯、读按键、打串口，能把“芯片能不能跑、时钟对不对、下载链路通不通”这三个黑匣子先拆开。指南上册的编排也是这个思路，硬件原理、开发工具、环境搭建、新建裸机工程、程序下载、GPIO输出、蜂鸣器、按键检测一路推下来，每个实验都说明基于哪个实验修改、要加哪些文件、头文件怎么引用，这种写法对复现很友好。

工具链不需要堆太多。常见做法是：一个能编译32位MCU工程的IDE、一个器件支持包、一个调试器驱动、一个串口终端、一个协议栈烧录上位机，再加手机端调试APP。选型时别看界面花不花，先看四个检查点：编译后能不能生成带调试信息的镜像；调试器能不能识别芯片ID和闪存容量；协议栈和应用镜像能不能分开写；串口能不能稳定收到打印。下面这张表是我拆这类资料时常用的核对表，名字用通用类别，具体工具按手头套件替换。

提示：先别急着装一堆版本。IDE、器件支持包和SDK版本要配套，混着装最容易出现“编译通过但链接地址不对”的玄学问题。

2.2 从零建工程：目录规划、库文件裁剪与编译选项

指南上册花了很大篇幅讲新建和配置裸机工程，这一步不能嫌烦。很多翻车不是代码写错，而是工程目录乱、库文件拷贝不全、头文件路径漏了、宏定义没开。我的习惯是先固定一个最小目录，把应用代码、板级支持、SDK库、启动文件、链接脚本和输出目录分开，后面加外设实验时只动app和bsp，不碰sdk。下面这个目录结构是通用做法，目录名可以按你的习惯改，分层逻辑别改。

mkdir -p project/{app,bsp,sdk,startup,linker,output} # app：实验应用代码，比如led_test.c、key_test.c # bsp：板级支持，封装GPIO、UART、定时器初始化 # sdk：芯片厂商提供的库、头文件和协议栈接口 # startup：启动文件、系统初始化 # linker：链接脚本，决定代码和RAM放在哪 # output：编译产物，hex、map、lst都放这里

这段命令只做一件事：把“会频繁改的代码”和“尽量不改的库”分开。参数上，app和bsp是后续实验的主要改动区；sdk只读引用，升级SDK时整目录替换；linker要跟协议栈分区表匹配，不能随便换。编译选项里最容易漏的是头文件路径、全局宏和C标准。头文件路径要包含app、bsp、sdk/include、startup；全局宏要跟板级定义一致，比如是否启用内部DC/DC、晶振频率、调试口使能；优化等级先选-O0或低优化，方便单步，等外设都通了再开高优化。

/* 典型的编译配置片段，伪Makefile，按你的IDE选项逐项对应 */ CFLAGS += -Iapp -Ibsp -Isdk/include -Istartup CFLAGS += -D BOARD_XTAL_32K -D DEBUG_UART_ENABLE CFLAGS += -O0 -g3 -std=c99 LDFLAGS += -T linker/app.ld -Wl,-Map=output/app.map

这段配置的逻辑是：-I决定编译器去哪找头文件，漏一个就会报“找不到board.h”这类低级错误；-D把板级差异做成宏，后续换板只改宏不改源码；-O0 -g3保留调试信息，适合上册这些逐个外设的实验；-T指定链接脚本，-Map生成映射文件，后面查变量地址和闪存占用全靠它。参数怎么改：如果串口打印乱码，先查晶振宏和波特率分频；如果程序下载后不跑，先看链接脚本起始地址是不是被协议栈占了；如果编译报重复定义，查sdk库是不是拷了两份。

2.3 烧录链路：协议栈+应用镜像的分区写入顺序

BLE程序和无协议栈裸机程序的烧录方式不一样。裸机程序通常直接写应用镜像；带协议栈的程序要先写协议栈，再写应用，而且应用链接地址要落在协议栈后面的分区里。指南上册把下载方式拆成IDE直接下载、独立烧录工具下载和协议栈上位机下载，并单独讲全片擦除，这个顺序很关键。我的经验是：第一次上手先全片擦除，再按“协议栈镜像→应用镜像→校验→复位”走一遍，别在旧内容上叠着写。

# 通用烧录流程示意，命令名按你手头的烧录工具替换 flash_tool --erase-all flash_tool --write softdevice.hex --address 0x00000000 flash_tool --write app.hex --address 0x00026000 --verify flash_tool --reset --run

这段流程里，--erase-all清掉旧协议栈、旧应用和可能残留的配置区；--address是分区基址，示例地址只作演示，实际以你所用协议栈的分区表为准，不要照抄；--verify一定加，烧录工具说成功但校验失败的情况并不少见；--reset --run让芯片从复位向量重新跑，避免调试器停在内核异常处。参数怎么改：应用镜像地址要看链接脚本和分区表是否一致；如果烧完广播搜不到，先确认协议栈是否真的写进去，再看应用有没有调用协议栈初始化；如果全片擦除后调试器连不上，检查调试口是否被低功耗模式关掉，必要时用复位引脚下拉再上电。

注意：带协议栈的工程不要只下载app.hex就判断“程序有问题”。协议栈没写、分区地址不对、应用镜像链接地址偏移，都会表现成“下载成功但不广播”。

3. GPIO与按键实验：LED、蜂鸣器和输入检测的可复用模板

3.1 输出驱动：限流电阻、驱动能力和库函数封装

指南上册从GPIO输出驱动LED开始，这个实验看着简单，但把硬件原理讲透了：LED控制方式、限流电阻选取、GPIO驱动能力、应用注意事项。很多新手直接抄代码，灯是亮了，但电流超标、亮度不一致、低电平灌电流过大，后面接蜂鸣器和外设模块时就开始翻车。LED限流电阻的常用算法是R=(VDD-VF)/I，其中VF是LED正向压降，I是目标电流。红色LED的VF通常低一些，蓝白绿高一些；GPIO高电平拉电流和低电平灌电流能力不一样，总电流还有上限。下面这张表是实验前我会先填的参数表，具体数值按手头板子改。

代码上，我一般把GPIO配置封在bsp层，应用层只调led_on/led_off/led_toggle。这样后面做流水灯、蜂鸣器、按键指示时不用重复配寄存器，也方便换板。下面是一段简化接口，底层实现按你的SDK替换。

/* bsp_led.h / bsp_led.c 简化示例 */ #include <stdint.h> #include "soc_gpio.h" typedef enum { LED_RED = 0, LED_GREEN, LED_BLUE, LED_MAX } led_id_t; static const uint32_t led_pin[LED_MAX] = { 6, 7, 8 }; /* 按实际引脚改 */ void bsp_led_init(void) { for (uint32_t i = 0; i < LED_MAX; i++) { soc_gpio_config_output(led_pin[i], SOC_GPIO_PULL_DISABLE); soc_gpio_write(led_pin[i], 1); /* 默认灭灯，按高/低有效调整 */ } } void bsp_led_set(led_id_t id, uint8_t on) { if (id >= LED_MAX) return; /* 若LED低电平点亮，这里取反；先确认硬件电路 */ soc_gpio_write(led_pin[id], on ? 0 : 1); } void bsp_led_toggle(led_id_t id) { if (id >= LED_MAX) return; soc_gpio_toggle(led_pin[id]); }

这段代码的逻辑是：led_pin集中管理引脚，换板只改数组；bsp_led_init统一配成输出并设默认灭灯，避免上电闪；bsp_led_set把“亮/灭”和“高/低有效”隔离开，应用层不关心电路反相。参数上，SOC_GPIO_PULL_DISABLE表示输出模式不需要上下拉；默认写1还是写0要看LED是灌电流还是拉电流；如果灯常亮不受控，先查引脚是否被复用成调试口或协议栈占用。

3.2 输入检测：上拉/下拉、消抖和触摸按键的边界

按键检测比点灯更容易出“玄学”。机械按键有抖动，触摸按键有基线漂移，轻触按键还要考虑上拉/下拉和按下电平。指南上册把轻触按键和触摸按键分开讲，还提到按键检测电路考虑因素，这个顺序是对的。机械按键常见做法是GPIO输入加上拉或下拉，按下产生电平变化，软件做10ms～20ms消抖；触摸按键则要看电容变化、基线校准和阈值，环境湿度、手指面积、面板厚度都会影响。下面这张表是我调按键时先定的参数，机械按键和触摸按键不要混用同一套阈值。

软件消抖不要用delay死等，上册后面的定时器和中断实验就是为这种场景准备的。我一般用状态机：每1ms或5ms采样一次，连续多次相同才确认。下面是一段按键扫描的简化代码，放在定时器回调或主循环节拍里都能用。

/* bsp_key.c 简化按键状态机 */ #include <stdint.h> #include "bsp_key.h" #define KEY_DEBOUNCE_CNT 5 /* 5ms节拍下约25ms确认 */ #define KEY_RELEASE_CNT 5 typedef struct { uint8_t stable_pressed; uint8_t sample_cnt; } key_state_t; static key_state_t key_state[KEY_MAX]; void bsp_key_scan_5ms(void) { for (uint32_t i = 0; i < KEY_MAX; i++) { uint8_t raw_pressed = (soc_gpio_read(key_pin[i]) == 0); /* 低有效 */ if (raw_pressed == key_state[i].stable_pressed) { key_state[i].sample_cnt = 0; continue; } key_state[i].sample_cnt++; uint8_t need = raw_pressed ? KEY_DEBOUNCE_CNT : KEY_RELEASE_CNT; if (key_state[i].sample_cnt >= need) { key_state[i].stable_pressed = raw_pressed; key_state[i].sample_cnt = 0; key_event_post(i, raw_pressed ? KEY_EVT_DOWN : KEY_EVT_UP); } } }

这段逻辑是“采样—计数—确认—发事件”，不会在主循环里卡死。KEY_DEBOUNCE_CNT和KEY_RELEASE_CNT分别控制按下和松开确认时间，按下可以稍短，松开稍长，避免连击；soc_gpio_read返回电平，低有效还是高有效要跟硬件一致；key_event_post只投递事件，具体业务在应用层处理。如果按键偶尔误触发，先看电源纹波和长线干扰，再看消抖节拍是不是被其他中断拖慢；如果触摸按键漂移，先打印原始值和基线，不要直接改阈值。

3.3 实验代码：LED闪烁、流水灯和按键状态机

上册的GPIO实验是递进的：先LED闪烁，再流水灯，再蜂鸣器，再按键检测。这个顺序的好处是每个实验只增加一个变量，排错范围小。我的建议是把闪烁和流水灯做成同一个bsp_led接口下的两个应用，按键实验则单独建一个key_test.c，不要在一个main里越堆越乱。下面这段应用代码把三个实验串起来，编译时用宏切换。

/* app/main.c 实验切换示例 */ #include "bsp_led.h" #include "bsp_key.h" #include "bsp_delay.h" #define EXP_LED_BLINK 1 #define EXP_LED_FLOW 2 #define EXP_KEY_LED 3 #ifndef EXP_MODE #define EXP_MODE EXP_LED_BLINK #endif int main(void) { board_init(); bsp_led_init(); bsp_key_init(); #if EXP_MODE == EXP_LED_BLINK while (1) { bsp_led_set(LED_RED, 1); bsp_delay_ms(500); bsp_led_set(LED_RED, 0); bsp_delay_ms(500); } #elif EXP_MODE == EXP_LED_FLOW while (1) { for (uint32_t i = 0; i < LED_MAX; i++) { bsp_led_set((led_id_t)i, 1); bsp_delay_ms(200); bsp_led_set((led_id_t)i, 0); } } #elif EXP_MODE == EXP_KEY_LED while (1) { key_event_t evt; if (key_event_get(&evt, 10)) { if (evt.type == KEY_EVT_DOWN) { bsp_led_toggle(LED_GREEN); } } } #endif }

这段代码的逻辑是：EXP_MODE选择实验，避免每次改一堆注释；board_init做时钟和调试口初始化；闪烁实验验证最小输出，流水灯验证多引脚顺序，按键实验验证输入事件到输出动作的闭环。参数上，延时500ms和200ms只是肉眼观察用，后面换定时器时把bsp_delay_ms替换成非阻塞节拍；key_event_get的超时10ms决定主循环响应速度，不要设成0导致空转。实验步骤很简单：先编译烧录闪烁，确认灯受控；再切流水灯，确认引脚顺序；最后切按键，确认按下和松开事件各一次，不连发。

提示：每换一个实验，先把上一个实验的硬件连接恢复干净。LED和蜂鸣器共用引脚、按键和调试口复用，是上册实验里最常见的“看起来代码没错但不按预期跑”的来源。

4. 串口、定时器与中断：外设联调先抓三个观察点

4.1 UART调试通道：波特率、引脚复用和环形缓冲

串口是外设联调的第一观察点。指南上册在硬件部分讲了USB转UART，在实验部分会用到串口打印。很多人点灯成功后就觉得串口自然能通，结果打印乱码或者一个字符都收不到。串口要抓三件事：引脚复用对不对、波特率分频准不准、收发缓冲会不会溢出。常见参数是115200、8数据位、1停止位、无校验、无流控；如果板上有USB转UART芯片，还要看TX/RX是否交叉、电平是否匹配。下面这张表是我排查串口时按顺序看的项。

不要在主循环里死等发送完成，长日志会拖慢业务。我一般用环形缓冲，中断里收，主循环里取。下面是一段简化实现。

/* bsp_uart_ring.c 简化环形缓冲 */ #include <stdint.h> #include "bsp_uart.h" #define UART_RX_BUF_SIZE 256 static volatile uint8_t rx_buf[UART_RX_BUF_SIZE]; static volatile uint16_t rx_head = 0; static volatile uint16_t rx_tail = 0; void bsp_uart_rx_isr(uint8_t byte) { uint16_t next = (rx_head + 1) % UART_RX_BUF_SIZE; if (next != rx_tail) { /* 留一个空位区分满/空 */ rx_buf[rx_head] = byte; rx_head = next; } } int bsp_uart_read_byte(uint8_t *out) { if (rx_tail == rx_head) return 0; *out = rx_buf[rx_tail]; rx_tail = (rx_tail + 1) % UART_RX_BUF_SIZE; return 1; }

这段代码的逻辑是：中断只做入队，主循环取出处理，避免在中断里做协议解析。UART_RX_BUF_SIZE按日志量选，256字节适合命令交互，长日志可以加到1KB；next != rx_tail留一个空位，防止head和tail相等时分不清满和空；volatile告诉编译器这两个下标会被中断改。参数怎么改：如果丢字符，先加大缓冲，再看中断优先级是否被其他外设压太久；如果乱码，先换波特率试，再查时钟源和分频；如果完全无输出，先量TX引脚有没有波形，别在代码里猜。

4.2 定时器与GPIOTE：中断优先级和事件回调的写法

定时器和GPIOTE是上册后半段的核心。LED闪烁用延时只是教学过渡，真正做产品要用定时器节拍；按键扫描、串口超时、低功耗唤醒都靠定时器。GPIOTE负责引脚事件，适合把按键从轮询改成中断。这里最容易翻车的是中断优先级和回调里干太多事。常见做法是：定时器中断只置标志或投递事件，GPIOTE中断只清事件并记录时间戳，业务在主循环处理。定时周期用ticks = timeout_ms * timer_freq / 1000算，注意整数溢出和分频。

/* bsp_timer.c 简化定时器节拍 */ #include <stdint.h> #include "soc_timer.h" #include "bsp_key.h" #define TIMER_FREQ_HZ 1000000UL #define TICK_MS 5 static volatile uint32_t g_tick_ms; void bsp_timer_init(void) { soc_timer_config_t cfg = { .freq_hz = TIMER_FREQ_HZ, .mode = SOC_TIMER_MODE_PERIODIC, .callback = bsp_timer_isr }; soc_timer_init(SOC_TIMER0, &cfg); soc_timer_set_period(SOC_TIMER0, TIMER_FREQ_HZ / 1000 * TICK_MS); soc_timer_start(SOC_TIMER0); } void bsp_timer_isr(void) { g_tick_ms += TICK_MS; bsp_key_scan_5ms(); /* 按键扫描只做状态机，不做业务 */ }

这段代码的逻辑是：定时器固定5ms节拍，g_tick_ms给上层做超时基准，按键扫描挂在节拍里。TIMER_FREQ_HZ选1MHz是为了分频好算，实际可按低功耗需求降低；TIMER_FREQ_HZ / 1000 * TICK_MS先除后乘，避免大数溢出；中断里只做短任务，串口打印和闪灯业务不要放进来。中断优先级建议：调试串口和定时器节拍优先，GPIOTE按键次之，低优先级外设不要长时间关中断。如果按键响应迟钝，先看定时器中断是不是被高优先级中断打断太久；如果系统偶发死机，查中断里有没有调用阻塞函数。

4.3 低功耗模式：保持调试口可用的取舍

低功耗是这类SoC的核心卖点，但上册阶段不建议一上来就把功耗压到最低。原因很简单：睡眠太深，调试器连不上，串口不打印，你会失去观察点。我的做法是分三档：调试阶段开调试口、关深度睡眠；功能验证阶段开浅睡眠，保留串口唤醒；功耗测试阶段再关调试口，用GPIO或定时器唤醒。低功耗模式进入前要确认唤醒源、外设时钟和引脚状态，退出后要重新初始化被关掉的外设。

/* bsp_power.c 简化低功耗进入 */ #include "soc_power.h" #include "bsp_uart.h" void bsp_enter_low_power(uint32_t wake_ms) { bsp_uart_flush(); /* 保证日志发完再睡 */ soc_power_config_wakeup_timer(wake_ms); soc_power_config_wakeup_gpio(KEY_WAKE_PIN, SOC_GPIO_WAKE_LOW); soc_power_enter(SOC_POWER_MODE_LOW); /* 调试阶段先用浅睡眠 */ }

这段代码的逻辑是：睡前冲掉串口缓冲，配置定时器和按键唤醒，再进浅睡眠。wake_ms按业务定，太短会频繁唤醒，太长按键响应慢；SOC_POWER_MODE_LOW是浅睡眠占位，深度睡眠模式要等调试口关闭后再试；唤醒后要重新检查外设时钟和UART状态。注意：如果烧录后程序“不跑”，可能是上电就进了低功耗，调试器来不及 attach。这时候用复位引脚下拉、上电延时或临时加一段“后悔药”延时，给自己留出连接窗口。

5. 避坑与排查：烧录失败、广播消失、串口乱码的五条记录

5.1 现象：下载成功但程序不跑

现象很典型：烧录工具提示成功，校验也过了，但LED不闪、串口无输出，调试器一暂停发现停在启动文件或异常向量。原因通常不是芯片坏了，而是应用镜像链接地址和实际烧录地址不一致，或者协议栈没写却直接跑了带协议栈的应用，也可能是全片擦除后把协议栈擦掉了。解决顺序是：先看map文件里代码起始地址，再对分区表和应用烧录地址；带协议栈的工程先写协议栈再写应用；最后做一次全片擦除后按顺序重写。血泪经验是，别在旧镜像上反复叠写，先擦干净再定位。

5.2 现象：BLE广播搜不到

现象是手机端能扫到别的设备，就是扫不到这块板。原因可能在天线匹配、协议栈初始化、广播参数、设备名过滤，也可能是应用根本没跑到广播启动。排查时先看串口有没有打印启动日志，再看调试器能不能停在广播启动函数，然后确认协议栈镜像和分区地址。手机端缓存也要清，设备名过滤条件别设太死。如果裸机程序能跑、协议栈也写了，但广播就是出不来，重点查应用链接地址和协议栈API返回值，不要一上来就怀疑天线。

5.3 现象：按键误触发或串口乱码

按键误触发和串口乱码经常一起出现，因为背后都是时序和电气问题。按键误触发可能是上拉/下拉没配、消抖节拍被高优先级中断拖慢、长线引入干扰；串口乱码可能是波特率分频不对、时钟源选错、TX/RX接反、电平不匹配。解决时先用示波器或逻辑分析仪看按键波形和串口TX波形，确认硬件边沿；再在软件里打印原始采样值和串口接收字节数。不要用加大延时掩盖问题，延时会把低功耗和响应速度一起拖垮。

5.4 现象：低功耗唤醒后外设异常

现象是进入低功耗再唤醒后，串口不发、定时器不走、按键没反应。原因通常是睡眠时关了外设时钟，唤醒后没重新初始化；或者引脚在睡眠时被切成高阻，外部上拉导致漏电或误触发；还有调试口被关掉，看起来像死机。解决时把低功耗分档，先浅睡眠保留调试口，唤醒后按“时钟—GPIO—UART—定时器”的顺序重新初始化，并在唤醒中断里记录唤醒源。功耗测试阶段再逐项关外设，别一次性全关。

5.5 现象：工程换机器编译不过

现象是同一份工程在另一台机器上编译报头文件找不到、链接地址错、库版本不匹配。原因多半是工程用了绝对路径、器件支持包版本不同、SDK库被局部修改过、编译宏没同步。解决时把路径改成相对路径，把器件支持包和SDK版本记录在工程说明里，库目录尽量只读，板级差异全部收进宏定义。换机器先跑一次最小点灯工程，确认工具链和下载链路，再编译大工程，别直接上全量代码。

6. 进阶验证：示波器波形加日志闭环的验收表

上册的实验做完，不等于外设就稳了。我一般加一道验收：上电时序、GPIO波形、串口日志、复位原因四项一起看。LED和蜂鸣器用示波器看上升沿和脉宽，按键看按下和松开抖动，串口看波特率误差和丢包，复位原因看是上电复位、看门狗还是软件复位。下面这张验收表可以直接抄到实验记录里。

再进一步，把每个实验做成可回归的小脚本：编译、烧录、串口抓10秒日志、检查关键字、记录复位原因。代码不用复杂，关键是每次改完外设都跑一遍，别靠肉眼。下面是一个伪脚本框架，命令按你的工具替换。

#!/usr/bin/env bash set -e make clean && make EXP_MODE=EXP_KEY_LED flash_tool --erase-all flash_tool --write softdevice.hex --address 0x00000000 flash_tool --write output/app.hex --address 0x00026000 --verify flash_tool --reset --run timeout 10s serial_capture --port COMx --baud 115200 > output/key_test.log grep -q "KEY_EVT_DOWN" output/key_test.log

这段脚本的逻辑是：固定实验宏、全片擦除、按顺序写协议栈和应用、抓串口日志、用关键字判断事件有没有上报。参数上，EXP_MODE决定编译哪个实验，timeout 10s防止串口抓取卡死，grep的关键字要和代码打印一致。从那以后我每次改GPIO或低功耗配置，都强制走一遍“擦除—写协议栈—写应用—抓日志—看复位原因”的闭环，不再凭感觉判断“应该没问题”。希望帮到你。

本文还有配套的精品资源，点击获取