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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

расстояние?

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

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

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

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

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

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