題:
實時系統是否需要實時時鐘(RTC)?
www
2018-10-29 15:02:15 UTC
view on stackexchange narkive permalink

假設我們正在研究由高分辨率計時器組成的實時Linux系統和硬件,那麼具有RTC是否會影響系統的實時性?

這裡它說它減少了CPU和內存的使用,但是有什麼方法可以比較兩者之間的差異嗎?

鏈接中的比較很愚蠢。
尼爾,希望您能重溫一下這個問題:我的猜測(根據我對我的出生地的了解以及對您暱稱的後綴的了解)是您比我更講母語,但不會影響實時性”是正確的說法嗎?
是的,@pipe,和最重要的是,即使數字是完全錯誤的。我將很高興購買價格為DS12C887的RTC芯片,該芯片具有“ 100年內出現1秒錯誤”的信息。實際上,我會購買盡可能多的積蓄來購買。這是300ppb的精度。超過100年。那是一些嚴重的頻率問題。
實時系統和實時時鐘是不同的東西,沒有可比性。RTC用於計時,而Real Time System用於實時服務(不是UTC中的,而是為了快速)。
-1
@pipe DS12C887,[100年計劃版本](https://en.wikipedia.org/wiki/Radioisotope_thermoelectric_generator#/media/File:Soviet_RTG.jpg)。
@MarcusMüller,300ppb的準確性/穩定性會很不錯,如果不是因為歐盟不斷威脅要擺脫leap秒和節省日光的事實的話:)
-1
@ChrisStratton我刪除了我的答案,儘管我仍然相信如果使用RTC,微控制器不需要中斷來獲取時間,它可以向RTC請求時間(即使用RTC)。
並非所有RTC都是一樣的,例如,有些可能比在處理器中使用時鐘和計時器更好(而向上運行),而有些則可能比調節溫度更好。還有其他一些方法可以在通電時不一定需要板載RTC。RTC通常用於保持時間,而不是其他任何時間。可能會有一些警報,但這又是一個計時功能。我停止假設linux保持了良好的時間,因為許多年以來板載RTC被認為是不正確的,而是使用了基於中斷的時間(這會導致明顯的時間漂移)。
_“幾乎可以忽略不計。100年中大約1秒”。該頁面是胡說八道。
@LightnessRacesinOrbit即使如此穩定,任何RTC芯片本身也無法解決leap秒問題。因此,無論如何,RTC每2-8年就會落後一秒鐘。
-1
@LightnessRacesinOrbit檢查OP中的鏈接。文本指的是DS12C887,它是“實際” RTC,(僅)提供基於日曆的時間信息。實際上,我還沒有看到標記為“ RTC”的芯片,它不是基於日曆的,而是僅由電池供電的秒計數器。
-1
@Wossname擺脫leap秒?您對此有參考嗎?
@glglgl: [Wikipedia](https://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish_leap_seconds)是一個起點。
@DennisWilliamson謝謝。這對我來說確實是新的。但是似乎他們談論從長遠來看,而不是在未來幾年內。
我投票決定關閉,因為這是關於實時含義的語義論證。我個人認為這很愚蠢。即使日期錯誤,實時操作系統仍然是實時操作系統。
七 答案:
R.. GitHub STOP HELPING ICE
2018-10-29 20:41:14 UTC
view on stackexchange narkive permalink

您鏈接的文章很完整,完全是胡說八道。 “實時時鐘”中的“實時”(用於指代本文中介紹的硬件設備的類型)和“實時系統”中的“實時”是完全不同的術語。前者意味著使用長壽命的鈕扣/硬幣型電池來存儲當前日曆時間(通常是非常差的近似值,而不是像要求的鏈接文章所述的高精度),並且無需外部電源就可以提前。後者意味著對事件的響應具有從事件發生時間到響應時間的潛伏期的嚴格限制。

文章中的其他一些內容確立了它應被視為不可信的地方:

幾乎可以忽略不計。在100年內約為1秒

100年

1秒大約是317 ppt(是的,這是每萬億的分量)。使用任何現有的商用時鐘技術都無法獲得這種時鐘穩定性。即使每年達到1秒,也至少需要一個OCXO,這需要一個高功率,始終開啟的烤箱來調節溫度。可以使用由長壽命鈕扣電池供電的設備來獲得它的想法是可笑的。

數字時鐘,考勤系統,數碼相機等實時系統

這些都不是實時系統。

第一句話實際上是這裡必須說的所有內容。整個網站充其量似乎令人懷疑。
-1
實際上,那些系統很可能具有實時組件,儘管它們是“軟實時”,因為丟失/超出處理刻度的後果很小。不過,鏈接作者並沒有誤入歧途。
-1
@R ..即使利潤豐厚,並非所有系統都是實時的。如果系統無限期掛起,則它不能是實時系統。系統必須具有“絕對保證”,即時隙只需要有限的時間,並且掛(死鎖/活鎖)根據定義是無限的。
但是,關於實時系統到底是什麼的元討論不在評論部分。
@Uwe:確實我搞砸了,但是現在我再看一遍,我認為我落後10的2個因素-是0.316ppb嗎?計算為1s /(100 * secs_per_year),其中secs_per_year = 31556952。
@R ..只要乘以100 * 365 * 24 * 60 * 60
@Uwe:是的,大約是100 * secs_per_year(模leap年),但是相對誤差是每秒/該數量。
@R .. 100 * 365 * 24 * 60 * 60是每100年的秒數。不考慮leap年。所以您是對的,它是317 ppt(萬億分之一)。請原諒我的錯誤。
@Uwe:沒問題。我只是想在更新答案之前澄清一下,我現在已經完成了。
MaNyYaCk
2018-10-29 15:22:05 UTC
view on stackexchange narkive permalink

實時系統是在指定的時間內響應內部或外部事件/刺激的東西,該時間通常以毫秒或微秒為單位。它需要精度較低的計時器而不是RTC。

您的問題的答案是“否”,它不會影響系統的實時性。

這很簡短,是對IMO問題的直截了當的答案。
一些像銀行這樣的聯邦實體,基於原子時鐘在其服務器中使用1ns RTC。甚至暗示篡改其微波鏈路都會改變到接收器的傳輸時間。快速RTC也適用於多相信號量。
一些實時系統不需要計時器,因為它們完全是事件驅動的,並且不需要任何事件都基於時間。系統只需要在分配給該事件的時間段內響應每個事件,包括當多個事件彼此非常接近時。在某些情況下,可能需要搶占式內核。可以使用外部計時器來驗證系統是否在其時間限制內運行。
如果您想要一個真實的示例,MicroWare的用於Motorola 6809 / Hitachi 6309處理器的OS-9操作系統是一個實時OS。Tandy彩色計算機系列使用6809s並運行OS-9(我第一次接觸過* nix式OS),並且實時時鐘從來都不是該系統上的標准設備,並且OS-9並不是必需的。
Anonymous
2018-10-29 16:37:34 UTC
view on stackexchange narkive permalink

如果您的系統在重置後具有RTC且處於脫機狀態,則可以在日誌中輸入正確的日期。如果您需要仔細查看日誌,並且時間戳不正確會使您,您的軟件開發人員和客戶發瘋,並且在一般情況下進行調查幾乎是不可能的。

您提到的文章中的容易或困難,低或高是一種個人見解。如果您以前從未做過並且沒有明確的系統要求和工作說明,那將是困難且昂貴的。當您知道需要什麼以及使用哪種最佳設備時,它既便宜又便宜。

問題是如何量化實時系統中RTC與無RTC相比減少的CPU時間和內存使用。您的答案無法回答。
@pipe這取決於CPU架構和要求。用給出的稀缺信息根本無法回答。我的回答是說,為什麼** RTC必須存在於其中**而不是通用的blak-bla,否則它將如何消失。程序員和系統架構師可能會花一些時間在時間上,設計出好的系統和代碼,而壞的系統和代碼。
supercat
2018-10-29 21:02:28 UTC
view on stackexchange narkive permalink

在大多數係統中,RTC外設相對於其他形式的計時的唯一真正優勢是,當系統的其餘部分進入睡眠狀態或在某些情況下通電時,RTC的時間測量將不受影響。完全關閉。實際上,許多RTC外設的設計方式使其無法用於大多數目的,而不是記錄大約一天中的時間。例如,許多RTC外圍設備(可能是多數,但可能不是絕大多數)僅限於以一秒為增量報告時間,並且其中許多有時至少需要在設置警報或-在某些情況下-甚至只是試圖閱讀時間。因此,使用RTC的通常方法是簡單地將其值複製到啟動時更有用的時鐘,在設置“ wall time”時進行設置,而在其餘時間忽略它。

使用47位紋波計數器可以將RTC芯片可以實現的所有有用目的以最低的成本和功耗實現,該計數器的位可以異步強制為48位電池供電的RAM(存儲一個“增量”值),一個32位警報寄存器和一個相等比較器,其比較器的低位與比較器的高位進行門控(因此,除非或直到高位匹配,否則低位將不被檢查),一個簡單的去抖動器(一系列緩慢的反相器和一個NAND,一個異步可重置的喚醒鎖存器以及用於異步讀出時鐘的電路。在遞增時讀取時鐘可能會產生假結果,但是如果任何兩個連續的讀取都匹配,則兩者會確保正確無誤,並且任何四個連續的讀取都將保證包含兩個匹配的(因此是正確的),除非在第一次和最後一次之間的間隔超過1/32768秒。設置警報可能會產生虛假的喚醒事件,但是序列重要性:

  • 禁用喚醒鎖存器中斷
  • 在當前時間之前將喚醒時間設置為最多0x7FFFFFFF個滴答(大約9小時)
  • 重置喚醒電路
  • 讀時鐘
  • 如果新讀取的時間表明已經達到喚醒時間,請採取適當措施
  • 啟用喚醒鎖存器中斷

應充分容易地處理所有邊緣情況,以適合於通用計時用途。不幸的是,無論出於何種原因,RTC外設都從未採用這種方式設計,而是更加複雜且用處不大。

“真實” RTC還提供日曆功能(每月,每週、,年...),這可能在軟件中實現您很麻煩。
@JimmyB:軟件無論如何都需要對日期和時間做一些瑣碎的事情,無論如何通常都將包含這樣的邏輯,並且能夠保持線性格式,除非執行用戶I / O時要比從無用的BCD YMDhms轉換要乾淨得多。每次讀取RTC時將其轉換為線性時間,並在寫入時轉換回無用的fromat。
@JimmyB:作為一個簡單的示例,如果要在似乎是2016-03-01 00:30的時間打開系統電源,而最後一次在2015-10-01的00:30:00開啟電源,那麼幾點鐘是嗎軟件需要知道2016年2月有29天才能確定時間是2015-02-29 23:30:00,那麼日曆硬件究竟能買到什麼?
OP中引用的RTC芯片本身可以正確處理leap年。
“需要處理日期和時間的重要事情的軟件”當然。但是RTC只是一個“時鐘”。它告訴您現在是幾點,它不會為您計算出幾秒鐘的年齡。因此,如果要為日誌條目打上時間戳,則只需要RTC,而不必處理任何日期/時間數學運算。如果您想按時進行任意計算,那對您來說並沒有太大用處。
@JimmyB:如果從“夏令時”過渡後首次打開系統電源,則軟件將需要將時鐘重新設置為一個小時。如果恰好發生在午夜和凌晨1:00之間,則需要將日曆重新設置為一天,這又需要了解日曆。確實,除非要求用戶手動設置工作日和日期,否則應用夏時制的最簡單方法是處理線性日期。
Anthony X
2018-10-31 05:03:11 UTC
view on stackexchange narkive permalink

這似乎是圍繞“實時”一詞使用的術語問題。

實時時鐘

實時時鐘是一種用於穩定/準確(在一定公差範圍內)計時的設備,因此主機系統可以使用它來將事件/動作與發生的時間和日期相關聯。

您可以認為實時時鐘類似於與計算機連接的數字手錶的內部。它具有獨立供電的時間基準,旨在保持穩定和合理的準確性。就像數字手錶一樣,它不會因為主機關閉而丟失當前時間。實時時鐘主要是為了方便安裝在計算機上,因此用戶不必在每次啟動系統時都重新輸入當前時間和日期,也不必進行頻繁的調整來補償漂移。

實時時鐘的替代方法是使用由系統時鐘驅動的軟件和內部計時器。這樣的方法是可行的(原始的IBM PC就是這樣),但並不是特別穩定。在操作系統關閉,掛起或崩潰的任何時候,它也會丟失日期/時間的跟踪。

實時系統

將“實時”一詞應用於計算機系統或應用程序時,它表示的是一種在很短的確定性時間內(通常只有幾毫秒,有時甚至更少)對現實事件做出響應的系統,具有同時輸入的定義順序。實時系統用於諸如機器控制,機器人,模擬和遊戲之類的事情。儘管實時應用程序可以利用當前時間和日期信息,但是應用程序並不是“實時的”,因為它利用了當前時間和日期。

實時時鐘與高分辨率計時器

如上所述,實時時鐘的目的是可靠地跟踪當前日期和時間,通常只跟踪秒和秒。一個好的人將具有最小的漂移(每天增加或丟失的秒數)。實時時鐘通常沒有高分辨率。與現代CPU時鐘相比,它們的基本時鐘通常運行得很慢。這是為了最大程度地減少功耗(消耗其獨立電源),以便在長時間關閉主機電源後,時鐘將繼續可靠地保持時間。

高分辨率計時器與當前時間或日期無關;它的目的是以某種精度(也許微秒或更短)測量時間間隔。為此,它必須基於穩定的高頻時鐘-通常是計算機系統時鐘。高分辨率計時器通常也不關心長時間的漂移,因為通常的目的是測量較短時間的時間。高分辨率計時器沒有與實時時鐘相同的功耗問題,因為在關閉主機電源時,它們沒有工作要做。

有點兒麻煩,“最短的可能”不是實時的。實時是指確定時間內的響應,如果同時發生多個事件,則以定義的順序響應。
Sean Houlihane
2018-10-29 17:25:57 UTC
view on stackexchange narkive permalink

如果您要與互聯網上的其他計算機進行安全通信,則需要一個實時時鐘(並非100%一定要使用,但是如果您沒有本地時間參考,則需要信任其他東西),並且除非您知道日期,否則您將無法信任證書。

因此,不,您不需要所有“實時”系統。但是,根據您的應用程序,您可能仍希望將RTC設為低功耗狀態下獲取良好時機的最節能方式。

這不是完全正確的。例如,您可以信任證書(尤其是固定證書),即使該證書已過期或理論上是在將來似乎發布的。但是,通常最好先嘗試做一個SSL客戶端,然後再進行NTP修復。自然,必須將NTP的安全方案設計為有效,而無需從明智的時間觀念入手。
過度誇張是一件令人心動和美麗的事情,如果它形成了主要信息,那是錯誤的。從根本上講,密碼的任何一種操作方式都不要求時間或日期。
marshal craft
2018-10-29 21:06:58 UTC
view on stackexchange narkive permalink

我認為使用實時時鐘的主要原因是精確的時間間隔。常規時鐘通常會用電容器進行修整,並可能由於多種因素(例如時鐘時序電路的電容/電阻失調,時鐘時序電路的不確定性)失控而導致頻率差異較大。既可以達到性能的雙重目的,又經常有可編程邏輯來劃分時間,而這又會引入錯誤。

通常,RTC可以與計時器和看門狗等配合使用,從而可以保證或良好地假設,以規則的精確間隔(甚至可以與各種事物保持同步)執行給定的過程或代碼。使用常規時鐘很難做到這一點。否則您需要在生產中非常小心時鐘是準確的。您會看到諸如音頻之類的東西,以及使用rtc代替高速系統時鐘可能不需要的東西。

至於RTC的含義,我不能肯定地說。我知道Linux是嵌入式世界中流行的工具,但是我不確定Linux在所有實時應用程序中的表現如何。多線程可以使執行時間不確定,但是當硬件大大超過性能要求時,即使在實時應用程序中,許多解決方案也可以正常工作。

然後是關鍵任務和低性能應用程序。這裡需要做的一件事是確定性的並且通常是較低複雜度的解決方案。在這裡可以明顯地使用RTC。 Linux可能提供對與其耦合的中斷的特殊訪問。在我看來,對於確定性實時,您不僅需要rtc,而且還需要中斷或操作系統。訪問它們。

如何將RTC與看門狗精確耦合,才能確保時鐘與各種事物保持“同相”?
好的,如果您使用外部時鐘源,則取決於該時鐘源以及與其相連的電路,例如電容,電阻或阻抗。因此,這可以通過諧波振盪(其解決方案是一個波,然後看相角等)以及微處理器的應用來回答您所要求的一切來描述。不幸的是,在很多應用程序中都必須考慮所有這些東西。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 4.0許可。
Loading...