MSSP(IIC) и USART

AHTOXA:
Наш с chav1961
А это Ваш коллективный проект?

тоже правильный
В теории-то, насколько я понял, подход - одинаковый. А вот с реализацией...
К сожалению, мне трудно судить, поскольку Си, тем более для АВРов, не люблю с детства.
Не знаю, какой смысл Вы вкладываете в понятие "дуплексный", но мой UART также может одновременно с приёмом вести и передачу. А ещё, при скорости 31250, он успевал пересылать данные в аппаратный UART, используя буффер (так как скорости - разные). Ну, и конечно, моргать светодиодами.

Так выложите её
Так, вроде, выше ссылку давал.
Дополнительная информация - у меня на сайте, в "Электронике" (Вы уж там, вроде, всё должны наизусть знать ).

Gregory: К сожалению, мне трудно судить, поскольку Си, тем более для АВРов

Вовсе и не для АВРов

Gregory: Так, вроде, выше ссылку давал.

Какую ссылку? Нет выше никакой ссылки.

Gregory: Дополнительная информация - у меня на сайте, в "Электронике"

Ну это уже неуважение какое-то. Дайте прямой линк на исходник, неужели трудно?

AHTOXA:
Какую ссылку?
Gregory
В 9-м номере журнала, за этот год, есть статья "Com to MIDI, или преобразователь скорости UART"

Коль не хотите статью читать, вот Вам прямой линк на исходник, дабы меня не обвиняли в неуважении.

Это не ссылка, это название статьи в каком-то журнале... Вы слишком высокого мнения о моих телепатических способностях
...
Посмотрел исходник. Честно говоря, у меня такое чувство, что если выкинуть зачем-то напичканные там NOP-ы, то можно обойтись и без кварца на 24МГц

Не увидел там ни многократного семплирования, ни ещё каких-либо отличий Вашего "ПРАВИЛЬНОГО построения UART" от моего обычного

AHTOXA, NOP'ы как-раз служат для "правильного" построения. Они выравнивают все ветви программы, и передача/приём битов происходит строго через АБСОЛЮТНО РАВНЫЕ промежутки времени. Именно это ставилось главной задачей, а не оптимизация кода.
Без 24МГц, увы, не обойтись (для данных скоростей, разумеется).
По этой же причине повторная выборка присутствует только для стартового бита. Этот момент я уже оговаривал, и сказал, что мы им пренебрегаем (линии связи - идеальные ). Если же скорости гораздо меньше, и позволяют делать аж 8 выборок (как в Вашем случае), то почему бы этим не воспользоваться?
Кстати, в в/у статье всё это расписанно.

P.S.: А автор темы так куда-то и исчез, толком не сказав, что ему надо?

Апсолютно равные промежутки времени обеспечивает таймер. Безо всяких nop-ов. Всё же гляньте мой пример, там, имхо, всё достаточно прозрачно.
Просто приём/передача отрабатываются в таймерном прерывании поочерёдно.
А выборок, кстати, там не 8, а всего 4
ЗЫ. Если у Вас одна выборка на бит, то приём - не работает.

AHTOXA:
гляньте мой пример
Говорю же: "Не понимаю я СИ". Поэтому ориентируюсь на рисунок chav1961. А там 8 тиков (а не выборок, которых там по одной).
Абсолютно равные промежутки времени между НАЧАЛАМИ ОБРАБОТКИ ПРЕРЫВАНИЯ от таймера не могут быть по определению, и происходят с разницей до 2-х машинных циклов. Не верите, проверьте сами. Могу даже, если хотите, поискать тему, где это обсуждалось.
Допустим, что этого нет, и вход в обработку происходит строго через равные промежутки времени. Но я-то добивался (и добился) не равных промежутков между ВХОДОМ В ОБРАБОТКУ, а между ФОРМИРОВАНИЕМ ПЕРЕДАВАЕМЫХ и СЧИТЫВАНИЕМ ПРИНИМАЕМЫХ битов. Надеюсь, разница ясна? Сомневаюсь, что это возможно реализовать на СИ.

приём - не работает
Не знаю, что Вы имели ввиду, но у меня всё собрано, проверено и работает (есть фотографии). Статье-то, уже скоро год будет (с момента написАния, разумеется )

Gregory: Но я-то добивался (и добился) не равных промежутков между ВХОДОМ В ОБРАБОТКУ, а между ФОРМИРОВАНИЕМ ПЕРЕДАВАЕМЫХ и СЧИТЫВАНИЕМ ПРИНИМАЕМЫХ битов

Гы, а какая связь между ними? Это совершенно независимые процессы. Видимо, у Вас там просто эхо ловится, поэтому приём и работает. Но это ненадёжно, случись небольшая задержка в МИДИ-устройстве - и Вы всё прозеваете.

Gregory: Сомневаюсь, что это возможно реализовать на СИ.

На Си можно реализовать всё, просто надо приложить голову Объясняю словами:
1. Делаем прерывание в 8 раз чаще чем скорость порта (погодите говорить, что не хватит скорости, её хватит);
2. В прерывании счётчик от 0 до 7.
3. При значении счётчика = 0 - занимаемся передачей. (задержка от входа в прерывание до изменения состояния ноги постоянная, джиттера нет (практически), скорость соблюдена)
4. При чётных значениях счётчика - занимаемся приёмом. У нас выходит 4 раза на бит, вполне достаточно для достоверного отсчёта сначала полубита (чтобы попасть после спада на середину бита), а затем и битов (на следующие середины).

5. Ещё 3 значения счётчика свободны, можно сделать ещё 3 передатчика, или ещё что-нибудь полезное

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

Почему это решение лучше? Потому что:
а) Это решение универсально;
б) Приём и передача независимы.

Я тут посчитал на калькуляторе...
Для PIC при кварце 24МГц и скорости порта 31 250 при моём алгоритме выходит 24 команды на прерывание... Негусто, но можно
АВР рулит

AHTOXA:
у Вас там просто эхо ловится
Давайте без оскорблений. Если я не понимаю СИ, мне не зазорно сказать про это. А МИДИ, за 15 лет общения, маленько освоил. Никаких эхов. Что надо, то, и ловится, и передаётся. И допустимая точность рассчитана и указана. И пользуюсь данным девайсом уже год.

Это совершенно независимые процессы.
Гы! Вы всё-таки никак меня понять не хотите. Даже не знаю, как ещё объяснить. Глядим на в/у рисунок. Я добивался равных промежутков МЕЖДУ СТРЕЛОЧКАМИ, как при приёме, так и при передаче. Так понятно?

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

не надо никаких nop-ов
Да что Вы привязались к этим нопам? Они там, в основном, как-раз для сокращения ВЫПОЛНЯЕМЫХ команд, при вычисляемых переходах. Что бы не производить дополнительные вычисления с аккумулятором, а сразу суммировать с PCL. Ну занимают они чуть больше програмной памяти. Ну и что? У нас её в избытке.

Приём и передача независимы
Как же они независимы, если используют одно и то же прерывание?

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