CAN128. Попробуем разобраться. Опции

[dormouse]

Начал разработку несложного софта для системы из нескольких at90can128. Фактически, надо сделать несложный исходник на IAR EC++ 4.1 Посмотрел, что есть из готового, но ничего не нашёл.
Единственное - колоссального размера исходник от Atmel'a (вроде адаптированный от прошлой архитектуры).

Для начала очень желаемо суметь написать софт, который сможет принять-послать-обработать ошибку.

Насчёт более высокого уровня (DeviceNET, CANOpen e.t.c) пока не сумел разобраться - складывается ощущение, что ничего готового (ни одного готового каркаса) невозможно найти...

Есть желающие включиться в разработку из идейных или материальных побуждений?

Жду ответа.

[dormouse]

Совершенно верное суждение насчёт протоколов высокого уровня. В CANOpen, DEVICENET это всё есть. Единственная сложность в том, что нет готового OpenSource верианта, если я правильно понимаю суть проблемы. Иными словами если надо использовать MODBUS/485 - пожалуйста. За час работы в сети я нашей 4 независимые реализации. Полностью все спецификации выложены на сайте и т.д. С CAN ситуация иная. Пути:
1. Иметь МНОГО времени и реализовать либо свой CANOpen
2. Иметь МНОГО денег и купить уже реализованный (как я понял, минимум $850 за библиотеку без исходников)
3. Иметь большой умный мозг и МНОГО времени - придумать некое "подмножество" протокола CANOpen и реализовать его.
4. Ограничиться самым примитивным решением - взять только DataFrame от физической части CAN и сделать только HeartBeat для гарантированности работы всего "в целом".

Можно даже BootUP не использовать - в некотором смысле при фиксированном наборе устройств, при отсутствии одного по HeartBeat, работа всей остальной совокупности уже невозможна. В этом смысле BootUP заменяется просто "push'ингом" HeartBeat'ов от слейвов к мастеру. Даже не требуется RDF использовать для этого, шина и так рассчитана на большую пропускную способность.

[ipc]

Совершенно верное суждение насчёт протоколов высокого уровня. В CANOpen, DEVICENET это всё есть. Единственная сложность в том, что нет готового OpenSource верианта, если я правильно понимаю суть проблемы. Иными словами если надо использовать MODBUS/485 - пожалуйста. За час работы в сети я нашей 4 независимые реализации. Полностью все спецификации выложены на сайте и т.д. С CAN ситуация иная. Пути:
1. Иметь МНОГО времени и реализовать либо свой CANOpen
2. Иметь МНОГО денег и купить уже реализованный (как я понял, минимум $850 за библиотеку без исходников)
3. Иметь большой умный мозг и МНОГО времени - придумать некое "подмножество" протокола CANOpen и реализовать его.
4. Ограничиться самым примитивным решением - взять только DataFrame от физической части CAN и сделать только HeartBeat для гарантированности работы всего "в целом".

Можно даже BootUP не использовать - в некотором смысле при фиксированном наборе устройств, при отсутствии одного по HeartBeat, работа всей остальной совокупности уже невозможна. В этом смысле BootUP заменяется просто "push'ингом" HeartBeat'ов от слейвов к мастеру. Даже не требуется RDF использовать для этого, шина и так рассчитана на большую пропускную способность.

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

В результате
1.Был произведен маркетинг и сравнение существующих систем и решений
В силу ряда причин готовое решение найти неудалось и было принято решение создавать свое
2.Была выбрана распределенная технология измерения(в силу конструктивных особеностей контролируемого обьекта)
3.Было проведено сравнение полевых шин и сделан выбор(CAN по соотношению цена качество оказался на коне)
4.Было проведено сравнение протоколов и по характеристикам и количеству/качеству существующего готового(само собой платного софта) а также ареалу рапространения был выбран CANOpen
5.Был проведен анализ функциональности(по пригодности для наших задач) готовых библиотек и их стоимость а также сроков выделенных на реализацию проекта после чего было принято решение писать протокол самостоятельно.
6.Была закуплена документация(спецификации CIA),интерфейсные платы для верхнего уровня и фирменная прога(Ixxat CANOpen Studio) для первоначально проверки реализации своего протокола.

Для чего все это и столько заморочек.А для того чтобы система была модульной и позволяла использовать приборы нашего изготовления совместно с покупными потомучто был выбран стандартный и очень рапространенный протокол.
Решение оказалось правильным и в данное время система находится в серийном производстве.