我所有gnd nc vcc 都平铺出来。


【 在 spadger 的大作中提到: 】
: https://forum.kicad.info/t/windows-7-soon-to-be-no-longer-functional-for-6-0
: /27149/41
: 原因主要是开发者没兴趣，建议升级Win10，或者买一台“现代”的PC，或者去用Linux，商业软件没有这么做的，开源软件这么做就没啥问题，毕竟不需要考虑市场，占有率这些事情
: ...................
--
FROM 101.229.121.*

win7的事情我之前就说过了，以我对开源做风的了解，这个不用怀疑他们肯定是不会在意windows平台。

至于这个库的问题嘛，这个可以好好说说。开源意味着众多的选择，自然会有很多细支末节的路线pk。
比如变量名windows喜欢CamelCase，linux就喜欢snake_case
比如python有经典的tab还是space的缩进之争。

这种事情要列，我可以随便列100个。以前大家经常是吵的天翻地覆谁也说服不了谁。这么多年了也都疲了，现在约定俗成，基本的规则就是在谁的地盘就遵守谁定的规矩。不服你就自己fork。开源里面一言不合就fork的案例也非常的多。最后都是用户用脚投票看谁胜出的。所以这个事情你不用多想，人家要维持风格的统一性，这也是可以理解的。世上千万种审美，总有跟你的审美冲突的地方。你要老想着这些事情那愚蠢的地方就多了。

最后，kicad这种把同名管腿摞一起的风格我并不是十分的反感，但尼玛这个渲染能不能解决一下...管腿的编号也摞一起叠成一个色块了都，这一点我也是要喷的...

【 在 spadger 的大作中提到: 】
: https://forum.kicad.info/t/windows-7-soon-to-be-no-longer-functional-for-6-0
: /27149/41
: 原因主要是开发者没兴趣，建议升级Win10，或者买一台“现代”的PC，或者去用Linux，商业软件没有这么做的，开源软件这么做就没啥问题，毕竟不需要考虑市场，占有率这些事情
: ...................
--
FROM 180.158.54.*

这个是历史问题，他们的封装风格其实都改过很多次了。
比如早期的封装，pinname会写的超级长。比如stm32一条腿上能复用各种功能的，他就会把所有的功能都写上去。
一个name能写50个字符的那种。
导致symbol超级胖。

中期做过一轮迭代，至少pinname不会这么夸张了，但这个时候还是平铺gnd的。
现在新的迭代周期就是进一步简化symbol，让它更简洁，所以搞起了摞gnd。。。

我的建议是他给啥就用啥。比如那个超级胖的虽然难看，但设计的时候很舒服呀，我不用去查datasheet一个个扣字眼了，复用冲突的问题也更容易观察到。

中期那就是现在的主流做法。至于现在这种更简洁的趋势嘛，也不是没啥坏处。sch原本就应该更专注逻辑，跟物理布局解耦合。

反正不管那个时代的库，都有本地cache，升级了旧的还能打开。虽然我是强迫症一旦看到了就会删掉cache自己重新拉一下让它升级到最新的库封装就是了。

【 在 spadger 的大作中提到: 】
: 问题是他自己内部也不是统一的。。一大堆封装都是平铺的GND。
:
--
修改:lvsoft FROM 180.158.54.*
FROM 180.158.54.*

不是，我不理解把GND合一起有啥问题？原理图描述的就是逻辑连接关系啊，具体怎么连线那是layout的事啊。而且GND能有啥特殊的连线，又不是把PGND,AGND,DGND一股脑合一起。真有特殊需求，肯定得用不同pin name的啊。总不能全用GND，然后一个脚注小字跟你说某个妖艳贱货的GND跟别的长的不一样，需要怎么怎么特殊走线伺候她...这不就是埋雷么...

有人喜欢symbol跟芯片物理布局一样，我也喜欢这样。这样设计的时候可以带着布线问题一起规划资源分配。这种情况下把gnd合一起是挺不能接受的。但大趋势是symbol就是不应该管芯片引脚布局，完全按照逻辑上怎么舒服怎么来啊。又不是kicad这么干，行业标杆orcad也这样呀。简单的芯片比如运放，电源ic，74系列是如此。复杂的芯片fpga，soc更是如此。fpga最典型，一个bank一个unit，然后最后来个unit里面只有一排GND，这和合一起也没啥区别啊。

【 在 dismoon 的大作中提到: 】
: 对硬件工程师来说，把GND全部合在一起是很愚蠢，因为PCB走线不是同net连在一起就行，但是你要考虑别人就是写个软件。。。。
:
--
修改:lvsoft FROM 223.104.148.*
FROM 223.104.148.*

我觉得要看数量可以出个统计功能，比如GND(123)就挺好。fgpa动辄上百个GND，一面铺开也不太可能一个个的去数。说到这个我想起来，虽然我好久不用了，但依稀记得allegro好像是不支持pin name重复的，尽管orcad支持。所以vcc/gnd都得编个号，看起来跟总线似的，倒是确实也不用数了...

另外没双标，vcc，vccint，vccio，当然也是要摞起来的。另外reserved，nc等等也一样。起码我做的封装是按照这个风格做的。除了pin number那里糊成一块让我不太舒服外，其他都感觉良好。

摞电阻这个操作我还没见过，但讲真，如果原理图上能有清晰标注，我觉得可以支持。总线匹配电阻，去耦电容，这些都是大数量简单重复的东西，没道理不可以简化。比如总线可以合并，那终端电阻应该也可以。如同你说的，原理图是给人看的，只要能做到简洁清晰无歧义，那就是应该提倡的方向。我就非常烦画一页的去耦电容。原理图上也无法描述每颗电容具体是放哪个vcc pin，不同容值怎么组合。那画这么多干嘛，这一页关键的内容就2个，什么容值需要多少颗，直接写张bom几个数字不就行了。ctrl c ctrl v一顿操作拉出来一大页，就是在浪费人的心智，不管是画图的还是看图的人。

你说的情况是不同芯片了，只是提供了向下兼容。原则上应该给兼容芯片重做封装，不然你拿着EPM570T100的封装，把标签改成AG576然后在GND上拉GPIO，你自己看着也不舒服啊。

最后，这个例子在coding里面还确实能找到相似的例子。最典型的就是Java，那代码描述能力，做点事情动不动就写的又臭又长，以至于IDE不得不进化出先进智能的自动化能力，帮你自动生成又臭又长的代码框架，然后再贴心的帮你缩写隐藏掉这些无聊的框架代码，让你只看核心部分。在我看来这么搞就是脱裤子放屁。削减冗余信息，提高信息密度，在任何时候都是很重要的事情，因为我们人的带宽只有10bps。

至于你说的这些个问题，我认为只是细节还没做到位，并不涉及本质。原理图最早是手绘的，eda工具也只是复现了这个过程。但现在ic功能越来越多越来越复杂，现在是可以有更好的描述方式的。只不过这个好像没有一个国际化组织推个什么标准出来，也没有看见类似Python PEP的提案讨论机制，基本上就是各家大厂自己定的内部规范。那我觉得由爱好者占主体的kicad来搞搞也没啥不好啊。这个起码是一个旺盛的社区，比如我以前也是相当鄙视Arduino和raspberry pi的，现在还不是真香...

【 在 spadger 的大作中提到: 】
: 原理图是给人看的，GND管脚数量也是个重要信息，像MCU/FPGA这种多个电源脚的芯片，
: 常规方法是GND/VCCINT/VCCIO放在一个Part里面，但是不要摞起来。摞起来只会给阅读
: 者造成困扰。
: ...................
--
FROM 180.111.49.*