Здравтвуйте.
Хотелось узнать есть ли большая разница при передачи 5 бит вместо 8 в работе? И работа с передачей и премом 5 бит будет аналогична как и с 8 битами?

Разница исключительно в числе передаваемых бит. Другой разницы в работе - нет.

ИМХО разницы в работе нет вообще когда кол-во бит <=8.
А вот 9 бит тут приходится делать дополнительные телодвижения.
Ну и естественно может возникнуть дополнительный геморрой при пропихивании данных, разрядностью не кратной разрядности канала.

При 5 битах допустимо б́ольшее рассогласование частот передатчика и приёмника, чем при 8.

А почему?
Дело в том что этот обмен данными планируется исп. при экстремальных температурных условиях. И говорят, что при передаче 8 бит идет потеря битов. Поэтому рекомендуют при температуре(например -30С) исп. 5 бит и скорость 2400 бод. Правильно ли это?

Правильно использовать более точные генераторы.
Учитывая, что многие контроллеры поддерживают только 7 и 8 бит, зачем загонять себя в угол?

В одном устройстве будит применяться кварц на 8 МГц. В другом нет(внутр RC) из-за отсутствия свободного места на плате!

Плохая связка по частотам даже при нормальной температуре. Используйте кварцы "заточенные" под USART , их перечень обычно есть в любом DS на MCU.
Нет места на плате , напаяйте на сами ножки микросхемы.

Я бы с радостью напаял на ножки МК. Только это потом будит применяться в серийном производстве!

Поэтому здесь нужно другое решение!!
Если исп. например бит контроля четности или передавать 5 бит вместо 8, скорость сделать например 2400 бод, передавать несколько раз.
В общем решать програмно!
Что можете посоветовать?

Калибровать RC-генератор по внешним посылкам. Хоть по приему (завести RxD еще и на ICP). Без калибровки полагаться на точность RC-генератора, да еще и при таком диапазоне температур - искать проблемы. И переход на 5-битовые посылки вряд ли гарантирует отсутствие проблем.

Мне поидее надо передавать всего 4 команды. Если сделать хитрый алгоритм. Декодер считывает принятую инфу по прерыванию и проверяет на сходность с 4 опред. символами(команды) с ASCII. Если например сильно похож на одну команду, значит его и сохранять и не хватающие биты дописать. Команды подобрать так, чтобы сильно отличались друг от друга!

Скорость наверное надо тоже переделать на 1200 бод?

Ну, так тоже можно (если упираться и использовать именно UART). А то можно и тональные посылки и самосинхронизирующиеся протоколы...

А смысл ? Принципиальной разницы нет. А можно каждый бит закодировать байтом и передавать по четыре байта зараз, тогда будет нечувствительно и к куда большему разбегу частот, лишь бы старт словить и стоп увидеть.

Откажитесь от асинхронного режима (без спец "извратов" ни фига нормально работать не будет) и переходите на синхронный , а там скорость предачи можете делать и выше 2400

А какие преимущества синхронного, по сравнению с асинхронным?
Да и кого-нибудь есть идея алгоритма декодера выше предложенного метода, чтобы не изобретать велосипед?

Никаких , но для Вашей задачи самое то , что бы не заморачиваться с синхронизацией столь "разных" частот.
И том что тот , кто мастер передаёт частоту синхронизации с которой он посылает 5- 8 бит и привязана она так , что однозначно указывает , какое именно значение бита 0 or 1 передается. К тому же это обычный режим любого USART и на тех же 2 ножках . И описание работы USART в таком режиме есть в DS любого контроллера.

Синхронный режим требует исп. ножки XCK. Я же выше написал, что нет места на плате!!! В таком случае я бы исп. кварц!
Поэтому вариант с синхронным режимом отпадает!!!
ТОЛЬКО АСИНХРОННЫЙ И ПРОГРАМНО!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Поэтому снова:
"Да и у кого-нибудь есть идея алгоритма декодера выше предложенного метода, чтобы не изобретать велосипед?"

Во - первых кричать не надо , Вы же не сообщали что плата у Вас разведена и переделать разводку шин вы не можете или не хотите.
Во -вторых , кто Вам мешает написать программный протокол синхронного режима USART используя разведенные шины. Он очень похож на программный протокол SPI/ И по описанию Вашей задачи у Вас передача идёт в одном направлении , что ещё больше упрощает разработку программы

да нет двухнапраленная. Обратная связь!