Bao lâu tôi nên truy vấn RTC?

11

Tôi chưa sử dụng RTC nên tôi không hoàn toàn chắc chắn về cách "bình thường" để đọc đồng hồ thời gian thực. Có một vài cách tiếp cận khác nhau mà tôi đã nghĩ đến nhưng hy vọng có một lời khuyên về nó.

Dưới đây là những cách tôi nghĩ về việc đọc và sử dụng thời gian cho đến nay:

Nhận ngày và giờ bật nguồn và lưu vào RAM, sau đó thông qua việc sử dụng bộ đếm thời gian làm tăng các giá trị RAM mỗi giây, v.v. Sau đó, mã sẽ sử dụng các giá trị trong RAM bất cứ khi nào cần biết ngày / giờ.
Thông qua việc sử dụng ngắt hẹn giờ, truy vấn RTC mỗi giây và sao chép ngày và giờ nhận được vào RAM. Một lần nữa, mã sau đó sẽ sử dụng các giá trị trong RAM bất cứ khi nào cần biết ngày / giờ.
Mỗi khi tôi cần tìm hiểu thời gian, hãy truy vấn RTC và sử dụng phản hồi trực tiếp.

Đó sẽ là cách tiếp cận tốt nhất?

microcontroller rtc

— người dùng9993
nguồn

15

Cách tiếp cận tốt nhất là phương pháp đáp ứng các thông số kỹ thuật của bạn trong khi sử dụng một lượng tài nguyên tối thiểu. Vì chúng tôi không thực sự biết nhu cầu của bạn, "tốt nhất" có rất ít ý nghĩa đối với chúng tôi.

— Scott Seidman

Tất cả các câu trả lời rất hay tôi không thể chọn một câu trả lời!

— dùng9993

23

Tôi sẽ sử dụng một lựa chọn thứ tư.

Hầu hết các chip RTC có tùy chọn xuất xung 1 giây. Bạn nên kết nối xung đó với đầu vào kích hoạt ngắt trên MCU của bạn.

Bạn nhận được thời gian từ chip một lần khi bắt đầu chương trình của bạn và đôi khi có thể từ đó trở đi - có thể mỗi giờ một lần.
Tín hiệu ngắt sau đó kích hoạt một thói quen ngắt trong MCU của bạn, trong đó bạn tăng thời gian thêm một giây.

Sự sắp xếp đó mang lại cho bạn sự chính xác đến lần thứ hai của RTC mà không cần phải chủ động đọc RTC.

— Majenko
nguồn

5

Khi sử dụng phương pháp này, điều quan trọng là phải biết cạnh đồng hồ nào thể hiện mức tăng và cũng để đảm bảo rằng bất kỳ việc đọc nào đang diễn ra trong thời gian cạnh đồng hồ đó sẽ bị bỏ qua.

— supercat

Hoặc đảm bảo rằng việc đọc chỉ được kích hoạt bởi ISR - bạn có khoảng cách một giây để thực hiện việc đọc trước khi ISR tiếp theo được kích hoạt.

— Majenko

Bất cứ khi nào có thể, tôi thích đặt đồng hồ thời gian thực chạy nhanh hơn một tích tắc mỗi giây và sử dụng chúng cho thời gian sự kiện cho mục đích chung, nếu độ phân giải RTC có thể được đặt đủ tốt để phù hợp với nhu cầu thời gian sự kiện; do đó có thể không phải luôn luôn có một sự gián đoạn xảy ra trên mỗi dấu hiệu RTC. Hơn nữa, khi cài đặt báo thức, điều quan trọng là phải biết chính xác thời gian RTC là gì tại thời điểm báo thức được đặt và thăm dò RTC để xem nó có di chuyển trong khi báo thức được đặt không. Tôi không biết tại sao các nhà cung cấp chip 32 bit không chỉ đơn giản cung cấp bộ đếm 47 bit với khả năng đọc ...

— supercat

... 32 bit trên hoặc 31 dưới cùng với trạng thái đầu vào đồng hồ, có báo thức có thể bật và tắt bất cứ lúc nào mà không bị trễ đồng bộ hóa và một thanh ghi báo động có thể được ghi bất cứ lúc nào khi báo thức tắt, với ngữ nghĩa là báo thức xảy ra nếu tăng tăng xảy ra trong khi báo thức được bật . Nếu một con chip có thể chấp nhận đánh thức không đồng bộ và phần mềm sẽ kiểm tra lại việc bỏ phiếu khi thích hợp, thì không cần phải đồng bộ hóa phần cứng nào khác và phần mềm sẽ không phải xử lý các vấn đề do các hình thức đồng bộ hóa phần cứng khác gây ra.

— supercat

9

Thứ 3 và thứ 2 khả thi hơn

Cách tiếp cận thứ 3 là những gì tôi sử dụng trong hầu hết các trường hợp. Lợi ích là tôi không cần phải lo lắng về việc phản chiếu RTC trong RAM. Thiếu sót tiềm năng của nó là việc thẩm vấn RTC thông qua xe buýt nối tiếp gây ra sự chậm trễ. Nếu bạn đang ghi dữ liệu một lần một giây, sự chậm trễ này có thể sẽ không quan trọng.

Cách tiếp cận thứ 2 cũng tốt. Duy trì đồng hồ gương có thể gây ra lỗi chấm công, nếu thiết bị chạy trong thời gian dài. Đồng hồ gương có thể trôi ra ngoài, RTC. Nếu bạn đọc RTC thường xuyên, thì sự trôi dạt sẽ không tích lũy.
Tuy nhiên, tôi sẽ khuyên không nên thực hiện giao tiếp nối tiếp trong chính thói quen dịch vụ ngắt (ISR). Đặt cờ trong ISR và thực hiện giao tiếp nối tiếp trong hàm main ().

ps Trong mọi trường hợp, tôi đã sử dụng DS1307.

— Nick Alexeev
nguồn

6

Một số RTC (ví dụ MC68HC68T1 [thừa nhận hầu như không ai nên sử dụng nữa]) sẽ tạm dừng việc đếm nội bộ của chúng khi được đọc từ đó để đưa ra phản hồi nhất quán. Chúng phải được đọc từ càng hiếm càng tốt để giảm thiểu gián đoạn. Đọc từ chúng một lần và sau đó sử dụng ngắt hẹn giờ để cập nhật giá trị thời gian được lưu trữ trong RAM của MCU.

— Ignacio Vazquez-Abrams
nguồn

Thiết kế như vậy làm lu mờ tâm trí. Có các lần đọc xảy ra trong một dữ liệu ngẫu nhiên tăng năng suất sẽ là một vấn đề dễ dàng để giải quyết. Có số lần đọc nguyên nhân bị bỏ sót là một vấn đề không thể giải quyết được ngoại trừ việc chấp nhận số lượng bị mất.

— supercat

2

Rõ ràng bộ đệm đôi là điều mà một số người không nghĩ tới khi họ thiết kế chip của họ.

— Ignacio Vazquez-Abrams

Nếu mã kiểm tra khi bỏ phiếu để đảm bảo giá trị không thay đổi, thì không cần đệm đôi. Đối với đồng hồ thời gian thực trên chip, việc bỏ phiếu lặp lại cho đến khi không thay đổi sẽ hoạt động ngay cả khi một ngắt cố gắng đọc RTC cùng lúc với mã dòng chính đang làm như vậy. Một số thiết kế bộ đệm đôi gây khó khăn cho việc viết mã dòng chính và mã ngắt có thể cùng tồn tại một cách an toàn và tôi chưa bao giờ thấy một mã nào mà tôi thực sự coi là "hữu ích".

— supercat

5

Tôi sẽ giả sử RTC là một con chip riêng biệt với tinh thể riêng của nó hoặc một mô-đun được tích hợp với bộ vi điều khiển của bạn một lần nữa có nguồn thời gian riêng (như tinh thể 32 kHz) so với đồng hồ chính. Và nguồn thời gian cho RTC chính xác hơn nguồn thời gian cho vi điều khiển.

Để xác định tần suất bạn cần đọc RTC, bạn cần tìm ra lỗi tối đa mà đồng hồ chính của bạn có thể có. Ví dụ: nếu tinh thể chính được xác định ở mức 20 ppm, thì tương đương với 0,002%. Vì vậy, một chiếc đồng hồ chỉ dựa trên nguồn đồng hồ chính có thể trôi 0,00002 * 3600 * 24 = 1,728 giây mỗi ngày.

Vì vậy, nếu bạn đọc RTC chỉ hai lần một ngày và giữa thời gian tăng thêm một lần một giây bằng cách sử dụng ngắt hẹn giờ, bạn sẽ không bao giờ tắt quá một giây - không bao giờ tắt nhiều hơn một giây so với RTC.

Nếu, như tôi đã giả định trước đó, RTC của bạn là một con chip riêng biệt với tinh thể riêng của nó hoặc một mô-đun được tích hợp với bộ vi điều khiển của bạn, điều đó không có nghĩa là nó đúng. Một RTC cũng có thể có lỗi. Ví dụ: nếu nó đang sử dụng tinh thể 32 kHz với dung sai 5 ppm (chỉ đắt hơn một chút so với 10 ppm), nó có thể tắt 0,43 giây mỗi ngày - hoặc 13 giây mỗi tháng.

Để giải quyết vấn đề này, bạn sẽ cần điều chỉnh RTC, nơi bạn viết một hệ số hiệu chỉnh trở lại một thanh ghi. Làm như vậy sẽ cho phép bạn nhận được lỗi thực tế về không. Nhưng tất nhiên bạn sẽ phải có nguồn đồng hồ bên ngoài thứ ba để sử dụng làm tài liệu tham khảo khi thực hiện điều chỉnh. Một tài liệu tham khảo vô cùng chính xác ở Mỹ là 60 Hz AC dòng, được đảm bảo là chính xác 60 * 60 * 60 * 24 ( 5.184.000) chu kỳ trong một khoảng thời gian 24 tiếng đồng hồ giữa midnights liên tiếp. Để điều này có ích, bạn phải có thời gian trong toàn bộ 24 giờ, vì tần số 60 Hz có thể trôi đi giữa các đêm.

Một tài liệu tham khảo thời gian tuyệt vời khác sẽ sử dụng GPS (độ chính xác 10 ns), nếu một người đã có phần cứng GPS trong dự án của họ.

Nếu thay vào đó, thời gian RTC của bạn đến từ nguồn bên ngoài, như thời gian mạng di động (cuộc gọi AT + CCLK?) Hoặc máy chủ thời gian mạng sử dụng NTP, thì bạn có thể sử dụng giá trị RTC vì sẽ không có gì để "điều chỉnh" .

— tcrosley
nguồn