Посоветуйте пожалуйста, ввязываться ли, ... в новую технологию и схемотехнику Опции

[Kitsok]

Добрый день!

Имеется задача: обеспечить интерфейс между ПО на компьютере и большим количеством дискретных вводов и выводов(около 300 вводов и примерно столько-же выводов), некоторого количества 7-сегментных индикаторов (12 штук по 5 разрядов), небольшим (8) - аналоговых входов, и десятка ШИМов (управление электромоторами).

Требования по таймингу - от нажатия на кнопку до срабатывания функции ПО на компьютере - макс. 100 мс, в обратную сторону - то-же.

Вокруг бродят магнитные поля от мощных сервоприводов.
Напряжение питания всей сети ввода-вывода - желательно одно, желательно - 12 вольт.

Из элементной базы - мне близки AVRы и ARM7 от Atmel, из языка - С, с ассемблером не дружу лет 10, крайний раз писал на нём под х51.
Дискретный ввод-вывод планировал делать цепочками сдвиговых регистров, ШИМ - ШИМом контроллера, аналоговый ввод - АЦП AVRов.

Особых требований по стоимости решения нет, поэтому я как буриданов осёл мечусь между IP, RS-232 over IP, RS-485 и вот наткнулся на CAN, а точнее - на чип MCP25050, и стало мне хорошо-хорошо

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

Заранее благодарен!

[firstvald]

Смотрите. Чем меньше технологий вы используете, тем больше шансов что справитесь с задачей. Обычный комп обладает только RS выходом. Если у вас есть наработанные отлаженные решения по передаче данных через локальную сеть, ну тогда вперед. Если вы только собираетесь с этим начать работать - это авантюра (ну правда если вам дают год сроку и бабла на это время, то ктож от щиастия повозиться за чужой счет откажется). Обычно подобные системы в промышленности делаются либо по 232 (через мощный драйвер проходит на 9600 и на километр) или на 485. Протокол уж на ваше усмотрение. В промышленности используются символьные и "сырые". В символьном посылки идут так как бы мы их на бумаге нарисовали. Плюс в том, что избыточность символьного протокола служит дополнительным фильтром повышающим надежность, можно понять что передавалось прослушивая линию , ну и просто заглянув в массивы передатчика и приемника. Дополнительный плюс - нечувствительны к временным задержкам. Минусом (с натяжкой) можно считать объем байт передачи. "сырые" передачи - когда гонятся сырые байты. Плюс малый объем передачи , чуть проще декодировать и кодировать посылку. Минус - заглянув в передачу сходу ничего не понятно, признаками окончания посылки является временная пауза (винда очень все это не любит правильно делать).
От себя добавлю, что время обмена вовсе не напрямую зависит от скорости обмена. На скоростях 19200 38400 57600 115200 вам за 100 мс удастся провести 2 цикла обмена с устройством (запросили - оно ответило). Практически не зависими от скорости. Это уже виндовые заморочки.

А вообще, судя по вашим задачам посмотрите готовые модули ICP DAS (у них есть и символьные и modbus ("сырые байты") ). (Есть ADAMы - но они в основном под символьный протокол заточены). Все что вы перечислили - уже есть готовое. Вам надо будет только программу на компе написать.

[Kitsok]

Спасибо за ответ.

Про RS-232. Самый быстрый (и самый при этом дорогой вариант) - внутри объекта наблюдения-управления строится LAN (100Base-T), делается N-модулей, каждый из которых - Mega-что-нибудь, у которой с одной стороны - RS-232, с другой - цепочка регистров ввода-вывода. На RS-232 меги цепляется инкапсулятор в IP, на PC - эмулятор COM-портов на количество портов по количеству модулей, софт получается примитивный. Цена интерфейса - где-то 1000-1500 рублей.

Более дешевый вариант - все то-же самое, только вместо LAN внутри объекта - строится сеть RS-485, поверх RS-485 пускаем Modbus и наслаждаемся жизнью.

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

Также плюсом CANа видится (!) помехозащищенность, большая чем у 485 и уж тем более, чем у 232. По факту, во время работы девайса, профессиональное видеооборудование ловит кучу помех, USB модули ввода-вывода (при помощи которого сейчас реализовано) на лету отваливаются от компьютера, и т.д.

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

Я сейчас активно занят поиском чего-нибудь а-ля "CAN networks for dummies", поскольку знания мои о шине почерпнуты из даташитов, и весьма поверхностны.

[firstvald]

С can не помогу - не знаю. RS232 и 485 по помехозащищенности одинаковые, при этом 232 все же получше (тока с согласующими резисторами на концах). Ставили эксперименты и смотрели.

USB - зло немерянное. Чего с ним делать ума не приложу. Крпус то компа посередине напряжения питания сети висит через кондюки фильтров в блоке питания - и отсюда куча радости.

[galjoen]

Добрый день!

Имеется задача: обеспечить интерфейс между ПО на компьютере и большим количеством дискретных вводов и выводов(около 300 вводов и примерно столько-же выводов), некоторого количества 7-сегментных индикаторов (12 штук по 5 разрядов), небольшим (8) - аналоговых входов, и десятка ШИМов (управление электромоторами).

Требования по таймингу - от нажатия на кнопку до срабатывания функции ПО на компьютере - макс. 100 мс, в обратную сторону - то-же.

Основная разница между CAN и RS485+модбас в том, что при работе по модбас имеется ведущий, который должен постоянно опрашивать все "а не случилось ли у тебя чего?" и в 99% получать в ответ "у меня всё так же". А CAN подразумевает, что тот у кого случилось к.л. событие сам передаёт в сеть сообщение об этом. Причём событие может быть и сообщение "я жив", "я появился в сети" и т.п., но об этом потом - если вам будет интересно...
В итоге, если в сети 2..3 устройства, то большой разницы между модбас и CAN нет. Но если больше, то в случае модбас время цикла опроса увеличивается пропорционально кол-ву устройств и при формировании модбас на компе при 4-х устройствах уже вы не уложитесь в 100 mS. В случае CAN кол-во устройств сети не имеет значения (до 100 шт.), а имеет значение частота возникновения событий у них. Реально, чтобы гарантировать 100 mS при 125 кбод, и получится порядка 100 устройств в сети. Кроме того в случае CAN легко решается проблемма горячей замены и т.д.
Вобщем выбор зависит от задачи. RS485 - для самых простейших.

Есть ещё вариан использовать USART, но с приёмопередатчиками CAN, или с RS485 приёмопередатчиками, но в другом включении - см. автомобильный стандарт J1708. Кстати, для вашей задачи вероятно будет оптимально сделать именно по стандарту J1708/J1587. Всё замечательно работает в жёстких автомобильных условиях... Там получается общая сеть как в CAN, но при использовании USART (собственно CAN из J1708 то и произошёл). И модбасоподобный протокол, но без ведущего (все равноправны). Кстати, не удивлюсь, если модбас тоже оттуда... Но тайминги в J1708 очень жёсткие, поэтому без контроллера не обойтись.

[Victor®]

RS232 и 485 по помехозащищенности одинаковые, при этом 232 все же получше (тока с согласующими резисторами на концах). Ставили эксперименты и смотрели.

Странно это как-то.
485 ведь диференциальный....

[mrlee]

Преимущество КЭН многие вещи делаются аппаратно. Ну то есть не надо строить обнаружение и поиск ошибок всегда можно узнать доставлен пакет или нет и тд.
Вопрос в том дискретные выводы группами находятся или нет. Ради каждого отдельного дискретного выхода ставить микроконтроллер конечно бред.
Лучше конечно сделать Универсальную небольшую платку на которой есть РС232 (соединение с ПК), Разъем под дискретные входы - выходы это же разъем можно использовать под индикатор.
Я изучал кэн сразу с пдф-а микросхемы все в принципе понятно, но правда протоколы высокого уровня не ставил.
Проверял работу в условиях достаточно сложных помех (высоковольтные испытания с пробоями) - претензий нет.

[syoma]

Если стоимость не имеет значения а изделие штучное, то может стоить попробовать что-нибудь на базе Ethernet - например EtherCat. Готовые модули под Ваши задачи имеются.

[galjoen]

Также плюсом CANа видится (!) помехозащищенность, большая чем у 485 и уж тем более, чем у 232. По факту, во время работы девайса, профессиональное видеооборудование ловит кучу помех, USB модули ввода-вывода (при помощи которого сейчас реализовано) на лету отваливаются от компьютера, и т.д.

По помехозащищённости CAN и RS485 примерно одинаковы (RS485 чуть-чуть лучше). А говорить про помехозащищённость RS232 вообще смешно...
Но в случае CAN самый низкий уровень (или 2 самых низких?) передачи обеспечивается аппаратно, а на RS485 нужно делать ручками. Но в реальности это делается легко...

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

Я сейчас активно занят поиском чего-нибудь а-ля "CAN networks for dummies", поскольку знания мои о шине почерпнуты из даташитов, и весьма поверхностны.

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

[rezident]

RS232 и 485 по помехозащищенности одинаковые, при этом 232 все же получше (тока с согласующими резисторами на концах). Ставили эксперименты и смотрели.

А условия эксперимента можете огласить? Видимо все по стандарту при этом было: 19200bps по RS232 на 12м и 115200bps по RS485 на 1000м? Или как?

[Kitsok]

Спасибо за отклик

Насчет multidrop RS-232 - я смотрел, не нравится, какой-то не шибко стандартный и непонятно как работающий вариант.

По прочтении даташитов и всяческих примеров, вырисовывается такая картина: есть контроллер, с одной стороны у него IP (не особо важно, RS-232 over IP или голые пакетики), с другой - несколько MCP2515+MCP2551 на SPI. К каждому MCP2551 подцеплена своя ветка шины (из соображений количества буферов приема-передачи, хотя я пока чушь несу, недочитал). Это у нас получается мастер. Его задача - принять данные от компа, разобрать их по узлам назначения и отправить. Принять от узлов сообщения, разобрать-собрать и передать в комп.

Периферийные узлы - либо та-же Мега + MCP2515+MCP2551 + (упс) цепочка регистров ввода-вывода на кнопочки-лампочки-концевички, либо MCP2505. Во втором случае количество периферийных узлов стремится в космос

А можно ли (предусмотрено ли стандартом) "попросить" периферийный узел прислать состояние всех своих входов-выходов? Ну например, в целях синхронизации, раз в пару секунд передавать в PC актуальное состояние всех входов?

[syoma]

А можно ли (предусмотрено ли стандартом) "попросить" периферийный узел прислать состояние всех своих входов-выходов? Ну например, в целях синхронизации, раз в пару секунд передавать в PC актуальное состояние всех входов?

"Попросить" всегда можно. MCP2505Х в таком режиме тоже работает. Также ее можно настроить, чтобы она автоматически сама посылала периодически состояние своих входов.

[firstvald]

бухта в 1000 метров с резюками на концах. И гоняем команды. Смотрим ошибки. Рядом ставим искровую помеху. Сравниваем. Влом уже смотреть до каких скоростей поднимался - неск лет назад было, но 19200 точно. Но только сравниваем на своих приемопередатчиках. В 485 это, правда, всегда какая-нибудь adm.

485 то дифференциальный, но порог у него порядка 200 милливольт, а 232 по-моему 2-3 вольта. Вот и разница. А на практике в
485 куча спецэффектов всяких, вот сижу думку гадаю, почем у в нем не все так замечательно, как могло бы казаться.
Вообще, то что вижу на практике - 485 очень ненадежно. Может заработать, а может и нет.
Очень коротко:умощненный 232 заработает сразу, 485 - все будет что-то не совсем так, потом может заработает. Там, кстати, не обращали внимание? , что 485 3 проводный (хотя в промышленности кто-то это выполняет, а кто-то нет)? А то я, как первый раз прочитал - ооочень удивился, оказывается документацию надо читать.

[Kitsok]

Добрый день!

Последние дни читал и даташит на AT90CAN, и исходники всевозможные (в особенности мне понравилось вот это: http://kschaefer.eit.h-da.de/ATMEL/CAN/index.html ), поэтому вопросы, наверное, будут теперь более осмысленные.

Читаю документец про сеть на борту наноспутника (http://etd.sun.ac.za/handle/10019/858 ) и удивляюсь: они выстроили протокол над CAN-контроллером, где имеют место быть квитанции (ACK).

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

Вот еще вопрос про физическую топологию. Хочу в один кабель запхать и CAN, и питание. Тянуть чистую "шину" не получается, "звезда" в моем случае оптимальна. Т.е. есть плата-дистрибьютор с кучей разъемов, например, DB-9. Максимальное расстояние от дистрибьютора до узла - метра три. Вопрос - а где ставить терминаторы?

[AlexandrY]

CAN самая надежная, дешевая и простая технология.
Сейчас в работе имею проект подобный вашему. Время реализации - пару недель.
Уже много систем реализовал на CAN. Один из них - ПОЛИГОН
Практически по скорости разработки CAN-у нет равных.
На скорость влияет прежде всего наличие софта готового и хорошо документированного.
На этот счет лучше всего поддержаны контроллеры от NXP и ST.
На втором месте по влиянию на скорость разработки стоит удобство отладки.
Здесь вне конкуренции чипы на ядре Cortex-M3.
Поэтому останавливаем свой выбор на STM32xxxx или LPC17xx
Скажем выбираем STM32F103ZE
Имеет надежный CAN контроллер. Отладка по JTAG с просмотром состояний любых переменных в реальном времени без остановки программы!
Куча примеров в средах разработки Keil и IAR. В Keil есть даже специальная библиотека работы по CAN и очень удобный диалоговый конфигуратор.
Для узлов с количеством сигналов более 8-и ставлю контроллер из линейки STM32F103. Где сигналов меньше ставлю из линейки MCP2502x.
Помехозащищенность CAN надо рассматривать не столько в плане уровней сигналов, а в плане аппаратных возможностей по исправлению ошибок.
Это прежде всего аппаратный CRC, безконфликтный арбитраж, самодиагностика, автоповторы, автоматические тайминги и т.д.
Скажем у нас в реальных условиях CAN работал даже когда некоторые узлы по ошибке были включены инверсно, когда насекомые объедали изоляцию и провода висели в сырости голые, когда сбоили и пытались передать мусор некоторые дивайсы в сети, когда применяли на длинных участках несогласованный кабель, когда рядом лежал силовой кабель 220 и т.д.

[galjoen]

они выстроили протокол над CAN-контроллером, где имеют место быть квитанции (ACK).

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

В сеть то гарантирует, но неизвестно есть ли в сети в данный момент нужное устройство.

Вот еще вопрос про физическую топологию. Хочу в один кабель запхать и CAN, и питание. Тянуть чистую "шину" не получается, "звезда" в моем случае оптимальна. Т.е. есть плата-дистрибьютор с кучей разъемов, например, DB-9. Максимальное расстояние от дистрибьютора до узла - метра три. Вопрос - а где ставить терминаторы?

Нужно проложить пару туда-сюда к каждому девайсу. Всё равно наверняка лишние пары будут. А по другому никак. Усы 3 метра - это уже перебор.
Ну или по стандарту J1708 сделать. Там как раз звезда.

[AlexandrY]

Усы 3 метра - это уже перебор.

Это зависит от битовой скорости. На 50 kbit отводы по 3-и метра несогласованным кабелем вполне работают.

[Kitsok]

Стандарт лезу читать.

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

И еще вопрос про RTR. Правильно ли я разумею, что это - заложенный в стандарт механизм опроса узлов, а как он (опрос и соответствующая реакция, т.е. что будет послано в ответ) будет реализован - отдано на откуп дизайнеру?

P.S. Извините пожалуйста за возможно глупые вопросы, я когда USB изучал, мозг на место вставал недели две

[Kitsok]

Добрый день!

Ввязался

Сейчас имеет место быть стенд из двух CAN-AVR от Olimex (at90can128 на борту).
Одна постоянно шлёт пакетики, другая - принимает и отправляет дебаг в RS-232, плюс отсылает пакетик регулярно.

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

Во-вторых, но это возможно софтовый глюк, приемник принимает все пакеты передатчика по два раза, примерно вот так:

Rcvd: 0x153 8 8e1000000
Rcvd: 0x153 8 8e1000000
Rcvd: 0x153 8 8f1000000
Rcvd: 0x153 8 8f1000000

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

Вопрос: а это правильно? Терминатор-то установлен вне зависимости от питания.

[Kitsok]

Всем привет опять!

Бьюсь, обессилил.

Со стороны передатчика - FreeRTOS и два таска:

Код

/* continuously send CAN packets ID 0x151 with max speed (approx 1000Hz) */
static void send_function2( void *x)
{
(void)x;
static CAN_packet packet={0x151, 8, "\0\0\0\0\0\0\0\0"};
    
for(;; )
  {
   can_send( &packet, 10, 10);
   packet.data[1]++;
   vTaskDelay(500);
  }
}

/* periodically send CAN packet ID 0x150 */
static void send_function( void *x)
{
(void)x;
static CAN_packet packet;

packet.id=0x150;
packet.length=2;
packet.data[0]=0x00;
packet.data[1]=0xaa;
    
for(;; )
  {
   can_send( &packet, 13, 500);        
   packet.data[0]++;
   vTaskDelay(1000);
  }
}

Приемник - без изменений echo & spy из Атмеловских библиотек:

Код

-0- RxCAN @ C20C: 0x00000150(Ext.), L=2, 81-AA
-0- RxCAN @ 047D: 0x00000151(Ext.), L=8, 00-03-00-00-00-00-00-00
-0- RxCAN @ 4686: 0x00000150(Ext.), L=2, 82-AA
-0- RxCAN @ 88FB: 0x00000151(Ext.), L=8, 00-05-00-00-00-00-00-00
-0- RxCAN @ CAFD: 0x00000150(Ext.), L=2, 83-AA
-0- RxCAN @ 0D72: 0x00000151(Ext.), L=8, 00-07-00-00-00-00-00-00
-0- RxCAN @ 4F75: 0x00000150(Ext.), L=2, 84-AA
-0- RxCAN @ 91EB: 0x00000151(Ext.), L=8, 00-09-00-00-00-00-00-00
-0- RxCAN @ D3EC: 0x00000150(Ext.), L=2, 85-AA
-0- RxCAN @ 1663: 0x00000151(Ext.), L=8, 00-0B-00-00-00-00-00-00

Т.е. каждый второй фрейм более "частого" таска - теряется. Ошибок нет, смотрел через JTAG регистры.
Вот теперь я гадаю, где теряется фрейм - на приемнике, или на передатчике.

Может кто-нибудь сталкивался?

Update: Вот еще глюк, это уже серьезно ИМХО:

Код

-0- RxCAN @ E373: 0x00000151(Ext.), L=8, 00-0F-00-00-00-00-00-00
-0- TxCAN @ B704: 0x00000152(Ext.), L=8, 00-0F-00-00-00-00-E3-73
-0- RxCAN @ 2579: 0x00000150(Ext.), L=2, 08-AA
-0- TxCAN @ D47F: 0x00000151(Ext.), L=8, 08-AA-00-00-00-00-25-79
-0- RxCAN @ 67EB: 0x00000151(Ext.), L=8, 00-11-00-00-00-00-00-00

Отсюда видно, что пакетик в D47F есть суперпозиция пересылки пакета 2579 и D47F (08-AA и 00-10-00...). Где же гарантированная целостность?

[syoma]

Про ошибки опять. Правильно ли я понимаю, что в полном контроллере (хм, не уверен, что это термин из какого-то стандарта, но CAN-контроллер AT90CAN именно так зовется) передатчик будет биться за арбитраж, пока таймаут не пройдет?

Нет. Каждый передатчик когда передает одновременно слушает линию. В CANе передатчики дерутся только в момент передачи ID пакета. В этот момент если один передатчик передаст 1 в линию а другой 0, то изза доминанты 0 в линии установится 0 и первый передатчик поймет, что арбитраж потерян и переключится на прием этого самого пакета от второго передатчика, то есть пакет не будет потерян. Так обеспечивется в CAN приоритет сообщений с более низким ID. Если же уровни не совпадут уже в теле сообщения - то это уже коллизия и будет ошибка. Обычно так бывает если два контроллера шлют сообщение с одним и тем же ID.

И еще вопрос про RTR. Правильно ли я разумею, что это - заложенный в стандарт механизм опроса узлов, а как он (опрос и соответствующая реакция, т.е. что будет послано в ответ) будет реализован - отдано на откуп дизайнеру?

Да. В атмелах помоему даже заложена возможность автоматической отправки ответа на RTR если пакет с соответсвующим адресом уже готов. По крайней мере в CC01 02 так.

Во-первых, пока плата была одна, и шины как таковой не было (и терминатор был только один), не работало вообще ничего - контроллер выдавал ошибку, и по таймауту передача накрывалась.

Конечно. Читайте внимательно спецификацию CAN. В сети должно быть как минимум 2 устройства изза того, что прием каждого сообщения приемником подтверждается установкой бита ACK в соответсвующий момент передачи. Так как у вас не было второго контроллера то первый не получал ACK и передача накрывалась.

Т.е. каждый второй фрейм более "частого" таска - теряется. Ошибок нет, смотрел через JTAG регистры.
Вот теперь я гадаю, где теряется фрейм - на приемнике, или на передатчике.

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

[cant]

Читаю документец про сеть на борту наноспутника (http://etd.sun.ac.za/handle/10019/858 ) и удивляюсь: они выстроили протокол над CAN-контроллером, где имеют место быть квитанции (ACK).

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

Вот еще вопрос про физическую топологию. Хочу в один кабель запхать и CAN, и питание. Тянуть чистую "шину" не получается, "звезда" в моем случае оптимальна. Т.е. есть плата-дистрибьютор с кучей разъемов, например, DB-9. Максимальное расстояние от дистрибьютора до узла - метра три. Вопрос - а где ставить терминаторы?

Смотря от задачи могли скоректировать под себя протокол.

Протокол избыточен очень. Часть проверок можно опустить в пользу скорости. Мне как-то нужна была скорость максимальная. так вот: мне оказалось более выгодна 7бит адресация с передачей 8 байт без подтверждения для всех узлов сразу, чем деления на группы через фильтры.

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

[Kitsok]

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

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

Про остальные моменты - понял, я как-то не учел, что передатчик сам себя слушает, но Ack не доминантит

Еще напоролся у атмела на некоторый TTC mode, использующий таймер CAN-контроллера. Пока не нашел, что это такое.

cant
спасибо за опыт, посчитал потребление конечных устройств и понял, что питание будет отдельными проводами

[Kitsok]

Чисто полтергейст.
Функция отсылки фрейма, низкоуровневая:

Код

BOOL can_tx( char mob,  CAN_packet *packet)
{
        unsigned short cnt;

        cli();//portENTER_CRITICAL();
        /* Select page (MOB 1) */
        CANPAGE = 1 << 4;
        /* Setup DLC and IDE */
        CANCDMOB = (packet->length) | (1<<IDE);
        /* Setup ID */
        CANIDT1=0;
        CANIDT2=packet->id >>13;
        CANIDT3=packet->id >>5;
        CANIDT4=packet->id <<3;
        /* Load data to FIFO, byte index is autoincremented */
        for (cnt=0; cnt<8; ++cnt)
         CANMSG = packet->data[cnt];

        /* Debug counter */
        cnt=0;
        /* Start transmittion */
        CANCDMOB|=(1<<CONMOB0); //enable TX FIXME!!!
        /* Wait until TXOK is raised */
        while (!(CANSTMOB & (1<<TXOK))) {cnt++;}
        /* Reset TXOK by  read-modify-write */
        CANSTMOB &= ~(1<<TXOK);                              
        /* Reset (disable) MOB */
        CANCDMOB = 0x00;
        /* Finita */
        sei();
        return (TRUE);
}

Единственное место, где вызывается can_tx:

Код

/* Task for CAN transmittion */
void can_tx_task(void *x)
{
(void)x;

static unsigned portCHAR mob;
static CAN_packet packet;
static unsigned portCHAR cnt;
static portCHAR retv=FALSE;

/* Create Tx queue */
CANTxQueue = xQueueCreate( 16, sizeof( CAN_packet));
ASSERT(CANTxQueue != 0);

/* Find free MOB, die if no free channel found */
/* FIXME!!! MOB #0 used by Dump queue */
cli();
for( mob=1; mob < NO_MOBS; ++mob)
  {
   if( channels[mob]==0)
                        break;
  }

ASSERT(mob != NO_MOBS);
channels[mob]=(CAN_cbf)0xffff;
sei();

/* Main loop */
while(1)
  {
   /* Receive packet to send */
   xQueueReceive( CANTxQueue, &packet, portMAX_DELAY);
   cnt=50;
   retv=TRUE;
   while( cnt--)
    {
     retv=can_tx( mob, &packet);
     if( retv==TRUE) // transmission succsessful
      {
       break;
      }
         vTaskDelay(1);
        }
  }
}

Многозадачность - кооперативная, не вытесняющая.
Если в дебаггере, с остановкой на sei() can_tx - все отлично, пакеты улетают друг за другом, все работает как задумано.
Без дебаггера - 2-байтовый пакет "затирает" длинный. Но не всегда Когда счетчик в первом байте длинного пакета (не ID, а payload) достигает 0x2a, все начинает работать как задумано Эффект постоянный.

Что это???

[Kitsok]

Отвечу себе сам.

Это - криво написанная функция приема фреймов в Атмеловском примере.
Приемник не справляется и молча теряет пакеты.