嘉立创社区
发动态
综合 最新发布 最新回复
图文
列表
置顶
【体验送券活动来咯】
使用ESP32-WROOM，制作一款产品，麻烦有画pcb和写代码的人员联系我。
开源硬件平台
MCP 出生时，被捧得很高。2024 年 11 月，Anthropic 发布"模型上下文协议"，几乎所有 AI 开发者社区都在讨论这件事。它的定位很诱人，要成为大模型和外部工具之间通信的"通用标准"，有点像当年 HTTP 对 Web 的意义。一时间，MCP server 满天飞，各种集成教程、开源实现层出不穷。但时间只过了一年多。上周，Perplexity 的联合创始人兼 CTO Denis Yarats 在内部表示，他们正在放弃 MCP，转而改用 API 和 CLI。这个消息扩散出来后，引发了一波讨论，但讨论的内容不是"为什么"，而是"早该如此"。Y Combinator 的总裁兼 CEO Garry Tan 甚至直接说了一句话："MCP sucks。"MCP 的问题从来都不是技术实现不够好很多人对 MCP 的质疑，停留在"不稳定"、"认证烦"这些体感上的抱怨。这些问题确实存在，但它们只是表象。MCP 真正的困境，是一个结构性问题。MCP 的工作方式是，把工具的名称、描述、参数结构（Schema）以及使用示例，全部注入到 Agent 的上下文窗口里。Agent 读完这些信息，再决定要调用哪个工具。这个设计在工具数量少时还可以接受。但你一旦接入 10 个服务，每个服务有 5 个工具，光是工具定义本身就已经烧掉了几千个 token。Agent 还没开始干活，上下文就已经塞满了一半。上下文窗口是 Agent 最宝贵的资源，它决定了 Agent 能看见多少对话历史，能保留多少工作记忆，能有多大的推理空间。MCP 的代价，是把这个资源拿来"列菜单"。面对这个问题，现有的出路只有三条：一次性加载所有工具，接受推理性能下降限制接入工具数量，接受 Agent 能力边界收窄构建动态工具加载机制，接受额外的延迟和复杂度三条路都不好走。这不是"实现质量"的问题，而是协议设计本身的代价。除此之外，日常使用中的痛点也不少。MCP server 启动失败是家常便饭，有时重试能解决，有时必须推倒重来。接入多个服务就要在每个服务上重新认证一遍。权限管理也只有"允许"和"不允许"两档，没有办法把某个工具限制为只读，也没有办法约束它可以传什么参数。技术大厂，前端-后端-测试，全国均有机=会，感兴趣可以试试。待遇和稳定性都还不错~CLI 是更好的答案，不是因为它新，而是因为它够旧工程师 Eric Holmes 写过一篇文章，观点直接：MCP 没有带来任何实际价值，LLM 完全可以自己搞懂怎么用 CLI。这话有点刺，但它说的是实情。大模型在训练时看过海量的 man 手册、Stack Overflow 回答和 GitHub 上的 Shell 脚本。它们对 CLI 的理解，远比对某个 MCP server 的理解深得多。给它一个命令行工具和一份文档，它就能上手，不需要特殊适配。CLI 在几个关键点上，比 MCP 天然占优。第一是可调试性。当 Claude 对 Jira 执行了一个出乎意料的操作，你可以直接跑同一条 jira issue view 命令，看看它看到了什么。输入一致，输出一致，没有谜团。但 MCP 的调用只发生在 LLM 的对话内部，出问题了只能去翻复杂的 JSON 传输日志。第二是可组合性。这是 CLI 的核心竞争力。你可以用 jq 过滤数据，用 grep 串联逻辑，把输出重定向到文件。这不只是方便，很多时候这是唯一可行的路。MCP 没有这个能力，你要么把完整数据塞进上下文，要么在 server 端自己写过滤逻辑，两种方式都在用更多的精力换取更差的结果。第三是认证。CLI 复用的是系统级别的认证体系，这套东西已经经过几十年的打磨。MCP 需要你重新为每个工具搭一遍认证流程。这件事说明了什么Perplexity 放弃 MCP，以及其他工具陆续移除 MCP 支持，这件事背后有一个更值得思考的信号。给 AI 构建工具链，不需要发明一套新的协议。AI 需要的工具，和人类需要的工具，在很多时候是同一套。最好的工具是对人类和机器都好用的工具。CLI 存在了几十年，设计上一直遵循一个哲学，每个工具做好一件事，然后把工具组合起来解决复杂问题。这套哲学放到 Agent 身上，依然成立。MCP 想构建一个更"现代"的抽象层，但它解决的问题，现有工具已经解决得够好了。在不需要额外抽象的地方强行加一层，带来的只有额外的成本和复杂度。当然，MCP 不会完全消失。在某些特定场景，比如需要强类型 Schema、有严格访问控制要求的企业内部系统，它依然有它的位置。但作为"AI 工具集成的通用标准"，这个定位恐怕很难站稳了。参考：MCP is Dead, Long Live the CLIDenis Yarats on X——转载自：Moment
从爆红到被嫌弃，MCP 为什么开始失宠了
开源硬件平台
提到 JetBrains，相信程序员和开发者们都再熟悉不过了。作为一家全球领先的软件开发工具提供商，他们打造的多款编程软件曾经都深受全球万千开发者喜爱。但是，伴随 AI Coding 的加速冲击，这家公司的很多产品策略，如今也在被迫作出各种调整。这不就在前几天，JetBrains 在其官博里又官宣了一项重大的软件服务调整，那就是：将正式停服 Code With Me 软件服务。提到 Code With Me 这项服务，不知道有没有同学用过。还记得 JetBrains 刚推出那会，还是他们新版的引以为傲的一个功能服务。Code With Me 是一个实时协同编程工具，主要用于协作开发与结对编程，旨在让开发工作突破空间限制，实现多人高效协同。它能够使身处不同地点的开发人员，同时对同一个项目代码进行编辑和操作，以实现 Host-Guest 模式的手把手结对编程和群体编程。聊到 Code With Me 服务的诞生，其实还得追溯到前几年的口罩时期。彼时，内置配对编程和实时协作工具的需求达到高峰，这也是当时 JetBrains 推出 Code With Me 这项服务的初衷。我记得当时 IntelliJ IDEA 2021 年的首个大版本，就开箱即用地支持了 Code With Me 功能，同时它还具有音频通话和视频通话功能，可以满足随时随地的沟通需求，这操作在当时非常酷炫，也解决了很大的痛点。【顺便提一嘴】技术大厂，前端-后端-测试，全国均有机=会，感兴趣可以试试。待遇和稳定性都还不错~但是随着时间的推移，很多事情发生了变化。这次 JetBrains 决定停止对 Code With Me 的开发，主要基于以下两点原因：**第一点是需求变化。**因为该工具在口罩期间需求达到顶峰，但随着团队协作工作流的改变，如今这方面的需求已逐渐下降。**第二点则是资源配置优化。**为了将工程资源集中在能为开发者带来最大价值的领域，公司决定不再投入资源维护该插件。那针对这次的 Code With Me 服务停服，JetBrains 官方制定了明确的停运时间表，以确保用户有足够的时间过渡。JetBrains 官博表示：自 2026.1 版本发布后，Code With Me 将从所有现有 JetBrains IDE 中分离出来，并通过 JetBrains Marketplace 作为独立插件提供。同时 2026.1 也将会是官方支持 Code With Me 的最后一个 IDE 版本，后续将不再开发任何新功能。过渡期自 2026.1 至 2027 Q1，Code With Me 插件将继续在受支持的 IDE 版本上运行，并由 JetBrains 官方提供安全更新，同时对应配套的公共中继基础设施也会保持运行。最终停用会定在 2027 年第一季度，届时公共中继基础设施将被关闭，Code With Me 服务将完全停止运行。话说最近这一年，JetBrains 可谓是动作频频，在产品策略方面，该放弃的放弃，该调整的调整，目前正在大刀阔斧地对其现有软件和服务进行改造。大家还记得吗，三个月前的时候，JetBrains 才刚刚官宣其下一代 IDE Fleet 的终止开发与更新。想当初 Fleet 刚出来那会，也承载了当年 JetBrains 的厚望，号称要对标 VSC，但是最终的结局大家也看到了，还是难逃停更的结果。究其原因，还是因为如今的开发工具领域正经历根本性变化，AI 大模型等技术的突破彻底改变了 Coding 的方式。去年底 Fleet 官宣落幕的时候，官方曾明确表态，Fleet 虽然倒下，但是其背后的技术和团队并不会消失，JetBrains 将基于该基础，转而押注 Agentic Development 赛道，去开发一个新的产品。这不，也就在前些天，Jetbrains 也在其官博里正式放风了一个新产品，即：发布全新的 AI Agent IDE，名字叫做：Jetbrains Air。JetBrains Air 定位为一款桌面级应用，官方是叫它：Agentic Development Environment，专为 AI Agent 工作流而设计，并将其描述为全新一代的开发工具。Jetbrains Air 支持多智能体并发，提供隔离环境。借助 Air，用户可以将编码任务委派给多个 AI Agent，并同时运行。说白了，这玩意有点类似于之前 OpenAI 发的那个 Codex App，不过不同于 Codex App 的是，这次的 JetBrains Air 走的是开放路线，生态开放，不搞 AI 供应商绑定。Air 支持将市面上多种常见的 Code Agent，比如 OpenAI 的 Codex、Anthropic 的 Claude、Google 的 Gemini，包括 JetBrains 自己的 Junie 等，支持整合到一个连贯的工作流中，以实现精准自定义任务、独立运行任务，并借助全面的代码智能功能来查看结果。当然，Air 目前还仍处于 Public Preview 阶段，下载页面目前也仅提供 macOS 版本安装包，Windows 和 Linux 版本在后续会跟进。写到这里其实挺感慨。JetBrains 作为曾经的开发软件领域的扛把子，如今随着 AI Coding 的加速进化与冲击，这两年遇到了不小的瓶颈。包括这一次 JetBrains Air 的亮相，被不少网友讨论说是 Jetbrains 在 all in AI 路上的最后一搏，显然 JetBrains 也不想在 AI 这个赛道上掉队。但不知道为啥，越是这样，现在越给人的感觉就是，产品策略愈渐被动，产品决策也有点仓促和迷茫，说实话，这可不是什么好事啊。而且该说不说，我觉得这次 JetBrains Air 又有点发晚了，毕竟别家像 Anthropic 或者 OpenAI 这些，人家早就已经推出类似产品来占领市场了。JetBrains 这才刚刚跟进不说，搞个 App 结果目前还只发了一个 macOS 版，Windows 和 Linux 版都还没推出来……说实话，这反应速度太慢了。面对各种先进 AI 工具带来的降维打击，以及开发者编码角色和习惯的逐渐转变，JetBrains 在 AI 时代正面临着前所未有的挑战。但是没办法，在这个技术日新月异的时代，唯一不变的就是变化。而作为开发者，我们唯一能做的，就是保持开放的心态，迎接 AI 时代的新浪潮、新范式、新工具。——转载自：CodeSheep
JetBrains又一知名软件宣布倒下，五味杂陈
开源硬件平台
嘉立创对应板材的天线有没有啊
开源硬件平台
#技术干货##技术干货##技术干货##技术干货##技术干货# 比较器电路是硬件设计里很常用的一种电路，它的功能是比较两个输入端电压的大小，并且根据比较结果输出高电平或者低电平。在电压检测、过压/欠压保护、波形整形、频率测量等场景下比较器电路使用非常广泛。 在多数场景下，使用比较器需要加入一定的迟滞；如果没有迟滞，当输入信号接近比较阈值时，在噪声的作用下比较器的输出会多次翻转，导致后级电路误判；下图中绿色三角波为输入，红色方波为输出；在三角波越过比较阈值2.5V时，比较器的输出多次连续反转；如果比较器后级为MCU，很可能导致MCU连续多次误动作； 而引入迟滞电压后，输出波形明显改善，不再有连续翻转； 因为有不同的使用需求，比较器的种类也很丰富。有需要外部电阻电路的比较器，也有集成度更高不需要外围电阻的比较器。在绝大多数场景下，专用比较器价格更便宜，而且参数更优秀；只有在特定的场景下，比如系统里有多余运放，同时对速度要求又比较低的情况下，才适合用运放搭一个比较器电路，降低硬件BOM成本。 常见的比较器芯片比如LM393（安森美出品）需要用到一个运放和几个外围电阻；配合电源电压，合理设定电阻的阻值大小就能搭建一个有迟滞效应的比较器。下面介绍一下使用电阻+比较器芯片搭建迟滞比较器的原理和参数计算方法。原理解析 迟滞比较实际上就是基于正反馈做的一个闭环结构，通过在输出端与同相输入端之间引入电阻分压网络，使比较器的输出值不仅与当前输入值有关，而且与当前时刻的输出值有关；典型的反向迟滞比较器电路结构如下。 图中所选的比较器输出极为开漏输出，需要外接上拉电阻R1才能输出高电平。很多比较器都是这种输出，它的好处在于可以灵活控制输出的高电平大小；对于多数MCU可以将输出上拉的电压设定为3.3V，与MCU供电电源保持一致，方便MCU接收；对于特定电路，可以设定上拉电压与比较器供电电压不同，比如设定为5V或者更高，以符合后级电路的输入幅度要求。 图 1 原理图 待比较信号从比较器反向端输入，比较阈值结合上拉电压VCC及外围电阻值进行设定。输出特性曲线如下图所示： 图2 输出特性曲线 对于输入信号而言，电路中存在两个比较电平，VL与VH。当输入信号高于VH时，输出电平肯定会变成0；当输入低于VL时，输出肯定会变成1；（因为信号输入到比较器的反向端，所以输出逻辑和输入信号的变化趋势是相反的）。而当输入信号处于VH与VL中间时，就要依靠当前输出电平状态来判断变化曲线。如果此时输出为1，那么输入必须继续上升，直到超过电平VH时才能使输出为0，否则输出仍然保持为1；如果此时输出为0，那么输入必须继续下降，直到低于VL时才能使输出为1，否则输出仍然保持0； 之所以出现这个曲线的原因在于，不同的输出状态会影响VTH处的电压值；导致输入信号所面对的比较值不同。当比较器输出为1（高电平）时，电阻R1+R3等效于与电阻R2并联的状态，此时VTH节点电压对应于图2中的VH，也就是我们目标设计参数中的2.7V。 图3 输出高电平时等效电路 而当比较器输出为0（低电平）时，电阻R4与电阻R3成并联关系，此时VTH节点电压对应于图2中的VL，也就是我们目标设计参数中的2.4V。 图4 输出低电平时等效电路 能做图3、图4等效的原因在于，比较器的输出是开漏输出。下图是LM393的结构框图，当比较器输出高电平的时候Q16处于关断状态；而比较器输出低时Q16导通，导致输出output直接接地。 参数计算 接下来就需要根据参数需求，来设定外围电阻值。为了计算方便我们可以举一个有具体数值的例子，来看一下如何根据参数计算电阻值。假设供电电源为5V，要求设计VH电平为2.7V，VL电平为2.4V，也就是中间迟滞电平为300mV。 为了保证输出电平的驱动能力，一般选定R1的阻值比较小；我们选定R1的阻值为4.7KΩ；同时为了尽量减少静态电流降低功耗，选择R4电阻为100KΩ。接下来就要根据这两个电阻参数计算剩下的R2、R3阻值。 根据电阻串并联分压的计算方法，两个阈值电压计算公式如下： 因为R1与R4已经选定，Vcc、VH、VL这些参数已经明确，计算R2与R3就是解这个二元一次的方程组。由于电阻之间存在串并联关系，这个方程求解过程比较复杂，在实际计算时并不实用，所以有必要根据实际情况做一点简化。 图3 输出高电平时等效电路 如果我们重新观察图3的结构就会发现，对于开漏输出的比较器而言，R1的阻值相较于R2、R3、R4必须是个很小的值，这样当比较器输出电平为高时才能使输出节点Output的电压尽可能接近Vcc；对于MCU应用来说更容易被MCU管脚检测到高电平。这样在实际应用时可以忽略在VH、VL计算公式中的影响；根据这个实际应用需求，在计算过程中忽略R1的影响，可以得到R2、R3的表达式为： 带入计算公式，就可以得到R2≈95.83KΩ；R3≈766.66KΩ。选取最接近的1%标准电阻值，R2 = 95.3KΩ，R3= 768KΩ，R1取R3的1/100大小，为7.68KΩ；仿真验证 接下来我们使用LTspice进行仿真，验证参数设置是否正确。仿真中使用了MAX9095做比较器，这个比较器也是一个开漏输出；使用5V供电，输入一个5V正弦波进行比较；可以看到标线处，VL≈2.4V，VH≈2.7V； 输入输出电压扫描特性如下 我还设计了一个简易的电阻计算程序，输入供电电压，下拉电阻阻值，VH、VL电压就可以计算出剩余电阻取值，并且推荐最为接近的1%精度标准电阻值，非常简单。把刚才的设计参数VH、VL和电源电压都标注进去，就能够获得标准外围阻值； 需要的朋友可以留言索取。关于这个小程序开发还踩了很多坑，里面的代码都是AI辅助编写的，其中有很多需要注意的事项，之后有时间我再写文章发出来。
告别反复调试：比较器迟滞电阻网络计算，看这篇就够（附计算小工具）
开源硬件平台
AI8051U电脑无法识别什么情况，求助555 #Ai8051U#
开源硬件平台
有没有那位大佬可以dai zuo 一下啊，也是开源的项目，谢谢有偿
开源硬件平台
反激电源复刻，大佬们纠纠错 第一次正经画板子，即将打样前想看看哪里还有错误
6
严重问题>>高压侧线间绝缘间隙太小了,不安全,容易炸 其他问题>>光耦开槽只挡住一半,跟不开槽没区别 新手建议先不要做元件太紧凑的板子. 研究开关电源先要掌握安全规范相关知识,不然做出东西只会害人害己
开源硬件平台
我们最近刚把一个后台系统从 element-plus 切成了完全自研组件，CSS 层统一用 Tailwind。全员同意设计稿一致性提升了，但代码里怨言开始冒出来。这篇文章不讲原理，直接上代码对比和团队真实使用反馈，看看是谁在享受，谁在撑着。1.组件内样式迁移原先写法（BEM + scoped）： <template> <div class="card"> <h2 class="card__title">用户概览</h2> <p class="card__desc">共计 1280 位</p> </div> </template> <style scoped> .card { padding: 16px; background-color: #fff; border-radius: 8px; } .card__title { font-size: 16px; font-weight: bold; } .card__desc { color: #999; font-size: 14px; } </style> Tailwind 重写： <template> <div class="p-4 bg-white rounded-lg"> <h2 class="text-base font-bold">用户概览</h2> <p class="text-sm text-gray-500">共计 1280 位</p> </div> </template> 优点：组件直接可读，不依赖 class 定义样式即结构，调样式时不用来回翻缺点：设计稿变了？全组件搜索 text-sm 改成 text-base？无法抽象：多个地方复用 .text-label 变成复制粘贴【顺便提一嘴】技术大厂，前端-后端-测试，全国均有机=会，感兴趣可以试试。待遇和稳定性都还不错~2.复杂交互样式纯 CSS（原写法） <template> <button class="btn">提交</button> </template> <style scoped> .btn { background-color: #409eff;color:#fff; padding: 8px 16px; border-radius: 4px; } .btn:hover { background-color: #66b1ff; } .btn:active { background-color: #337ecc; } </style> Tailwind 写法 <button class="bg-blue-500 hover:bg-blue-400 active:bg-blue-700 text-white py-2 px-4 rounded"> 提交 </button> 问题来了：✅ 简单 hover/active 很方便❌ 多态样式（如 disabled + dark mode + hover 同时组合）就很难读： <button class="bg-blue-500 text-white disabled:bg-gray-300 dark:bg-slate-600 dark:hover:bg-slate-700 hover:bg-blue-600 transition-all"> > 提交 </button> 调试时需要反复阅读 class 字符串，不能直接 Cmd+Click 查看样式来源。3.统一样式封装，复用方案混乱原写法：统一样式变量 + class $border-color: #eee; .panel { border: 1px solid $border-color; border-radius: 8px; } Tailwind 使用中经常出现的写法： <div class="border border-gray-200 rounded-md" /> 问题来了：设计稿调整了主色调或边框粗细，如何批量更新？BEM 模式下你只需要改一个变量，Tailwind 下必须靠 @apply 或者手动替换所有 .border-gray-200。于是我们项目里又写了一堆“语义类”去封装 Tailwind： /* 自定义 utilities */ @layer components { .app-border { @apply border border-gray-200; } .app-card { @apply p-4 rounded-lg shadow-sm bg-white; } } 最后导致的问题是：我们重新“造了个 BEM”，只不过这次是基于 Tailwind 的 apply 写法。🧪 实测维护成本：100+组件、多人协作时的问题我们项目有 110 个组件，4 人开发，统一用 Tailwind，协作两个月后出现了这些反馈：👨‍💻 A 开发：写得很快，能复制设计稿的 class 直接粘贴🧠 B 维护：改样式全靠人肉找 .text-sm、.p-4，没有结构命名层🤯 C 重构：统一调整圆角半径？所有 .rounded-md 都要搜出来替换所以我们内部的结论是：Tailwind 写得爽，维护靠人背。它适合“一次性强视觉还原”，不适合“结构长期型组件库”。🔧 我们后来的解决方案：Tailwind + token 化抽象我们仍然使用 Tailwind 作为底层 utilities，但同时强制使用语义类抽象，例如： @layer components { .text-label { @apply text-sm text-gray-500; } .btn-primary { @apply bg-blue-500 hover:bg-blue-600 text-white py-2 px-4 rounded; } .card-container { @apply p-4 bg-white rounded-lg shadow; } } 模板中统一使用： <h2 class="text-label">标题</h2> <button class="btn-primary">提交</button> <div class="card-container">内容</div> 这种方式保留了 Tailwind 的构建优势（无 tree-shaking 问题），但代码结构有命名可依，后期批量维护不再靠搜索。📌 最终思考Tailwind 是给设计还原速度而生的，不是给可维护性设计的。 设计师爱是因为它像原子操作； 开发者撑是因为它把样式从结构抽象变成了“字串组合游戏”。如果你的团队更在意开发效率，样式一次性使用，那 Tailwind 非常合适。 如果你的组件系统是要长寿、要维护、要被多人重构的——你最好在 Tailwind 之上再造一层自己的语义层，或者别用。分享完毕，谢谢大家🙂——转载自：ErpanOmer
Tailwind 到底是设计师喜欢，还是开发者在硬撑？
开源硬件平台
立创EDA 立创EDA现在支持orcad和allegro工程导入吗？ #嘉立创EDA#
开源硬件平台
此题何解
开源硬件平台
V3.0 – 两板集成方案 版本：V3.0 日期：2026-03-21 用途：厂家评估、出样、量产开发 一、项目目标 开发一套双电机升降控制系统，用于控制： 电机1：桌面升降 电机2：显示器升降 系统需具备： 电容触控控制（4键） 无线遥控控制（433MHz） 记忆位置（站姿/坐姿） 自动行程学习 完整安全保护机制 二、系统架构（强制要求） 2.1 整体架构（两板方案） 主控板（MCB）位于底部金属结构内，负责： 双电机驱动（H桥+PWM） 霍尔信号处理 主逻辑控制与安全保护 电源转换（24~29V → 5V） UART通信接口 ↓ UART通信线（≤2m），信号：5V / TX / RX / GND HMI+无线合并板安装在桌面内部（非金属环境），集成： 电容触控区（4弹簧，中心灯珠） 天线区（433MHz） 本地MCU（处理触控、背光、无线、UART） 集成433无线接收 UART通信接口 2.2 架构设计原则（不可更改） 主控板（MCB）位于底部金属结构内，负责电机驱动与主逻辑。 HMI+无线合并板安装在桌面内部（非金属环境），集成触控与无线功能。 主控与HMI之间采用UART通信，线缆长度 ≤2m。 无线模块必须集成在HMI板上，远离金属，与触控弹簧保持 ≥15mm 间距。 禁止将电容触控原始信号通过长线传输（触控信号在HMI板上本地处理）。 HMI板需独立MCU进行本地处理，不得依赖主控进行触控扫描。 三、硬件系统要求 3.1 主控板（MCB） 功能： 双电机驱动（正反转 + PWM，频率 ≥20kHz） 霍尔信号处理（双路AB相，5V供电） 主逻辑控制 安全保护 与HMI板UART通信 电气要求： 输入电压：24~29V DC 输出：5V（供HMI板使用） 电机驱动：双路独立 H桥 持续电流：≥2A/路 峰值电流：≥3A/路 待机功耗：≤0.5W（休眠状态下） 驱动要求： 必须支持正反转（H桥或等效方案），不接受继电器切换方向 PWM频率 ≥20kHz Hall信号需做RC滤波及施密特触发处理 5V电源方案： 24V→5V 降压建议采用同步降压 DC-DC（如 MP2307 或同类），效率≥85%，输出电流≥500mA（含 HMI 板+霍尔供电余量）。 硬件急停： 硬件急停通过切断 24V 主供电链路实现（串联急停开关或继电器），MCU 软件急停为辅助手段，不可替代硬件断电。 电机接口线序（仅供参考）： 电机线序建议按捷昌标准6芯：MOTOR+、MOTOR-、HALL_B、HALL_A、HALL_GND、HALL_5V。若使用其他线序，请提前沟通。 3.2 HMI+无线合并板 功能组成： 电容触控（4键） LED背光（4个，每个弹簧中心一颗） 本地MCU（处理触控、背光、无线、UART通信） 433MHz无线接收模块（集成在板上） 触控要求（不可妥协）： 电容弹簧：直径 ≥12mm，高度 8~10mm 面板：木板，感应距离3~5mm（局部薄区约1mm） 触控芯片需具备上电自动基准校准和自适应环境基准跟踪，能稳定穿透木板厚度 触控信号在本地处理，不得通过长线传输 LED要求： 每键1颗LED，支持PWM调光 无线模块要求： 频率：433MHz（学习码） 距离：室内 ≥5米 模块集成在HMI板上，远离金属结构，与触控弹簧保持 ≥15mm 间距 天线区域（后部约53×17mm）正反面禁止铺铜，天线走线做阻抗匹配 无线模块电源需独立滤波（100nF+10µF），不与触控芯片共用 遥控器配套： 配套遥控器由厂家推荐或采购市售 433MHz EV1527 学习码遥控器（4键），需与接收方案兼容，厂家需提供配对测试说明。 布局建议： HMI板尺寸约53×70mm（具体以附图为准），触控区与天线区物理分隔 触控感应走线建议加 Guard Ring（地线包围） 触控IC的模拟地与无线模块的数字地单点汇合，避免大面积混用 UART接口（5V/TX/RX/GND）放置于板侧边，方便与主控连接 3.3 通信接口 主控 ↔ HMI： UART，线长 ≤2m 电平：5V逻辑，建议上拉4.7kΩ 支持校验（建议CRC）和超时机制 HMI ↔ 无线模块： 由模块接口决定（UART/GPIO），直接连接至本地MCU 四、功能逻辑 详细功能逻辑见单独提供的 《功能逻辑表》（含按键映射、唤醒休眠、长按运行、组合键学习、记忆位置、安全保护等）。 请厂家按该表完整实现，本处不再重复。 五、抗干扰要求（必须满足） 系统在电机运行、LED PWM、长线通信等条件下必须稳定运行，不得出现误触发、死机、无线失效。 HMI板布局需分区、单点接地 无线模块电源独立滤波 UART通信线建议使用屏蔽线或双绞线，远离动力线 六、交付要求（量产级） 必须交付以下文件，确保可直接移交生产： 硬件部分： 原理图（源文件+PDF） PCB Layout（源文件+Gerber） BOM（含替代料） 贴片坐标文件 装配图 固件部分： 完整源码（C语言，注释清晰） 烧录文件（hex/bin） 烧录工具及烧录说明 固件版本管理说明 测试部分： 功能测试规范（含测试点说明） 老化测试方案（≥48小时） 不良品判断标准 其他： 线束图纸 接口定义说明 装配说明 物料承认书清单 七、验收标准 功能验收：按《功能逻辑表》逐项验证通过 无线验收：遥控器室内5米稳定控制，配对可靠 稳定性验收：连续运行48小时无异常（含休眠唤醒） 量产文件验收：所有文件齐全，可支持工厂直接生产 八、厂家评估要求 请提供： 方案说明：是否基于现有平台，简要技术路线 样品周期：从合同到提供2套完整样机的时间 报价：NRE（研发费）与BOM成本（按1000套批量）分开列出 重点评估： 53×70mm空间内集成触控、LED、MCU、433模块及天线的布局可行性 3~5mm实木板穿透的触控灵敏度稳定性 天线区净空及抗干扰措施的实现 附：推荐器件参考清单 （厂家可替换，需提前沟通） 主控MCU：STC8H8K64U（LQFP-32，约2元） HMI MCU：STC8G1K08（SOP-16，约0.8元） P-MOS高边：AP40P100K（TO-252，约0.6元） N-MOS低边：HYG180N10LS1P（TO-220FB，约0.6元） 电容触控IC：BS86C04A（合泰，SOP-16，约1.5元） 433接收IC：SYN480R（杰盛微，SOP-8，约0.7元） 5V电源：MP2307/MP1584 类（SOT-23，约0.5元） 说明：以上器件仅为参考，厂家可根据自身供应链选用同等性能、封装兼容的替代料，需提前沟通确认。 附件： 板框示意图（附后） 功能逻辑表（附后）
双电机升降桌控制系统（PRD）
开源硬件平台
ESP-VoCat 喵伴旋转底座 想问一下大家怎么进的上面这个项目的交流群的？
开源硬件平台
有没有复刻过涂鸦智能的这个万能遥控 这个联网的灯不会亮
开源硬件平台
"微服务是银弹！" "Docker不是银弹！" "React才是真正的银弹！" 天天在文章和评论区看到这个词语，他到底是个啥，又是从哪里开始的。今天不讲技术，聊一下啥是银弹。概念来源"银弹"（Silver Bullet）这个概念来自于弗雷德里克·布鲁克斯（Fred Brooks） 的经典著作《人月神话》（The Mythical Man-Month）。1986年，布鲁克斯在著名论文《没有银弹：软件工程的本质与偶然性》中提出了这个影响深远的论断：在软件工程领域，没有任何技术或方法能够在十年内使生产率、可靠性和简洁性有数量级的提升。狼人传说的隐喻为什么要用"银弹"这个词？这个比喻来自狼人传说：狼人：被认为是不死的、无坚不摧的怪物银弹：传说中唯一能够杀死狼人的武器布鲁克斯用这个比喻来说明：软件开发的本质复杂性 = 狼人（看似不可战胜的难题）神奇的技术解决方案 = 银弹（人们期望的一招制敌的办法）残酷的现实 = 银弹根本不存在软件困难的分类布鲁克斯将软件开发的困难分为两类：本质性困难（Essence）这些是软件开发固有的、无法避免的困难：概念结构的复杂性：软件本身的概念结构不可见性：软件没有物理实体，无法直观把握一致性和可变性：必须适应不断变化的需求离散性：软件系统的状态组合极其庞大偶然性困难（Accident）这些是由于当前工具和技术限制造成的困难：开发工具的限制编程语言的复杂性硬件性能约束团队协作问题布鲁克斯的核心观点是：银弹最多只能解决偶然性困难，但无法触及本质性困难。 ，虽然我没看完，但总结下来应该就是这个意思😂需要一个跳板工作的，想一手抓主业，一手抓副业的，不妨看看这个机会~：技术大厂，前端-后端-测试，全国均有机会，感兴趣可以试一试；待遇和稳定性都还可以~ 且不需要你耗费很多“人际关系的心力”在上面。2. 现在"银弹"的实际含义银弹 = 能够解决所有问题的技术、方法或工具技术圈中的典型使用当有人说"xxx是银弹"时，通常意味着：这东西太厉害了，能解决我们所有的烦恼有了它，之前的所有问题都不是问题了别的技术都可以不用考虑了典型例子： // React派 const ReactIsSilverBullet = () => {     return "React才是真正的银弹，解决所有前端问题！"; }; // Vue派 const VueIsSilverBullet = () => {     return "Vue才是银弹，简单易学，性能无敌！"; }; // 微服务派 const MicroservicesAreSilverBullet = () => {     return "微服务就是银弹，拆分后所有扩展问题都解决了！"; }; // Docker派 const DockerIsSilverBullet = () => {     return "Docker就是银弹，一次构建到处运行！"; }; 当有人说"xxx不是银弹"时，意思是：这个技术有局限性，不能解决所有问题不要指望它能一劳永逸还是需要配合其他方案典型例子： -- MySQL不是银弹 -- "MySQL虽然不错，但面对大数据量时还是有限制，不是银弹！" -- K8s不是银弹 -- "K8s功能强大，但运维复杂度很高，不是银弹！" -- 敏捷开发不是银弹 -- "敏捷不是银弹，还需要结合其他工程实践！" 3. 银弹概念的传播路径3. 银弹含义的演变过程原始含义（1986年）核心概念： 能够数量级（10倍）提升软件开发生产率、可靠性和简洁性的技术或方法软件开发的本质复杂性是否存在革命性的突破技术软件工程的基本限制现在的技术圈上普遍的含义能够神奇完全解决具体场景的一系列问题的技术、工具或方法React vs Vue 哪个更好微服务 vs 单体如何选择MySQL vs MongoDB 哪个更适合Docker vs K8s 如何选择总结能很清晰的看到银弹这个词从抽象的架构设计理念，演变成了具体的对某件技术、框架、工具、方法的评价。原本：指软件工程中的架构设计和整体方法论现在：变成了对具体某个技术方案、技术框架的评价工具具体含义变化原始含义：布鲁克斯指的是能否根本上解决软件复杂性的架构方法现在含义：用来评价某个具体技术、框架、工具是否万能也反映了大家讨论技术的时候，越来越具体，越来越落地。 普通人也很难接触到什么太抽象，太宏大的架构设计，我们也更应该关心更具体的方案，来更好的解决问题。——转载自：9号达人#嘉立创PCB#
大家天天说的'银弹'到底是个啥？
开源硬件平台
找一个可以开发nRF52832的伙伴 找一个可以开发nRF52832的伙伴
开源硬件平台
开源硬件平台
去官网查看
优质硬件创作分享平台
打赏记录
激励规则
服务时间：周一至周六 9::00-18:00 · 联系地址：中国·深圳（福田区商报路奥林匹克大厦27楼） · 媒体沟通：pr@jlc.com · 集团介绍
移动社区
联系我们