Bir RTC'yi ne sıklıkla sorgulamalıyım?

11

Henüz bir RTC kullanmadım, bu yüzden gerçek zamanlı saati okumak için "normal" yoldan tam olarak emin değilim. Düşündüğüm birkaç farklı yaklaşım var ama bu konuda bazı tavsiyelerde bulunmayı umuyordum.

İşte şimdiye kadarki zamanı okumayı ve kullanmayı düşündüğüm yollar:

Açılışta tarih ve saati alın ve RAM'e kaydedin ve daha sonra zamanlayıcı kesintisi kullanarak RAM değerlerini her saniye arttırın vb. Kod daha sonra tarih / saati bilmek gerektiğinde RAM'deki değerleri kullanır.
Bir zamanlayıcı kesmesi kullanarak, RTC'yi her saniye sorgulayın ve alınan tarih ve saati RAM'e kopyalayın. Yine, kod daha sonra tarih / saati bilmek gerektiğinde RAM'deki değerleri kullanır.
Her zaman zamanı bulmam gerektiğinde, RTC'yi sorgulayın ve doğrudan yanıtını kullanın.

Hangisi en iyi yaklaşımdır?

microcontroller rtc

— user9993
kaynak

15

En iyi yaklaşım, minimum miktarda kaynak kullanırken spesifikasyonlarınıza uygun yaklaşımdır. İhtiyaçlarınızı tam olarak bilmediğimiz için, "en iyi" nin bizim için çok az anlamı var.

— Scott Seidman

Hepsi çok iyi cevaplar Bir cevap seçemiyorum!

— user9993 12:05

23

Dördüncü bir seçenek kullanırdım.

Çoğu RTC çipinde 1 saniyelik darbe verme seçeneği vardır. Bu darbeyi MCU'nuzda bir kesme etkin girişe bağlamalısınız.

Süreyi programınızın başlangıcında bir kez çipten alırsınız ve belki o andan itibaren - belki de saatte bir kez.
Kesme sinyali daha sonra MCU'nuzda zamanı bir saniye artırdığınız bir kesme rutinini tetikler.

Bu düzenleme , RTC'yi aktif olarak okuma yükü olmadan RTC'nin ikincisine doğruluk sağlar .

— Majenko
kaynak

5

Bu yaklaşımı kullanırken, hangi saat kenarının bir artışı temsil ettiğini bilmek ve aynı zamanda bu saat kenarı sırasında devam etmekte olan herhangi bir okumanın terk edilmesini sağlamak önemlidir.

— supercat

Veya okumanın sadece ISR tarafından tetiklendiğinden emin olun - bir sonraki ISR tetiklenmeden önce okumayı yapmak için bir saniyelik boşluk elde edersiniz.

— Majenko

Mümkün olduğunda, RTC çözünürlüğü olay zamanlama gereksinimlerini karşılayacak kadar iyi ayarlanabiliyorsa, gerçek zamanlı saatleri saniyede bir işaretten daha hızlı çalışacak şekilde ayarlamayı ve genel amaçlı olay zamanlaması için kullanmayı tercih ederim; bu nedenle her RTC işaretinde her zaman bir kesinti olmayabilir. Ayrıca, alarmları ayarlarken, alarmın ayarlandığı anda RTC süresinin tam olarak ne olduğunu bilmek ve alarm ayarlanırken RTC'nin hareket edip etmediğini görmek için çoğu zaman önemlidir. 32-bit yonga satıcılarının neden sadece okuma yeteneği olan 47 bitlik bir sayaç

— sunmadığını bilmiyorum

... üst 32 bit veya alt 31 artı saat giriş durumu, senkronizasyon gecikmesi olmadan herhangi bir zamanda açılıp kapatılabilecek bir alarma ve alarm olduğunda herhangi bir zamanda yazılabilen bir alarm kaydına sahiptir. kapalı, semantikler ile alarm etkinleştirilirken bir artış meydana gelirse alarm oluşur . Bir çip, eşzamansız uyanmaları kabul edebiliyorsa ve yazılım uygun olduğunda yoklamayı iki kez kontrol ederse, başka bir donanım senkronizasyonu gerekmeyecek ve yazılımın diğer donanım senkronizasyonu biçimlerinin neden olduğu sorunlara geçici bir çözüm bulması gerekmeyecektir.

— supercat

9

3. ve 2. daha uygundur.

Çoğu durumda kullandığım 3. yaklaşım. Faydası, RTC'yi RAM'e yansıtmak konusunda endişelenmem gerekmiyor. Potansiyel eksiklik, RTC'yi seri veri yolu üzerinden sorgulamanın bir gecikmeye neden olmasıdır. Saniyede bir kez veri yazıyorsanız, bu gecikme önemli olmayacaktır.

2. yaklaşım da iyidir. Bir ayna saatinin tutulması, cihaz uzun bir süre çalışıyorsa bir zaman işleyişi hatası verebilir. Ayna saati, RTC'den ayrılabilir. RTC'yi düzenli olarak okursanız, sapma birikmez.
Ancak, interrupt servisi rutininin (ISR) kendisinde seri iletişim kurmamanızı tavsiye ederim. ISR'de bir bayrak ayarlayın ve main () içindeki seri iletişimi yapın.

ps Her durumda, DS1307 kullanıyordum.

— Nick Alexeev
kaynak

6

Bazı RTC'ler (örneğin, neredeyse hiç kimsenin artık kullanmaması gereken MC68HC68T1) tutarlı bir yanıt vermek için okunduğunda dahili sayımlarını duraklatacaktır. Kesintiyi en aza indirgemek için mümkün olduğunca nadiren okunmalıdır . Onlardan bir kez okuyun ve daha sonra MCU'nun RAM'inde saklanan zaman değerini güncellemek için zamanlayıcı kesmelerini kullanın.

— Ignacio Vazquez-Abrams
kaynak

Bu tür tasarımlar zihni şaşırtır. Bir artış sırasında meydana gelen okumalara sahip olmak rasgele veriler üretmek kolay bir problem olacaktır. Okumak, sayıların kaçırılmasına neden olmak, kayıp sayıları kabul etmek dışında çözülemeyen bir sorundur.

— supercat

2

Görünüşe göre çift tamponlama, bazı insanların cipslerini tasarlarken düşünmedikleri bir şeydir.

— Ignacio Vazquez-Abrams

Sorgulama sırasında bir değerin değişmediğinden emin olmak için kod kontrol ederse, çift arabelleğe almanıza gerek yoktur. Çip üzerinde gerçek zamanlı bir saat için, böyle bir tekrarlama-yok-yoklama yoklaması, bir kesme, RTC'yi ana hat koduyla aynı anda okumaya çalışsa bile çalışacaktır. Bazı çift tamponlu tasarımlar, güvenli bir şekilde birlikte varolabilen ana hat ve kesme kodunu yazmayı zorlaştırıyor ve gerçekten "yararlı" olduğunu düşündüğüm bir kod görmedim.

— supercat

5

RTC'nin kendi kristaline sahip ayrı bir çip olduğunu veya mikrodenetleyicinizle entegre edilmiş bir modül olduğunu ve yine ana saatten ayrı bir zaman kaynağına (32 kHz kristal gibi) sahip olduğunu varsayacağım. Ve RTC için zaman kaynağı mikrodenetleyici için olandan daha doğrudur.

RTC'yi ne sıklıkta okumanız gerektiğini belirlemek için, ana saatinizin ne kadar maksimum hata yapabileceğini bulmanız gerekir. Örneğin, ana kristal 20 ppm'de belirtilirse, bu% 0.002 ile aynıdır. Böylece sadece ana saat kaynağına dayanan bir saat günde 0.00002 * 3600 * 24 = 1.728 saniye sürüklenebilir.

Bu nedenle, RTC'yi günde sadece iki kez okursanız ve zamanlayıcı kesintisi kullanarak saniyede bir kez artırılırsa, asla bir saniyeden fazla kapalı olmazsınız - asla RTC'ye kıyasla bir saniyeden fazla kalmazsınız.

Daha önce varsaydığım gibi, RTC'niz kendi kristaline sahip ayrı bir yonga veya mikrodenetleyicinizle entegre edilmiş bir modülse, bunun doğru olduğu anlamına gelmez. RTC'de de hata olabilir. Örneğin, 5 ppm toleranslı bir 32 kHz kristal kullanıyorsa (10 ppm olanlardan biraz daha pahalı), günde 0.43 saniye veya ayda 13 saniye kapalı olabilir.

Bunu aşmak için, bir kayıt defterine bir düzeltme faktörü yazdığınız RTC'yi ayarlamanız gerekir. Bunu yapmak, hatayı pratik olarak sıfıra indirmenize izin verecektir. Ancak elbette , ayarlama yaparken referans olarak kullanmak için üçüncü bir harici saat kaynağına sahip olmanız gerekir . ABD'de son derece hassas bir referans 60 Hz bir AC hattı olduğu garanti olduğu tam olarak birbirini takip eden gece yarılarına arasında 24 saatlik bir süre içinde 60 * 60 * 60 * 24 (5.184.000) döngüler. Bunun yararlı olması için, 60 Hz gece yarısı arasında biraz kayabileceğinden, 24 saat boyunca zaman ayırmalısınız.

Başka bir mükemmel zaman referansı, projelerinde zaten GPS donanımı varsa GPS (10 ns doğruluk) kullanmak olacaktır.

Bunun yerine RTC süreleriniz hücresel ağ süresi (AT + CCLK? Çağrısı) veya NTP kullanan bir ağ zaman sunucusu gibi harici bir kaynaktan geliyorsa, RTC değerini "ayarlamak" için hiçbir şey olmayacağından olduğu gibi kullanabilirsiniz .

— tcrosley
kaynak