Может не хватить дискретности перестройки генератора для относительно высоких скоростей обмена. Диапазона перестройки хватает с избытком.
Касательно скорости - сомневаюсь, что софтовый УАРТ позволит достичь в одинаковых условиях тех же скоростей, что и хардовый.

И здесь Вас опередили - в LIN'е оно тоже предусмотрено.

<<... Диапазона перестройки хватает с избытком>>
В большинстве случаев - да. В начале тоже занимался подстройкой генераторов, пока не стали изредка попадаться не настраиваемые экземпляры. Мне их жалко выкидывать.

<< сомневаюсь, что софтовый УАРТ позволит достичь в одинаковых условиях тех же скоростей, что и хардовый>>
Практически не уступает. По крайней мере - для скоростей до 115200.

<<...в LIN'е оно тоже предусмотрено>>
Ну и что? Почему обязательно LIN? По моему, протокол выбирается по задаче.

Т.е., н-р, АВР@8 МГц INTRC сможет софтово уартить на 115200 и делать еще что-нибудь общественно-полезное? Снимаю шляпу.

Безусловно. Но LIN - это простейшая надстройка над УАРТом, решающая обсуждаемые задачи стандартным образом.
(по секрету - он мне не нравится своей избыточной недостаточностью. но стандартен, зараза)

<<Т.е., н-р, АВР@8 МГц INTRC сможет софтово уартить на 115200 и делать еще что-нибудь общественно-полезное? Снимаю шляпу.>>
Оденьте шляпу. Это на 9600 можно параллельно общественно-полезной деятельностью заниматься. На 115200 - с этим уже туго. Только последовательно...

Да ладно, если пару регистров занять, то вполне можно на 115200 с загрузкой процессора порядка 25 процентов радоваться софтовому UART'у, т.е. 3/4 времени заниматься общественнополезными делами. Но делать такое имеет смысл только в том случае, если уж очень надо.

А если в софтовом UART-е задействовать таймеры с входами захвата, то загрузка процессора уменьшится ещё как минимум в 2 раза. И прерывания можно будет запрещать на дольшее время. И вообще, приём можно будет сделать не по прерыванию.
Только нужно ли это? Чем LIN то плох?

Ну причем тут LIN?!
В этой теме речь о том, как обеспечить надежную работу UART в указанных условиях.
А какую шину использовать для передачи и какой протокол выбрать - это уже совсем другая задача.
Связывать эти две проблемы в одну - совершенно не обязательно. На мой взгляд - лучше, как раз, НЕ связывать, и иметь определенную свободу дальнейшего выбора и протокола, и физической шины.

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

to attab: Вы, видимо, не совсем поняли, что предлагается. Калибруется программная процедура - по приему известных значений байт. Поэтому, ни термометр, ни калибровочные значения для генератора - не требуются.
Диапазон такой "подстройки" по частоте составляет "разы" от предполагаемого номинального значения, как
вверх, так и вниз. По сему, такая калибровка - заодно выполняет функцию автоопределения скорости обмена.
На практике все это давно и многократно проверено...

Это так кажется, пока не столкнёшься.
Пусть даже один из сотни попадётся, всё равно очень неприятно. Пользователя ведь не волнует, что ему вот с кварцем не повезло.
Причём проблемы могут возникнуть через полгода-год успешной эксплуатации.
А некоторые семейства атмелов (например, 8253) имеют особую предрасположенность к таким дефектам.

Надо ли это понимать так, что дефектных часовых кварцев в природе не бывает ?



А что в нем хорошего ? На малые расстояния, с малой скоростью - ну, может быть и ничего. А если большая емкость, переключение линии несимметричное и время перехода 1->0 и 0->1 существенно различаются ? И аппаратный UART задействовать тоже не особо просто, даже если опорный генератор процессора допускает "электронную" подстройку. А если не допускает, то типично дискретность перестройки через опорный делитель слишком грубая. А синхронные протоколы - просто и надежно.

Я имел ввиду использование автоподстройки частоты как в протоколе LIN в комплекте с СОФТОВЫМ UART. В таком случае разница переднего и заднего фронтов и соотв-но время перехода 1->0 и 0->1 запросто компенсируются програмными настройками по результатам приёма известного байта. А ещё лучше сделать софтовый CAN. Для скорости 5000 бод это вполне реально. В таком случае можно использовать драйвера линии LIN. Т.е. 3-х жильный провод - земля, линия связи и питание 12 вольт. А синхронные протоколы потребуют и проводов и драйверов линии поболее. А цена драйвера линии (хоть RS485, хоть CAN, хоть LIN) на уровне младших AVR (ATmega48 например).

Цитата(galjoen): "... синхронные протоколы потребуют и проводов и драйверов линии поболее..."

Это не так. Самосинхронизирующиеся способы кодирования - специальных драйверов и дополнительных проводов не требуют... Ув. rx3apf, на самом деле, прав. Применительно к условиям задачи, заданной в этой теме, то же "манчестер" был бы на много предпочтительнее. Но вопрос был поставлен об использовании и обеспечении стабильности UART...

Синхронные, это которые с внешней синхронизацией. А самосинхронхронизирующиеся - это другое. Все современные протоколы самосинхронизирующиеся. Поэтому у них и имеется битстаффинг - для синхронизации. USB, CAN и т.д. Да и LIN тоже, с некоторой натяжкой, можно отнести к самосинхронизирующимся. Он на базе UART. Поэтому его и рекомендуют.

<<Все современные протоколы самосинхронизирующиеся. Поэтому у них и имеется битстаффинг - для синхронизации. USB, CAN и т.д. Да и LIN тоже>>

И снова не верно. НЕ все.

И стандарный UART - НЕ самосинхронизирующийся! Не зная опорной частоты невозможно достоверно принять информацию. А для самосинхронизирующегося "манчестера" - можно!

Извините, ув. galjoen , но Вы хотя бы уясните для себя разницу между физическим уровнем и протоколом...