news 2026/6/14 2:38:59

从Arduino AVR到ARM开发板迁移：选型、代码移植与无线通信实战指南

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
从Arduino AVR到ARM开发板迁移：选型、代码移植与无线通信实战指南

1. 开发板选型：从AVR到ARM的跨越与抉择

当你第一次打开Arduino IDE，面对Boards Manager里琳琅满目的选项，是不是有点懵？从经典的Uno R3到各种带“Feather”、“M0”、“M4”后缀的板子，选错了可不是简单的“编译不通过”那么简单，它直接关系到你后续整个开发流程的顺畅度。我见过太多新手，甚至是有些经验的开发者，因为一开始选错了板子型号，导致一连串诡异的问题，从程序烧不进去，到串口数据乱码，再到外设驱动失灵，折腾好几天才发现根源在这里。

为什么选型这么关键？这得从Arduino生态的底层架构说起。早期的Arduino，比如Uno、Mega2560，清一色用的是Atmel（现在被Microchip收购）的AVR系列8位微控制器。这类芯片架构简单，外设固定，Arduino IDE为它们提供了一套高度封装、几乎“傻瓜式”的操作接口。但后来，为了追求更强的性能、更低的功耗和更丰富的外设，像Adafruit、Arduino官方自己都开始引入基于ARM Cortex-M内核的32位微控制器，比如ATSAMD21（M0+）和ATSAMD51（M4）。这就带来了一个根本性的变化：编程模型和底层硬件抽象层（HAL）完全不同了。

举个例子，你手上这块小巧的Adafruit Feather 32u4，它用的ATmega32u4虽然也是AVR，但它内置了USB功能，可以直接模拟成串口（CDC），所以你在设备管理器里看到的COM端口，是芯片自己虚拟出来的。而Feather M0（ATSAMD21）虽然也能虚拟串口，但它的USB协议栈和驱动方式跟32u4又不一样。如果你在IDE里错误地为Feather M0选择了“Feather 32u4”的板型，编译器会按照32u4的寄存器地址和内存布局去编译代码，然后试图往一块ARM芯片里烧写，这无异于对着英文说明书去修一台德文标注的机器，结果只能是“avrdude: butterfly_recv(): programmer is not responding”这类让人摸不着头脑的错误。

所以，选型第一步，务必、务必、务必看清楚你板子上印的型号。这不是开玩笑，很多板子长得像，但核心迥异。Feather 32u4就选“Adafruit Feather 32u4”；Feather M0就选“Adafruit Feather M0”；ItsyBitsy M0就选“Adafruit ItsyBitsy M0”。不要凭感觉，也不要看它“长得像”哪个就选哪个。这是所有后续工作的基石，这块错了，后面全是空中楼阁。

注意：Adafruit的板型支持包（Board Support Package, BSP）是需要单独安装的。你需要在Arduino IDE的“首选项”->“附加开发板管理器网址”中添加Adafruit的索引地址，然后在“工具”->“开发板”->“开发板管理器”中搜索并安装“Adafruit SAMD Boards”和“Adafruit AVR Boards”（针对32u4等）。没装BSP，你连选项都看不到。

2. COM端口“神隐”与手动引导：ARM架构开发板的特殊之处

如果你是从Arduino Uno这类板子转过来的，那么COM端口问题可能是你遇到的第一个“坎”。在Uno上，你插上USB，电脑识别出一个COM口，上传代码，一气呵成。但在Feather M0或32u4上，你可能会发现：有时能识别两个COM口，有时一个都没有，有时上传代码时IDE报错说找不到端口。这不是板子坏了，而是ARM（以及内置USB的AVR）与传统Uno在启动流程上的一个关键差异。

传统Uno（ATmega328P）使用了一个独立的USB转串口芯片（比如CH340、CP2102或经典的FT232RL）。这个芯片有两个核心作用：1. 给主MCU烧写程序（通过DTR信号线触发复位进入引导程序）；2. 在MCU运行时，提供稳定的串口通信通道。关键点在于，这个串口芯片是独立供电和工作的，即使主MCU程序跑飞了、死机了，这个COM端口依然坚挺地存在于设备管理器中。你可以随时通过它来监控或重新上传程序。

而Feather M0（ATSAMD21）和Feather 32u4（ATmega32u4）则采用了“内置USB”方案。芯片自己实现了USB协议栈，并虚拟出一个串口（CDC）。这就意味着，串口功能是由你上传到芯片里的用户程序来创建和维持的。这里通常存在两个固件模式：

  1. 引导加载程序模式：当你双击板子上的复位按钮时，芯片会运行一段预先烧录在保护区域的引导程序（Bootloader）。此时，它会枚举为一个特定的USB设备（比如“Adafruit Feather M0 Bootloader”），并呈现一个COM端口。这个端口专门用于接收新的用户程序（.bin或.hex文件）。
  2. 用户程序模式：当你成功上传了程序（比如一个简单的串口打印“Hello World”的程序），芯片会运行你的代码。如果你的代码里初始化了串口（Serial.begin(115200)），那么芯片会再次枚举为一个USB设备（比如“Adafruit Feather M0”），并呈现另一个COM端口。这个端口用于你的应用程序通信。

问题就出在这两个模式的切换和COM端口的“存活”上。如果你的用户程序崩溃、进入死循环、或者压根就没有正确初始化串口，那么“用户程序模式”的COM端口就会消失。此时，你只剩下进入“引导加载程序模式”这一条路来上传新程序。但Arduino IDE的自动上传功能，默认是尝试向当前活跃的COM端口（也就是你选中的那个）发送烧写指令。如果这个端口恰好是那个已经消失的“用户端口”，或者IDE没有正确触发芯片复位进入引导模式，上传就会失败。

解决方案就是“手动双击复位大法”：

  1. 在Arduino IDE中点击“上传”按钮。
  2. 在IDE状态栏显示“正在编译...”切换到“正在上传...”的一瞬间，快速双击板子上的复位（RST）按钮。
  3. 如果操作成功，你会看到板载的红色LED开始呈现呼吸灯式（pulsing）闪烁，这表示芯片已进入引导加载程序模式。同时，设备管理器里可能会短暂出现一个新的COM端口（引导程序端口）。
  4. IDE会检测到这个变化，并自动将程序上传到这个新出现的引导程序端口。

这个过程需要一点手速和时机把握。核心原理就是在IDE尝试建立连接的关键时刻，手动强制芯片复位并进入引导模式，从而“劫持”上传流程，将程序发送到正确的地方。

实操心得：如果双击复位不成功，可以尝试更“暴力”的方法：先按住复位按钮，点击IDE的上传按钮，等IDE开始编译（状态栏显示“正在编译...”）时，松开复位按钮。多试几次，总能找到节奏。另外，确保你的USB数据线是可靠的，有些充电线只能供电不能传输数据，也会导致端口识别不稳定。

3. 代码移植与核心差异：避开那些“看起来一样”的坑

选对了板子，解决了上传问题，你以为就能愉快地抄Uno的代码了吗？且慢！从8位AVR迁移到32位ARM，很多在Uno上“约定俗成”的写法，在M0/M4上可能会失效，甚至导致难以排查的运行时错误。下面我梳理了几个最常见的“坑”。

3.1 模拟写入与PWM：当255不等于100%

在Uno上，analogWrite(9, 255)意味着让9号引脚输出100%占空比的PWM，等同于digitalWrite(9, HIGH)，引脚会稳定输出高电平。但在ATSAMD21（M0）上，analogWrite的精度是8位（0-255）对应256级，analogWrite(pin, 255)实际产生的是255/256 ≈ 99.6%的占空比。这意味着仍有极短时间的低电平脉冲。对于驱动某些对电平敏感的外设（比如某些需要绝对高电平来使能的模块），这可能不够“干净”。

解决方案：如果你需要绝对的、无波动的高电平，不要用analogWrite(pin, 255)，直接用digitalWrite(pin, HIGH)。同理，绝对的低电平用digitalWrite(pin, LOW)，而不是analogWrite(pin, 0)（虽然analogWrite(pin, 0)在ARM上通常也能输出持续低电平，但习惯上区分开更清晰）。

3.2 上拉电阻的配置：语法糖的陷阱

在AVR的Arduino编程中，为一个输入引脚启用内部上拉电阻，经典的做法是：

pinMode(pin, INPUT); digitalWrite(pin, HIGH); // 启用内部上拉

这是因为在AVR的硬件设计里，控制输出电平的寄存器和控制上拉电阻的寄存器是同一个。但在ARM Cortex-M架构中，引脚模式配置更加模块化。上面的写法在M0/M4上不会启用上拉电阻，digitalWrite在引脚模式为INPUT时是无效的。

正确写法：使用Arduino框架提供的专用模式常量。

pinMode(pin, INPUT_PULLUP); // 一行搞定，清晰且跨平台兼容

这个INPUT_PULLUP模式在AVR和ARM的核心库中都有正确实现，是推荐的标准写法。尽早改掉旧习惯，能让你的代码更具可移植性。

3.3 串口打印：Serial还是SerialUSB？

这是一个历史遗留问题。在Arduino官方为SAMD系列提供的早期核心库中，为了区分芯片的硬件串口（如Serial1, Serial2）和通过USB虚拟的串口，将USB虚拟串口命名为SerialUSB。而传统的Serial对象则可能指向某个硬件串口。但在Adafruit优化过的SAMD核心库中，他们做了更符合直觉的映射：Serial对象默认就指向USB虚拟串口。这样，你之前为Uno写的Serial.begin(9600); Serial.println("Hello");代码，在Feather M0上可以直接运行，并在串口监视器中看到输出。

如何判断：如果你用的是Adafruit的SAMD Boards包（强烈推荐），那么直接用Serial即可。如果你因为某些原因使用了官方的Arduino SAMD核心，并且发现Serial.print没有输出到USB，那么你需要将代码中的Serial替换为SerialUSB。一个更稳妥的、兼容两种核心的写法是在代码开头添加预处理指令：

#if defined(ARDUINO_SAMD_ZERO) && defined(SERIAL_PORT_USBVIRTUAL) && !defined(ADAFRUIT_FEATHER_M0) // 如果是官方SAMD核心且定义了USB虚拟端口，且不是Adafruit Feather M0（其核心已修复） #define Serial SERIAL_PORT_USBVIRTUAL #endif void setup() { Serial.begin(115200); // 现在这个Serial在所有情况下都指向USB了 // ... }

3.4 内存与存储：PROGMEM成为过去式

在AVR上，SRAM很小，我们经常需要用PROGMEM关键字把常量字符串或数据表存放到Flash中，以节省宝贵的RAM。使用时还需要用pgm_read_byte这样的特殊函数来读取。

在32位的ARM Cortex-M上，得益于更大的内存空间和更先进的编译器，事情简单多了。你只需要在常量声明前加上const关键字，编译器会自动将其分配到Flash中。而且，你可以像访问普通RAM数组一样直接使用它，编译器会生成正确的代码从Flash读取。

// AVR上的旧写法（在ARM上也可用，但繁琐） // const char message[] PROGMEM = "A very long string..."; // char myChar = pgm_read_byte(&message[0]); // ARM上的推荐写法（简洁，且兼容AVR） const char message[] = "A very long string saved in Flash, not RAM!"; Serial.println(message); // 直接使用，无需特殊函数

如果你想确认变量是否真的被放到了Flash里，可以打印它的地址。Flash地址通常从0x0000开始，而SRAM地址则从0x20000000开始。

3.5 缺失的头文件与平台判断

一些为AVR高度优化的库，可能会直接包含AVR特有的头文件，比如<avr/pgmspace.h>或<util/delay.h>。这些头文件在ARM的核心库中不存在，直接包含会导致编译错误。

解决方案：使用条件编译（#ifdef）来包裹这些平台特定的代码。

// 假设你有一段代码需要用到AVR特有的延时函数 #if defined(__AVR__) #include <util/delay.h> #define myDelayMs(ms) _delay_ms(ms) #else // 对于ARM或其他平台，使用Arduino通用延时 #define myDelayMs(ms) delay(ms) #endif

这样，代码在AVR和ARM平台上都能正确编译。在移植第三方库时，这是一个非常常见的修复点。

4. 无线通信实战：集成RFM69模块的完整流程

无线功能是很多物联网项目的核心。Adafruit的Feather系列很多都预留了RFM69/95等无线电模块的焊盘，甚至直接推出了集成RFM69的“Feather with RFM69”版本。这里以最常用的RFM69HCW（433MHz或915MHz）为例，讲解从硬件确认到代码跑通的完整过程。

4.1 硬件确认与连线

首先，分清你的模块是“Breakout”（分线板）还是“FeatherWing”（翅膀板），或者是“All-in-One Feather”（一体板）。这决定了连线方式。

  • 一体板：如Adafruit Feather 32u4 RFM69HCW，无线电模块已集成，无需额外接线，但需要注意板载天线是否已焊接。
  • FeatherWing：直接插在Feather开发板上，通常使用特定的引脚（如Feather 32u4的引脚11, 12, 13用于SPI，引脚10作为CS，引脚6作为IRQ等）。你需要查看对应Wing的说明书。
  • Breakout板：需要你自己用杜邦线连接。核心连接是SPI总线：
    • MISO-> 开发板的MISO引脚
    • MOSI-> 开发板的MOSI引脚
    • SCK-> 开发板的SCK引脚
    • CS/SS-> 选择一个数字引脚作为片选（如引脚10）
    • RST-> 选择一个数字引脚作为复位（如引脚11）
    • GND-> GND
    • VIN-> 3.3V (切记，RFM69是3.3V逻辑，绝对不能接5V！)
    • IRQ/DIO0-> 选择一个支持中断的数字引脚（如引脚2）

注意事项：务必确认频率匹配！一个915MHz的模块无法与433MHz的模块通信。天线也要匹配对应频率，长度不对会严重影响通信距离。

4.2 库的选择与安装

对于RFM69，社区有两个主流的Arduino库：LowPowerLab的RFM69库和AirSpayce的RadioHead库。RadioHead库的优势在于它支持非常多的无线电模块（RFM69, RFM95, SI4432等），且API统一，便于项目后期更换无线方案。Adafruit的教程也主要基于RadioHead库。

安装RadioHead库：

  1. 从Adafruit的GitHub仓库下载RadioHead库（确保是Adafruit维护的版本，通常对Feather系列兼容性更好）。
  2. 在Arduino IDE中，点击“项目”->“加载库”->“添加.ZIP库...”，选择你下载的ZIP文件。
  3. 或者，将解压后的“RadioHead”文件夹手动复制到你的Arduino Sketchbook目录下的libraries文件夹中。
  4. 重启Arduino IDE。

4.3 关键配置：频率、引脚与功率

打开RadioHead库中的示例：RadioHead -> examples -> feather -> RadioHead69_RawDemo_TX（发射端）和RadioHead69_RawDemo_RX（接收端）。

在代码开头的配置部分，有三处必须根据你的硬件进行修改：

  1. 频率：

    #define RF69_FREQ 915.0 // 改为你的模块频率，如434.0

  2. 引脚定义：这是最容易出错的地方。示例代码通常用#ifdef来为不同开发板预定义引脚。你需要找到匹配你板子的那段代码，或者自己定义。

    // 例如，对于Feather M0 RFM69 #elif defined(ADAFRUIT_FEATHER_M0) || defined(ADAFRUIT_FEATHER_M0_EXPRESS) || defined(ARDUINO_SAMD_FEATHER_M0) #define RFM69_CS 8 #define RFM69_INT 3 // 必须是中断引脚！Feather M0上引脚2, 3等支持中断。 #define RFM69_RST 4 #define LED 13 // LED_BUILTIN

    务必检查RFM69_INT引脚在你的板子上是否支持外部中断。可以参考对应板子的引脚图。

  3. 发射功率：

    rf69.setTxPower(20, true); // 参数1: 功率等级(14-20 dBm)，参数2: true表示是RFM69HCW高功率模块
    • 如果是普通RFM69（非HCW），第二个参数应为false，且功率等级范围不同。
    • 功率越大，通信距离越远，但耗电也越快。在室内或短距离测试时，可以适当调低（如17）以减少干扰和功耗。

4.4 初始化与通信测试

在setup()函数中，库会完成无线电模块的初始化。成功后，发射端会每隔一秒发送一个包含计数器的“Hello World”数据包，接收端收到后会回复一条消息，并打印接收信号强度指示（RSSI）。

上传与测试步骤：

  1. 分别给两个板子（一个刷TX代码，一个刷RX代码）上传程序。上传前务必确认每个板子都选对了正确的开发板型号和COM端口。
  2. 打开两个串口监视器，分别连接到TX和RX板子，波特率都设置为115200。
  3. 你应该能在RX端的串口监视器看到不断打印接收到的消息和RSSI值（负数，绝对值越小信号越好，例如-30比-80信号强）。
  4. 同时在TX端，你会看到“Sending...”和“Got a reply”的打印，表明双向通信成功。

如果通信失败，按以下顺序排查：

  1. 电源：确保无线电模块供电稳定（3.3V），且电流充足（发射瞬间电流较大）。
  2. 频率与功率设置：确认TX和RX代码中的RF69_FREQ完全一致，setTxPower的第二个参数（是否为HCW）设置正确。
  3. 引脚连接：用万用表或代码简单测试，确认CS、RST、IRQ引脚的电平控制是否正确。特别是IRQ中断引脚，连接必须可靠。
  4. 天线：确保天线已牢固连接，并且是适合当前频率的天线。
  5. 库版本与冲突：确保使用的是Adafruit fork的RadioHead库，并检查是否有其他无线电库造成冲突。

5. 高级调试与性能调优：让M4飞起来

当你使用更强大的ATSAMD51（M4核心）板子，如Feather M4 Express时，你可能会想榨干它的性能。Adafruit SAMD Boards包在Arduino IDE的“工具”菜单里提供了一些高级选项。

5.1 CPU超频

默认情况下，M4芯片运行在120MHz。但你可以尝试将其超频到更高的频率，如150MHz、180MHz甚至200MHz，以获得更快的程序执行速度。但这是一种有风险的激进操作。

  • 潜在收益：计算密集型任务（如FFT、图像处理、复杂算法）速度提升。
  • 潜在风险：
    • 系统不稳定：在极端温度或电压波动下可能死机。
    • 外设时序错乱：严重依赖CPU时钟周期进行精确定时的库可能会出错。最典型的例子是NeoPixel（WS2812）库，其数据时序非常严格，在非120MHz下需要特殊处理或使用特定版本。
    • 功耗与发热增加。

建议：仅在需要时开启超频，并且从低一档的频率开始测试（如先试150MHz）。如果项目依赖NeoPixel、精确的PWM伺服控制或特定音频库，最好保持默认的120MHz。

5.2 编译器优化

“优化”选项改变了编译器生成机器码的策略。

  • Small (-Os)：默认选项。优化目标是程序体积最小。代码可能不是最快的，但最适合Flash空间紧张的场景。
  • Fast (-O1/-O2)：优化目标是运行速度。编译器会采用一些可能增加代码体积但能提升速度的优化策略。对于Flash空间充裕的M4（通常512KB以上），这是推荐的首选优化选项，能在不牺牲稳定性的前提下获得免费的性能提升。
  • Here be dragons (-O3/-Ofast)：“猛龙之地”，意味着冒险。启用更激进、更深入的优化。可能导致程序行为异常，因为某些优化可能会违反严格的ISO C++标准（比如对浮点数运算的重新排序）。除非你非常清楚自己在做什么，并且做了充分测试，否则不要轻易使用。

5.3 缓存与闪存加速

  • Cache：启用CPU缓存。这几乎总是应该保持启用状态，它能显著提升从Flash中读取指令和数据的速度。只有在遇到极其罕见的、与缓存一致性相关的诡异bug时，才考虑关闭它。
  • Max SPI / Max QSPI：这些选项调整SPI和QSPI（用于板载额外Flash）控制器的时钟源，以突破默认的24MHz限制。除非你完全理解其后果，否则不要动。
    • Max SPI：提高SPI时钟频率（如到60MHz），可能让TFT屏幕刷新更快。但副作用是：SPI读取操作（如读取SD卡）将完全失效。只适用于纯写入的SPI设备。
    • Max QSPI：提升板载QSPI Flash的访问速度。对于大多数不频繁访问外部存储的程序，提升感知不明显。

调优策略：对于大多数应用，保持“CPU Speed”为120MHz，将“Optimize”改为“Fast”，其他保持默认，就能获得一个很好的性能与稳定性的平衡点。在最终发布固件前，务必在整个项目的功能范围内进行充分测试。

6. 疑难杂症速查表

以下是一些常见问题及其快速解决方案的汇总：

问题现象可能原因解决方案
上传时提示“avrdude: butterfly_recv(): programmer is not responding”或类似错误1.开发板型号选错（最常见）。
2. 串口被其他软件占用。
3. 引导程序损坏。		1.仔细核对并选择正确的开发板型号。
2. 关闭其他串口监视器、调试工具。
3. 尝试手动双击复位上传。
代码上传成功，但串口监视器无输出1. 代码中未初始化Serial或波特率不匹配。
2. 使用了官方SAMD核心但未用SerialUSB。
3. 程序崩溃，未运行到串口输出部分。		1. 检查setup()中是否有Serial.begin(波特率)。
2. 尝试将Serial替换为SerialUSB，或添加兼容性宏定义。
3. 简化代码，先只测试Serial.println(“Test”);。
COM端口时有时无，或在设备管理器中消失用户程序崩溃或未正确创建USB CDC端口。1. 检查程序是否有死循环、数组越界等bug。
2.双击复位按钮，使板子进入引导模式（红灯呼吸闪烁），此时会出现一个固定的引导程序COM口，可尝试上传一个已知正常的程序（如Blink）。
PWM输出不正常，或analogWrite(255)不是纯高电平ARM架构的analogWrite分辨率是256级，255对应~99.6%占空比。需要绝对高电平时，使用digitalWrite(pin, HIGH)。
编译错误：fatal error: util/delay.h: No such file or directory代码或库中包含了AVR平台特有的头文件。使用条件编译#ifdef __AVR__包裹该头文件包含语句，或在非AVR平台提供替代实现。
RFM69通信失败，接收端无数据1.TX/RX频率不一致。
2.引脚定义错误，特别是CS和IRQ引脚。
3.电源问题，发射时电压被拉低。
4. 天线未接或损坏。
5. 加密密钥不一致。		1. 检查双方代码中的RF69_FREQ。
2. 对照原理图，确认代码中RFM69_CS,INT,RST定义与实际接线一致。
3. 使用万用表测量模块VCC脚，在发射时电压是否稳定在3.3V。
4. 确保天线连接牢固且频率匹配。
5. 检查双方setEncryptionKey的密钥数组是否完全相同。
程序运行一段时间后死机1.内存泄漏或堆栈溢出，在ARM上同样需要关注。
2. 数组访问越界，破坏了内存。
3. 中断服务程序(ISR)处理时间过长或做了不该做的操作（如delay）。		1. 使用FreeRam()函数监控内存变化。
2. 严格检查数组索引。
3. 遵循ISR编写原则：快进快出，使用标志位，在主循环中处理耗时任务。
读取模拟电压值（如电池电压）不准确1. 模拟参考电压（ARef）设置问题。
2. 在M0/M4上，使用了AR_EXTERNAL而非EXTERNAL。
3. 引脚冲突，某些引脚在特定功能下无法用于ADC。		1. 默认使用3.3V作为参考。如需使用外部参考，使用analogReference(AR_EXTERNAL)。
2. 检查板子引脚图，确认所用模拟引脚没有被其他功能（如PWM、串口）占用。

开发本身就是一个不断遇到问题、解决问题的过程。尤其是在嵌入式领域，硬件和软件的交叉点众多，一个看似软件的问题，根源可能在硬件配置。我的经验是，保持耐心，进行系统性排查：从最基础的电源和连线开始，确认开发板型号和端口选择，然后检查代码中的关键配置（频率、引脚），最后再深入到程序逻辑和库的兼容性。养成在代码中添加详细串口日志的习惯，它能帮你快速定位问题发生的阶段。多利用社区资源，但提问时尽量提供详细的信息：你用的具体板子型号、Arduino IDE版本、库版本、完整的错误信息以及你已经尝试过的步骤。这样，你不仅能更快地得到帮助，也能更深刻地理解问题背后的原理。

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/6/14 2:29:51

OAuth 中的 client_id 与 client_secret 深度解析

一、本质定义 在 OAuth 2.0 协议中&#xff0c;client_id 和 client_secret 是客户端凭证&#xff08;Client Credentials&#xff09;&#xff0c;用于在授权服务器&#xff08;Authorization Server&#xff09;上唯一标识和验证一个已注册的第三方应用。字段类比作用client_…

作者头像 李华
网站建设 2026/5/15 9:14:27

基于单片机的教室节能控制系统（有完整资料）

编号&#xff1a;CJL-51-2022-005设计简介&#xff1a;本设计是基于单片机的教室节能控制系统&#xff0c;主要实现以下功能&#xff1a;1.通过蓝牙控制灯具开关。 2.通过人体红外检测是否有人经过&#xff0c;检测到没有人延迟一段时间关闭 3.通过红外对管检测教室人数&#x…

作者头像 李华
网站建设 2026/5/15 9:07:14

OpencvSharp 算子学习教案之 - Cv2.Accumulate

OpencvSharp 算子学习教案之 - Cv2.Accumulate 大家好&#xff0c;Opencv在很多工程项目中都会用到&#xff0c;而OpencvSharp则是以C#开发与实现的Opencv操作库&#xff0c;对.NET开发人员友好&#xff0c;但很多API的中文资料、应用场景及常见坑点等缺乏系统性归纳&#xff…

作者头像 李华
网站建设 2026/5/15 9:05:25

Ollama本地大模型部署指南：从入门到精通的完整实践

1. 项目概述&#xff1a;为什么Ollama能成为本地大模型的首选最近两年&#xff0c;大语言模型&#xff08;LLM&#xff09;的热度居高不下&#xff0c;但很多朋友在实际尝试时&#xff0c;往往会遇到一个门槛&#xff1a;要么需要联网调用API&#xff0c;存在隐私和成本顾虑&am…

作者头像 李华
网站建设 2026/5/15 8:51:06

ColorUI：15分钟打造高颜值小程序的色彩魔法指南

ColorUI&#xff1a;15分钟打造高颜值小程序的色彩魔法指南 【免费下载链接】coloruicss 鲜亮的高饱和色彩&#xff0c;专注视觉的小程序组件库 项目地址: https://gitcode.com/gh_mirrors/co/coloruicss 想让你的小程序在众多应用中脱颖而出吗&#xff1f;ColorUI正是你…

作者头像 李华