文章

目前顯示的是 十月, 2009的文章

如何有效地報告錯誤

以下文章是轉po Simon Tatham 先生的文章。 翻譯的部份似乎是對岸的網友翻的,這點我就不太清楚了 ^^"" --------------------------------------------------------------------------------- 介紹 寫過供大眾使用軟體的人可能都收過一份以上的爛錯誤報告. 有啥都沒講的報告(這個程式不會動), 有不合理的報告或資訊不足的報告, 也有提供不正確資訊的報告. 還有一些報告查到後來不是使用者自己攪錯, 就是其他程式惹禍, 或是網路斷線等等. 有個理由可以解釋為什麼技術支援工作這麼難做, 原因就是這些亂七八糟的錯誤報告. 不過並非所有錯誤報告都是這麼糟糕. 我工作之餘有在維護免費軟體, 有時候會收到一些非常清楚有幫助而且 很有內容 的錯誤報告. 我會試著在這篇短文中清楚說明良好錯誤報告的重點. 基本上我希望全世界的人在報告任何錯誤前都能讀讀這篇短文. 當然我更希望每個送錯誤報告給 我 的人都讀過. 簡而言之, 錯誤報告的目的是要讓程式師能親眼目睹程式出錯. 你可以親身示範給他們看, 也可以提供一份詳細而徹底的指令教他們如何重現問題, 如果他們可以重現問題, 就會試著收集更多資訊去瞭解問題的原因. 如果他們無法重現問題, 就只能要你幫他們收集資訊. 在錯誤報告中, 必須要把真實發生的事實(我在電腦前看到這個狀況)和臆測(我 認為 問題可能是)很明顯的區分開來. 必要時可以把臆測略過不提, 不過事實絕對不能漏. 因為你希望錯誤能被修正, 才會提出報告錯誤. 沒有必要對程式師惡言相向或故作無助: 問題有可能是他們搞的, 但也可能是你自己惹的. 或許對程式師發脾氣有點道理, 不過如果你能協助提供所有必要的資訊, 問題就能儘快修好. 另外也請記住, 既然程式是免費的, 表示作者是基於好心而提供的. 如果很多人對他們不禮貌, 他們可能就不會那麼好心了. "程式不會動." 多少相信程式師的基本智能吧. 如果程式完全不會動, 他們應該會發現的. 既然他們沒有發現, 表示他們用的時候沒問題. 所以要不是你的作法和他們不同, 就是你的環境和他們不同. 他們需要資訊, 錯誤報告的目的就是提供這些資訊. 資訊過多往往好過資訊不足. 很多程式

Intel Hex File -- Part 1

這二天因為工作上的需要,所以在研究Intel Hex File 的格式: 這邊是我下載來看的PDF和wiki http://pages.interlog.com/~speff/usefulinfo/Hexfrmt.pdf http://en.wikipedia.org/wiki/Intel_HEX 以下是從PDF 中整理出來,不同bit support的record 類型: Data Record (8-, 16-, or 32-bit formats) End of File Record (8-, 16-, or 32-bit formats) Extended Segment Address Record (16- or 32-bit formats) Start Segment Address Record (16- or 32-bit formats) Extended Linear Address Record (32-bit format only) Start Linear Address Record (32-bit format only 先來談General Record Format: 這是個sample: : 01 0000 00 AA 55 其中: : :record mark, 不管這本記錄的用途為何,都必定用這個符號開頭。 01 :RECLEN, 用來指定後面的Data/Info 長度。上限值是FF,也就是後續的data 不得超過255的長度限制。 0000 :OFFSET,只在data record中有用。如果這個field 是無效的話,必須指定"0000"才行。 00 :RECTYP,也是就record type, 以用表記data 的類型。 AA :data, 如同前面reclen 所說的,長度上限為255。 55 :CHKSUM,也就是check sum。把除了record mark以外的字元,二二相加後進行二的補數運算。 wiki 上的SAMPLE:03 + 00 + 30 + 00 + 02 + 33 + 7A = E2 => chksum=1E 類型的種類如下: '00' Data Record:一般的資料 '01' End of F