简单电路的想法及尝试(2)

之前想到一个简单的电路,然后画了画、今天动手试了一下,感觉没有问题、可以实现。但是比较郁闷的是其中要使用单刀双掷开关、或者更方便一些就是使用双刀双掷开关。虽然使用更高级的开关可以让电路简化,但是这些高级的开关并不好找,即便真的有、手感上和形式上也很难满足我的需求。

所以我觉得还是退而求其次,用比较简单的单刀单掷开关来实现吧。以下是第一部分电路的重新规划——完全改用单刀单掷开关来实现。电路看上去应该是可以运行的,不知道实际效果怎么样,还要再花时间搭建真实的电路来验证一下:

我设想的电路整体分成三个部分,上面是第一部分。现在觉得第一部分的电路无论怎么实现,都是可以搞定的,毕竟它的功能最简单;难的是第二部分的电路,没有想好怎么才能只通过一个单刀单掷开关实现。

另外,上面的第一部分电路现在也只是核心功能,如果考虑到更复杂的情况,例如将LED增加进去,也会让问题变得复杂。

看来这个“小功能”也不是一朝一夕能够搞定的,我索性也就不着急、慢慢学习、慢慢尝试了。

想了想,第二部分电路的结构大概清晰了,并且有对第一部分电路进行了微小调整,至此的基本思路如下:

每天学习一些新的知识,尽可能保持自己的学习动力。

Related Posts

树莓派(6)基于LT3748的设计过程

原文地址:https://www.farnell.com/datasheets/1332863.pdf

树莓派(5)四个PoE PD方案的初期备忘

最近粗略的看了三个PoE PD方案,分别是: 核心芯片 品牌 拓扑结构 说明 BD9G341AEFJ ROHM Buck 非隔离、无变压器单元。外围电路简单。需前端PD模块。 LT3748 LINEAR Flyback 隔离、反激、主边反馈。需前端PD模块。 Si3404-A-GM SKYWORKS Flyback 隔离、反激、副边反馈。内置PD模块。 DPA425R 从电路的复杂程度上而言,BD9G341AEFJ看上去是最简单的。它没有用到变压器结构、也没有隔离机制,因而用到的IC既少、又容易获得。所以我想先尝试以BD9G341AEFJ为目标,自己试着实现一个DCDC模块。 在Mouser上能够看到这个芯片共有两款料号,分别是BD9G341AEFJ-E2和BD9G341AEFJ-LBE2。其中后者尾椎中多出来的“LB”是long time support in Industrial market的含义。也就是说如果面向工业化设计时,BD9G341AEFJ-LBE2这款芯片更适合采用。 此外在Mouser上还有一款BD9G341AEFJ-EVK-101评估板,它的BD9G341AEFJ-EVK-101…

补录一个之前遇到的问题

在2025年4月21日的《通过MT3608进行升压问题不大》文章中,提到了一句“关于上面的第4点,要再花时间额外写一篇博客”。当初遇到的是什么问题呢? 我从电源板上得到“电能”之后,会将电能分成5V和11.4V两路,传递给蜂鸣板,以令蜂鸣板上的两部分模块同时开始工作。然而在这个电力传输通道上,却出现了一些莫名其妙的情况:通过中间的四根导线将电能传递到蜂鸣板之后,蜂鸣器发出来的声音十分浑浊、沙哑。 我现在已经记不清之前写文章时听到的声音状态了,而现在听到的声音状态一定和之前的不一样、有了些许好转,但依然不是饱满、洪亮的声音。 这个问题,还要再花时间研究一下。 其实我也不用纠结之前听到的声音有多么恶劣,毕竟最近一段时间对电路进行了很大幅度的调整,可能已经解决了不少问题。只需要在此刻听到的声音的基础上,继续完善、优化电路就可以了。

电源芯片基本完成

如前文提到的,上一版电路板无法正常工作,原因就是IP5407芯片停止工作了。然而与前文猜测的也许不同,并不一定是我猜测的PCB布线过窄引起的。还有可能是外部线缆(从电池到PCB、从开关电源到PCB)的线径太小;还有一种可能就是上一版电路中,我在输出位置使用的3颗22uF电容用的是X5R导致的。 无论哪一种可能性,本质上都是IP5407看到的电池电压出现了错误、虚低,导致芯片停止工作。 因为没有精力逐项排查,所以我今天新做出来的电路,就索性将上面的怀疑问题,全都改良了一遍。结果,问题得到解决,现在电路可以正常工作了。因而也就不再仔细推敲上一版中究竟是哪里出现的问题了。 现在接下来的工作开始变得有些尴尬:接下来做什么呢? 想着应该是先将整体功能全部实现出来,所以下一个工作,就是完成前面板PCB的设计与制作。 经过测试,这个电路还是存在问题的 现在怀疑是C7这颗电容是多余的,但是在反复测试过程中,将电路板烧毁了。还要再找时间重新做一块电路板,好辛苦。我为什么会怀疑是C7电容导致的问题呢? 现在IP5407上电之后,明显会出现一个1秒的延迟,看它的技术手册提到1s停摆是因为出现了过流保护、会间断1秒重新上电。当我将电路导通时,整个电路中C7这个电容是饿着的、并且这个电容容量还不小,所以它很可能会在上电瞬间吃电吃到过流,引起IP5407停摆。一秒之后,C7已经被其他电容充上电、也被上一次停摆之前充上电,所以整个电路就是稳定的,所以只要经历一次停摆,就能恢复正常工作。 如此想来,C7现在就是重点怀疑对象。

仿真软件开发进展

Day: 44, SLOC: 6182。 前阵子将仿真软件的基本开发环境搭建起来、勾勒了个整体的模型结构,并且先有的没的将符号绘制、图像渲染、参数调整、计算输出……都草草实现了一遍,绝大多数都是以快速成型、不确保正确为原则开拓的代码基底。 这套开发环境的构建原则是“尽量轻巧”,因而甚至连IDE工具、CMake都没有引入,纯粹使用裸代码撰写,虽然过程痛苦,换来的却是十分的轻便,而且每一行代码都是纯手写,代码敲得十分过瘾。 上面的快乐时光结束之后,就是实打实的撰写每一个具体方法,再不能天马行空、一日百行。每天代码增长大约只有几十行。好在我对模块拆分的很细,基本上每一天都能有个小小的新功能被实现出来。 今天完成的是AC电源的引入,现在终于可以看到一张“时域动画”,效果比之前每天看到的“直流稳态”要灵动一些。 接下来要完成的是电容的引入,这是一个比较重要的、也是需要用到更多核心计算机制的IC,一旦完成了电容的引入,就可以进行一些基本电路的仿真了。 当然,电容的引入并不是1、2天就能完成的事情,所以这期间还会找一些相对容易的功能也一起实现。例如:对已经绘制了的线段、IC进行删除、移动。这样以上普通功能和“难点功能”,就共同构成了本周要进行的开发需求。

sncircuit开发备忘:网络合并

在 NetlistManagerClass 中原本有一个方法叫做 updateAllNetlistIndexTo(),它起初的含义是将第一网络节点中所有的成员,从第一网络节点中删除、并且追加到第二网络节点中,然后第一网络节点便成为了“荒废节点”,可以删除掉了。 这个方法存在着一些问题。首先是它的名称今天看来已经不再准确,更准确的名称应该是 merge,完成的功能还是一样的:将网络节点a和网络节点b中的所有成员,都迁移到a或b网络节点中,然后将荒废掉的网络节点剔除掉。 其次,对于merge(netlist a, netlist b),究竟是将谁的内容迁移到另外一个网络节点中呢?昨天我纠结了很久,后来想明白了:无论从a到b,还是从b到a,实际上都是一样的,因而完全没有必要纠结要不要为这个方法增加第三个参数指明保留谁。 而今天重构这块代码的时候,又有了更为“智能”的一个方案:既然无论怎样的方向对于合并都没有影响,那么就应该选择成员最少的网络节点进行“搬家”操作,这样效率会更高,因而在merge()内部进行判断,找到a和b中迁移成本低的进行迁移。 额外的,在完成上述方法重构时发现,除了在 PlacementManagerClass 中会调用netlistManager->merge()方法外,在NetlistManagerClass中也会调用netlistManager->merge()方法,并且后者的调用是“迂回到footpin中”进行调用,后者的“迂回”导致代码逻辑十分难以理解,所以将迂回的调用删除了,如此就简化到只要在PlacementManagerClass和NetlistManagerClass两个类中的两个位置上调用merge(),如此代码相对比较容易理解。 即便做到了上面说的“只在两个地方调用”,实际上还是有些“繁琐”的,还是业务逻辑上的繁琐与不恰当。这一点上现在脑子有些乱,所以先写下这篇备忘,将相关工作记录一下。有时间会再推敲如何继续合并代码,争取只在一个地方、一个逻辑内,完成“网络节点的合并”。