Arduino.ru

Нужен, и это даже не обсуждается.

Интересный вопрос. Это пошло потому, что изначально я этот протокол использовал для широковещательной передачи по RS485. Собственно, и сейчас использую. С другого Serial. :)

В данном случае вы правы, можно обойтись без маркера начала. Да и, по хорошему, без маркера конца. Достаточно контрольного байта.

Задача связки - первый контроллер собирает информацию с разной периферии, второй ее обрабатывает и записывает. Смертельного от одного неверного параметра не будет ничего, один черт математика сглаживает почти все данные, но и хорошего тоже не будет.

Согласен. Протестирую в таком виде, спасибо за подсказку.

Я старый хардверщик, был втянут в проект, где над частью , которая была реализована на Распбери, работали программеры. Была задача установить обмен между моим контроллером, и "их балалайкой".  Ну я по простоте душевной предложил : структура 20 байт раз в секунду, распбери запрашивает, проц отвечает. 

Сделали по быстрому. на прогонке за 2 недели ни одного сбоя. Но программеры , почесав репу, заявили, что это не достаточно кошерно, перешли на JSON. Объем пакета вырос в разы, гоняли еще две недели, и опять без сбоев. Мне никогда не понять критерии адекватности этих небожителей :)

Ну вот именно сериальный протокол так устроен, что одна и та же форма сигнала , на разных скоростях может без детектированных ошибок быть распознана по разному. Поэтому нужен дополнительный контроль. Контрольной суммы достаточно вполне. Там вероятность не детектированной ошибки начинает стремиться к нулю.

JSON последние годы стали пихать по моему везде, где только можно. Но тут конечно это явный перебор. :)

Я пока так и переделал, выкинув маркеры начала и конца пакета. Контрольный байт разумеется оставил. Будем посмотреть, трафик это сократило заметно. Не то, чтобы это было критично, но копейка рубль бережет. :)

Поиск единого формата обмена - просто таки охота разработчиков инф.систем за священным Граалем. XML у нас уже есть...

Приемник может включиться на середине передачи. И все время пытаться анализировать хвост предыдущего состояния и голову следующего.

Я отслеживаю подобные вещи, если ответ не соответствует запросу, то буфер чистится и дальше идет новый запрос с нуля. Отвал по таймауту также есть.

Автор не указал, в чем вообще смысл переделки протокола, который работает? Обмен не успевает?

Если скорость не критична, я бы ничего не трогал. Если есть другая линия с аналогичным протоколом, то с точки зрения программирования всегда правильнее делать единообразно.

А так получается какая-то модификация ради самой модификации. То что трафик сократился - аргумент бессмысленный. Он у вас что, пакетами выделяется на месяц, как в мобильнике? :)

ЗЫ я программист, не железячник

Ремонт нельзя закончить, его можно только прекратить. С оптимизацией кода и разводки плат - та же фигня.

Скажем так - я хотел чуть снизить загрузку отвечающего контроллера, дабы освободить время на опрос дополнительного оборудования. Эта оптимизация снизила загрузку с 97-98% до 94-95%. Мелочь, но приятно. И на этом успокоюсь. Или постараюсь успокоится. ;)

По этим цифрам можно сделать два вывода:

 1. Система катастрофически перегружена
 2. Проведенная "оптимизация" провалилась

Может ошибаюсь, но с моей точки зрения снижение загрузки с 97% до 95% - это никакя не оптимизация. а просто провал. В первую очередь оптимизировать нужно критические стадии процесса. В таких случаях эффект обычно не проценты, а разы и даже порядки. А выигрыш в 2% - говорит лишь о том, что вы улучшали то, что на скорость не влияет вообще. Что-то вроде "готовя машину к ралли, повесил под стекло "елочку" дезодорант"...

По загрузке - 95% это далеко за гранью устойчивой работы. На мой взгляд программиста, правильно спроектированная система в среднем должна быть загружена на единицы процентов.  Загрузка 20% - это  уже много.

Я бы до начала схватки уточнил - 97% какого ресурса? Так-то МК всегда на 100% загружен, если не спит.

Весь функционал в прошивке у меня разбит на процедуры, время выполнения которых в микросекундах я считаю. От вызова и до окончания работы. И раз в фиксированный интервал времени (обычно секунда или две) я вычисляю, какой процент времени был занят моими процедурами. Таким образом получается понимать как общую загрузку, так и вычислять блоки, в которые я упираюсь, и которые надо стараться оптимизировать. 

Так ардуина - это вроде не сервер, где внезапно MS SQL или 1С выжирают весь оставшийся RAM, CPU Load, валят остальные процессы и гонят систему в такой своп, из которой она сама выбраться не в состоянии.

Если сторонние задачи (типа прерываний) постоянно в основной детерминированный процесс не врываются, то лично я ничего страшного не вижу ни в 95%, ни в 97% "загрузки" МК. Все равно он молотит на 100% - если не в пользовательских процедурах, так в делэе каком-нить. 

Знаете, если бы мы говорили о загрузке процессора ПК - я бы с вами согласился. Потому что ресурс, перегрев, и так далее. Плюс операционная система, многозадачность и прочий мусор. Окошечки, менюшечки, юзверь интерфейс и вся та херня, без которой современные OS не мыслят существования.

Но мы говорим о МК. Который туп как пробка и крутится в вечном цикле 100% своего времени. Это по сути как экскаватор, который не устает и не ломается. Вообще. 

Соответственно, нет никакого смысла использовать от этого времени всего 20%. Вообще никакого. Он все равно крутится в цикле, просто пользы не приносит.

Поэтому я не вижу ничего плохого в том, что полезная нагрузка занимает 98% времени. А в холостую он крутится только 2%. Это идеально. Все процедуры выверены по времени и максимально оптимизированы. И на сэкономленные 2% я могу добавить опрос еще одного внешнего АЦП. Или пары далласов. И так далее. Или просто оставить их на будущее.

Вас же не смущает, что мы выгребаем почти всю доступную оперативную память или место во флеше под свои прошивки? :) Так почему вы считаете, что к загрузки по времени мы должны относится как-то по другому?

P.S. Машину к ралли мне также доводилось готовить, если что. ;)

Понятно.

Т.е. если раньше на полезную работу уходило 97% времени, а на подсчет статистики - 3%, то теперь на полезную работу 95%, а на статистику - 5%.

5% уходит на кручение loop в холостую. :) Расчет статистики вызывается раз в секунду или две и занимает время, которым можно пренебречь. Мои процедуры отрабатывают далеко не каждый проход loop, а вызываются по несколько раз в секунду по опять же жестко заданному в прошивке интервалу. Никаких дополнительных прерываний (кроме штатных, обслуживающих Serial) не используется. 

Единственное, что не привязано ко времени этого контроллера жестко - код, который слушает Serial и отвечает на него. Но (сюрприз!) запросы по нему второй контроллер шлет также по жесткому графику, привязанному ко времени. Который фиксирован и практически не меняется.

Поэтому - да, фактическую загрузку как минимум ЭТОГО контроллера можно посчитать с вполне достаточной точностью. Никаких иных внешних воздействий на него нет.

для начала - я никогда не выгребаю в программах память под 90%.

Говоря о загрузке проца - я имел в виду отношение времени выполнения рутинных задач к общему времени работы.

Я говорю о программах,  которые должны быстро откликаться на случайно поступающие внешние сигналы. И достичь этого можно только в случае, если конктроллер в основном простаивает. Только в этом случае он готов в любой момент обработать приходящий сигнал. а может и несколько сразу. Вот это я и имел в виду. Возможно это называется не загрузка проца, а как-то иначе.

А если программа занята рутиной 90% времени - она реально вообще ни на что не реагирует. Хотя для некоторых систем, вероятно, это нормально. Например, для контроллера рекламного экрана никакие реакции на внешние сигналы не требуются., он может и все 100% производительности тратить на вывод картинки

Если же речь идет о системе автоматического управления автомобилем - там процессор постоянно должен быть свободен для оперативного реагирования на изменение обстановки, иначе в аварийной ситуации он просто не успеет просчитать правильные действия. Не знаю, какие точно показатели у системы Гугль-мобиль, но уверен что их процессоры при спокойной езде загружаются на десятые процента, оставляя 99% мощности как стратегический запас на аварийные ситуации.

В данном случае речь идет о системе сбора данных для телеметрии, все задачи которой жестко прописаны и какие-либо вмешательства в работы или изменение времени выполнения задач просто невозможны. Исключая таймауты по не ответу какого-либо датчика, но время ожидания тоже фиксировано. Исходя из этого, считаю что могу смело использовать ВСЕ доступное мне время. Собственно, я интервалы опроса определяю как раз исходя из того, чтобы успеть максимально много за имеющееся время. И именно для вычисления ФАКТИЧЕСКОГО времени, которое затрачивается, я и считаю загрузку. И балансирую ее так, чтобы исключить ситуацию, когда в рамках фактической секунды задачи требовали бы более секунды на выполнение. 

Понятно, что если бы МК выполнял более гибкие задачи, или его бы дергали внешние прерывания с НЕ фиксированным интервалом - ваша логика была бы правильной, и цифры в 90 с чем-то процентов загрузки были бы косяком. Но в данном конкретном случае все проще.

А в целом - скажем, если мы будем говорить о такой операции как сброс данных на microSD карту, то он способен неприятно удивлять. И даже 80% свободных ресурсов иногда могут не спасти. Зависит от производителя карты, зависит от емкости карты, и хз еще от чего. Это из того, с чем сталкивался лично.

И это одна из причин, почему я решил разбить задачи одного устройства на несколько простых и надежных МК, вместо того, чтобы поставить один более злой. При жестком распределении задач две головы завсегда лучше одной. :)

P.S. И кстати - я не вижу проблемы выгрести даже 99% доступной памяти при условии, что ВЕСЬ код написан и проверен мною, и НИГДЕ не используется гибкое выделение памяти, а только фиксированное. Но такие случаи крайне редки. И банальная смена компилятора или апдейт чужой библиотеки способны все сломать к хренам. :( 

Микроконтроллеры стоят копейки, нафига на этом экономить. У строителей есть понятие запас прочности... Завтра вам понадобится что нибудь добавить и будете опять "оптимизировать" .

То, что Вы называете "загрузкой процессора" по сути ей не является и никакого отношения к решаемой Вами задаче не имеет, да и вообще не имеет физического смысла.

Чем больше процессоров, там меньше "запас прочности". Возможное исключение - если это дублирование, троирование ....

Интересно. Я всегда считал время неизменной величиной. Раскройте тему, если не сложно. 

В 24 сообщении ТС подробно и понятно описал, почему от так делает. Так что понять смысл цитируемого сообщения кроме как "эскалация троллинга" трудно.

я имел ввиду поставить один нормальный, который и на флешку быстро пишет и ОЗУ и флэш у которого не на овер 90 процентов забито от поставленной задачи. Убираем целый один байт КС и контроль четности вводим, который чисто для галочки. 21 век 21 год чо. 

Ну, вообще-то время как раз величина, непрерывно изменяющаяся. Со скоростью одна секунда за секунду.)))

Но Вы ведь говорили о "загрузке процессора", а не о времени.

А процессор загружен на 100% до тех пор, пока мы не начнем отправлять его в сон. Если Вы процессор в сон не отправляете, то и термин "загрузка процессора" лишен смысла.

Ну и, чтобы не растекаться мыслью по нескольким сообщениям, отвечу и на другой Ваш тезис. 

Вот здесь, мне кажется, Вы ставите перед собой ложные цели. 

Ну не задача это для микроконтроллера - успеть максимум за некоторый интервал времени. Это - задача для нереалтаймовой обработки большого массива информации. Ну, напрример, сколько паролей может быть подобрано за месяц. Или сколько микросекунд физического процесса может быть посчитано по имеющейся численной методике за час машинного времени. То есть все это в основном для случаев, когда имеется некий большой фиксированный объем работы и требуется сделать его как можно быстрее. Ну, например, обсчитать физический процесс не за 2 месяца, а за полтора. Или успеть подобрать пароль раньше, чем он устареет.

В случае микроконтроллеров требуется, чтобы последний успел сделать фиксированный объем работы за фиксированное время. Не успеваем - повод для оптимизации. Успеваем - можно на этом успокоиться. 

Да, карта - это беда. Экран, как правило, - тоже беда. Но там хоть немного можно прогнозировать. А с картой можно прогнозировать только в одном единственном случае - если ты сам задаешь формат записи на карту. В случае же более или менее стандартного формата (FAT), затраты времени прогнозу практически не поддаются ввиду неизвестной заранее степени фрагментации карты. Но в случае собственного формата записи мы рискуем очень сильно ускорить износ карты, т.к. конструктивно она заточена именно под FAT. 

Так что - да, карта это головная боль.

Тут тоже не могу не согласиться.

Но в целом мои возражения изложены в первом абзаце:

1. Есть всегда фиксированный объем работы, и в части случаев желательно сделать этот объем как можно быстрее.

2. Но никогда не может быть желательно сделать за единицу времени как можно больший объем работы кроме случая, сводимого к 1.

Т.е. потребность укладывать как можно больше кирпичей в единицу времени диктуется именно желанием как можно быстрее закончить строительство дома. 

Хорошо, давайте перетрем за 21 век. Некоторое время я думал также, как вы. Поскольку на цену в мелкосерийке мне вообще наплевать, поставлю-ка я монстра. И поставил. Наиболее злым был Teensy 4.0. Гляньте ТТХ, вам понравится. 

Но есть два момента. Один мелкий, а вот второй весьма серьезный.

1. Мне удобнее работать с 5 вольтами. Исторически и по периферии. Я все запустил на 3.3, все отлично работало, но как бы мне не особо понравилось нагромождение преобразователей уровней. Вы знаете хоть один широко распространенный МК на 5 вольт, который будет заметно сильнее той же Меги 2560? И будет иметь такой же порог вхождения в экосистему, наработки и так далее? Я вот не нашел. Как вариант смотреть в сторону Cypress, но я хз, где мне взять 48 часов в сутках и здоровье на все это. Но в целом - изучаю потихоньку, пока теоретически.

2. Основной момент - СКОРОСТЬ КОНВОЯ ОГРАНИЧЕНА СКОРОСТЬЮ САМОГО МЕДЛЕННОГО КОРАБЛЯ.

Мы работаем с кучей внешней фигни, типа тех же АЦП, преобразователей сигналов, средств индикации и так далее. И когда мы используем обмен по различным интерфейсам - то, с какой скоростью мы можем бежать теоретически, не имеет вообще никакого значения. Наша фактическая скорость будет зависеть от скорости интерфейсов и от времени, которое будет тратить наша периферия на выполнение наших команд. Мы все равно не можем бежать дальше, пока не получим ответ. Это решаемо программно по типу эмуляции многозадачности (послали запрос, побежали дальше, через какое-то время забрали ответ), но как бы оно все равно остается. И влияет.

Поэтому распределение задач на два МК в моем случае - оказалось оптимальным. И вполне возможно, что их в итоге станет три, с учетом опять же разделения сфер ответственности. Что, кстати, позволит в будущем менять основный МК минимальной кровью, поскольку он вообще не будет иметь дел практически ни с какой внешней периферией, а только командовать младшими.

чота с архитектурой приложений у тебя совсем крах, адъ и израиль.  Не надо так. 

Согласен, термин "загрузка процессора" не очень удачный. Правильнее будет назвать "процент затрачиваемого времени". Но смысл от этого не меняется. Это позволяет объективно оценить, какой процент доступного времени мы тратим на выполнение различных задач, сколько какие из них занимают и где у нас узкие места. Ибо секунда - она в наших рамках величина неизменная. Она всегда секунда.

Далее я буду отвечать без красивого цитирования, простите меня за это - я просто запутался в тегах уже. :) Ваши цитаты будут выделены болдом.

Ну не задача это для микроконтроллера - успеть максимум за некоторый интервал времени

Правильно. Это не задача для микроконтроллера, это задача для устройства в целом. Как я уже сказал, мы имеем дело с системой телеметрии. Она собирает различные параметры. В зависимости от вида параметра - некоторые достаточно фиксировать раз в секунду. А некоторые - десять раз в секунду. Фиксировать текущие значения, запоминать минимальные и максимальные, логгировать все это дело опять же по несколько раз в секунду.

Соответственно, ТЕОРЕТИЧЕСКИ стремится мы должны к тому, чтобы производительности системы хватало на опрос всего по верхней планке. Т.е. например 10 раз в секунду. ПРАКТИЧЕСКИ - это невозможно. Мы просто не успеваем, по различным причинам. Поэтому идет балансировка - какие-то я опрашиваю чаще, какие-то реже. И подгоняю процент занятого времени максимально близко к фактически возможному. Именно за счет контроля фактического времени выполнения различных задач - я и могу сделать такую подгонку. 

Вы возможно просто не представляете себе, до какой степени наличие телеметрии облегчает разбор полетов по работе двигателя или автомобиля в целом. :) Совершенно нереально в боевых режимах успеть понять и осознать все. Зато вечером, за чашкой чая и с простыней логов на экране - многое становится понятным.

И в идеальном сферическом мире - датчик, который способен дать актуальную информацию сто раз в секунду, полезнее датчика, который дает ее десять раз. 

По факту все сложнее, поскольку даже безотносительно скорости преобразователя любой датчик имеет и свое временное ограничение, которое может связано как с его электронной начинкой, так и с банальной теплоемкостью измерительного элемента и корпуса.

Но в целом - я считаю, что стремится к максимально возможной частоте опроса там, где это реально нужно - это правильно. И совершенно не по тому, что что-то получится закончить быстрее. Закончить не получится ничего. Но чем больше данных мы получим, тем проще нам будет получить ответы на возникающие вопросы. :)

Возможно. А как надо?

надо добавить асинхронности в процесс. 

Возможно, мы называем одно и тоже разными словами? Скажем, для примера - надо опросить 4 АЦП (не четыре канала одного АЦП, а четыре разных АЦП). Каждому АЦП надо время на осмысленный ответ. Небольшое, но время. 

Есть два варианта. Первый, тупой - запросили первый, дождались ответ, запросили второй, дождались ответ и так далее. Это неправильный вариант.

И второй - запросили первый, запросили второй, запросили третий, запросили четвертый. Далее забираем ответ от первого, потом от второго, потом от третьего, потом от четвертого. Время как раз прошло, и они все подготовили.

Я вот это называю эмуляцией многозадачности. Занимать МК чем-то еще, что он должен делать, вместо того чтобы чего-то там тупо дожидаться.

Далее я буду отвечать без красивого цитирования, простите меня за это - я просто запутался в тегах уже. :) Ваши цитаты будут выделены болдом.

Последую Вашему примеру.

Соответственно, ТЕОРЕТИЧЕСКИ стремится мы должны к тому, чтобы производительности системы хватало на опрос всего по верхней планке.

Не согласен.

См. ниже.

Вы возможно просто не представляете себе, до какой степени наличие телеметрии облегчает разбор полетов по работе двигателя или автомобиля в целом. :) Совершенно нереально в боевых режимах успеть понять и осознать все. Зато вечером, за чашкой чая и с простыней логов на экране - многое становится понятным.

По роду своей профессиональной деятельности я не имею дела с "железом", а занимаюсь численным моделированием физических процессов. И пользу от подробного логгирования хорошо представляю. Начинал я вообще с перфокарт, когда логгирование было единственным способом отладки. Так что за логгирование меня агитировать не надо.

И в идеальном сферическом мире - датчик, который способен дать актуальную информацию сто раз в секунду, полезнее датчика, который дает ее десять раз. 

Я бы расставил акценты немного иначе.

У нас есть датчик А, способный выдавать данные 100 раз в секунду и датчик Б - 10 раз в секунду соответственно. А также у нас есть N задач, в которых может понадобиться измерять соответствующую величину. Так вот, датчик А подойдет для решения K задач из N, а датчик Б - L из N, причем K >= L. Собственно все: датчик А лучше только тем, что покрывает бОльший процент наших потребностей. Но если в некоторой задаче по скорости нам подходит любой из этих датчиков, от и на наш выбор эта скорость влиять не должна. Скорее всего, мы будем подбирать датчик из соображений цены, геометрических размеров, удобства подключения, экономичности питания и тд. и т.п. Но скорость (если она достаточна) уже нигде в условиях выбора фигурировать не будет.

Но в целом - я считаю, что стремится к максимально возможной частоте опроса там, где это реально нужно - это правильно.

Не согласен.

Тут возможны только два варианта:

1. Датчик подходит для данной задачи.

2. Датчик не подходит для данной задачи.

И ответ, какой вариант имеет место в нашем случае, должен быть получен заранее. Например, на основании теоремы Котельникова-Найквиста. Т.е. мы сначала определяем необходимую частоту опроса, а после просто проверяем датчики на применимость по этому критерию.

Ну или другими словами: частота опроса должна быть не максимально возможной, а строго фиксированной, вычисленной на основе анализа задачи.

Возможность все просчитать теоретически - она хороша для максимально конкретной задачи. Обсуждаемая система - это универсальный инструмент. Кто-то повесит на нее пять датчиков, ему достаточно. А через год добавит еще три. А кто-то десять сразу и попросит добавить еще три. Потому что не хватило. Моя задача - предусмотреть так, чтобы система подошла обоим пользователям. Я не эппл, чтобы за каждый чих брать деньги.

И загрузку я считаю с запасом. Применительно к тем же АЦП - я предусматриваю опрос четырех при том, что по факту использую только три. Потому что МОЖЕТ быть человек, который заюзает все четыре. И пофигу, что сейчас он не используется - в системе это УЖЕ предусмотрено и временной ресурс под это заложен.

Соответственно, мы балансируем между теоретическим идеалом и практической возможностью реализации. :) В том числе, и от того, какие датчики вообще доступны на рынке и за какие деньги. И что делать, если завтра они вдруг пропадут. А такое бывает.

Реальность - всегда компромисс.  :)

раз уж требуется такая большая частота дискретизации при логировании , и нет желания   переходить на STM и 3.3 В. Тогда распределять вычислительную мощность между тем что имеется, т.е. атмегами. Я бы сделал как это и сделано в автомобиле. Датчики бы сделал цифровые c шиной CAN.  4 провода на датчик. Питание , масса, два провода CAN.  Они тупо шлют в CAN свои логи с нужной частотой. Регистратор все это пишет на SD карту. Никаких запросов ответов и контрольных сумм, все это аппаратно встроено в CAN.  ну и наверное можно поработать над  ускорением записи на SD у регистратора ...так первая ссылка      А то что у вас под 90 % всё загружено это не айс, тем более вы говорите может что-то меняться . Завтра автомобиль изменится и опять нужно что-то добавлять. По моей схеме это сделать проще простого. замена ПО регистратора никак не повлияет на отлаженную работу датчиков. 

UPD. к тому же часть информации вообще из штатной CAN шины авто можно извлекать , там много чего есть. 

так для понимания пропускной способности CAN. вот лог картинка. Шина 500 кбит/с . Форд транзит 2014. На шине блоки PCM, ABS, BСM,  и еще пару блоков . Колонка TIME это частота обновления соответствующих сообщений,  в миллисекундах. И это шина не загружена на 100%.

Я не знаю более глючных по электрике и геморройных в обслуживании и доработке машин, чем машины с общей шиной. Поэтому упаси господь самому плодить чудовищ :) Но что для производителей машин и датчиков это выгодно - тут без вопросов. По ускорении записи на SD гляну внимательно позже, спасибо, но по моему я так изначально делаю так, как они советуют - формирую блок данных и сбрасываю его целиком после формирования. Не помню уже.

Спасибо, я вполне знаком с CAN шиной и ее работой. Имею опыт, в том числе и по перепрограммированию ECU. Для моих задач она не имеет никаких плюсов.

а где вы сейчас находите машины без шин CAN. Как бы это сейчас на всех машинах. По вашему сейчас все машины 

Целые автоконцерны херней занимаются, уж простите, куда уж им до ваших  двух ардуин соединённых по уарт. 

ну например один из плюсов. вы говорите разные производители и схема датчиков. Имея систему предлагаемую мной, Вы адаптируете аппаратно этот датчик и в CAN выплевываете всё тот же ID, как было и с предыдущим датчиком.  Всё остальное не меняется. Регистратор и не знает, что датчик аппаратно поменялся, он только видит, что инфа нужная присутствует и не жужжит . В вашем случае менять всю плату и переписывать много ПО, что может еще и остальную часть схемы убить , т.к. места мало по памяти и ресурсам.  

Но дело ваше. Может у вас там формула 1 или дакар гонки где надёжность космическая

Целые автоконцерны занимаются зарабатыванием денег. И современные технологии им в этом отлично помогают. Если вам не очевидна разница в надежности и запасе прочности автомобилей, которые разрабатывали и производили 20-30 лет назад с теми, что производятся сейчас, то как бы извините. :) 

Посмотрите, например, в сторону любительских ралли или подобным им по составу участников соревнований. Изучите, на чем они в основном ездят. И задумайтесь, ПОЧЕМУ. 

Я в НЕ ЗАВОДСКИЕ машинки играю не первое десятилетие уже, и как бы знаю, о чем говорю. И если я прихожу к НЕ использованию CAN шины БЕЗ необходимости, то на это есть вполне объективные причины. И если они непонятны вам, то это не имеет никакого значения. Главное, что они понятны МНЕ.

Вернитесь ради интереса к началу темы, прочитайте вопрос в первом посту. А потом задумайтесь, с чего вдруг тема свалилась из вполне полезных ответов по сути поставленного вопроса совершенно в левую степь, в которой люди, не имеющие не малейшего представления о том, что и почему я делаю, начинают мне рассказывать о том, что делать надо вот совсем по другому. :)

P.S. А дуины использую потому, что порог вхождения в совершенно незнакомую мне область в их случае оказался оптимальным. 

вы ж не сказали чем конкретно занимаетесь, упомянули лишь автомобиль, тогда зачем удивляться тем или иным предложениям. Автомобили бывают очень для разных целей. Понятно, что при построении космолета  все будет по другому. Я ваши слова воспринимал в контексте гражданских автомобилей, коих большинство. 

ну вопрос был про контроль целостности пакета. Я вам посоветовал CAN, где этим занимается аппаратно соответствующий контроллер  добавляя надёжность передаваемым данным,  разгружая ваш МК. вроде по теме

Серьезно? Цитирую фрагмент названия темы:

 Обмен между двумя дуинами по аппаратному Serial

А в тексте указано, что обе дуины стоят в одном устройстве на расстоянии друг от друга в 100 мм. Вот нафига там CAN даже теоретически? :) 

Уважаемый, я помню что вы большой дока по CAN, читал вас не раз. И если полезу туда глубже, чем мне было надо пока, и будут непонятки - почти наверняка обращусь. Но вот к конкретно данной теме CAN вообще не имеет отношения. :) Я ее создал исключительно потому, что в одной из прошлых, когда упомянул что протокол требует избыточную информацию, мне намекнули что я перестраховщик. Вот и решил уточнить.

Я вам не навязываю CAN, я лишь не согласен с вашими обвинениями, что инфа была не по теме и что я диктовал вам как поступить, такого не было. Также меня улыбнуло ваше высказывание про глючность автомобилей с CAN шиной. ( с такими доводами можно вообще на карбюратор перейти). Я вам сказал, лишь, как бы я сделал и назвал несколько плюсов данного решения, только и всего.
И CAN не нужен между двумя дуинами на расстоянии 100мм, я про другое говорил

Чечако, чисто пример из своей практики. Примитивное ус-во, 3 мк связанных по UART на 9600, 50 мм друг от друга, работает в комнатных условиях уже 3 года. Трафик минимальный - 4 байта в сутки(!), и тот для индикации))). Естественно, никаких КС-ов. Однако, крайне редко замечаю что и этот "пакет" до ведомого не доходит... Вот если бы сам не столкнулся - не поверил бы.) Это я к тому что, лишнего не надо, но КС и подтверждение желательны.