djarmy-优快云博客

原创烧录程序后不停重启警告解读：`文件大小超出程序区范围,超出部分已被自动移到EEPROM区！

STC8G1K08芯片Flash仅8KB（0x0000–0x1FFF），但编译后代码达8427字节，超出235字节导致函数被链接至EEPROM区，无法执行指令，引发程序不停重启。问题根源为SPST_button1_on等函数地址超限（如0x2070H），CPU取指失败后跑飞至低端启动代码。解决方法：1）屏蔽未调用的combinationFunc1函数（用#if 0/#endif包裹）；2）将Keil优化改为“最小代码”模式（Level 9 + Favor Code Size）。修复后需确保code≤8192

2026-09-14 08:16:00 332

原创 MAIN.c(1): warning C318: can’t open file ‘STC8G.H’ 报错解决分析

编译STC8G1K08-38I-TSSOP20时出现warning C318: can't open file 'STC8G.H'，因Keil找不到头文件。解决方法：以管理员身份运行STC-ISP，进入【Keil仿真设置】，点击“添加STC单片机到Keil中”，选择Keil安装目录（如D:\software\KEILC51），系统将自动复制STC8G.H至C51\INC\STC。随后在Keil中配置Include Paths为C:\Keil_v5\C51\INC\STC，即可成功包含头文件并消除警告。校验路

2026-09-09 18:19:36 152

原创 Cannot convert undefined or null to objectThe “path“ argument must be of type string 报错 ESP-IDF

报错环境：插件安装好esp-idf 后，打开下载好的zip文件进行解压后，进行打开。操作步骤：由于上述截图矩形框1：原先显示“ESP-IDF-xxx” ，这代表是不确定具体版本。此时点击矩形框2：就会出现如下报错：报错截图：报错文本：Cannot convert undefined or null to object------解决步骤：先。

2026-08-30 16:03:40 238

原创 ..\..\Output\atk_h743.axf: Error: L6218E: Undefined symbol SystemInit 解决

摘要：在Keil5中进行STM32H743 USART1串口通信实验时，出现链接错误L6218E，提示SystemInit、D1CorePrescTable等符号未定义。根本原因是工程未包含system_stm32h7xx.c文件，该文件不仅提供SystemInit()函数，还定义了时钟相关的全局变量和数组。解决方法是将该文件加入工程编译。需注意： L6218E错误可能由缺失函数或全局变量引发； H7基础工程必须包含system_stm32h7xx.c、stm32h7xx_hal.c等核心文件；仅包含头

2026-08-21 14:06:56 258

原创：DMA 的中断，和普通的其它中断存在区别？前者不占用 CPU，后者占用 CPU？还是说所有的中断到底哪些占用 CPU？还是怎么区分。

文章摘要： DMA中断与普通中断在触发后均需占用CPU执行中断服务程序（ISR），核心区别在于触发频率与ISR耗时。DMA的优势在于硬件自动搬运数据时CPU零参与，但传输完成触发的中断仍需CPU响应，机制与其他中断相同。CPU占用差异源于中断触发频次（如DMA批量处理减少中断次数）及ISR代码效率（轻量操作开销低）。所有中断均遵循“触发即占用CPU”的规则，实际负载取决于应用场景设计（如ADC采样使用DMA可大幅降低中断次数）。优化方向是减少中断频率并精简ISR逻辑。

2026-08-08 22:07:15 424

原创不能修改芯片底层寄存器驱动逻辑如果你的产品需要极致定制射频、底层功耗硬核调校，Hi3861 不合适；

摘要：报告证实hi_gpio_init()函数无法查看源码的根本原因是其实现位于海思提供的预编译二进制库中（build/libs/libbsp_base.o），而非开源代码中。通过头文件分析、全工程源码搜索、编译产物验证及构建系统检查，确认该函数及其相关GPIO操作接口均由闭源的libbsp_base.o提供，属于海思SDK的未开放部分。构建系统通过GN和SCons将预编译库链接到最终固件，导致开发者无法查看或修改底层实现。

2026-06-23 22:21:43 306

原创 Claude + DeepSeek 合体教程：连桌宠都给你安排上了！

本文介绍了使用Claude Code（基于DeepSeek）开发桌面电子宠物猫的完整流程。项目采用Python+Tkinter实现，包含矢量绘制猫咪、自主行为AI、互动控制等功能。文章详细解析了代码生成与写入过程（如自动生成652行的cat_pet.py）、测试运行命令以及核心技术栈（Tkinter透明窗口、Canvas绘图、事件监听等）。同时解释了Claude Code中的趣味状态词（如"Schlepping"表示处理繁重任务），并提供了项目目录结构、安全机制说明和核心功能实现原理。开发过程展现了AI辅助

2026-05-20 13:18:56 511

原创一级函数头地址指针，(p_func)的函数头的返回值，(p_func)的函数头的参数列表

摘要：本文深入解析了C语言函数指针的底层原理，明确指出函数入口地址存储在Flash/ROM而非RAM中，函数名本身就是地址常量。文章通过实例验证了函数指针的类型匹配要求，展示了类型不匹配时的GCC报错信息（"incompatible pointer type"），并揭示了函数指针作为指向Flash地址的一级指针本质。最后总结了5个关键结论，包括函数存储位置、地址特性、类型匹配原则等，确认读者已达到嵌入式开发的中高级理解水平，并预告了更深入的扩展内容。全文以精准的技术语言和底层视角，系统性地解答了关于函数地址

2026-05-19 19:19:43 204

原创 C 标准库 `＜stdio.h＞` 完整函数清单（官方标准 + 常用全部函数）

C标准库<stdio.h>核心函数摘要 C17标准中<stdio.h>包含31个函数，涵盖文件操作和输入输出功能。高频使用15个核心函数包括：控制台I/O：printf/scanf（格式化）、getchar/putchar（字符）、puts（字符串）文件操作：fopen/fclose（打开关闭）、fgets/fputs（文本读写）、fread/fwrite（二进制）指针控制：fseek（定位）、rewind（复位）、fflush（刷新缓冲）状态检测：feof（文件尾判断）这

2026-05-11 21:54:44 424

原创哪些海外国家最可能落地矿鸿/OpenHarmony矿山方案？1. 资源型发展中国家（最优先）

2. 矿鸿的核心技术：分布式互联、实时调度、设备统一接入、工业安全，全部基于 OpenHarmony 开源底座，海外完全可以照搬、本地化适配。1. 分布式软总线：不同厂商、不同协议的井下设备（采煤机、运输机、传感器、摄像头、瓦斯监测、机器人），打破协议壁垒，统一组网、统一管控。技术上100%可行，开源无限制；煤矿的防爆、安全、监管、井下规范，中国、俄罗斯、澳大利亚、南非、印尼完全不一样，需要大量本地化适配、认证，成本极高。煤矿井下、露天矿的设备统一互联、统一调度、无人化、少人化、安全生产、提效降本。

2026-05-10 11:43:17 296

原创所有通信协议，上层包装再花哨，底层全是字节流。你看到的 char*，就是字节流的标准载体。

通信协议的本质所有通信协议（IIC、SPI、UART、蓝牙等）的底层传输都是0/1比特流，最终以字节（char*/uint8_t）形式呈现。核心流程为：发送数据→解析判断→执行对应函数。虽然常以char*表示，但准确说是二进制数据流而非字符串。协议的本质是约定数据格式，中断仅通知数据到达，真正的解析由后续代码完成。专业表述为：二进制数据交换+协议帧解析+命令分发。无论协议多复杂，最终都简化为if-else判断执行不同函数。这种理解已达到驱动工程师的核心思维水平，看透了通信的本质。

2026-05-03 00:30:36 376

原创拆解实训设备箱小鸿ai硬件：和小智 AI 的差异与鸿蒙生态价值

本文围绕 AtomGit 发布的开源鸿蒙 AI 硬件「实训箱设备小鸿ai硬件」展开分析，结合其 WS63+CI1302 方案、OpenHarmony LiteOS-A 架构、模块化磁吸设计等核心特征，对比了它与消费级小智 AI 的定位差异，明确其面向教学实训、鸿蒙生态开发的核心价值，同时指出其在用户体验层面暂无颠覆性创新的局限，是一款面向开发者的、有明确技术补位意义的鸿蒙实训平台。

2026-04-28 21:08:54 301

原创 openharmony分布式软总线，借鉴点

摘要：分布式软总线是组合式创新，将传统硬总线的通信模型与分布式网络技术结合，通过软件协议栈替代物理线路，实现多设备资源池化与无感协同。其创新性体现在SCAMPER工具的7个改造维度（如替代、组合、去除冗余等），核心价值在于降低部署成本、提升灵活性，并抽象硬件能力为共享资源。相比NFS、远程桌面等传统方案，它突破客户端-服务器模型，以P2P网络实现原子化资源调用，优化延迟与体验。判断技术真伪需从底层逻辑、技术实现、场景价值、行业影响四步分析，分布式软总线解决了跨设备通信的高成本与低效痛点，属于优化型创新而非

2026-04-25 22:59:42 367

原创 Ubuntu Touch / PureOS / PostmarketOS 太小众 - Linux 桌面发行版（Ubuntu、Debian、CentOS）根本不是移动端生态，完全没法挑战安卓

摘要：本文分析了安卓与OpenHarmony开源模式的本质相似性，指出两者都存在底层开源但核心服务闭源的垄断风险。OpenHarmony的战略价值在于打破谷歌单极垄断，形成移动端双强格局。文章提出理想状态应是三权分立：安卓（谷歌）、鸿蒙（华为）和第三个真正中立的开源系统共同制衡。这个"全球公共操作系统"需具备多内核支持、全开源服务框架和兼容现有生态等特点，才能实现不被卡脖子、公平竞争的移动生态。当前移动端仅有安卓和鸿蒙两大体系仍不足以保证安全，未来需要第三极形成三足鼎立之势。

2026-04-13 16:50:54 595 1

原创 GMS / HMS 是整个生态的 “命根子”，谁开源谁就放弃控制权

OpenHarmony开源生态的战略价值与落地挑战核心摘要：技术构成：OpenHarmony基于80%Linux等开源技术+20%自研创新（分布式总线/KAL/HDF框架），采用合理的技术集成策略而非抄袭。战略本质：通过完全自主的架构设计+开源Linux底座，实现系统主导权掌控，建立不受制于人的数字安全基座，其战略安全性＞短期功能性。生态现状：开源部分仅含操作系统骨架（Apache 2.0协议），不含HMS级服务层，其他厂商需自建账号/商店/推送等全套服务体系，投入需数百人团队+3-5年周期。落地

2026-04-13 16:28:14 567

原创 OpenHarmony 全架构一张图看懂我把 59 个子系统 → 浓缩成 7 大层，严格按源码真实结构分层，嵌入式工程师必须背下来。

并按分层整理，让你。

2026-04-07 21:20:04 599

原创芯片是“底子”，手册是“说明书”，头文件是“代码翻译器”； 2. 三者必须严格匹配芯片型号，差一个字母/数字都不行；

这篇文章探讨了单片机寄存器操作的底层机制，重点解析了寄存器地址映射与数据写入的区别。核心观点包括：寄存器操作顺序问题：代码执行顺序≠硬件生效顺序，先写电平只是暂存值，后配模式才会生效。寄存器地址映射本质：CPU只认硬件地址，P1等名称是编译器通过sfr关键字映射的"别名"。 sfr关键字详解：它是51单片机专用关键字，用于将寄存器名称绑定到固定硬件地址（如sfr P1=0x90），不同于普通变量。 16进制数的双重含义：在sfr定义中表示硬件地址（固定），在赋值语句中表示可修改的数据

2026-03-21 12:17:12 516

原创其他大厂不是做不到，是不想做高转是噱头属性强，日常体验提升有限。

而其他大厂不是做不到，是路线、定位、成本、量产优先级不同。要不要我把V8S与比亚迪30511rpm电机做一份技术细节对比表（材料、结构、散热、成本、适用场景），让你一眼看清两家的路线差异。◦ 特斯拉/比亚迪/华为：更均衡，优先效率、可靠性、成本、量产规模，转速够用即可（20000–22000rpm）• ✅ 你对：V8S的高转，材料/工艺/人才都来自行业，小米是“集成者+定义者”，不是原创发明者。◦ 小米：单点冲极限转速，主打性能、赛道、极速（300km/h），不计成本做材料/结构/散热。

2026-03-20 19:55:55 262

原创量子计算必然走向边缘+终端+云端的分布式架构，而oh是目前唯一面向全场景的分布式

1. 技术趋势：量子计算必然走向边缘+终端+云端的分布式架构，而 OpenHarmony 是目前唯一面向全场景的分布式开源底座。目前确实没有成熟产品，但从技术架构、产业趋势、硬件演进看，这条路是可落地、有依据、有明确前提的。OpenHarmony 不是“能不能”和量子结合，而是“最应该、最适合”和量子结合的操作系统。• 量子计算会破解 RSA/ECC，OpenHarmony 必须升级为后量子安全（PQC）• 佐证：IBM、本源量子已推出经典-量子混合架构，OpenHarmony 可基于此扩展。

2026-03-16 17:16:31 393

原创 ubuntu20.04搭建openharmony6.0的master分支。构建编译环境报错解决记录

总览依据URL链接:步骤依据：成功安装20.04的Ubuntu系统完整四期视频步骤完成：url如截图链接:按照步骤一个一个校验并且执行。针对dt的安装依据安装步骤：在Firefox浏览器通过url下载依照nodejs环境下一步安装截图这个过程报错如下：成功解决依据：按照视频教程走成功建立连接ssh。使用DevEco Device tool拉取源码在 /usr/bin 目录下创建一个叫 python 的 “快捷方式”，这个快捷方式指向系统里本来就有的 python3 命令。

2026-03-15 13:06:33 682

原创 OpenHarmony 6.0 对编译环境的兼容性要求很严格，Ubuntu 20.04 是 OpenHarmony 官方推荐的编译系统版本，而 Ubuntu 22.04 确实存在不少兼容性问题

删除Ubuntu22.04重新下载20.04的Ubuntu系统进行重新搭配openharmony6.0 !!! 吐血了

2026-03-12 11:20:43 486

原创选苹果：追求稳定、长期流畅、隐私、纯苹果设备、不折腾• 选华为：要车家深度打通、跨设备流转、跨品牌兼容

要不要我把上面的对比浓缩成一页“快速决策清单”，-----------------------------• 中国·华为人车家全生态：开放、跨设备深度流转、车联极强、智能家居覆盖广、本地化无敌。• 美国纽约·苹果全生态：封闭、稳定、细节拉满、车联弱、智能家居成熟但设备少。• 设备：HomePod、Apple TV、门锁、摄像头、灯；• 选华为：要车家深度打通、跨设备流转、跨品牌兼容、本土化体验、万物互联。• 差异本质：苹果是云同步+封闭闭环；• 设备：美的、海尔、九阳、TCL等300+厂商，覆盖全品类。

2026-03-09 16:55:31 380

原创 OpenHarmony 整体：To B/G 远大于 To C

• 2024年规模：OpenHarmony 产业链约 237亿元，其中 To B/G 占比超80%（≈190亿元），To C 不足20%（≈47亿元）• 典型业务：政务终端、工业平板、教育设备、电力/金融/交通定制方案，不做消费级手机/PC。典型产品手机、平板、手表、智慧屏、车机工业平板、电力终端、政务设备、物联网网关。赚钱方式卖硬件、服务、云、生态分成 OS 授权、项目定制、开发服务、运维。技术方向应用开发、框架、UX、多媒体驱动、BSP、移植、行业定制、适配。

2026-03-09 16:31:52 625

原创 HarmonyOS整理一份超级终端常见场景的行为对照表，比如“手机看视频投屏到电视”、“手机导航流转到车机

你的观察非常细致，这个问题正好触及了 HarmonyOS 超级终端设计的核心逻辑：它不是简单的“投屏”或“应用迁移”，而是基于分布式能力的“能力调用”和“资源共享”。• 系统行为：超级终端会识别到当前App（阅读App）的主要能力是“显示文本”，而音响不具备这个能力，因此不会提供“流转”或“投屏”的选项。所以，当你把音响拉进超级终端时，它并不是要“接管”你的阅读App，而是作为一个可用的音频输出资源，随时准备被系统或你的操作调用。• 结果：手机继续显示电子书，音响保持静默，等待你的下一个指令。

2026-03-09 15:46:44 302

原创鸿蒙智选复用车型的适配周期：6–8个月，比如h5

我直接给你做一张全网可查证、最清晰的对比表，把你最关心的「从合作/签约 → 上市量产用了几个月」全部算清楚，全部是公开真实时间线。品牌首款车型签约/合作时间正式上市/量产周期（月）模式说明。• 品牌+车型官宣：2025年4月16日（尚界H5首次亮相）• 鸿蒙智选复用车型的适配周期：6–8个月（行业最佳实践）• 签约：2025年2月21日（上汽+华为深度合作协议）• 签约 → 正式上市/量产：约 6.3个月（192天）• 从签约到量产：6–8个月（尚界是6.3个月，典型值）

2026-03-09 10:01:09 517

原创基于openharmony系统确实在做 PC/笔记本系统，但只做政企/信创/工业/开发者市场，不碰华为 HarmonyOS 的消费 PC 赛道。

• 他们确实在做 PC/笔记本系统，但只做政企/信创/工业/开发者市场，不碰华为 HarmonyOS 的消费 PC 赛道。• 他们做 PC/笔记本，但只做政企/信创/工业/开发者，避开华为消费 PC 赛道。• 华为 HarmonyOS 已占据消费 PC 生态位，有品牌、渠道、应用生态优势。• 生态厂商 OpenHarmony PC：主打信创、政务、工业、教育、开发者。• 例：电力终端、矿山设备、政务一体机、金融 POS、安防摄像头。• 芯片适配、内核裁剪、驱动开发、安全加固、OTA 升级。

2026-03-05 21:59:11 913

原创 openharmony系统门禁 → 99% 是本地离线识别

我直接用最通俗、最贴近你这个RK3568人脸识别门禁的场景，把要不要联网、存本地还是云端、用eSIM还是离线讲清楚，同时给你OpenHarmony 下的最佳实践方案。3. RK3568 算力足够跑本地轻量级人脸识别模型（如 FaceDetect、MNN、NCNN 等）。五、OpenHarmony + RK3568 最佳实践（直接给你最终方案）一、先给结论：你说的这种门禁 → 99% 是本地离线识别。三、那它到底要不要联网、要不要eSIM？• 人脸在本地录入、本地比对、本地开门。

2026-03-05 21:42:48 369

原创基于 Openharmony 系统的底座的系统的主流外包公司

先说明：国内九大IT外包公司并无统一官方榜单，以下按主流头部外包公司口径整理，仅列出有公开自研OpenHarmony基座系统的企业；• 资料：OpenHarmony发起单位、代码贡献前三；• 中电金信（文思海辉）：仅做HarmonyOS应用开发平台（源启），无OpenHarmony自研OS。• 博彦科技：仅做鸿蒙应用开发平台（BROS），无OpenHarmony自研OS底座。• 东软集团：仅做OpenHarmony应用/实训方案，无自研OS底座。二、其余头部外包公司（无公开自研OpenHarmony底座）

2026-03-05 21:29:56 369

空空如也

空空如也