Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Есть ли смысл в простой задаче использовать HLP?
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Controller Area Network (CAN)
gladov
Здравствуйте.

Занимаютсь разработкой устройства, состоящего из нескольких блоков на микроконтроллерах. В принципе, использование CAN не является обязательным, но очень удобно ложится на задачу и хочется его применить. Все устройства будут самодельные, специализированные, поэтому и использование HLP типа CANopen тоже не обязательно. Объемы данных небольшие, но, возможно, будет необходимость гонять блоки более 8 байт. Так вот есть ли смысл в простой системе использовать CANopen или еще что-то, или лучше свое написать? Я сам приверженец использования стандартных вещей, но, почитав CANopen, прихожу к выводу что эта монстрообразная вещь мне совсем не нужна. Максимум что можно взять - какие-то идеи по реализации.
Подскажите плз из личного опыта: стоит ли закладываться на какие-то стандарты?
galjoen
Цитата(gladov @ Mar 18 2009, 15:02) *
Здравствуйте.

Занимаютсь разработкой устройства, состоящего из нескольких блоков на микроконтроллерах. В принципе, использование CAN не является обязательным, но очень удобно ложится на задачу и хочется его применить. Все устройства будут самодельные, специализированные, поэтому и использование HLP типа CANopen тоже не обязательно. Объемы данных небольшие, но, возможно, будет необходимость гонять блоки более 8 байт. Так вот есть ли смысл в простой системе использовать CANopen или еще что-то, или лучше свое написать? Я сам приверженец использования стандартных вещей, но, почитав CANopen, прихожу к выводу что эта монстрообразная вещь мне совсем не нужна. Максимум что можно взять - какие-то идеи по реализации.
Подскажите плз из личного опыта: стоит ли закладываться на какие-то стандарты?

Если вы будете использовать CAN с 29 битами адреса, то как минимум 2 байта данных можно переместить в адреса. Т.е. 10 будет.
А насчёт стандартов. Я тоже их в своё время почитал-почитал и сделал по своему. А потом ещё где-то вычитал, что 80% так делают. Без стандарта.
gladov
Цитата(galjoen @ Mar 23 2009, 16:04) *
А насчёт стандартов. Я тоже их в своё время почитал-почитал и сделал по своему. А потом ещё где-то вычитал, что 80% так делают. Без стандарта.

Спасибо за ответ, я так и думал smile.gif
Если стандарт не слишком избыточен, то конечно лучше им и воспользоваться. Например, когда мне надо было реализовать обмен мастер-слейв по 485, взял нижний уровень от ModBus (т.е. сам протокол, но без его предопределенных команд). Но в случае с CANopen видимо так не получится, ибо все равно из пушки по воробьям. Буду делать свой простенький и без загонов smile.gif
Mos
Тут, на форуме несколько раз звучала здоровая идея по поводу того, что, "Если Вы хотите сделать что-либо РАБОЧЕЕ и в КОНЕЧНЫЙ срок, то скорее всего следует использовать стандартное, широко распространённое решение".

Кроме того, может быть применение КЭНопэн в данном случае поможет Вам разобраться с этой технологией "вообще". Ведь если Вы так любите КЭН, то эта технология Вам скорее всего пригодится в будущем. И ещё, знаю по себе, что через 3-4 дня практически все монстровые вещи начинают раскладываться по полкам (если конечно их придумывали инженеры, а не "менеджеры").
Чепурнов Александр Сергеевич
Здравствуйте,
сам я приверженец стандартов и в настоящее время мы все наши разарботки стараемся делать с использованием стнадартных HLP. Очень поддерживаю мнение, что "разобраться со стандартом полезно что бы вообщеть разобраться с тем, что такое CAN ик ак его правильно использовать". CANopen, например создавали высококлассные инженеры.
Не согласен, что СANopen монстрообразная вещь, просто нет на русском языке хороших книг.
Но, если у Вас устройство "закрытое", Вы не планируете подключать какие-либо устройства третьих производителей, вы не работаете в большой кооперации. Устройство компактное и CAN используется для внутриблочного обмена, устройств не очень много (не более 5-6), то можно портренироваться и придумать свой простой протокол.
Это тоже методологически полезно.
Мы с этого начинали. когда отказались от SPI и I2C в пользу СAN для межблочного обмена внутри сложных устроств при количестве МК больше 2.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.