Kami melanjutkan serangkaian artikel tentang pengujian otomasi sistem Tertanam. Artikel ini akan memberi tahu Anda bagaimana dengan cepat dan relatif mudah mengintegrasikan kemampuan untuk mengontrol kekuatan perangkat yang sedang diuji dari skrip pengujian, serta mendapatkan kemampuan untuk mensimulasikan menekan tombol mekanis pada perintah dari skrip pengujian.
Jadi apa yang kita miliki:
- Lusinan perangkat Tertanam di mana Anda perlu menguji versi baru FirmWare (lebih tepatnya, perakitan firmware harian)
- Karena sifat prosedur boot FW, Anda mungkin perlu mengatur ulang daya (mode unduh firmware yang disebut dalam mode Capture Daya Pada)
- Saya ingin pada beberapa titik tertentu dalam waktu selama pelaksanaan skrip uji untuk mensimulasikan menekan tombol mekanik yang terletak di papan debug sistem Embededed
Mengapa poin 3 dibutuhkan? Dalam kasus saya, tugasnya adalah sebagai berikut - dalam hal Pengecualian yang kritis terhadap eksekusi kode, sistem "bangkit" ke kondisi setengah mati dari mana ia tidak akan keluar sampai dimatikan (alasan lain untuk manajemen daya). Tetapi hal yang paling menarik adalah jika dalam mode ini Anda menekan tombol mekanik yang dirancang khusus untuk tujuan ini, yang disebut Log pengecualian - informasi debug yang memungkinkan untuk mencoba memahami di tempat apa pengecualian terjadi pada kode.
Justru karena alasan inilah bahwa untuk otomatisasi pengaturan tes yang efektif, menjadi perlu untuk dapat mengatur ulang kekuatan perangkat dan mensimulasikan menekan tombol mekanis pada papan debug, dengan demikian βmenyimpanβ informasi yang sangat penting tentang Pengecualian agar tidak segera hilang. cepat atau lambat, skrip uji yang menyadari bahwa tidak ada respons dari perangkat akan mencoba menghidupkannya kembali dengan mengatur ulang daya.
Penyimpangan lirik kecil - kadang-kadang Anda akan berjalan selama berminggu-minggu di belakang Pengecualian ini karena itu muncul hanya sesekali ketika semua bintang bertemu dan banyak kondisi lainnya tidak terpenuhi. Oleh karena itu, setiap log debug tersebut sangat penting dan perlu.
Analisis debugging papan sirkuit menunjukkan bahwa tombol hanya menutup garis GPIO yang ditarik hingga +3,3 V pada GND. Jadi jika Anda "solder" ke tombol dan menggunakan relay untuk menutup garis GPIO ke tanah, maka itu akan menjadi apa yang Anda butuhkan.
Selanjutnya, muncul pertanyaan untuk memilih perangkat / modul untuk kontrol yang diajukan persyaratan berikut:
- Jumlah maksimum relay (Anda perlu 2 pcs per perangkat, dan ada puluhan perangkat)
- Akses Ethernet
- Kelola Perintah URL
- Kemampuan untuk menyalin dan skala sistem
Secara tradisi, mereka berhenti pada modul Etherent dari Laurent-128 relay:

Modul ini, berdasarkan semua parameter, membuat kami senang: kami dapat mengelola 14 perangkat sekaligus (satu relay untuk daya, yang lain dengan satu sentuhan tombol) menggunakan perintah URL (sangat nyaman untuk bahasa skrip di mana otomatisasi pengujian ditulis).
Diagram koneksi dan komunikasi papan debug perangkat yang diuji dan modul kontrol ditunjukkan pada gambar di bawah ini:

"Solder" ke kontak tombol mekanis pada contoh salah satu perangkat yang diuji terlihat seperti ini:

Hore! Bagian teknis selesai. Satu-satunya yang tersisa adalah menambahkan kode prosedur pengujian sehingga jika perlu (unduh gambar firmware setelah power reset atau merekam debugging dengan satu sentuhan tombol) berikan perintah untuk menghidupkan / mematikan relay yang diinginkan.
Sintaks URL perintah kontrol sederhana dan jelas. Misalnya, untuk mengaktifkan relai di bawah angka 4, Anda harus menggunakan alamat HTTP berikut:
http://192.168.0.101/cmd.cgi?psw=Laurent&cmd=REL,4,1
Dan di sini adalah fungsi sederhana di Perl yang dipanggil dari prosedur tes utama jika Anda perlu "menarik" relay:
Saya perhatikan bahwa sistem bekerja sangat andal tanpa crash dan freeze. Laurent-128 dan Laurent-112 yang sebelumnya digunakan (untuk 12 relay) bekerja selama beberapa tahun tanpa kegagalan dan berhenti, dengan mempertimbangkan pekerjaan harian.
Dan di sini adalah contoh Pengecualian yang diidentifikasi selama pengujian dengan perakitan firmware harian yang luar biasa. Setelah menjadi jelas pada skrip uji bahwa tidak ada jawaban dari perangkat pada port serial (yaitu, "mati"), upaya dilakukan untuk menekan tombol mekanis darurat untuk merekam debugging dan ini berfungsi - laporan tes akhir yang dihasilkan oleh skrip tes itu sendiri diisi dengan informasi yang berguna dari tempat kemungkinan sistem crash untuk analisis lebih lanjut oleh tim pengembangan:
