Há um ponto de vista merecidamente difundido de que um desenvolvedor típico de software de aplicativo de alto nível está tão acostumado com a disponibilidade de recursos do sistema e a suavidade dos requisitos em tempo real que se pode esperar dele para otimizar o código a fim de reduzir o intensidade de recursos do aplicativo apenas em casos extremos, quando é diretamente exigida pelos interesses comerciais. Isso é lógico, pois nas tarefas de automação aplicada, o recurso humano continua sendo o recurso mais caro. Além disso, reduzir o custo cognitivo de mexer com bytes deixa a atenção do desenvolvedor livre para tarefas de importância primária, como garantir a correção funcional de um programa.
Raramente quando se trata do problema inverso que ocorre em círculos muito mais estreitos de desenvolvedores de sistemas embarcados, incluindo sistemas com maior tolerância a falhas. Há motivos para acreditar que a experiência inicial de usar o MCS51 / AVR / PIC é tão traumática que muitos pacientes continuam a contar bytes ao longo de suas carreiras, mesmo quando não há razões objetivas para isso.... Isso, é claro, não se aplica a casos em que restrições rígidas de preço definem o teto dos recursos da plataforma de computação (microcontrolador). Mas isso é verdade nos casos em que o preço de uma plataforma de computação em série é insignificante em comparação com o custo do produto como um todo e o custo de desenvolvimento e verificação de seu software não trivial, como é o caso de transportes e complexos automação industrial. Esta postagem é sobre a última categoria de sistemas.
Normalmente aqui você pode encontrar uma reprovação: " O que você é um cachorro A MISRA? E os padrões AUTOSAR? Talvez você não tenha lido os manuais HIC ++? Temos um negócio sério aqui, e não suas bugigangas. O guindaste vai cair sua cabeça, você estará completamente morto. "é preciso perceber cuidadosamente que o design de software adequado e as práticas de correção funcional em sistemas de missão crítica não são mutuamente exclusivos. Se todo o seu software for projetado de acordo com o modelo V , então você provavelmente aprenderá um pouco de novo neste artigo, apenas porque sua metodologia contém um item com o nome significativo de design de arquitetura . Exorto o resto dos embeders a sentar e pensar sobre seu comportamento.
Não roube
, , ? :
, , . , , , .
" "? . , - , . , , 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) , , , . .