Cara membaca data serial dari osiloskop

Saya punya mikrokontroler (PICAXE 20X2) dan meteran pot. Saya memprogram mikro sehingga mengirimkan perubahan pot meter ke port serial PC. Jelas itu adalah 8bit ADC. Sekarang hal yang menarik bagi saya adalah dapat memecahkan kode data serial ini pada osiloskop.

Berikut adalah dua gambar, yang pertama adalah ketika mikro mengirim "0" ke PC dan yang berikutnya adalah ketika mengirim "255". Data sedang dikirim menggunakan 9600 buad dan saya bisa menerimanya di terminal PC.

Pic pertama masukkan deskripsi gambar di sini

Foto kedua masukkan deskripsi gambar di sini

Jadi pertanyaan saya adalah, apakah saya menangkap data yang tepat pada ruang lingkup saya, dan kedua bagaimana seseorang dapat membaca dan mendekode pulsa ini ke dalam format hex atau ascii. Maksud saya cara membaca pulsa naik dan turun ini (0/1).

Terima kasih.

serial oscilloscope wave

— Sean87
sumber

baris serial menganggur dalam keadaan logis '1', jadi perhatikan bahwa Anda memiliki 1 di bagian bawah dan 0 di bagian atas di sini. Saya tahu orang-orang sudah mengunci itu. Komentar saya adalah untuk tujuan memandu jangkauan-lingkup data serial di masa depan; Anda dapat menyelidiki berbagai hal sehingga kondisi siaga tinggi.

— JustJeff

Jawaban:

Pertama, sesuatu yang diperhatikan Olin: levelnya adalah kebalikan dari apa yang biasanya dihasilkan oleh mikrokontroler:

masukkan deskripsi gambar di sini

Tidak perlu khawatir, kita akan melihat bahwa kita juga bisa membacanya. Kita hanya harus ingat bahwa pada lingkup bit awal akan menjadi 1dan bit berhenti 0.

$\mu$ $\mu$ $\mu$ 1 $\mu$ 0

0x001 $\mu$
0xFF $\mu$

tebak waktu:

0b11001111 = 0xCF
0b11110010 = 0xF2

0b11001101 = 0xCD
0b11001010 = 0xCA
0b11001010 = 0xCA
0b11110010 = 0xF2

sunting
Olin benar sekali, ini seperti ASCII. Sebenarnya ini adalah pelengkap 1 dari ASCII.

0xCF ~ 0x30 = '0'
0xCE ~ 0x31 = '1'
0xCD ~ 0x32 = '2'
0xCC ~ 0x33 = '3'
0xCB ~ 0x34 = '4'
0xCA ~ 0x35 = '5'

0xF2 ~ 0x0D = [CR]

Ini menegaskan bahwa interpretasi saya atas tangkapan layar itu benar.

sunting 2 (bagaimana saya menginterpretasikan data, atas permintaan populer :-))
Peringatan: ini adalah cerita yang panjang, karena ini adalah transkrip dari apa yang terjadi di kepala saya ketika saya mencoba untuk memecahkan kode hal seperti ini. Bacalah hanya jika Anda ingin belajar satu cara untuk mengatasinya.

Contoh: byte kedua pada tangkapan layar 1, dimulai dengan 2 pulsa sempit. Saya mulai dengan byte kedua secara sengaja karena ada lebih banyak tepi daripada di byte pertama, sehingga akan lebih mudah untuk memperbaikinya. Masing-masing pulsa sempit sekitar 1/10 divisi, sehingga mungkin masing-masing 1 bit tinggi, dengan bit rendah di antaranya. Saya juga tidak melihat sesuatu yang lebih sempit dari ini, jadi saya rasa ini sedikit. Itu referensi kami.
Kemudian, setelah 101ada periode yang lebih lama di level rendah. Terlihat sekitar dua kali lebih lebar dari yang sebelumnya, sehingga bisa jadi 00. Pengikut tinggi yang lagi dua kali lebih lebar, sehingga akan menjadi 1111. Kami sekarang memiliki 9 bit: bit mulai ( 1) ditambah 8 bit data. Jadi bit selanjutnya akan menjadi bit stop, tetapi karena itu bit0itu tidak segera terlihat. Jadi, satukan semuanya yang kita miliki 1010011110, termasuk mulai dan berhenti sedikit. Jika bit stop tidak menjadi nol, saya akan membuat asumsi yang buruk di suatu tempat!
Ingatlah bahwa UART mengirim LSB (bit paling signifikan) terlebih dahulu, jadi kami harus membalikkan 8 bit data: 11110010= 0xF2.

Kita sekarang tahu lebar bit tunggal, bit ganda dan urutan 4 bit, dan kita lihat byte pertama. Periode tinggi pertama (pulsa lebar) sedikit lebih lebar dari 1111pada byte kedua, sehingga akan menjadi lebar 5 bit. Periode rendah dan tinggi yang mengikutinya masing-masing selebar bit ganda di byte lain, jadi kita dapatkan 111110011. Sekali lagi 9 bit, jadi yang berikutnya harus sedikit, stop bit. Tidak apa-apa, jadi jika tebakan tebakan kami benar kami dapat kembali membalikkan bit data: 11001111= 0xCF.

Lalu kami mendapat petunjuk dari Olin. Komunikasi pertama panjangnya 2 byte, lebih pendek 2 byte dari yang kedua. Dan "0" juga 2 byte lebih pendek dari "255". Jadi itu mungkin sesuatu seperti ASCII, meskipun tidak persis. Saya juga mencatat bahwa byte kedua dan ketiga dari "255" adalah sama. Hebat, itu akan menjadi ganda "5". Kami baik-baik saja! (Anda harus mendorong diri Anda sendiri dari waktu ke waktu.) Setelah menguraikan kode "0", "2" dan "5" Saya perhatikan ada perbedaan 2 antara kode untuk dua yang pertama, dan perbedaan 3 antara yang terakhir dua. Dan akhirnya saya perhatikan bahwa itu 0xC_adalah pelengkap dari 0x3_, yang merupakan pola untuk digit di ASCII.

— stevenvh
sumber

Terima kasih atas tipsnya, saya akan mencoba menangkap bentuk gelombang yang tepat dan memperbarui pertanyaan saya.

— Sean87

Terima kasih, Maukah Anda menandai gambar seperti bagaimana Anda menemukan data itu?

— Sean87

@ Sean87 - Ini menjadi cerita yang panjang, saya menambahkannya ke jawaban saya. Itu menggambarkan cara saya melakukan ini, orang lain mungkin mengikuti jalan yang berbeda. Jangan khawatir jika Anda pikir Anda tidak akan melihat setengahnya; sebagian besar hanya pengalaman dan imajinasi. Tidak ada intelijen khusus yang terlibat.

— stevenvh

Jawaban dan pertanyaan yang sangat bagus, tapi saya ingin tahu mengapa Anda mengatakan bahwa Oscilloscope menunjukkan kebalikan dari apa yang sebenarnya. Saya tahu bahwa baris idle hampir selalu tinggi, tetapi bukankah osiloskop seharusnya menangkap gambar yang tepat dari benda asli? Kecuali jika pengguna mengubah parameter pengaturan osiloskop.

— Nikos

Sesuatu tidak bertambah. Sinyal Anda tampaknya 3.3V puncak ke puncak, yang berarti mereka langsung keluar dari mikro. Namun, level UART mikrokontroler (hampir) selalu idle tinggi dan aktif rendah. Sinyal Anda terbalik dari itu, yang tidak masuk akal.

Untuk akhirnya mendapatkan data ini menjadi PC, harus dikonversi ke level RS-232. Inilah yang diharapkan port PC COM. RS-232 idle rendah dan aktif tinggi, tetapi rendah di bawah -5V dan tinggi di atas + 5V. Untungnya ada chip untuk itu yang membuatnya mudah untuk mengkonversi antara sinyal logika tingkat mikrokontroler khas UART dan RS-232. Chip ini berisi pompa pengisian untuk membuat tegangan RS-232 dari catu daya 3.3V Anda. Kadang-kadang chip ini secara umum disebut "MAX232" karena itu adalah nomor bagian untuk chip awal dan populer dari jenis itu. Anda memerlukan varian yang berbeda karena Anda tampaknya menggunakan kekuatan 3.3V, bukan 5V. Kami membuat produk yang pada dasarnya adalah salah satu dari chip ini di papan dengan konektor. Kunjungi http://www.embedinc.com/products/rslink2dan lihat skema untuk melihat satu contoh bagaimana menghubungkan chip seperti itu.

Hal lain yang tidak bertambah adalah bahwa kedua urutan tampaknya lebih dari satu byte, meskipun Anda mengatakan Anda hanya mengirim 0 dan 255. Jenis data serial ini dikirim dengan bit mulai, kemudian 8 bit data, lalu berhenti sedikit. Bit awal selalu berada pada polaritas berlawanan dari level idle baris. Dalam kebanyakan deskripsi, tingkat siaga garis disebut sebagai "ruang" dan sebaliknya sebagai "tanda". Jadi bit awal selalu tepat. Tujuan bit mulai adalah untuk menyediakan sinkronisasi waktu untuk bit yang tersisa. Karena kedua belah pihak tahu berapa lama sedikit, satu-satunya pertanyaan adalah kapan dimulainya byte. Bit awal menyediakan informasi ini. Penerima dasarnya dimulai jam di tepi terkemuka dari mulai sedikit, dan penggunaan yang tahu kapan data bit akan datang bersama.

Bit data dikirim setidaknya ke urutan yang paling signifikan, dengan tanda 1 dan spasi 0. Bit stop pada level ruang ditambahkan sehingga awal bit mulai berikutnya adalah tepi baru, dan untuk menyisakan sedikit waktu antara byte. Ini memungkinkan untuk sedikit kesalahan antara pengirim dan penerima. Jika penerima yang lebih lambat dari pengirim bahkan sedikit, jika tidak akan kehilangan awal awal bit berikutnya. Penerima me-reset dan mulai jamnya lagi setiap bit mulai baru, untuk kesalahan waktu tidak menumpuk.

Jadi dari semua ini Anda harus dapat melihat bahwa muncul jejak pertama yang mengirimkan setidaknya dua byte, dan penampilan terakhir seperti mungkin 5.

Ini akan membantu jika Anda memperluas skala waktu jejak. Dengan begitu Anda bisa mengukur sedikit waktu sebenarnya. Yang akan memungkinkan Anda untuk memverifikasi Anda benar-benar memiliki 9600 baud (104 mikrodetik / bit), dan membiarkan Anda men-decode bit individu capture a. Seperti sekarang, tidak ada resolusi yang cukup untuk melihat di mana bit, dan karena itu benar-benar decode apa yang sedang dikirim.

Ditambahkan:

Baru terpikir oleh saya bahwa sistem Anda mungkin mengirim data dalam ASCII bukan biner. Bukan itu yang biasanya dilakukan karena mengonversi ke ASCII dalam sistem kecil membutuhkan lebih banyak sumber daya terbatas, menggunakan bandwidth dengan buruk, dan mudah melakukan konversi pada PC jika Anda ingin menampilkan data kepada pengguna. Namun, jika transmisi Anda adalah karakter ASCII yang akan menjelaskan mengapa urutannya lebih dari satu byte, mengapa yang kedua lebih panjang ("255" lebih banyak karakter daripada "0"), dan mengapa keduanya tampaknya berakhir di byte yang sama. Byte terakhir mungkin semacam karakter garis akhir, yang biasanya berupa carriage return atau line feed.

Pokoknya, memperluas skala waktu dan kita dapat memecahkan kode persis apa yang sedang dikirim.

— Olin Lathrop
sumber

Bit stop (dan kebalikan dari bit mulai) juga memaksa keunggulan pada awal transmisi baru.

— stevenvh

@steven: Ya, saya menyadari bahwa saya meninggalkan itu setelah membaca kembali jawaban saya dan menambahkannya dalam sebuah suntingan, mungkin pada saat yang sama Anda menulis komentar Anda.

— Olin Lathrop

Saat mengirim ASCII adalah "tidak efisien" masih bisa menjadi pilihan yang sangat baik. Sebagian besar sistem tertanam tidak hanya mengirim ASCII, mereka menerima perintah ASCII juga, sehingga memungkinkan untuk secara manual bereksperimen dengan "memiliki percakapan" dengan mereka dari program terminal. Standar SCPI (semacam perbaikan pada GPIB, diperluas ke antarmuka listrik lainnya) adalah metode yang sangat formal yang bekerja di sepanjang garis-garis ini.

— Chris Stratton

Akan sangat tidak setuju. Ascii membutuhkan seperti sejumlah kecil kode, bahkan menjalankan logam terbuka pada sedikit 8-pahit. Tentu, Anda dapat menulis sebuah program kustom, tetapi apa yang terjadi 10 tahun dari sekarang ketika yang hilang dan itu akan mengambil mesin virtual untuk menjalankan bahkan jika itu bisa ditemukan? Dan yakin, setiap programmer senilai garam nya dapat hack sebuah terminal biner ke balik sesuatu. Tapi antarmuka yang dapat dibaca manusia layak overhead kecil di sebagian besar tapi yang paling parah memori terbatas dan kinerja sistem kritis. Ditambah jika Anda memiliki memori, Anda dapat menanamkan debug output dengan on / off.

— Chris Stratton

Saya harus menyebutkan bahwa saya memulai pada antarmuka ASCII karena itu adalah kebutuhan pelanggan ... tapi saya menyimpannya karena betapa berharganya mereka. Aku bisa menambahkan ide sebagai perintah dalam firmware dan kemudian mengujinya di mana saja di fasilitas tersebut. Tanpa harus menyebarkan pembaruan ke klien konfigurasi setiap kali saya memposting versi firmware eksperimental dengan tambahan untuk melihat masalah yang dialami seseorang dalam sistem rumit yang hanya berupa satu modul. Di telepon dengan klien, saya dapat meminta mereka menyalakan terminal dan memandu mereka menggunakan fungsi-fungsi tes pabrik yang tidak diterbitkan.

— Chris Stratton

Anda perlu mengetahui rincian lengkap: kecepatan, jika ada ada sedikit awal, jumlah bit data, jika ada stop bit dan jika ada sedikit paritas. Ini harus menjadi fungsi bagaimana UART dalam mikrokontroler dikonfigurasikan.

Jika ruang lingkup Rigol tidak memiliki pilihan decode serial (banyak DSO lakukan), Anda dapat menggunakan X-kursor untuk membantu dalam decoding. Tempatkan kursor pertama di tepi depan data dan pindahkan kursor kedua melalui bitstream. Delta antara kursor dapat digunakan untuk menentukan 'sedikit' Anda sedang melayang di atas oleh aritmatika sederhana. Abaikan bit start / stop / parity, jelas.

— Adam Lawrence
sumber

Selalu ada bit awal dan selalu setidaknya satu bit stop. Mungkin ada bit stop tambahan, tetapi ini tidak dapat dibedakan dari waktu mati antara byte. Decoder mekanis lama kadang-kadang membutuhkan dua bit stop untuk memberikan waktu bagi mekanisme untuk mereset. Saat ini hampir selalu ada 8 bit data dan tidak ada bit paritas, tetapi seperti yang Anda katakan, itu bisa bervariasi.

— Olin Lathrop