Сеть для объединения устройств на AVR: что выбрать?

[ellioh]

-

[radio-kot]

CAN контроллеры Microchip не дорогие.

[s64]

что то похожее делал на RS485. В пределах 30-40 метров летало на скорости 115200, но в конечном варианте оставил 38400 (вполне хватало). В сети было 17 устройств.

[ellioh]

CAN контроллеры Microchip не дорогие.

Спасибо, хотя в данном случае мне хотелось бы ограничиться Atmel по субъективным причинам, для работы с ними у меня всё уже есть. Правда, поглядел сейчас PIC с CAN, действительно, чего только там нет... Возможно, стоит задуматься, но пока склоняюсь-таки к RS485, как мне ниже советуют.

что то похожее делал на RS485. В пределах 30-40 метров летало на скорости 115200, но в конечном варианте оставил 38400 (вполне хватало). В сети было 17 устройств.

Да, спасибо, поглядел на RS485, что-то такое мне, скорее всего, и надо, сейчас буду смотреть. А что за протоколы были поверх физического уровня? Что-то стандартное или самопал? Ведь, как я понимаю, стандарт RS485 более высокие уровни не регламентирует.

[Engineer_Keen]

С программной точки зрения RS485 тот же самый RS232 или UART. Только помимо сигналов RxD и TxD от контроллера нужен еще и сигнал прием/передача для управления преобразователем UART-RS485.

[ellioh]

С программной точки зрения RS485 тот же самый RS232 или UART. Только помимо сигналов RxD и TxD от контроллера нужен еще и сигнал прием/передача для управления преобразователем UART-RS485.

Это интерфейс с трансивером? Я-то спрашивал у s64 больше не про интерфейс с трансивером (там-то всё должно быть просто: впрочем, трансивер-то тоже надо будет выбирать), а про более высокие уровни модели OSI, чем физический -- адресацию, логику захвата линии, форматы сообщений.

[Engineer_Keen]

адресацию, логику захвата линии

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

форматы сообщений.

Самый простой вариант: 1-й байт - признак начала команды, 2-й - адрес устройства, 3-й размер команды (если размер не фиксирован), далее байты данных.
МК, который в головном блоке управления включает приемопередатчик на передачу, передает команд, переключается на прием. Оконечные устройства анализируют команду и в случае совпадения адреса формируют ответ, переключаются на передачу, отправляют ответ и переключаются опять на прием.
Все это делается очень просто на связках "любой МК с UART (в т. ч. AVR) - MAX487 (как пример)".

[ellioh]

В 485 интерфейсе обычно все что выше физического уровня разрабатывается для конкретного устройства, хотя возможно есть готовые протоколы.
...
Все это делается очень просто на связках "любой МК с UART (в т. ч. AVR) - MAX487 (как пример)".

Ага, значит, это для RS-485 стандартный подход. Готовые протоколы всё равно поищу, но не из соображений, что не придумать свои (придумать как раз не должно быть проблемой), а просто из предпочтения более стандартных решений. Хотя понимаю, что готовые будут разве что протоколы, код всё равно придётся писать самому и с нуля, но это как раз не страшно.

О, MAX487, сейчас погляжу даташит, пока я поглядел на какой-то первый попавшийся трансивер, уже заподозрил, что можно просто прицепить UART.

Конечно, будет занят UART, но, с другой стороны, никто не мешает мне подключение компьютера к головному устройству с целью диагностики/настройки/обслуживания делать не через RS-232, как планировал изначально, а через ту же сетку на RS-485.

Упс... а ведь я ещё GSM-модем планировал через UART... так придётся ещё один МК для общения с модемом ставить и общаться с ним, скажем, по I2C. Ладно, не страшно, всё равно решаемо.

В общем, спасибо, ушёл курить даташит.

[kolobok0]

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

в догонку:

гляньте ModBus. простой как палка. есть где своё притулить и можно в случае чаво заюзать внешние всякие контроллеры. в добавок понтовое название - для тех кто с предыханием произносит модбас будет уважительно ставить плюсик вашему девайсу к нему ышо пару механизаций(аля dhcp, switch slave-master, update software, find speed) - и вообще универсальный протокольчик получается.

удачи вам
(круглый)

[ellioh]

гляньте ModBus

Да, спасибо, именно то. Вероятно, буду юзать RS-485 и ModBus поверх.

[s64]

только добрался до компа, целый день бегал...
софтовая часть было своя, под конкретную задачу. Чтобы не описывать коллизии - сделал 1 мастер и 17 слейвов.
Все запросы только со стороны мастера. Формат данных: 1. признак начала посылки 2. адрес 3. признак ( в моем конкретном случае) мастер записывает данные или хочет прочитать 4. данные 5. CRC
Опять же повторюсь делал именно для себя, поэтому так. Для простоты обработки посылок, выбран формат 5 байт.
гонял 5 байт в любом случае, даже если шел запрос и не нужно было передавать данные.

[svs39]

адресацию, логику захвата линии

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

форматы сообщений.

Самый простой вариант: 1-й байт - признак начала команды, 2-й - адрес устройства, 3-й размер команды (если размер не фиксирован), далее байты данных.
МК, который в головном блоке управления включает приемопередатчик на передачу, передает команд, переключается на прием. Оконечные устройства анализируют команду и в случае совпадения адреса формируют ответ, переключаются на передачу, отправляют ответ и переключаются опять на прием.
Все это делается очень просто на связках "любой МК с UART (в т. ч. AVR) - MAX487 (как пример)".

Делал так для 7 МК (мега48, 168, 32), прозрачность обеспечивал байт-стаффингом - удваивал служебный символ, в качестве которого
использовал символ ; как признак начала сообщения. В конце контр сумма по мод2 (до CRC не дошли рукм). Считаю RS485 оптимальным стыком по всем параметрам (стоимость, помехоустойчивость, доступность, скорость, простота). ПК подключал через переходник USB-UART на меге8 ( скорость 38400, переключение на передачу делал мегой8 в переходнике по факту появления инф передавемой от ПК, а вот FTD232 делает это автоматично)

[ellioh]

Коллеги, всем большое спасибо, советы очень помогли.

После чтения документов именно решение с RS-485 нравится больше всего. Уже обсудил перспективы с будущим пользователем системы, его устраивает. Остаётся приступить и получить удовольствие от процесса.

[Jack_A]

Самый простой вариант: 1-й байт - признак начала команды, 2-й - адрес устройства, 3-й размер команды (если размер не фиксирован), далее байты данных.

Когда-то я так делал, пото'м отказался, упростив до безобразия. Признак начала - он не должен совпадать ни с каким байтом передаваемых данных? Если да, то это ограничивает набор передаваемых данных, если нет, то что делать, поймав его в середине пакета? Начинать с начала? Игнорировать и считать обычным байтом? - но тогда зачем он вообще нужен - можно определить начало пакета по самому факту передачи чего-нибудь после паузы.
У меня : счетчик байтов в пакете ( включая его самого и CRC ) -- адрес -- код команды -- [данные] -- CRC . Если топология " точка - точка " ( направлением приема-передачи рулит мультиплексор у мастера ), то еще проще, адрес выбрасываю. Жертвую универсальностью ради простоты. Такое построение позволяет повысить скорость обмена : поймав счетчик, слейв уже может не дожидаться тайм-аута и выставлять флаг готовности по приему заданного числа байт.
Работает хорошо. Мне нравится.

[Engineer_Keen]

Согласен насчет признака начала команды, мне он и не особо нужен, но приходится его использовать в целях совместимости с предыдущим поколением оборудования (по той же причине нет CRC). И я действительно игнорирую его, если он попадается в 4 или 5-м байте команды (длина команды 5 байт и последние 2 из них - данные, которые могут быть любыми байтами). Если признак начала попадается в первых 3 байтах или размер принятой команды получается больше 5 байт я просто сбрасываю принятую команду.

А когда делал для себя (через обычный com-порт) просто первым байтом шел размер команды, CRC не делал, как ни странно, мне удалось передать 2 мегабайта данных (записывал в EEPROM) без единой ошибки, на скорости 38кбит/с

[ARV]

а зря от CAN отказались-то... контроллер типа MCP2515 стоит недорого, подключить можно к любому МК, хоть к тини2313, интерфейс по параметрам не хуже RS485 (дальность-скорость), зато содержит аппаратные средства, гарантирующие доставку пакета, т.е. не надо дополнительно мудрить над CRC и т.п. мишурой. отрабатывает конфликты/коллизии аппаратно в отличие от RS485. дает возможность любому устройству посылать свои данные любому другому, т.е. конфигурация не "1 ведущий - много ведомых", а "много почти равноправных"... В общем, очень много плюсов.

[ellioh]

а зря от CAN отказались-то... контроллер типа MCP2515 стоит недорого"... В общем, очень много плюсов.

Спору нет, CAN в перспективе интереснее, это действительно полноценная сеть, но в конкретной разработке мне его плюсы не так уж много дадут, а отладка наверняка будет тяжелее. Кстати, поглядел этот микрочиповский standalone контроллер -- очень понравилось, запомню на будущее.

А протокол поверх физического уровня я напишу, тем более, что USART-то поддерживает и адресацию. Не уверен, правда, что с головным устройством на Си я влезу в 16К, только код для TWI (на прерываниях) со стороны мастера у меня получился порядка килобайта (GCC), но можно, в конце концов, и ATMega32 заюзать.

P.S. От идеи чистого ассемблера после серии экспериментов отказался -- слишком трудоёмко и ненадёжно на нём вручную выписывать логику обработки прерываний и протокольные машинки состояний, без которых на прерываниях ввод-вывод не сделать. Внешних устройств много: LCD, USART (RS-485), GSM-модем (возможно, придётся ставить второй простенький МК на той же плате и связывать по I2C, поскольку USART всего один), возможно, какая-то I2C-память, возможно, встроенные АЦП, какая-то минимальная клавиатурка, и работа со всем в параллель, и всё придётся делать именно на прерываниях, простого линейного кода ввода-вывода вообще не предвидится.