MSSP(IIC) и USART
Совершенно верно, тиками таймера управляется как передача, так и прием. У меня просто еще выполнялся останов таймера, когда ни прием, ни передача не требовались 
chav1961:
Не нужно делать прием/передачу асинхронными
Это и есть проблема. 
Ну так мы ее решили С АНТОХИной помощью.
Если сегодня будет время, нарисую временную диаграмму. Будет понятно Может быть, и АНТОХА что-нибудь напишет/нарисует.
Tim18, выкладываю обещанное (см рисунок).
1 строчка - прерывания (тики) от таймера
2 строчка - процесс передачи
3 строчка - процесс приема
С АНТОХИной программой есть некоторые расхождения непринципиального характера. Предполагается, что интервал между тиками таймера в 8 раз короче, чем длительность передаваемого (принимаемого) бита данных. И передача, и прием данных выполняется в обработчике прерываний от таймера. Процесс передачи (8 бит без контроля четности, 1 стоповый бит) выполняется следующим образом:
1. Для передачи байта вначале на линию выдается старт-бит длительностью 8 тиков таймера.
2. Затем аналогичным образом передаются 8 битов данных.
3. Затем передается стоп-бит также длиной 8 тиков.
Если при передаче на входной линии появился принимаемый сигнал, одновременно с передачей начинается процесс приема. Для этого через 4 тика с момента появления сигнала считывается состояние приемной линии - это будет стартовый бит (на рисунке моменты чтения обозначены стрелочками). Через 4 - для того, чтобы попасть в середину принимаемого бита, где его значение наиболее "правильное". Затем, через 8 тиков, считывается старший бит (опять, чтобы попасть в середину бита), затем, также через 8 тиков - следующий, следующий и т.д. пока не будет считано 10 битов, т.е. цикл чтения приемной линии выполняется 10 раз (хотя последний стоп-бит можно и не читать - тогда 9 раз). Первый и последний считанные биты отбрасываются, получается принятый байт.
Вот в все Если таймер выставлен корректно, никаких подгонок с точностью до машинных циклов не требуется. Если нужно разгрузить систему, таймер при отсутствии передачи и приема можно отключить. При передаче он включается программно, перед началом передачи байта, при приеме - прерыванием от входной линии. Полагаю, с этим у Вас проблем не будет.
chav1961:
Вот в все
А вот и нет. Бум разбираться.
интервал между тиками таймера в 8 раз короче
А в цифрах? Жаль, конечно, что, видимо, никто не смотрел моей программы. Так вот. Принцип там такой же (используются прерывания от одного таймера).
Но.
Что бы получить скорость 31 250 бод, пришлось увеличивать частоту генератора до 24 МГц (это я про ПИКи), что выше гарантированной разработчиком (благо все экземпляры завелись без сбоев), и я еле-еле уложился в 3 тика. Если же Ваш интерфейс настолько медленный, что позволяет использовать 8 тиков, при приёме, разумнее делать несколько выборок (как положено), и принимать решение, на основе "среднего значения".
Если таймер выставлен корректно
Таймер тут ни при чём. Речь идёт о том, что, в связи с аппаратными особенностями, переход на вектор прерывания осуществляется с разницей до 2-х М.Ц.
Кроме того, как уже говорил ранее, все остальные прерывания должны быть выключены.
Теперь надо внести ясность в вышесказанное.
Всё вышеперечисленное относится к случаю, когда вы хотите получить скоростной UART с высокой достоверностью. При этом все некоторые расхождения непринципиального характера не обязательно приведут к неработоспособности интерфейса. Возможно они всего лишь повысят требования к идентичности скоростей приёмника и передатчика, т.е. приведут к большОму количеству сбоев (неверно принятых байтов).
Естественно, требования снижаются, при уменьшении скорости интерфейса. Был девайс, где организовал передатчик, не выключая остальных прерываний. Но там, надо было передать только две команды (на остальные приёмник не реагировал), очень редко. Поэтому скорость была снижена, насколько позволял приёмник, а команды дублировались несколько раз.
Gregory, тот подход, что я описал, обеспечивает не более 9600 бод на 8 Мгц на любой Меге. Реализовывать программным путем 31кбод и выше - издевательство и над собой, и над девайсом, потому что ничем, кроме приема/передачи, такой девайс больше заниматься не сможет. Не жалко железку-то ? Речь именно о высокоскоростном UARTе в топике не шла, поэтому разговор и пошел в нынешнем русле.
chav1961:
в топике не шла
Кстати, я так что-то и не уловил, какая скорость нужна?
издевательство
Я бы всё-таки сформулировал малость по-другому.
Я описАл способ ПРАВИЛЬНОГО построения UART, с определёнными характеристиками (данные в статье).
Описанный же Вами способ "грешит" некоторыми расхождениями непринципиального характера, что необходимо учитывать, при его использовании.
Не согласны?
Gregory: Я описАл способ ПРАВИЛЬНОГО построения UART, с определёнными характеристиками (данные в статье).
Наш с chav1961 UART тоже правильный И к тому же дуплексный, в отличие от
Отсутствует только многократное семплирование, то есть помехоустойчивость похуже, вот и всё. Аппаратные реализации UART семплируют по 16 раз на бит, я сомневаюсь, что Вы это реализовали.
Gregory: Жаль, конечно, что, видимо, никто не смотрел моей программы.
Так выложите её, вот и посмотрим