ronz 发布的文章

嘉立创EDA 专业版(需注意是专业版,标准版已停更)均支持。针对1024个LED的RGB驱动电路,最理想的方案是结合层次图与复用模块的批量放置功能,这比手动阵列绘制高效得多。

以下是具体的功能对应关系和操作方案:

第一步:创建一个复用模块
新建一个“复用模块”,在里面只画1个完整的LED驱动电路(例如:1个LED + 1个限流电阻 + 1个驱动三极管/MOS管)。将需要连接的总线(如R/G/B通道和GND)用端口引出。

第二步:在顶层使用“批量复用”
回到顶层原理图,放置这个模块。在右侧属性栏找到批量复用功能:

输入范围:如果你想做成32x32的阵列,可以输入 1-32,然后放置一次。

生成结果:它会自动生成32个独立的模块图页,省去了画32份电路的时间。

第三步:完成阵列布局

原理图连接:利用总线功能,将32个模块的R、G、B端口一次性连接到对应的控制总线上。

PCB布局:框选PCB中生成的32个模块,使用布局 -> 分布 -> 阵列分布功能,设置行列间距,让软件帮你把这32块电路整齐排好。

操作建议:
如果1024个LED由多个相同的子板(如32块32路板)构成,可以只做1个子板的复用模块。如果是一整块大板,就先做好一个方向的批量复用,再用同样的方法做另一个方向。

  1. 重要提醒:区分“阵列”功能的应用场景
    这两个功能容易混淆,但使用阶段不同:

阵列副本/分布:更适合PCB布局阶段,当你已经画好了元器件,需要把它们在板子上摆整齐时使用。

批量复用:更适合原理图绘制阶段,当你需要画出许多份相同的电路时使用

接收器使用VISHAY-BPW34,硬件使用OSCA02X
硬件连接:
A通道 钩针钩正极,GND接接收管的地(接受面上有个点的为正)
2026-03-23T05:30:40.png
大概这个样子

2026-03-23T05:31:15.png

软件配置

开启channel A,关闭channel B
Channel A - 使能AC
时间设置为25us
电压调整为50mv
1X 1倍,钩针打到1X
2026-03-23T05:34:29.png

触发配置
上升沿触发
单次触发,60mv触发
2026-03-23T05:36:25.png

实际抓取效果
56kHZ
2026-03-23T05:38:20.png
38kHZ
2026-03-23T05:39:00.png

遇到这种“重启就恢复原样”的情况确实非常折磨人。这通常说明你的路由器在重启后,系统仍然试图加载一个损坏或不兼容的第三方主题,或者是你的系统配置无法永久保存(比如存储空间满了,导致每次重启都回滚)。

为了彻底解决这个问题,我们可以按照以下几个步骤进行排查和修复:

第一步:找出并卸载那个“惹祸”的主题
既然你必须切换回 bootstrap 才能打开网页,说明默认加载的那个主题是有问题的。我们需要把它彻底删掉。

先不要执行你的修复命令,在刚重启后(打不开网页的状态下),通过 SSH 登录,运行以下命令查看当前系统正试图加载什么主题:

Bash
uci get luci.main.mediaurlbase
记下输出的结果(比如 /luci-static/argon)。

查看当前安装了哪些主题:

Bash
opkg list-installed | grep luci-theme
卸载那个损坏的主题(假设坏掉的主题是 argon,请替换为你实际查到的名字):

Bash
opkg remove luci-theme-argon
第二步:检查路由器存储空间(Overlay)是否已满
如果你的 uci commit luci 命令在执行时没有报错,但重启后依然无效,极有可能是路由器的可写分区(Overlay)已经满了(100%)。当空间满时,OpenWrt 无法保存新的配置,重启后就会丢失修改。

运行以下命令查看磁盘空间:

Bash
df -h
重点查看挂载点为 /overlay 或 / 的这一行,看 Use%(已用百分比) 是否达到了 100%。

如果是 100%:你需要清理空间,或者重置路由器。通常是因为安装了太多插件,或者系统日志占满了空间。可以尝试删除一些不用的插件来释放空间。

第三步:检查是否有开机自启脚本在“捣鬼”
有时候,某些一键安装包或固件自带的脚本会在开机时强制设置某个特定主题。如果该主题不存在或损坏,就会导致你现在的状况。

检查开机脚本 rc.local:

Bash
cat /etc/rc.local
看看里面有没有类似 uci set luci.main.mediaurlbase=... 的命令。如果有,用 vi /etc/rc.local 编辑文件,把那行删掉或注释掉(在行首加 #)。

检查自定义设置(如果你用的是某些定制版的固件,如 Lean 的 LEDE):
去 /etc/uci-defaults/ 目录下看看有没有可疑的初始化脚本。

第四步:在 Web 界面中“彻底”保存并清理缓存
如果你通过命令行修复后进入了网页,建议在网页端再彻底保存一次,这有时能触发系统更新其他的关联配置文件。

执行你那三行命令,恢复网页访问。

清理系统中的 LuCI 缓存:

Bash
rm -rf /tmp/luci-modulecache/
rm -f /tmp/luci-indexcache
登录 OpenWrt 网页后台,进入 系统 (System) -> 系统属性 (System) -> 语言和界面 (Language and Style)。

确保主题下拉菜单中选择的是 Bootstrap。

点击页面底部的 保存并应用 (Save & Apply)。

整体架构(含RabbitMQ)
┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ 用户微信 │ │ 微信服务器 │ │ 你的后端 │
│ (小程序) │◄────►│ (公众号/ │◄────►│ (业务逻辑/ │
│ │ │ 小程序API) │ │ RabbitMQ │
└─────────────┘ └──────────────┘ └──────┬──────┘

                                                │
                                                │ 推送消息
                                                ▼

┌─────────────────────────────────────────────────────────┐
│ RabbitMQ 集群 │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ 登录消息队列│ │战绩上报队列│ │推送通知队列│ │
│ └────────────┘ └────────────┘ └────────────┘ │
└─────────────────────────────────────────────────────────┘

     ▲                    ▲                    ▲
     │ 消费登录指令        │ 消费战绩数据        │ 消费推送任务
┌────┴─────┐         ┌────┴─────┐         ┌────┴─────┐
│本地游戏   │         │本地游戏   │         │你的后端   │
│服务器A    │         │服务器B    │         │推送服务   │
└──────────┘         └──────────┘         └──────────┘
                                                │
                                                ▼
                                        ┌─────────────┐
                                        │  公众号     │
                                        │ 模板消息推送 │
                                        └─────────────┘
                                                │
                                                ▼
                                        ┌─────────────┐
                                        │  用户微信   │
                                        │ (聊天列表)  │
                                        └─────────────┘

策略 A:建立并定期更新《项目全局上下文 (Context.md)》
每当我们确定了一个核心模块(例如:数据解析逻辑或 UI 架构),你可以要求我总结一段“当前进度摘要”。

操作: 每次开启新话题或感觉逻辑变复杂时,你把这段摘要贴出来。

内容包括: 核心类名、数据协议格式、已解决的坑、下一步目标。

策略 B:模块化“投喂” (Modular Feeding)
不要一次性把 50 个 Java 文件全丢进来。

做法: 按照 数据协议 -> 数据流转 (Repository) -> UI 状态控制 (ViewModel) -> UI 渲染 (Compose/View) 的顺序。

优势: 我在每一阶段都会生成对应的 Kotlin 规范,后续对话中,我只需基于这些已确认的规范进行扩展。

策略 C:使用“核心逻辑锚点” (Logic Anchors)
在对话中,给你的特殊逻辑起一个唯一且具有辨识度的名字。

比如:ScoreboardProtocolV1 或 BoxDisplayManager。

当我表现出遗忘迹象时,你只需说:“请基于我们之前定义的 ScoreboardProtocolV1 来重写这个方法”,我会立即从上下文缓存中检索到相关定义。