Привет.
CAN шина - вещь хорошая, но без правильного представления принципа обмена ее ценность может упасть до нуля. Лепить протоколы высокого уровня типа CANopen на 8-и битные контроллеры тоже не имеет смысла.
Поэтому я для себя разработал концепцию обмена по CAN шине, которая меня устраивает, при этом использует все преимущества CANа, и сравнительна проста в реализации.

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

1. Принцип обмена
Базовой единицей информации в системе является "сигнал". Передача информации осуществляется по изменению сигнала или по требованию получателя. Источниками сигналов являются датчики,контроллеры и модули ввода-вывода. Получателями сигналов являются контроллеры, модули ввода-вывода и исполнительные устройства.
2. Определения:
2.1. Датчик – электрическое устройство, которое при определенном физическом воздействии генерирует электрический сигнал;
2.2. Исполнительное устройство – электрическое устройство, которое при подаче на него электрического сигнала выполняет какое либо действие (включается, загорается,вращается и т.д.)
2.3. Контроллер – микропроцессорное устройство, выполняющее определенные задания и вычисления, для которых в качестве входных и выходных данных используются сигналы.
2.4. Модуль ввода- вывода – немикропроцессорное устройство, не выполняющее никаких заданий и вычилений, а служащее только для преобразовывания виртуальных сигналов в реальные и наоборот(см. ниже)
2.5. В дальнейшем в тексте контроллеры и модули ввода вывода будут называться одним словом «контроллер», если не будет специально оговорено.
3. По отношению к конкретному контроллеру сигналы делятся на следующие типы:
3.1. Входные реальные сигналы – сигналы, которые принимаются данным контроллером от датчиков, непосредственно подключенных к нему.
3.2. Входные виртуальные сигналы – сигналы, которые принимаются данным контроллером в виде сообщений шины CAN от датчиков, подключенных к другим контроллерам системы. При этом виртуальный сигнал может быть не связан с физическим датчиком, а генерироваться контроллером на основании каких- либо вычислений. Например, сигнал "Авария" не генерируется каким либо датчиком, а генерируется контроллером на основании имеющейся у него информации о состоянии группы датчиков.
3.3. Выходные реальные сигналы – сигналы, которые генерируются контроллером и управляют работой исполнительных устройств, непосредственно, подключенных к данному контроллеру.
3.4. Выходные виртуальные сигналы – сигналы, которые генерирует данный контроллер в виде сообщений шины CAN, для передачи другим контроллерам. При этом виртуальный сигнал может быть простым отображением реального сигнала от датчика , или может не иметь физической связи с каким либо реальным сигналом, а генерироваться на основании вычислений.
4. Каждый контроллер в своей оперативной памяти должен иметь "виртуальное" отображение текущего состояния всех используемых им сигналов. При этом в случае если изменяется реальный сигнал – контроллер должен произвести обновление своей памяти и сгенерировать соответствующий виртуальный сигнал.
5. В случае если в памяти отображается виртуальный сигнал, то при получении нового сообщения по шине CAN контроллер должен обновить информацию, хранящуюся в памяти.
6. Так как в шине CAN есть возможность определения приоритетности сообщений, то каждому сигналу присваивается приоритет в зависимости от необходимой времени реакции на изменение данного сигнала.

По поводу моего принципа я вижу следующие преимущества:
1. Идентификатор сообщения определяет сигнал, передаваемый в нем, а не адрес. Контроллер, которому интересен данный сигнал его принимает и обрабатывает, другие нет. Т.о система не должна перенастраиваться при добавлении и удалении контроллеров.
2. Система предусматривает генерацию сообщений только если произошло изменение сигнала на входе. Т.е. трафик минимальный.
3. Приоритет сообщения однозначно определяет критичность времени реакции на конкретный сигнал. Выше приоритет- быстрее будет реакция.
4. Простота реализации. При приеме сообщения в прерывании надо просто обновить память. В цикле опроса входных сигналов при изменении сигнала поставить флаг на генерацию соответствующего сообщения. Основная программа работает только с памятью и таким образом нет задержек из-за отсылки, приема сообщений.
5. Использование MCP25020 подходит - так как у него есть режим передачи сообщения по изменению входа. Я уже это проверил.
6. Простота реализации "Черных ящиков" и сервисных приборов, так как все сигналы присутвтуют на шине.
7. Можно реализовать програмное назначение виртуальных сигналов на соответствующие пины контроллеров.Тогда возрастает гибкость.

Потенциальные недостатки :
1. Недостаток в том, что оперативка каждого контроллера в сети должна хранить все сигналы, которые он использует. Если сигналов много, то памяти может сожнрать тоже много. Я пытался рализовать принцип использования одной ячейки для разных сигналов, когда программа выполняется в определенных циклах, но выход и вход требуют генерации Remote frame для обновления информации, а это почему-то медленно работает по CANу даже с автоматическими ответами.
2. Подразумевается, что если какойто контроллер сгенерил сообщение, то все его примут 100% - это вроде гарантируется спецификацией. И этот принцип тоже на это расчитывает, поэтому нет периодических посылок и т.д. Но если это не гарантируется, тогда надо что-то думать. Я не знаю так ли это?
3. Теоретически для время реакции на критические сигналы будет маленьким, но так ли это я не знаю.

CANopen SDO-обмен, может, и нет смысла, а PDO-обмен - как раз и есть тот минимально необходимый протокол для обмена данными.
Примерно так и работают ПЛК (PLC).

Это все есть в CANopen.
Либо хранить, либо городить алгоритмы синхронизации, что, думаю, гороздо хуже. А от Remote Request лучше вообще избавиться.
Никакой гарантии. А в CANopen есть (можно использовать) либо периодические посылки данных, либо посылка телеграммы "я живой" для диагностики наличия узла в сети.
Будет, но даже самая приоритетная телеграмма не выйдет в сеть пока идет передача, начавшаяся ранее, т.е. макс. задержка будет равна времени передачи одной телеграммы (+ пауза) на данной скорости.

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

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

Кстати, гляньте протокол CAN Aerospace. Там вообще идентификатор не используется в качестве адреса устройств.

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



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


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

Вы знаете, на форуме Делфи-Мастер есть замечательный раздел, называется "Орешник"... Советую ознакомиться.
тынц
А вот вообще, Ваш случай (см. Русские мы или нет") тынц
Так вот, не нужно рассказывать очевидные вещщи как откровение.

А по поводу Аероспейс - это вообще такая приблуда... А их логотип "Driven By Aerospace" ассоциируется с эпизодами про упавшие самолёты...

Этож надо было так КЭН опошлить то...

Не особенно информативно
По существу нечего сказать?

Или его входная очередь переполнилась. А ACK любой другой контроллер выставить может.

Есть.
1) Логотип лишен всяческой эстетики (для того, чтобы это понять не нужно обладать вкусом).
2) Слоган (то, что с точки зрения маркетинга должно быть тяжело каверкаемо) так и наравит вместо "Driven" произнести "Drived" и прикркпить к папке с фотографиями упавших самолётов!

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

Лень перечислять все её глупости, приведу несколько явных:
Рассмотрим формат поля данных: первый (счёт с нуля) байт описывает код типа данных. Разве это не маразм? Вопервых, зачем 256 типов данных, почему не 3-4 (этого вполне может хватить в совокупности с инфой о длинне кадра (DLC)). Тут всего 64 бита данных на кадр и если бы была острая необходимость передавать тип данных, то можно было бы откусить 4 но не 8!
Во вторых, зачем вообще тип данных? Разве возможен вариант, когда один параметр системы описан несколькими типами данных?
Иными словами, первый байт поля данных кадра - всегда детерминирован (может быть получен в результате расчёта по другим байтам одного сообщения), а раз так, то передаётся итак известная информация, снижается информативность сообщения.
Разве этого не достаточно, чтобы признать отсутствие у системы права на жизнь?

Так в этом случае он должен Overload frame выставить вроде. Правда я думаю что это уже зависит от конкретной реализации CANа в микроконтроллере - автоматически или надо что-то предпринять.

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

Избыточность 8 бит?
В типе данных можно определить смещение в текстовом буфере. Все туда и уйдет.
(Это я абстрагировался от Aerospace, может это и не используется).

Ну а логотип не комментирую

А без типа, конечно не знаешь. И получить тип данных по идентификатору конечно же нельзя.

Причём тут удобно или нет. Я Вам говорю про основы "теории информации и кодирования" (ТИК), и если Вы не согласны канонами этой науки, то мне Вам больше сказать нечего.

Итак, может ли быть два или более абсолютно одинаковых сообщения в сети но только с разными значениями полей "тип данных"? - ответ: "НЕТ".
Согласны?

А раз так, то байт типа данных - всегда детерминирован (т.е. не информативен). Иными словами по сети передаётся мусор.

Вывод: байт типа данных, во-первых, безполезен, а во-вторых, снижает производительность, надёжность и т.д. Если его исключить никто не пострадает и все выиграют.


Нет, нельзя. Код типа данных - это код типа данных и всё. Если даже на его месте будет стоять поле с другого назначения, оно будет называться по другому.

Если Вам нужно смещение в бинарном буффере (текстовые на этом логическом уровне не могут существовать (см. "ТИК")), то этим должен заниматься протокол более высокого уровня. Тут я согласен, в поле данных кадра КЭН можно (и нужно) инкапсулировать разные структуры транспортного уровня (я сам так делаю).
Но рачь не об этом. Я говорю, что Аероспейс - отстой! И всё.

Честно говоря, не знаю, что ответить. Зависит от точности следования модели OSI.
Пример. В одном из моих протоколов (не CAN) одно и то же значение 100 может передаваться как "100" и как "0x64", причем тип данных не передается. Правда, я грохнул несколько уровней, пусть приложение определяет тип по идентификатору (как Вы и предлагаете, кстати).
То есть без оговорок с вышеприведенной Вашей фразой не согласен.


Да я верю на слово. Но отстойные вещи бывают так привлекательны При малом трафике лишний байт - ну подумаешь?