在前一小節(jié)中介紹了點亮第一個LED燈，這里我們準備進階嘗試下，輸出第一段PWM波形。（PWM也就是脈寬調(diào)制，一種可調(diào)占空比的技術，得到的效果就是：如果用示波器測量引腳會發(fā)現(xiàn)有方波輸出，而且高電平、低電平的時間是可調(diào)的。）
10年積累的網(wǎng)站設計、成都網(wǎng)站制作經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計后付款的網(wǎng)站建設流程，更有眉山免費網(wǎng)站建設讓你可以放心的選擇與我們合作。
這里爪爪熊準備寫成一個golang的庫，并開源到github上，后續(xù)更新將直接更新到github中，如果你有興趣可以和我聯(lián)系。 github.com/dpawsbear/bear_rpi_go
我在很多的教程中都看到說樹莓派的PWM（硬件）只有一個GPIO能夠輸出，就是 GPIO1 。這可是不小的打擊，因為我想使用至少四個 PWM ，還是不死心，想通過硬件手冊上找尋蛛絲馬跡，看看究竟怎么回事。
手冊上找尋東西稍等下講述，這里先提供一種方法測試 樹莓派3B 的 PWM 方法：用指令控制硬件PWM。
這里通過指令的方式掌握了基本的pwm設置技巧，決定去翻一下手冊看看到底PWM怎么回事，這里因為沒有 BCM2837 的手冊，根據(jù)之前文章引用官網(wǎng)所說， BCM2835 和 BCM2837 應該是一樣的。這里我們直接翻閱 BCM2835 的手冊，直接找到 PWM 章節(jié)。找到了如下圖：
圖中可以看到在博通的命名規(guī)則中 GPIO 12、13、18、19、40、41、45、52、53 均可以作為PWM輸出。但是只有兩路PWM0 PWM1。根據(jù)我之前所學知識，不出意外應該是PWM0 和 PWM1可以輸出不一樣的占空比，但是頻率應該是一樣的。因為沒有示波器，暫時不好測試。先找到下面對應圖：
根據(jù)以上兩個圖對比可以發(fā)現(xiàn)如下規(guī)律：
對照上面的表可以看出從 BCM2837 中印出來的能夠使用在PWM上的就這幾個了。
為了驗證個人猜想是否正確，這里先直接使用指令的模式，模擬配置下是否能夠正常輸出。
通過上面一系列指令模擬發(fā)現(xiàn)，（GPIO1、GPIO26）、（GPIO23、GPIO24）是綁定在一起的，調(diào)節(jié)任意一個，另外一個也會發(fā)生變化。也即是PWM0、PWM1雖然輸出了兩路，可以理解成兩路其實都是連在一個輸出口上。這里由于沒有示波器或者邏輯分析儀這類設備（僅有一個LED燈），所以測試很簡陋，下一步是使用示波器這類東西對頻率以及信號穩(wěn)定性進行下測試。
小節(jié)：樹莓派具有四路硬件輸出PWM能力，但是四路中只能輸出兩個獨立（占空比獨立）的PWM，同時四路輸出的頻率均是恒定的。
上面大概了解清楚了樹莓派3B的PWM結構，接下來就是探究如何使用Go語言進行設置。
因為拿到了手冊，這里我想直接操作寄存器的方式進行設置，也是順便學習下Go語言處理寄存器的過程。首先需要拿到pwm 系列寄存器的基地址，但是翻了一圈手冊，發(fā)現(xiàn)只有偏移，沒有找到基地址。
經(jīng)過了一段時間的努力后，決定寫一個 樹莓派3B golang包開源放在github上，只需要寫相關程序進行調(diào)用就可以了，以下是相關demo（pwm）（在GPIO.12 上輸出PWM波，放上LED燈會有呼吸燈的效果，具體多少頻率還沒有進行測試）
以下是demo(pwm) 源碼
單片機不像一些應用軟件，和硬件結合十分緊密，必須要求“高效”，所以匯編語言是最好選擇，其次就是C語言了。其他語言編譯效率都太低，滿足不了要求。
創(chuàng)建 PayPal 的目的是使金融服務民主化，并使個人和企業(yè)能夠加入并在全球經(jīng)濟中蓬勃發(fā)展。這項工作的核心是 PayPal 的支付平臺，該平臺使用專有技術和第三方技術的組合來高效、安全地促進全球數(shù)百萬商家和消費者之間的交易。隨著支付平臺變得越來越大、越來越復雜，PayPal 尋求對其系統(tǒng)進行現(xiàn)代化改造并縮短新應用程序的上市時間。
Go 在生成干凈、高效的代碼方面的有著極高的價值。這些代碼可以隨著軟件部署的擴展而輕松擴展，這使得該語言非常適合支持 PayPal 的目標。
支付處理平臺的核心是 PayPal 用 C++ 開發(fā)的專有 NoSQL 數(shù)據(jù)庫。然而，代碼的復雜性大大降低了開發(fā)人員發(fā)展平臺的能力。Go 的簡單代碼布局、goroutine（輕量級執(zhí)行線程）和通道（用作連接并發(fā) goroutine 的管道）使 Go 成為 NoSQL 開發(fā)團隊簡化和現(xiàn)代化平臺的自然選擇。
作為概念驗證，一個開發(fā)團隊花了六個月的時間學習 Go 并在 Go 中從頭開始重新實現(xiàn) NoSQL 系統(tǒng)，在此期間，他們還提供了有關如何在 PayPal 更廣泛地實施 Go 的見解。截至今天，已遷移 30% 的集群以使用新的 NoSQL 數(shù)據(jù)庫。
隨著 PayPal 的平臺變得越來越復雜，Go 提供了一種輕松簡化大規(guī)模創(chuàng)建和運行軟件的復雜性的方法。該語言為 PayPal 提供了出色的庫和快速工具，以及并發(fā)、垃圾收集和類型安全。
借助 Go，PayPal 使其開發(fā)人員能夠將更多時間從 C++ 和 Java 開發(fā)的噪音中解放出來，從而能夠花更多時間查看代碼和進行戰(zhàn)略性思考。
在這個新改寫的 NoSQL 系統(tǒng)取得成功后，PayPal 內(nèi)更多的平臺和內(nèi)容團隊開始采用 Go。Natarajan 目前的團隊負責 PayPal 的構建、測試和發(fā)布管道——所有這些都是在 Go 中構建的。該公司擁有一個大型構建和測試農(nóng)場，它使用 Go 基礎設施進行完全管理，以支持整個公司的開發(fā)人員的構建即服務（和測試即服務）。
憑借 PayPal 所需的分布式計算能力，Go 是刷新系統(tǒng)的正確語言。PayPal 需要并發(fā)和并行的編程，為高性能和高度可移植性而編譯，并為開發(fā)人員帶來模塊化、可組合的開源架構的好處——Go 已經(jīng)提供了所有這些以及更多幫助 PayPal 對其系統(tǒng)進行現(xiàn)代化改造。
安全性和可支持性是 PayPal 的關鍵問題，該公司的運營管道越來越多地由 Go 主導，因為該語言的簡潔性和模塊化幫助他們實現(xiàn)了這些目標。PayPal 對 Go 的部署為開發(fā)人員提供了一個創(chuàng)意平臺，使他們能夠為 PayPal 的全球市場大規(guī)模生產(chǎn)簡單、高效和可靠的軟件。
隨著 PayPal 繼續(xù)使用 Go 對其軟件定義網(wǎng)絡 (SDN) 基礎設施進行現(xiàn)代化改造，除了更易于維護的代碼外，他們還看到了性能優(yōu)勢。例如，Go 現(xiàn)在為路由器、負載平衡和越來越多的生產(chǎn)系統(tǒng)提供動力。
作為一家全球性企業(yè)，PayPal 需要其開發(fā)團隊有效管理兩種規(guī)模：生產(chǎn)規(guī)模，尤其是與許多其他服務器（如云服務）交互的并發(fā)系統(tǒng)；和開發(fā)規(guī)模，尤其是由許多程序員協(xié)同開發(fā)的大型代碼庫（如開源開發(fā)）
PayPal 利用 Go 來解決這些規(guī)模問題。該公司的開發(fā)人員受益于 Go 將解釋型動態(tài)類型語言的編程易用性與靜態(tài)類型編譯語言的效率和安全性相結合的能力。隨著 PayPal 對其系統(tǒng)進行現(xiàn)代化改造，對網(wǎng)絡和多核計算的支持至關重要。Go 不僅提供了這種支持，而且提供的速度很快——在單臺計算機上編譯一個大型可執(zhí)行文件最多需要幾秒鐘。
PayPal 目前有 100 多名 Go 開發(fā)人員，未來選擇采用 Go 的開發(fā)人員將更容易獲得該語言的批準，這要歸功于公司已經(jīng)在生產(chǎn)中的許多成功實現(xiàn)。
最重要的是，PayPal 開發(fā)人員使用 Go 提高了他們的生產(chǎn)力。Go 的并發(fā)機制使得編寫充分利用 PayPal 的多核和聯(lián)網(wǎng)機器的程序變得很容易。使用 Go 的開發(fā)人員還受益于它可以快速編譯為機器代碼的事實，并且他們的應用程序獲得了垃圾收集的便利和運行時反射的強大功能。
今天 PayPal 的第一類語言是 Java 和 Node，Go 主要用作基礎設施語言。雖然 Go 可能永遠不會在某些應用程序中取代 Node.js，但 Natarajan 正在推動讓 Go 成為 PayPal 的第一類語言。
通過他的努力，PayPal 還在評估遷移到 Google Kubernetes Engine (GKE) 以加快其新產(chǎn)品的上市時間。GKE 是一個用于部署容器化應用程序的托管、生產(chǎn)就緒環(huán)境，并帶來了 Google 在開發(fā)人員生產(chǎn)力、自動化操作和開源靈活性方面的最新創(chuàng)新。
對于 PayPal 而言，部署到 GKE 將使 PayPal 更容易部署、更新和管理其應用程序和服務，從而實現(xiàn)快速開發(fā)和迭代。此外，PayPal 會發(fā)現(xiàn)更容易運行機器學習、通用 GPU、高性能計算和其他受益于 GKE 支持的專用硬件加速器的工作負載。
對 PayPal 來說最重要的是，Go 開發(fā)和 GKE 的結合使公司能夠輕松擴展以滿足需求，因為 Kubernetes 自動擴展將使 PayPal 能夠處理用戶對服務不斷增長的需求——在最重要的時候保持它們可用，然后在安靜的時間來省錢。
C++適合本地程序的開發(fā)。Go語言適合網(wǎng)絡程序和本地程序的開發(fā)。Go的優(yōu)點:垃圾回收，語意明確，格式統(tǒng)一。?Go的缺點:效率目前沒有C++高，但對于桌面程序而言，效率問題不大，因為硬件已經(jīng)很快了。c++過于復雜了，加入很多炫技的內(nèi)容。這些內(nèi)容脫離了事情的本質。
最明顯的就是所謂的面向對象。基于面向對象的工程如果足夠大的情況下，會帶來很大的耦合度，如果再加上內(nèi)存管理，多線程等等。項目后期基本上沒辦法維護和增加功能。
關于c++的語言復雜性，你可以問知乎上的任何一位高手。沒一個敢說自己精通c++。你也可以去看一下所有的c++編繹器，沒有任何一個敢說自己完全實現(xiàn)了c++的標準。不同的編繹器之間實現(xiàn)細節(jié)又不同。所以功能再強大沒有實用性，就失去了意義，只會制造更多的問題。
應用程序發(fā)生異常 未知的軟件異常
1.病毒木馬造成的，在當今互聯(lián)網(wǎng)時代，病毒坐著為了獲得更多的牟利，常用病毒綁架應用程序和系統(tǒng)文件，然后某些安全殺毒軟件把被病毒木馬感染的應用程序和系統(tǒng)文件當病毒殺了導致的。
2.應用程序組件丟失，應用程序完整的運行需要一些系統(tǒng)文件或者某些ll文件支持的，如果應用程序組件不完整也會導致的。
3.系統(tǒng)文件損壞或丟失，盜版系統(tǒng)或Ghost版本系統(tǒng)，很容易出現(xiàn)該問題。
4.操作系統(tǒng)自身的問題，操作系統(tǒng)本身也會有bug 。
5.硬件問題，例如內(nèi)存條壞了或者存在質量問題，或者內(nèi)存條的金手指的灰塵特別多。
應用程序發(fā)生異常怎么辦
1.檢查電腦是否存在病毒，請使用百度衛(wèi)士進行木馬查殺。
2.系統(tǒng)文件損壞或丟失，盜版系統(tǒng)或Ghost版本系統(tǒng)，很容易出現(xiàn)該問題。建議：使用完整版或正版系統(tǒng)。
3.安裝的軟件與系統(tǒng)或其它軟件發(fā)生沖突，找到發(fā)生沖突的軟件，卸載它。如果更新下載補丁不是該軟件的錯誤補丁，也會引起軟件異常，解決辦法：卸載該軟件，重新下載重新安裝試試。順便檢查開機啟動項，把沒必要啟動的啟動項禁止開機啟動。
4.如果檢查上面的都沒問題，可以試試下面的方法。
打開開始菜單→運行→輸入cmd→回車，在命令提示符下輸入下面命令 for %1 in (%windir%\system32\*.dll) do regsvr32.exe /s %1回車。
完成后，在輸入下面
for %i in (%windir%\system32\*.ocx) do regsvr32.exe /s %i 回車。
如果怕輸入錯誤，可以復制這兩條指令，然后在命令提示符后擊鼠標右鍵，打“粘貼”，回車，耐心等待，直到屏幕滾動停止為止。（重啟電腦）。
在開始之前，希望你計算一下 Part1 共占用的大小是多少呢？
輸出結果：
這么一算， Part1 這一個結構體的占用內(nèi)存大小為 1+4+1+8+1 = 15 個字節(jié)。相信有的小伙伴是這么算的，看上去也沒什么毛病
真實情況是怎么樣的呢？我們實際調(diào)用看看，如下：
輸出結果：
最終輸出為占用 32 個字節(jié)。這與前面所預期的結果完全不一樣。這充分地說明了先前的計算方式是錯誤的。為什么呢？
在這里要提到 “內(nèi)存對齊” 這一概念，才能夠用正確的姿勢去計算，接下來我們詳細的講講它是什么
有的小伙伴可能會認為內(nèi)存讀取，就是一個簡單的字節(jié)數(shù)組擺放
上圖表示一個坑一個蘿卜的內(nèi)存讀取方式。但實際上 CPU 并不會以一個一個字節(jié)去讀取和寫入內(nèi)存。相反 CPU 讀取內(nèi)存是 一塊一塊讀取 的，塊的大小可以為 2、4、6、8、16 字節(jié)等大小。塊大小我們稱其為 內(nèi)存訪問粒度 。如下圖：
在樣例中，假設訪問粒度為 4。 CPU 是以每 4 個字節(jié)大小的訪問粒度去讀取和寫入內(nèi)存的。這才是正確的姿勢
另外作為一個工程師，你也很有必要學習這塊知識點哦 :)
在上圖中，假設從 Index 1 開始讀取，將會出現(xiàn)很崩潰的問題。因為它的內(nèi)存訪問邊界是不對齊的。因此 CPU 會做一些額外的處理工作。如下：
從上述流程可得出，不做 “內(nèi)存對齊” 是一件有點 "麻煩" 的事。因為它會增加許多耗費時間的動作
而假設做了內(nèi)存對齊，從 Index 0 開始讀取 4 個字節(jié)，只需要讀取一次，也不需要額外的運算。這顯然高效很多，是標準的 空間換時間 做法
在不同平臺上的編譯器都有自己默認的 “對齊系數(shù)”，可通過預編譯命令 #pragma pack(n) 進行變更，n 就是代指 “對齊系數(shù)”。一般來講，我們常用的平臺的系數(shù)如下：
另外要注意，不同硬件平臺占用的大小和對齊值都可能是不一樣的。因此本文的值不是唯一的，調(diào)試的時候需按本機的實際情況考慮
輸出結果：
在 Go 中可以調(diào)用 unsafe.Alignof 來返回相應類型的對齊系數(shù)。通過觀察輸出結果，可得知基本都是 2^n ，最大也不會超過 8。這是因為我手提（64 位）編譯器默認對齊系數(shù)是 8，因此最大值不會超過這個數(shù)
在上小節(jié)中，提到了結構體中的成員變量要做字節(jié)對齊。那么想當然身為最終結果的結構體，也是需要做字節(jié)對齊的
接下來我們一起分析一下，“它” 到底經(jīng)歷了些什么，影響了 “預期” 結果
在每個成員變量進行對齊后，根據(jù)規(guī)則 2，整個結構體本身也要進行字節(jié)對齊，因為可發(fā)現(xiàn)它可能并不是 2^n ，不是偶數(shù)倍。顯然不符合對齊的規(guī)則
根據(jù)規(guī)則 2，可得出對齊值為 8?，F(xiàn)在的偏移量為 25，不是 8 的整倍數(shù)。因此確定偏移量為 32。對結構體進行對齊
Part1 內(nèi)存布局：axxx|bbbb|cxxx|xxxx|dddd|dddd|exxx|xxxx
通過本節(jié)的分析，可得知先前的 “推算” 為什么錯誤？
是因為實際內(nèi)存管理并非 “一個蘿卜一個坑” 的思想。而是一塊一塊。通過空間換時間（效率）的思想來完成這塊讀取、寫入。另外也需要兼顧不同平臺的內(nèi)存操作情況
在上一小節(jié)，可得知根據(jù)成員變量的類型不同，其結構體的內(nèi)存會產(chǎn)生對齊等動作。那假設字段順序不同，會不會有什么變化呢？我們一起來試試吧 :-)
輸出結果：
通過結果可以驚喜的發(fā)現(xiàn)，只是 “簡單” 對成員變量的字段順序進行改變，就改變了結構體占用大小
接下來我們一起剖析一下 Part2 ，看看它的內(nèi)部到底和上一位之間有什么區(qū)別，才導致了這樣的結果？
符合規(guī)則 2，不需要額外對齊
Part2 內(nèi)存布局：ecax|bbbb|dddd|dddd
通過對比 Part1 和 Part2 的內(nèi)存布局，你會發(fā)現(xiàn)兩者有很大的不同。如下：
仔細一看， Part1 存在許多 Padding。顯然它占據(jù)了不少空間，那么 Padding 是怎么出現(xiàn)的呢？
通過本文的介紹，可得知是由于不同類型導致需要進行字節(jié)對齊，以此保證內(nèi)存的訪問邊界
那么也不難理解，為什么 調(diào)整結構體內(nèi)成員變量的字段順序 就能達到縮小結構體占用大小的疑問了，是因為巧妙地減少了 Padding 的存在。讓它們更 “緊湊” 了。這一點對于加深 Go 的內(nèi)存布局印象和大對象的優(yōu)化非常有幫
重慶分公司
重慶分公司
