Посоветуйте простой протокол передачи данных Опции

[Pyku_He_oTTyda]

Нуждаюсь в связи двух МК между собой.
Скорость практически не важна (необходимо передать 8ми битную уставку при нажатии\отпускании кнопки без раздражающей человека задержки).
Однако важна помехозащищеннось, так как один из МК трудится на плате управления ДПТ с импульсными токами до 6А и осуществляет PWM управление этим двигателем без гальванической развязки.
Команду необходимо передать четко, громко и без искажений, как лай караульной собаки

Процессор интерфейса находится на отдельной плате, но также гальванически не развязан и питается от того же источника, что и МК управляющий мотором, так что возможны "иголки". Протокол нужен софтовый, так как для связи используются выводы, не несущие альтернативных функций протоколов связи. На целевом МК доступно внешнее прерывание на одном из выводов. Оба МК тактируются от внутренней RC и будут работать не только в комнатных условиях.

Какой интерфейс посоветуете (хоть стандарт, хоть самодельный)?

[firstvald]

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

В вашем случае можно сделать так:
команда начинается символом ":"
команда заканчивается символом "cr"
Если вам надо передать просто байт один, то дальше ничего не надо выдумывать, а просто между символами начала и конца передаем дважды в hex виде этот байт, т е четыре символа. Мы фактически вместо контрольной суммы просто повторим байт. При передаче бывает полезно по разным причинам перед символом ":" передать 3-4 байта 0xFF (если смотреть терминалом что происходит в линии вы их увидете как буквы "я").
По окончании передачи тоже полезно после "cr" передавать "lf", это все упростит отладку.

[MrYuran]

В вашем случае можно сделать так:

Тогда уж проще взять Modbus ASCII и вообще ничего не изобретать.
И на терминале будет не буква "я", а HEX-коды переданных байтов.

Можно немного упростить, выкинув поле адреса и кода команды (если они не нужны).
Но не стоит экономить 1 байт на CRC

Готовая библиотека freemodbus имплементируется в 3 шага за полчаса.

[XVR]

Тогда вам нужен символьный протокол.

Сам по себе символьный протокол не обеспечит помехозащищенность. Нужно нечто большее. Если брать по максимуму, то протокол должен обладать следующими характеристиками:

1. Данные должны передаваться в виде пакета (можно в виде символьной строки, как предлагал firstvald)
2. Обязательна должен быть контроль целостности
3. Можно добавить коды, корректирующие ошибки (forward error correction)
4. Протокол должен быть двухсторонним - т.е. на пакет с установками приемник должен ответить пакетом с подтверждением. Если подтверждения нет - пакет должен перепосылаться
5. Должна быть предусмотрена реакция на невозможность посылки пакета (например при превышении количества попыток отправки и при отсуствии ответа)

[stells]

[*]Протокол должен быть двухсторонним

если протокол двусторонний, то и проблем нет - приемник просто возвращает назад команду для контроля целостности ее передачи, да и все...

если протокол не двусторонний, то можно мажоритарный принцип рассмотреть - 2 из 3-х

[firstvald]

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

[MrYuran]

Нужен простой протокол, который легко отладить и написать.

Да уж куда проще...
А Modbus - промышленный стандарт.
К тому же готовый - и писать ничего не надо. Множество открытых библиотек - как для контроллеров (разных), так и для PC.

Межприборным обменом занимаюсь непрерывно.
В данный конкретный момент выковыриваю самописные велосипеды и переделываю на модбас РТУ, ибо проще, логичнее, универсальнее и к тому же куча готовых тулзов.

[Pyku_He_oTTyda]

Спасибо за ответы!
Но меня в первую очередь волнует физическая реализация протокола.
Я для этого и описал среду обитания МК.
Пока размышляю по поводу однопроводного двунаправленного интерфейса, вторую имеющуюся линию использовать для определения направления передачи.

[stells]

Но меня в первую очередь волнует физическая реализация протокола.

расстояние?

[Pyku_He_oTTyda]

прошу прощения, расстояние упустил, так как оно незначительное.
Межплатный шлейф - 10 - 20 см

[stells]

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

так может uart софтовый?

[Pyku_He_oTTyda]

UART не хотелось бы из-за тактирования МК от RC внутренних и широкой температуры использования.

[Александр77]

UART не хотелось бы из-за тактирования МК от RC внутренних и широкой температуры использования.

Чем обосновано внутреннее тактирование?
Ведь если начнет плыть - то уже почти ничего не спасет, разве только параллельной шиной завязав источниками внешних прерываний оба МК. Но такое решение - изврат на мой взгляд

[rx3apf]

UART не хотелось бы из-за тактирования МК от RC внутренних и широкой температуры использования.

Используйте что-нибудь самосинхронизирующееся, "Манчестер" или бифазное кодирование. Тогда нет никаких проблем работать хоть при изменении битовой скорости на порядок, лишь бы за время передачи бита скорость не уходила больше чем 50% (но проще, если на время всей посылки, тогда подстройку скорости достаточно делать один раз, при начальной синхронизации). Чисто программно это не очень приятно делать (высчитывать по тактам), лучше, когда есть таймер с аппаратным выходом и захватом. Но можно и программно. Синхронизация, данные, CRC - вполне надежно.

[stells]

UART не хотелось бы из-за тактирования МК от RC внутренних и широкой температуры использования.

т.е. интерфейс должен быть синхронным и обеспечивать полудуплекс, занимая только 2 ноги у контроллера?
тогда что-то типа I2C, только подтяжка помощнее, чтобы помеху задавить

[MrYuran]

А SPI чем не подходит?
Тем более, что запасная линия есть (это которая под переключение направления - зачем?)

А так - да, манчестер очень даже подходит, но там есть нюанс - для правильной синхронизации необходима преамбула.
В принципе, если брать стандартные решения - то это протокол МКИО (MIL STD 1553)

[stells]

А так - да, манчестер очень даже подходит

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

[Pyku_He_oTTyda]

Спасибо за проявленное внимание!
Внутренне тактирование определено тем, что небыло необходимости в точных интервалах. UART не планировался изначально.
SPI с заведенным на прерывание синхроимпульсом мне видится не очень надежным, любая "иголка" вызовет ненужное прерывание.
Манчестер да, спасибо! Видимо оптимум, на нем пока и остановлюсь.
Вторая нога - ну лишней не будет, по крайней мере можно возложить функцию, определяющую продолжительность посылки или что либо еще. Я же еще не определился с протоколом

[stells]

Манчестер да, спасибо! Видимо оптимум, на нем пока и остановлюсь.

Вы все-таки не забудьте про интерфейс типа I2C. после того, как помучаетесь с софтовым Манчестером, после ловли синхросигнала и оценки оставшихся ресурсов (временнЫх) контроллеров может сильно пригодиться

[Pyku_He_oTTyda]

Конечно, я приму во внимание I2C. Вы, насколько я понимаю, работали с тем и другим. Чем плох манчестер в моем случае?
У меня нажал пальцем кнопку- передал восьмибитное число, отпустил-передал нули. Собственно больше ничего не требуется, кроме надежности и однозначности.

[stells]

Чем плох манчестер в моем случае?

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

да и надежность пожалуй пониже будет. вот и rx3apf написал не "абсолютно", а "вполне":

Синхронизация, данные, CRC - вполне надежно.

Сообщение отредактировал stells - Nov 30 2010, 18:32

[rezident]

Есть еще такая забытая штука как ACCESS.bus. Протокол поверх аппаратной шины I2C.

[rx3apf]

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

да и надежность пожалуй пониже будет. вот и rx3apf написал не "абсолютно", а "вполне":

Это лишь оборот речи. Можно ведь и 64-битную CRC, например, добавить - будет абсолютно надежно. Тут скорее надо думать о надежности физического уровня. А протокол - это самое простое.

[Pyku_He_oTTyda]

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

[stells]

Крайнее опасение, как я писал выше, вызывает работа по прерываниям в условиях помех от коммутации ДПТ

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

[Pyku_He_oTTyda]

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

Скорее всего Вы правы! Я еще раз проанализировал ситуацию и решил связать по I2C. Дальше видно будет.

[Pyku_He_oTTyda]

Не нашел для себя ответа на вопрос: если помеха будет воспринята за стартовую посылку, как распознать этот момент?

[stells]

... вам нужен символьный протокол. В нем существуют определенные символы-байты за которыми закреплены определенные значения. Важно что это позволяет четко определить начало посылки и ее окончание.
В вашем случае можно сделать так:
команда начинается символом ":"
команда заканчивается символом "cr"
Если вам надо передать просто байт один, то дальше ничего не надо выдумывать, а просто между символами начала и конца передаем дважды в hex виде этот байт, т е четыре символа. Мы фактически вместо контрольной суммы просто повторим байт. При передаче бывает полезно по разным причинам перед символом ":" передать 3-4 байта 0xFF (если смотреть терминалом что происходит в линии вы их увидете как буквы "я").
По окончании передачи тоже полезно после "cr" передавать "lf", это все упростит отладку.

[Pyku_He_oTTyda]

Нет, проблема не в этом.
Стартовым условием в посылке I2C считается спад уровня SDA при высоком SCL. Предположим, помеха вызвала условие "старт", мастер естественно молчит. Что делать слейву? Зависать в ожидании посылки?
Вот этот момент меня заботит на данный момент.

[stells]

Что делать слейву? Зависать в ожидании посылки?

проверить еще раз условие старта (у Вас же все ноги доступны для чтения), если оно подтверждается, то считать истинным