pretty code

2022年6月14日 星期二

WFH 所需頻寬統計

Wi-Fi 訊號一直很差,WFH 視訊開會時確實造成不少困擾,故重要會議時都改用手機 USB 網路分享,手機一直插著這樣下去不是辦法,還好我有一個預付卡門號,上面還有幾 G 可用,買了一個 4G USB 網卡來改善 WFH 辦公環境好提升工作效率。

在偶爾上上網查詢資料的情況下,随便看一下流量統計似乎都不到 20MB。

今天在開了 2 個小時又 7 分鐘會議的情況下,使用 Skype Bussiness 約莫用了 500 MB 流量。

2022年6月6日 星期一

上週生活雜感

上星期因為測試進去辦公室兩天,再加上遇到一些問題心中頗有感觸,不得不提筆記錄一下。

首先是在研究 C++ 書籍時,無意間看到 tinlans 大神回答網友的某篇文章,看到大神在回覆文章時,還不厭其煩的先搜尋一下對方的發文才決定如何回答 C++ 參考書籍的問題,這才是理工人該有的素養,實事求是,可惜我的 Level 不夠,無法遇到這樣的隊友,真希望我有大神的萬分之一功力就好,我現在也不會被 C++ 搞到好煩XD

再來是進辦公室後遇到網路問題,也算是被折騰了一下,後來終於在快下班時把所有想法都搞定,可以悠閒的觀察測試結果。還好我有帶 Elipsa 進去,在觀察測試結果時,可以邊看一下書避免無聊,雖然因為不想多帶翻頁器導致無翻頁器可用,但因為兩年前有開發過軟體翻頁器,馬上拿出我的手機使用這個軟體,一邊按著音量鍵翻頁看書,一邊又可以觀察測試結果避免 miss,真是聰明的工作方式呀?


最後則是我的書房越來越潮濕了,目前看來是外牆的防水層沒了,導致書房的兩面對外牆都是濕氣,不是不想花錢找蜘蛛人搞定,但以裝潢修繕業的陋習來看,在沒有熟識的人介紹下,你肯多花錢都不一定可以找到有良心的施工廠商!還好我的爸媽已經不住在這裡,不然對他們的身體健康一定不好。

有時候敗家就是一個爽字而已

最近買了四樣東西,都是我考慮好幾天以上才購買的東西,甚至其中有一項東西我可能考慮了兩年有吧XD

第一個是 Supernote A6 X,購買它的原因是被討論區的某位社友形容燒到,包括內建 Kindle App、PDF 可支援裁邊,再加上略輸給 reMarkable 2 的手寫體驗,我大概考慮了一兩個星期有,後來還是拿起我的魔法小卡勇敢的給它刷下去,可惜因為疫情關係,現在應該還躺在對岸倉庫中XD


第二個是 OWON VDS1022I,兩年前在開發翻頁器時,因為需要製作升壓或降壓電路,想來看一下供電電源是否穩定,不過因為價格確實較高,故當初並沒有購買。最近因為某些原因,我需要研究一下示波器,剛好又買了幾顆穩壓 IC 想要配合 3D 列印做一支漂亮一點的翻頁器,再加上那麼貴的電子閱讀器前後買了十台有,吃飯的工具不買一台似乎說不過去?於是在端午節前夕終於收到它本人,目前的感想就是一分錢一分貨呀,不過我最不滿意的是它的 UI 過於陽春,也不方便測量,如果有機會可以研究它 USB 封包的格式,我想自己來寫 UI 應該是比較好用?但暫時先這樣用即可。



第三個是 Nintendo Switch OLED,既然都買了示波器,乾脆一不做二不休的連電動都買了,另外還買了兩個數位版遊戲,我終於可以玩到去年就想玩的《暗黑破壞神 2 重製版》了!不過坦白說,可能是人老了,覺得玩遊戲很浪費時間,這應該也是四樣中我最後悔購買的東西,之後再視情況買幾個瑪莉歐的遊戲來玩玩,看看是否能從中找到玩遊戲的樂趣?我想這應該跟我童年本來就沒有一直在玩遊戲有關,絕對不是說任天堂不好,畢竟我還是很喜歡任天堂的《太空戰士三代》,這是我童年唯一自己購買的卡匣,它應該也是我人生當中覺得最好玩的遊戲無誤。

最後則是 NeoFlam FIKA 鑄造不沾炒鍋 26CM,由於我平常用的是父母搬走後留下的不鏽鋼炒鍋,雖然是雙人牌的,但坦白說不太好用,尤其煎蛋時那一層遺留蛋屑,都讓人覺得很阿雜,雖然阿淇博士常說什麼要注意萊頓弗羅斯特現象,但我有那麼厲害我就去當特級廚師了還做什麼工程師XD

終於在前天悠哉的星期六購物時,因為不用特別買生鮮食品可以去 HOLA 閒逛後,入手了這隻鍋子,試用的感想就是為什麼不早點買,我想我的廚藝能力至少有加 30% 有,大概可以算是我心目中的傳說廚具之一。


後來我上網查了一下,好像很多人用了半年後還是會沾鍋,不過我就是把它當陶瓷鍋用,不沾只是附加的好處,幾個月後再來看看是否開始會沾鍋呢?

2022年6月2日 星期四

阿伯出事了XD

好久沒有關於 UEFI 的文章了!雖然我幫自己及同事寫了很多 UEFI Sell 下的小程式,但大部份都是基於 pure C 的程式,很少有用到 UEFI 相關的東西,最多用到一些 SetVariable 以及呼叫兩個 Services 的 API 居多。

今天為了檢查前天進辦公室跑的測試問題,很早就進來辦公室,居然發現是因為網路的問題而不是我原本想的系統問題?然而最近幾次進辦公室都有用 Wireshark 來檢查 ARP 廣播封包的數量好確保 UEFI 網路可以正常工作,我們公司的人確實大部份都是 WFH,故不像以前有七八十趴的 ARP 廣播封包,況且出問題時是凌晨四點多鐘,我是不相信那時候公司有什麼人啦!但你知、我知、獨眼龍也知 UEFI network stack 本來就只是堪用,實在不建議拿來用在專案上,無奈我只是個細漢,只好一直面對這種跟程式無關的 issue。

說也湊巧,前一天也是為了解決跟我自己程式無關的 issue(UB,嚴格來說是未定義行為),更新了一些 code 來做防衛駕駛,既然前一個測試被中斷了,想說還是先花一點時間來跑測試驗證這個問題好結案,不然真的很阿雜。沒想到中途又一直遇到網路問題,此時又拿出了 Wireshark 來檢查 ARP 廣播封包,發現一樣剩不到 15%,故應該不是廣播封包問題?

在我使出了任何絕招都無效後,正準備發個郵件問一下 IT 公司網路最近是否有異動?但據我之前經驗,除了廣播封包這個問題外,我們 IT 在收到申請網路特殊用途後,其實不太會去改變申請的網路設定,無奈一時又沒有其他想法!

就在這個 moment,我突然想到好幾年前,我們開始一個新專案後,我本來用的 UDK base 似乎也要跟著更新,當初我最後用的是 UDK2018,不然網路就是會有奇怪的問題,此時 Wireshark 看到的現象就是掉封包或是 network stack 有很多奇怪的行為。剛好今年 WFH 時,我並沒有特別準備 UDK2018 來 build 我的網路程式,而是延用另一個 tool 內建的 UDK base,雖然我無法看出是那個版本,但我直覺應該是 UDK2014 左右的 base。

知道問題後並不是就沒事了,我以後要怎樣避免這個 UDK base 的問題?雖然說寫文件可以解決這個問題,但我們公司的專案並沒有很系統的規劃,導致文件散落一地,我想就算我寫了文件,其他人也不見得遇到網路問題就會想到是這個原因而來我寫文件的資料夾找答案(這就是沒有系統規劃專案的壞處,沒有固定的地方來放文件,所以你也不會有事就去找文件)?

本想 Google 看看是否有 UDK base 的相關 define 來做編譯檢查,無奈這是個很冷門的問題,我用英文在網路上找不到答案。

我又試著用 file search 關鍵字的技巧,看能不能硬在 UDK base 裡找到 define,無奈用了 UDK2018VERSION 等關鍵字都沒有幫助,因為這個搜尋的結果太多,我不太可能一個一個 review,只能粗略的看一眼但仍然沒有答案。

最後我決定在 edksetup.bat 做手腳,我在檔案開頭加了以下指令:

echo #define UDK2018 > Stdlib\Include\ABC.h

然後我在我程式的 main.c 加了一個 #include <ABC.h> 並寫清楚註解以提醒後人。

因為我只在我公司電腦的 UDK2018 base 加了這個 trick,故當我這個專案被別人用在別的 UDK base 就一定會遇到 compile error,此時他看我的註解就知道問題是什麼,這樣就達到提醒的作用了,因為那個別人也包括未來的我XD

就在寫此文章的同時,又突然想到用 2.7(UEFI_Spec_2_7,目前最新是 2.8)來搜尋,果然在 MdePkg\Include\Uefi\UefiSpec.h 找到一些 defines,故我們可以用 EFI_SPECIFICATION_VERSION 是否等於 0x20046 或是 EFI_2_70_SYSTEM_TABLE_REVISION 這個 define 是否存在,並配合 #error 這個前置處理器語法來觸發 compiler error。