Mengapa chip jam waktu nyata menggunakan BCD

14

Saya telah melihat puluhan chip clock real-time yang berbeda di pasaran, serta sejumlah prosesor dengan modul clock real-time bertenaga terpisah secara terpisah.

Hampir semuanya tidak hanya menyimpan waktu sebagai tahun-bulan-hari-jam-menit-detik, tetapi bahkan masing-masing bidang disimpan dalam BCD daripada format biner.

Apakah ada alasan yang mendasari hal ini?

Apakah ada aplikasi mikroprosesor yang melakukan sesuatu yang lebih canggih daripada hanya menampilkan jam di mana format BCD lebih berguna daripada biner, atau di mana format tahun-bulan-hari-jam-menit-detik akan lebih berguna daripada hitungan lurus 47-bit perubahan status osilator?

Dari apa yang saya tahu, tampaknya pembuat RTCC menambahkan banyak sirkuit ekstra untuk membuat chip mereka kurang berguna; satu-satunya alasan saya dapat mencari modul RTCC dalam prosesor untuk berperilaku seperti itu adalah bahwa vendor prosesor menggunakan beberapa implementasi BCD yang sudah ada daripada memproduksi sendiri.

rtc supercat
sumber
2
Saya tidak tahu jawabannya tetapi saya ingin tahu apakah ada korelasi dengan BCD dengan 7-Segment Decoder ?
Prof. Meow Meow
@Prof. Meow Meow: Nama yang bagus. Metode paling praktis untuk menyimpan angka yang akan ditampilkan dalam perangkat keras adalah BCD. Ada sistem yang menyimpan angka untuk ditampilkan dalam format lain, tetapi dalam banyak kasus mereka hanya menggunakan ROM untuk memetakan langsung dari angka ke representasi visualnya (misalnya mesin arcade "Tank" menggunakan penghitung skor 6-bit, dan 512). byte ROM untuk mengonversi setiap nilai skor menjadi bentuk 8x8) tetapi ini umumnya hanya bisa diterapkan jika nilai numerik maksimumnya cukup kecil.
supercat

Jawaban:

12

Apakah semua RTC menggunakan pengkodean BCD?

RTC dari Philips / NXP (keduanya mandiri dan terintegrasi ke dalam chip ARM7 atau Cortex-M3) tidak menggunakan pengkodean BCD.

Apa yang salah dengan BCD RTC?

Jika dibandingkan dengan penghitung datar, satu-satunya operasi yang lebih sulit dengan jam BCD terpisah adalah perhitungan perbedaan waktu (menambahkan detik atau menghitung waktu yang berlalu). Perbandingan waktu seperti: "adalah waktu saat ini lebih besar dari waktu alarm yang ditetapkan oleh pengguna" sama mudahnya.

Apa yang baik tentang BCD (dan umumnya split-field) RTC?

Memisahkan bidang benar-benar baik ketika Anda merawat tanggal kalender. Kalender manusia memiliki hal-hal lucu seperti berbulan-bulan panjang yang berbeda dan di atas tahun kabisat itu. Coba lakukan itu dalam satu penghitung (Anda bisa mendapatkan poin bonus karena menggunakan hampir tidak ada daya). Oh dan coba mendukung hari-hari minggu (cukup berguna di semua jenis perangkat yang diperuntukkan bagi manusia: mulai dari jam alarm hingga pengontrol pemanas) dengan ini.

Pendekatan BCD memiliki satu fitur tambahan: Anda mendapat interupsi "setiap detik" atau "setiap sepuluh detik" secara gratis, tanpa harus melakukan perhitungan pada waktu atau tanggal.

Untuk catatan tahun kabisat perhitungan sedikit tidak aktif di NXP RTC karena hanya peduli untuk yang dapat dibagi dengan 4 aturan dan tidak memeriksa pembagian dengan 100 dan 400. Jika disimpan di penghitung tahun di BCD ini akan menjadi sepele dan kemungkinan besar dilakukan dengan benar.

Ringkasan

  1. Jika Anda ingin jam monoton maka gunakan satu. Anda dapat membeli PIC atau AVR dengan "penghitung RTC" (yang hanya penghitung asinkron dengan osilator 32kHz otonom). Hanya perlu diingat bahwa hanya menampilkan tanggal akan sulit. :)

  2. Ketika Anda perlu menampilkan waktu dan tanggal dan mengatur alarm berdasarkan input pengguna dari waktu dan tanggal kemudian gunakan RTC. Dan ingatlah bahwa ketika pengguna mengubah waktu dan tanggal saat ini, interupsi berbasis RTC Anda mungkin tidak akurat.

jpc
sumber
1
Saya baru saja mulai menggunakan Gekko, yang memiliki RTC 24-bit yang hampir saya inginkan kecuali bahwa itu tidak dapat menjaga waktu ketika prosesor mati. Saya juga melihat ST Micro ARM, yang memiliki modul BCD RTC konyol yang hanya mendukung interupsi pada basis satu detik. Jika chip ST tidak akan pernah tanpa daya selama lebih dari tiga tahun, saya bisa membawa sial prescalar RTC untuk berjalan pada kecepatan 32x, dan kemudian menggunakan trik perangkat lunak untuk mengkompensasi, sehingga mendapatkan resolusi waktu 1/32-detik pada peristiwa wakeup, tetapi waktu yang disimpan dalam RTC tidak akan memiliki hubungan yang bermakna dengan waktu kalender dan ...
supercat
1
... jadi perlunya mengkonversi dari format konyol RTC ke peningkatan 1/32 detik akan mengganggu, terutama karena konversi seperti itu akan diperlukan pada setiap siklus tidur / bangun. Saya rasa saya ingin tahu berapa banyak orang yang menggunakan pembacaan RTCC tanpa mengubahnya menjadi satu detik. Mungkin ada cukup banyak untuk membuat format YMDHMS bermanfaat, tetapi menurut saya itu jauh lebih berguna untuk memesan YMDHMS untuk I / O manusia , dan menggunakan detik langsung (atau fraksi apa pun daripadanya) untuk yang lainnya.
supercat
1
@ jpc: Kecenderungan saya sebenarnya adalah untuk tidak pernah mengatur waktu RTC-chip, tetapi tetap "waktu sejak baterai jam dipasang", dan menyimpan perbedaan antara itu dan waktu dinding. Saya menggunakan pendekatan itu dalam satu generasi produk yang menggunakan PIC terpisah untuk menjaga waktu yang didukung baterai (waktu pada saat PIC itu hanya baca) dan akan menggunakannya pada chip dengan penghitung lurus. Sepertinya ide yang agak konyol, untuk memiliki mesin RTC menyimpan nilai diformat-tanggal-makna, meskipun jika saya menggunakan chip ST Micro saya mungkin hanya melakukan itu.
supercat
1
BTW, seri STM32F100 menggunakan RTC detik 32-bit (bukan BCD), tetapi seri STM32F400 mundur kembali ke RTC yang dikodekan BCD. Mendesah.
Mark Lakata
1
@FedericoRusso: Bidang pemisahan akan masuk akal, meskipun lebih cenderung menjadi penghalang daripada bantuan di sebagian besar aplikasi. Pilihan BCD, meskipun, tampaknya benar-benar aneh sebagai pilihan untuk bergabung dengan CPU yang tidak memiliki dukungan BCD .
supercat
3

Saat menggunakan jam pada akhirnya, Anda cenderung lebih tertarik pada menit dan puluhan detik (untuk menampilkannya) daripada total total detik, menit, dan sebagainya. Jika Anda tidak tertarik pada peluang digit yang terpisah adalah Anda tidak peduli dengan nilai menit atau detik yang terpisah, dan Anda mungkin juga menggunakan penghitung biner panjang seperti yang Anda sarankan.
Lebih mudah untuk mengkonversi dari BCD ke biner dalam perangkat lunak daripada sebaliknya. Dan karena penghitung BCD tidak memerlukan real estat ekstra lebih dari penghitung biner, masuk akal untuk memilih untuk BCD.

stevenvh
sumber
2
Seberapa sering aplikasi tidak ingin melakukan apa pun dengan tanggal dan waktu selain menampilkannya? Sepertinya saya jauh lebih umum untuk ingin melakukan hal-hal seperti menghitung waktu agak jauh di masa depan, atau menentukan berapa banyak waktu yang telah berlalu sejak beberapa peristiwa tertentu, dll. Yang lebih mudah untuk dihitung: tanggal dan waktu 45 detik setelah 28-Feb-2000 23:59:52, atau 5097582 + 45 (nilai terakhir dengan asumsi tengah malam 01-Jan-2000 sebagai zaman)? Bagaimana menentukan apakah 5 menit telah berlalu antara 28-Feb-2000 23:59 dan 01-Mar-2000 00:03 (vs 5097540.0 dan 5184180.0)
supercat
1
Sebuah RTC dengan penghitung 48-bit untuk 65,536 detik dan modul alarm-bandingkan yang mencakup bagian bawah 24 bit atau lebih akan sangat berguna untuk sistem daya rendah karena dapat digunakan sebagai dasar untuk penjadwalan OS terlepas dari Prosesor bangun dan tidur. Jika sesuatu seharusnya terjadi 4 detik dari sekarang, sistem dapat mencatat nilai RTC ketika peristiwa itu terjadi. Jika 2 detik dari sekarang prosesor tidak dapat melakukan apa-apa, itu dapat mengatur alarm RTC dan tidur. Ketika acara harus terjadi, sistem akan bangun.
supercat
@supercat - untuk komputer serba guna, biarkan OS melacak waktu dan melakukan "hal-hal yang berguna" dengan info waktu itu. RTC hanya dikonsultasikan sekali untuk menginisialisasi info waktu OS, dan kemudian waktu diperbarui oleh interupsi. Tetapi untuk banyak penggunaan sederhana yang tertanam, jauh lebih mungkin bahwa
Toybuilder
1
@ Toybuilder: Yang terakhir ini persis pendekatan yang saya gunakan pada beberapa generasi terakhir dari kunci elektronik. Gangguan terbesar saya adalah tidak adanya pilihan output pulsa antara 32Khz dan 16Hz (karena saya tidak percaya 1M pullup untuk beroperasi dengan andal dengan output kolektor terbuka 32Khz, satu-satunya pilihan yang masuk akal adalah 16Hz), dan kecerobohan PIC itu. sirkuit pengatur waktu.
supercat
1
@FedericoRusso: Jika seseorang memiliki penghitung waktu biner lurus, seseorang tidak perlu mengkonversi kembali menjadi jam, menit, dan detik, kecuali mungkin untuk tampilan yang dapat dibaca manusia. Satu hanya menambahkan 3723 dan hanya itu. Ketika bekerja dengan nilai-nilai tanggal / waktu YMD-HMS, seseorang membutuhkan kode terpisah untuk menambah dan mengurangi, waktu musim panas adalah mimpi buruk di mana pembuat chip sepertinya ingin menambahkan dukungan yang rusak [seperti perintah yang mengurangi satu dari hitungan jam kecuali saat itu nol, dalam hal ini tidak ada artinya]. DST juga menyakitkan dalam biner, tetapi tidak terlalu mengerikan.
supercat
3

Saya menduga beberapa alasan:

Historis - mereka telah melakukannya dengan cara ini selama beberapa waktu sekarang. Jika Anda ingin bagian baru Anda menggantikan beberapa bagian lain, maka ia harus bekerja kurang lebih sama. Jadi, Anda tetap menggunakan BCD.

Aplikasi - jika seseorang menggunakan RTC dari mikro kecil (sesuatu dalam kisaran 8 bit, seperti PIC low-end), maka berurusan dengan sejumlah besar (seperti penghitung 47 bit Anda) adalah rasa sakit yang besar di leher. JAUH lebih mudah untuk berurusan dengan angka BCD, karena Anda tidak harus bekerja untuk memecahkan masalah.

Tidak terlalu sulit - Melakukan penghitung BCD tidak terlalu sulit, dan pada kenyataannya saya pikir tidak banyak gerbang daripada melakukan biner.

Orang dapat membayangkan sebuah sistem di mana Anda mendapatkan penghitung jam, menit, dll yang terpisah dalam biner alih-alih BCD (sehingga menghindari masalah 'mogok nomor 47 bit'), tetapi itu tidak jauh lebih mudah, dan Anda akan melakukan beberapa konversi saat menampilkan hal itu.

Michael Kohne
sumber
1
Angka 48-bit akan menjadi jumlah 32-bit detik dan fraksi 16-bit. Bekerja dengan angka 32-bit pada mikro 8-bit tidak terlalu buruk. Saya dapat membayangkan bahwa pada sesuatu seperti 6502 yang dapat menangani BCD yang dikemas dengan baik, format BCD mungkin menghemat beberapa byte dalam beberapa kasus, meskipun kompleksitas tambahan penanganan yang dibawa antara detik-jam-menit akan mengimbangi keuntungan apa pun. Tapi tentunya orang-orang yang membangun RTCC ke dalam chip ARM ST mikro tidak mengharapkan seseorang untuk menggunakan 6502 untuk memproses data - tidak dengan ARM 32-bit yang ada di sana!
supercat
1
@supercat - walaupun tidak sulit, melakukan pekerjaan 32 bit pada mikro 8 bit masih menyebalkan di <bleep>. Dan pada sesuatu seperti PIC (dengan instruksi SANGAT terbatas & ruang register & ram) itu bahkan lebih menyakitkan. Mengenai chip ARM - saya berani bertaruh bahwa ini lebih banyak berkaitan dengan preseden historis daripada yang lainnya - semua orang terbiasa melakukannya dengan cara itu, jadi mereka tetap melakukannya dengan cara itu.
Michael Kohne
1
Saya ingin tahu, seberapa kecil orang yang menggunakan periferal RTCC yang tidak mengubah tanggal / waktu menjadi penghitung detik gaya Unix?
supercat
1
supercat: Semuanya? Apa gunanya cap waktu gaya Unix dalam satu jam? OTOH satu-satunya case use Anda adalah alarm RTOS yang lebih baik disajikan dengan timer normal atau dengan interupsi "kenaikan kedua" sederhana dari RTC.
jpc
1
@ jpc: Bagaimana jika Anda ingin menentukan apakah suatu tanggal diberikan dalam waktu musim panas, atau menentukan apakah suatu program yang dimulai pada tanggal / waktu tertentu dan berlangsung lama tertentu akan tumpang tindih dengan yang lain? Hal-hal seperti itu mudah dengan detik lurus, tetapi lebih sulit dengan YMDHMS. Sedangkan untuk menggunakan timer normal, apa yang saya gunakan saat ini adalah centang 1/16-detik dari chip RTC yang mengemudikan TMR1 dan TMR3 pada PIC; yang memberi saya bangun 16/16 detik akurat yang bekerja bahkan ketika jam CPU utama berhenti, dan saya mendapatkan semua waktu saya dari itu.
supercat
1

Saya setuju dengan Michael Kohne bahwa ada banyak momentum sejarah.

MCU awal juga memiliki lebih sedikit ruang untuk kode dan data (pikirkan 128 BYTES RAM, misalnya). Karena informasi waktu sering digunakan untuk keperluan antarmuka manusia, lebih masuk akal untuk menyimpan data yang paling dekat dengan format yang digunakan untuk menampilkan / input dari manusia.

Beberapa MCU yang lebih baru dengan lebih banyak kode dan ruang data kadang-kadang mengimplementasikan perangkat keras penghitung waktu nyata - perangkat ini sering menyimpan jumlah biner 32 kHz.

Toybuilder
sumber
Saya telah membuat kode untuk Atari 2600 (128 byte RAM), dan saya tahu manfaat dari BCD. Hal-hal seperti skor hampir selalu dihitung dalam BCD; angka level terkadang. Bahkan pada 6502, saya akan berharap bahwa jika saya perlu menentukan apakah dua tanggal / waktu dalam lima menit satu sama lain dan menentukan apakah waktu musim panas berlaku, kode untuk mengkonversi penghitung 32-bit detik ke YMDHMS akan kira-kira sekompak kode untuk melakukan perhitungan tanpa melakukan konversi seperti itu. Sedangkan untuk CPU yang lebih baru, saya telah melihat beberapa dengan counter 32Khz lurus yang membutuhkan CPU utama untuk hidup ...
supercat
... tapi chip yang saya perhatikan memiliki RTCC yang menggunakan daya secara terpisah menggunakan BCD YMDHMS.
supercat
CPU yang lebih baru melakukan ini karena lebih murah dan menggunakan arus lebih sedikit (terutama penting karena proses semikonduktor yang digunakan dioptimalkan untuk membuat CPU dan bukan RTC).
jpc
@ jpc: Mengapa lebih murah dan arus lebih rendah untuk menggunakan BCD YMDHMS? Saya akan berpikir counter read-only 47-bit dengan komparator di bagian bawah 32 bit akan lebih sederhana daripada semua hal pengurai tanggal dalam chip RTC. Kecuali ada beberapa film master dari sirkuit tanggal BCD yang, karena beberapa sihir misterius yang lama terlupakan, dapat dimasukkan ke dalam desain untuk mencapai arus yang lebih rendah daripada yang tersedia dengan metode modern, saya tidak jelas mengapa BCD akan lebih murah atau digunakan kurang saat ini?
supercat
Saya sedang memikirkan jawaban @Toybuilders di mana ia menyatakan bahwa CPU yang lebih baru hanya memiliki counter dan bukan RPC full-blown.
jpc
1

Jika ada yang tertarik, saya hanya melihat seri 32F ST dan sepertinya seri 32L yang lebih baru menggunakan BCD RTC, 32F menggunakan counter 32-bit lurus dengan prescalar yang dapat dikonfigurasi dan menyediakan input baterai terpisah untuk itu (hore! ). Saya lebih suka memiliki penghitung lurus yang lebih panjang tanpa prescalar yang dapat dikonfigurasi (sehingga saya bisa mendapatkan akurasi 1 / 256sec tetapi tetap waktu selama bertahun-tahun tanpa harus khawatir tentang pembungkus) tetapi jika saya harus mengatur prescale untuk 1 / 64sec timer dapat berjalan dua tahun tanpa meluap. Tidak ideal, tetapi tidak terlalu buruk. Sedikit tidak estetis bahwa jika seseorang menghidupkan mesin setelah mati terlalu lama (2,1+ tahun), waktu / tanggal akan tidak terdeteksi mundur 2,1 tahun, tetapi bukan masalah besar (konter memiliki bendera melimpah, tetapi di banyak kasus yang tidak akan sangat membantu. Jika mesin dihidupkan selama dua tahun sebelum dimatikan, dan dinyalakan tiga bulan kemudian, penghitung waktu akan diperkirakan meluap; pertanyaannya adalah apakah sudah dua kali meluap, dan saya tidak tahu ada bendera untuk itu.

supercat
sumber
0

Pepatah tampaknya melakukan apa yang Anda inginkan dengan DS1372U . Dibutuhkan kurang dari 1μA, biaya 1,7 USD dan tersedia (!) Di DigiKey dan Mouser. Satu-satunya masalah adalah tampaknya tidak menawarkan alarm dengan lebih dari 1 detik presisi dan tingkat jam keluaran terendah adalah $ \ sekitar $ 4kHz.

jpc
sumber
1
Agak mahal, dan tidak memungkinkan untuk membaca selisih lebih kecil dari satu detik. Output 4096Hz akan lebih baik, meskipun akan jauh lebih baik jika rendah untuk 1/65536 detik dan tinggi untuk 15/65536. Output kolektor terbuka harus serendah mungkin.
supercat