По моему разумению, девайс должен и по CAN и по RS-232 делать одно и то-же.
По моему разумению RS-232 старо и не совершенно. Заморачиваться с контролем данных и их обменом гиммор, кроме того этот протокол не позволяет по моему работать нескольким устройствам в одной шине, а это :'(. RS-485 могёт, но это не наш метод :IMHO. CAN решает эти проблемы легко :~). Вопрос, для чего это нужно? А посмотри, сколько интересных девайсов можно повесить на твои сенсоры:
- блокировщик убирания шасси при скорости ниже заданной
- речевой информатор предельных скоростных значений, а с добавлением датчика положения закрылка/щитка ещё доп. инфа
- данные для энкодера высоты для режима "C" ответчика
- данные для EFIS (нескольких EFIS, расположенных в разных кабинах в тандеме)
... это только на вскидку, вероятно ещё можно для чего нибудь полезного приспособить (идеи принимаются
😉)
CAN имеет по моему мнению потрясающую устойчивость к помехам. За всё время работы с ним в тяжелых цеховых условиях, где помех было катастрофически много и сбоило всё что даж нможет сбоить на CAN жалоб у меня не было, только уменьши скорость до 500 кБит (этого будет предостаточно для обмена, но протокол будет неубиваемый извне).
Можно сделать 2 альтернативных варианта для RS-232 и CAN, таким образом конструкция будет механически легче собираться и иметь меньшие размеры и цену (на 5 копеек ;D). Я её вижу в виде залитой баксой плитки с 2! сосками для статического и прямого давления (соединить нужно 2 статика вместе ещё внутри и вывести наружу 2 шт. латунные штуцера, а не те пластиковые соски, которые торчат из сенсора). 1 датчик (абсолютного давления заменить на датчик с соской, расположенной по горизонтали и чтобы 2 датчика стояли рядом, иначе соединительные трубки будут устанавливаться НЕУДОБНО!!!). На корпусе должна быть установлена гребенка на 4 провода под винт - земля, +бортпитания (12/24В), CAN LO, CAN HI, а также набор переключателей для установки CAN адреса(группы адресов) устройства. Больше ничего из этого кирпичика торчать не должно.
1.3. Барометрическая высота
Не нужно передавать, достаточно передать точное давление. Прибор, который спрашивает сам пересчитает как нужно а ты будешь экономить на протоколе т.к. он получится проще
😉
2.1. Необходимые данные для калибровки всех датчиков (наклоны характеристик, смещения и т.д.)
если даже этот кусок протокола и будет нужен, то он должен использоваться не пользователем и не оборудованием самолета, а на стенде контроля при сборке/калибровке. Не видел (может плохо смотрел) таких настроек для пользователя (посмотри Стратомастер и аналогичные девайсы, по моему там этого нету).
Про вычисления из верхнего текста понятно что остается
😉.
То есть, в финале на выходе имеем 4 типа данных для последующей обработки и ничего туда не шлем в нормальном режиме работы :IMHO.
Каждая посылка ДОЛЖНА иметь индентификационный код устройства м.б. 2 байта и тип данных. Раскладываешь все эти данные по полочкам в соответствии с разрядностью и получаешь почти готовый протокол
😉. Дальше обкатка и если необходим правки.
В принципе - если ты подробно разжуешь в описании как чего настроить и предоставишь протоколы обмена - то вопросов ни укого не будет. а как таковых стандартов на мелколетческие приборы невстречал. в принципе на RSе можно сделать поддержку NMEA протокола .. надо думать как лучше.
Согласен. Протоколов практически нет открытых. Если будет описание телеграмм CAN вопросов не будет. Да, и устройство должно быть естественно slave с выдачей данных по запросу. Если его не спрашивают, пусть молчит, а не талдычт в шину. Скорость и моменты опроса должны определять другие устройства :IMHO.
ЗЫ. По моему Бериевцы разрабатывали протокол обмена данными по CAN на своих самолетах. В своё время данные были доступны в инете. Они там расписали очень всё подробно, но боюсь не найду я это в своих архивах :-[.
