我正在開發一個項目，我需要支持ms粒度的日曆+時鐘。 我設法配置芯片的RTC來幫助我保持時間，但是我很難找到正確的數據類型來表示時間。嵌入式系統時鐘
我總是time_t（Unix的時代）的工作，但它是基於秒，所以它不是去上班。 struct timeval怎麼樣？看起來在演示（asctime）的上下文中不支持該結構作爲struct tm。
什麼是表示在嵌入式系統中的時間的優選方法是什麼？
注：該系統基於接口後端服務器的Java，需要的時間與之同步，所以我在尋找可能在幾種語言進行開箱即用的結構。
你需要毫秒的粒度，並與一些Java的互動基於雙方認爲，64位的時間，因爲時代將是一個合適的，直接的，選擇。
今天大多數編譯器都有64位類型;如果不是，你可以將它作爲兩個32位類型的結構以本地結尾的適當順序處理，並放入代碼來處理進位。
即使編譯器可以處理64位類型，我也不希望在嵌入式系統上使用它，這些嵌入式系統本身無法處理它們，具體取決於使用這些值進行的操作的數量。 –
如果需要幾毫秒，一個32位值將在大約49天內溢出。設計一個具有這種正常運行時間限制的系統似乎是一個壞主意，所以設計一些與遠程系統所需要的兼容的東西會更好。現在32位MCU的成本只有8位，這真的不是什麼大問題。正如我所提到的，32位值的結構和手動處理溢出是一種選擇，儘管總是花時間週期去做64位的情況可能會更好，並且避免定時器ISR出現意外的風險每49天需要更長的頭髮。 –
姆姆，好點，我忘了毫秒的事情（這裏遲到了）。 –
有毫秒和毫秒，一個很容易，另一個很難。
我們運行，其具有以在固體光柵操作1ms的硬件定時器中斷循環，處理的東西（例如馬達控制）。我們從這個例程中增加一個全局的32位「ticks」值，然後可以用它來計算需要在亞秒間隔內發生的事情（EG每隔50ms輪詢一次）。
這與使用微型硬件定時器作爲計時參考不同，系統中任何事物的準確性都存在問題 - 從您的時鐘晶體的準確性到所有各種預分頻器，中斷延遲，等等。現在，我們不關心我們的電機控制程序是否每秒運行999次或每秒鐘1001次，或者如果我們每49.5ms輪詢一次引腳的狀態而不是50次，因爲它足夠接近，重要的是它及時發生。在24小時的過程中，我們最終可能會得到比「毫秒」更多的「滴答聲」，這會造成可怕的手錶。
例如 - 不時鐘分頻器計數到N，然後復位，或n-1和復位？它是立即重置還是需要一個時鐘週期？這種細節使得微軟的時機頭痛。
我會使用RTC作爲時間參考，然後可能會同步ms計數器到秒的滴答聲（每1Hz RTC中斷重置「ticks」爲0），這將意味着您的ms值會相對於RTC來說，只有很小的一部分。您甚至可以直接讀取RTC的輸入時鐘寄存器，以提取運行RTC的更快的時鐘（通常爲32.768kHz時鐘）。我們這樣做是爲了從我們的1kHz定時器的預分頻器時鐘寄存器獲得微秒值。這並不完美，我們不使用它來保持時間，只是爲了趕上亞毫秒事件。
或者，看看如果你真的需要 MS在所有的應用程序，或者如果你能彌補一些在100ms內這和報告，它不是像JS是原子時鐘級時序明智的 - 這是甚至沒有米老鼠手錶級。如果你確實需要這種準確性，那麼你做錯了。
你有操作系統嗎？ –
C或C++？選一個。 –
@JoachimPileborg，目前沒有操作系統 – stdcall