我的問題可能看起來如此普遍，但我真的需要你的幫助。我是新手嵌入式軟件工程師，我用TI DSC和STM微控制器完成了一些小型項目，包括C和C++編程語言。但現在我要開始爲一個大型項目編寫固件，我正在尋找一種方法來模擬我的固件，然後再實施它。實際上，我有兩個問題：在爲大型項目編寫固件時應該遵守的注意事項
1.我想知道專業嵌入式軟件工程師在開始編寫固件之前要做什麼？（對於固件建模，使用的是適合固件的理性玫瑰或企業架構，我認爲這兩個適合於IT和軟件應用而非固件）
2.什麼重要規則在寫固件的時候我必須觀察一下？ 例如我考慮一下：
a.Never曾經投入了大量的代碼放到中斷服務例程
灣千萬不要忙着等着迴圈 我還有什麼其他的事情要考慮？
這些類型的問題是題外話上如此，但無論如何，我會回答，因爲這些非常重要的考慮因素的任何地方，不是一個真正的論壇。通常情況如下：
編寫規範和要求。花一些時間在此，關注產品，而不是技術細節。 UML「用例」可以很方便，但常識也可以很好地工作。確保規範是一個活的文件，可以在必要時進行修改。
然後做方案設計，面向對象模型（稱之爲類/代碼模塊/翻譯單元或者你會）。寫下程序需要的代碼模塊，確保它們符合規範 - 理想情況下，每個要求導致特定的代碼（稍後會導致對該代碼的特定測試）。然後關注不同模塊之間的依賴關係：這應該是一個「從上到下」的依賴關係樹，驅動程序不依賴於HAL，而不依賴於調用者等等。用筆和紙畫出這棵樹。花式UML是好的，但沒有必要。
你需要儘早考慮便攜性。代碼是否應該在項目之間移植？ （很常見）編譯器之間？ （相當普遍）平臺之間？根據所需的可移植性級別，您可以使用設計作弊並跳過一些HAL。但是，將驅動程序與應用程序分開幾乎總是一個好主意。
關於「重要規則」，這些都沒有關係的方案設計階段。相反，這些應該在你的編碼標準文件中。最好是用於每個項目的公司標準。它應該關注于禁止所有不良做法，並且還應包含風格指南。對於嵌入式系統，我強烈建議將這個文檔建立在MISRA-C上，然後根據需要添加自定義規則（例如「保持ISR代碼最小化」），然後在其上添加樣式指南。請注意，編寫這個編碼標準是它自己的一個項目。
我覺得關於模塊性的一點是這個答案中最重要的一點。其他的錯誤，比如缺乏可移植性和錯誤風格，更容易修復（儘管它們不應該在第一次被忽略），而當代碼庫並不是可怕的意大利麪和遍佈各處的依賴關係時。 – user694733
@ user694733確實。來自小規模項目的嵌入式程序員幾乎沒有或幾乎沒有程序設計，但往往無法認識到爲什麼這是必要的。所以他們寫的東西沒有模塊化，結果緊密耦合：程序中的所有內容都取決於其他所有內容。全球範圍內有數百個布爾「標誌」和隱藏狀態變量，以及意大利麪全局數據。它變得越來越難以維持，直到它達到臨界質量並且永久地出錯。還沒有真正的方法來恢復這些程序，它們必須從頭開始重新編寫。 – Lundin
@Lundin非常好的一點。但是這個金屬的另一面。如果編碼人員完全不關心它，那麼關注模塊化和抽象有時會產生與您完全相同的效果。 MISRA-C是一個很好的起點，因爲這個標準是在真正的固件問題上發展和發展的。我在這裏經常受到批評，因爲我更喜歡函數中的一個返回點，因爲它使代碼清除並且對人類更具可讀性，而沒有或者很小的開銷。 –
單從正對固件的另一端，它是否將有一個API，別人必須以確保你問他們，你把它寫之前，他們需要的東西互動的親身經歷。 – Robinson
第一件事：收集要求！進行用例研究！找出需要的東西！然後根據您的信息進行分析。繼續從分析中進行設計。然後繼續製作測試用例。然後你實現這個設計，並確保它通過測試用例。根據需要迭代任何步驟或多個步驟。 –
感謝您的回答，您是否在工作中使用過基於UML的任何建模設計工具，或者固件沒有必要？（比如企業架構師） –