MSSP(IIC) и USART

Да это так, сопли и вопли , вы ещё не видели настоящих сражений , как например у меня с AVR с телесисек...

Вот у меня, Gregory, к вам, как к автору, два вопроса. В статье приводится оценка отклонений скорости приёма и передачи по миди, как ±(1/3)/10=±0.033. На самом деле, оценка должна быть ±((1/2)/3)/8.5=±0.0196 или ≈±2%, а не ±3.3%, как показано у вас. Допустимо это для миди?

Второй вопрос касается задержки передачи байта от миди-устройств. Сначала вы принимаете байт полностью, затем передаете его по ком. Задержка будет не менее 10*32=320 мкс. Ощутимо ли это для комфортной работы по миди интерфейсу?

To AHTOXA: То есть, записи: incf tmr_cnt,F и incf tmr_cnt - эквивалентны
Да, для конкретного транслятора. А в общем случае - нет, второго варианта команды просто может не быть. Учите матчасть.

GM: вы ещё не видели настоящих сражений , как например у меня с AVR с телесисек...

И что, не хватает? Не стоит тащить это сюда, ладно? Здесь немножко другая атмосфера...

GM: Да, для конкретного транслятора.

Ок, слив засчитан

Ну так и не портите её, начните с себя.

GM: Ну так и не портите её, начните с себя.

Ну вот ещё. Портите Вы, а начинать мне с себя? Не согласен

Господа, вернулись бы вы к теме, а ?

Господа, вернулись бы вы к теме
Стопудово поддерживаю.

GM:
Допустимо это для миди?
Тут дело не в том, что это - МИДИ, а в том, что это - UART. Т.е., при реальной разнице скоростей приёмника и передатчика менее указанной величины, данные будут приниматься без ошибки. Напомню, что в идеале, они должны быть абсолютно равны.
По поводу непосредственно величины.
Статья была довольно сильно отредактирована редактором (пардон за тавталогию). В частности удалены эпюры, которые поясняют рассчёты. Попробую найти и выложить здесь. Может я где и ошибся.

Ощутимо ли это
В принципе, ответ отрицательный.
Как Вы сами подсчитали, MIDI - довольно "тормозной" интерфейс, с точки зрения электроники, но для музыканта таких скоростей вполне хватает. Кстати говоря, сам "приёмник", сперва примет весь байт, а уж только затем начнёт звук "воспроизводить". Или, если одновременно воспроизводится несколько нот (аккорд), они тоже передаются по МИДИ последовательно. И таких примеров можно ещё найти. Т.е., данная задержка, присутствует практически постоянно.
Так что, если не перегружать интерфейс большим количеством информации, то проблем быть не должно.
Честно говоря, ни разу в жизни не довелось видеть МИДИ-систему из большого количества устройств.
Больше знакома ситуация: миди-контроллер (клавиатура, драм-контроллер, и т.п.) - программа-секвенсор, на компьютере. Последовательно прописываются партии-треки, а звуковоспроизведение идёт через звуковую карту. Кстати, вот тут действительно становится актуальной задержка от подачи команды воспроизведения до начала звучания (латенси, но это - уже из другой "оперы"). А сам, внутренний миди-интерфейс компьютера, практически не имеет ограничений. Собственно говоря, его, как такового, там и нет. Секвенсор же позволяет корректировать моменты извлечения нот, или же "привязывать" их к тактовой сетке.

Ещё один вопросик, если позволите. У вас делается три считывания на бит, хотя реально используется два. С моей точки зрения совершенно бесполезно делать два считывания вместо одного, даже вредно, хотя бы потому, что возрастают требования к точности частот приёма-передачи, не говоря уже о пропуске миди-пакета (в случае принятия решения об ошибке).

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

А что за мысль вы хотели высказать в последнем предложении статьи? Никак не могу вчитаться. Почему обсуждается программная реализация усарт, и если это усарт, то почему скорость 3,125. Если это миди, то причём здесь скорость? Разве есть миди с другой скоростью?

GM:
Ещё один вопросик
Полагаю, надо подождать, пока найду оригинал статьи. Думаю, так наглядней будет.

к половине длительности бита
Естественно, это было бы замечательно. Но как?

Почему обсуждается программная реализация усарт
Ну, чего ж тут не понятного?
Интерфейс МИДИ - обычный UART, со скоростью 31 250 бод, и с электрическим исполнением типа "токовая петля". Соответственно, изменив скорость и согласующие каскады, можно применить данный девайс и в любом другом UART'е.
А самая последняя фраза о том, что скорость 31 250 бод, для программной реализации на данном МК, предельная (то, о чём мы чуть выше довольно долго с Антохой обсуждаем).

Gregory: Естественно, это было бы замечательно. Но как?

Сделать достаточно просто, но оба интерфейса должны быть программными, поскольку передача начинается не по приёму целого байта, а по приёму некоторого количества бит.

Поясню на примере. Предположим вы принимаете по миди, пусть начало старт-бита будет при Т=0 мкс. При Т=272 мкс вы примете последний бит байта, значит на 273 мкс вы можете начать передачу последнего бита по ком. Соответственно начать передачу старт-бита по ком вы можете при Т=272-8,5*26=51 мкс или позже, но никак не раньше. Минимальная величина задержки будет 4 мкс.

Gregory: А самая последняя фраза о том, что скорость 31 250 бод, для программной реализации на данном МК, предельная

Значит, надо менять процессор, увы. Особенно с учётом того, что вы его эксплуатируете неправильно, на 24 МГц вместо 20. На авр 20 МГц для заявленных скоростей я мог бы сделать 8 дуплексных независимых конвертеров. А для двух конвертеров по предварительной оценке можно достичь скорости 500 кбод (с учётом аппаратного сом, конечно).

GM:
Поясню
Даже, если предположить, что удастся реализовать два программных UART'а (что само по себе весьма сложно), я всё-равно ничего не понял.

8 дуплексных независимых конвертеров
Чёй-то, по-моему, Вас уж слишком "заносит".