Ada sudut pandang luas yang sepatutnya tersebar luas bahwa pengembang tipikal perangkat lunak aplikasi tingkat tinggi begitu terbiasa dengan ketersediaan sumber daya sistem dan kelembutan persyaratan waktu nyata yang dapat diharapkan darinya untuk mengoptimalkan kode untuk mengurangi intensitas sumber daya aplikasi hanya dalam kasus ekstrim bila secara langsung dibutuhkan oleh kepentingan bisnis. Ini logis, karena dalam tugas otomatisasi terapan, sumber daya manusia tetap menjadi sumber daya yang paling mahal. Selain itu, mengurangi biaya kognitif dari mengutak-atik byte membuat perhatian pengembang bebas untuk tugas-tugas yang sangat penting, seperti memastikan kebenaran fungsional suatu program.
Jarang ketika datang ke masalah terbalik yang terjadi di lingkaran yang lebih sempit dari pengembang sistem tertanam, termasuk sistem dengan toleransi kesalahan yang meningkat. Ada alasan untuk percaya bahwa pengalaman awal menggunakan MCS51 / AVR / PIC sangat traumatis sehingga banyak penderita kemudian terus menghitung byte sepanjang karier mereka, bahkan ketika tidak ada alasan obyektif untuk ini.... Ini, tentu saja, tidak berlaku untuk kasus-kasus di mana pembatasan harga keras menetapkan batas atas sumber daya platform komputasi (mikrokontroler). Tetapi ini benar dalam kasus di mana harga platform komputasi dalam suatu seri tidak signifikan dibandingkan dengan biaya produk secara keseluruhan dan biaya pengembangan dan verifikasi perangkat lunaknya yang tidak sepele, seperti halnya dalam transportasi dan kompleks. otomasi industri. Posting ini adalah tentang kategori sistem yang terakhir.
Biasanya di sini Anda dapat menemukan celaan: " Apa yang Anda anjing A MISRA? Dan standar AUTOSAR? Mungkin Anda belum membaca manual HIC ++? Kami memiliki bisnis yang serius di sini, dan bukan pernak-pernik Anda. Derek akan jatuh kepala Anda, Anda akan benar-benar mati. "seseorang harus dengan hati-hati menyadari bahwa desain perangkat lunak yang memadai dan praktik kebenaran fungsional dalam sistem mission-critical tidak eksklusif satu sama lain. Jika semua perangkat lunak Anda dirancang sesuai dengan model-V , Anda mungkin akan mempelajari sedikit hal baru di artikel ini, jika hanya karena metodologi Anda berisi item di bawah nama bermakna desain arsitektur . Saya mendorong para embeders lainnya untuk duduk dan memikirkan perilaku mereka.
Jangan mencuri
, , ? :
, , . , , , .
" "? . , - , . , , MISRA- () .
, , , . , , , Boeing 737MAX ( , ). -, ( ) , . - .
, :
-, .
, - , .
Utils helpers, .
: , ; , ; , , . , -, , , .
: Mbed, Arduino, .. , , . CLion ; . , - . , - , .
( ) ; ( ). , . . , , . , , :
, ! , Mbed , , . , ! , , ! , . , , CAN , , Mbed.
, , , . , , : , - . , — , . , , - , 1% .
, . , .
UAVCAN (Uncomplicated Application-level Vehicular Computing And Networking), () Ethernet, CAN FD RS-4xx. - DDS ROS, , , , baremetal .
UAVCAN - — DSDL — , -. REST , XMLRPC, . — , - — , , UAVCAN.
, " , ". DSDL:
# Calibrated airspeed
uavcan.time.SynchronizedTimestamp.1.0 timestamp
uavcan.si.unit.velocity.Scalar.1.0 calibrated_airspeed
float16 error_variance
# Pressure altitude
uavcan.time.SynchronizedTimestamp.1.0 timestamp
uavcan.si.unit.length.Scalar.1.0 pressure_altitude
float16 error_variance
# Static pressure & temperature
uavcan.time.SynchronizedTimestamp.1.0 timestamp
uavcan.si.unit.pressure.Scalar.1.0 static_pressure
uavcan.si.unit.temperature.Scalar.1.0 outside_air_temperature
float16[3] covariance_urt
# The upper-right triangle of the covariance matrix:
# 0 -- pascal^2
# 1 -- pascal*kelvin
# 2 -- kelvin^2
, (, , ). , , , .
, , . - . , , , , , .
" " — — " , , ". , , , : , , . , : , . - :
uint16 differential_pressure_reading uint16 static_pressure_reading uint16 outside_air_temperature_reading
, , , , , , . , , . .
-, , — . , , , , .
, . , , . , , .
, .
, , , . , , , : UAVCAN Interface Design Guidelines. , , , - .
. DS-015 ( NXP Semiconductors Auterion AG) , , , . .