聽聽，底層軟件老鐵談硬件電路風險
硬件理解透徹了，風險也就不存在了
|| 前言
在產品設計開發中，硬件電路設計最終看起來是硬件工程師完成的，但是不要忽略了底層軟件工程師哦！他們也是需要對電路有一定理解的，並不是僅僅簡單的停留在高低電平的概念。所以硬件電路設計如果能與底層軟件工程師的溝通橋樑建立好，真的可以事半功倍，並且會有助於異常分析及甩鍋猜疑的。
怎樣能建立這種有效溝通，原理圖註釋是首要的，這個註釋不止是layout看的。我們可能會看到一些大廠的參考設計原理圖上備註是非常豐富的，硬件軟件小夥伴都有必要仔細看看，會有很多收穫的。為什麼要這樣了，這個是一種節省溝通釋疑的最簡潔手段了！
當然也不是註釋完善了就一了百了了，註釋完善只是會減小或者降低溝通成本和節省資源，有時候也可以減少一些負能量在溝通過程中傳遞過去幾率。更多時候是降低一些低級的溝通。
|| 正文
原理圖參考下圖
問題前奏
這個電路嚴格條件上來說，存在一定風險。具體的風險因為牽扯到行業標準和其他輔助電路及產品特徵，一時半會沒法講清楚，在此不做介紹。同時這個風險硬件內部評估過，按照產品應用條件，可以忽略，隨後也會優化將此風險完全消除。原創今日頭條：臥龍會IT技術
某日，正在分析此產品一個與此相關問題時候。和一個軟件工程師溝通完成思路和分析計劃及可能存在的問題解決方案後，將要拜拜掛電話的時候。軟件工程師說，我覺得這個電路存在一個風險
我去，這種風險軟件也能發現，頓時有點焦慮了。請將你說的風險，我看看。
軟件工程師：嗯，這樣的，主控這個信號對應的pin默認是下拉的。當然初始化後，軟件可以禁用掉下拉，但是我們的擔心是在此之前會不會導致我檢測異常。我一直覺得目前這個問題與這個有關係。
我，哦，你說的這種擔憂其實是不存在的。
軟件工程師：怎麼可能了（我是學過模擬電路的，而且是名校哦）。這個就是一個簡單的分壓關係了，芯片內部弱下拉典型值是75K。按照歐姆定律（是歐姆定律吧）計算
這，這個電路兄弟不是這樣的。這個應該考慮光耦導通（他說這個是三極管），但是得照顧老鐵感情（友軍不能亂噴的）。要不我給你個仿真你再理解下，看看是不是理解的有偏差。
軟件工程師：可以可以（當然內心裡可能有些許不理解），你的電路超越歐姆定律了，我看你能解釋個花出來
仿真解釋
掛了電話，內心裡還是有點忐忑，怎樣解釋既能說明問題，也不讓友軍尷尬。這個兄弟平常灰常配合我們，有些需要多次循環確認重現的問題都是很快給我我們搞個腳本出個特殊測試版本的，從來不官僚要走啥流程抄送這個領導請示那個領導的，效率剛剛的。原創今日頭條：臥龍會IT技術
不扯那麼遠了，技術友軍永遠是耿直的，提升溝通效率是最重要的。亂七八糟的都是官斗的，都是屌絲不存在。這樣想下來就好說了！
默認設計
歐姆定律妥妥的
增加內部下拉
有內部下拉（R3）條件下仿真
這個看起來不是電阻分壓哦，電阻分壓流過兩個電阻的電流是相等的，這兩個電阻流過的電流相差近240倍了。所以老鐵這個不是電阻分壓的，上拉電阻消耗的電流主要是光耦導通程度決定的（上拉電阻流經電流的99.8%電流都通過光耦到地了）。
這個風險你可以放心了！原創今日頭條：臥龍會IT技術
|| 總結
軟件老鐵擔心的風險看起來是不存在的，但是他的擔憂硬件設計的時候考慮到了嗎？我覺得大多數情況下是沒有考慮到的，目前的結果更多是是誤打誤撞吧。不過只要成功了，過程細節對於我們來說就放在腦後了。其實總結下來做個回憶或者與人分享也是一件好事情，或許她正好在這塊有困惑了。
點擊，關注我們！分享IT，電子方面的技術知識，精彩內容繼續。。。
臥龍會，臥虎藏龍！IT，電子行業高手匯聚。
有啥問題，歡迎大家入下面的頭條圈子交流！
閱讀更多 臥龍會IT技術 的文章
