Раз это отдельный модуль, значит он должен брать на себя основную задачу по организации работы шины? Т.е. МК подготовил сообщение и передал модулю TWI на отправку, после чего процессор "пошел" заниматься своими делами до возникновения прерывания от TWI, например. Так? Или я ошибаюсь и процессор МК "висит" пока идет отправка сообщения? - но тогда прерывания от TWI становятся ненужными.

А что происходит если сообщение еще отправляется модулем TWI, а процессор уже накидал новых сообщений?

Добавлено after 5 minutes 46 seconds:
Работаю в CVAVR со встроенной библиотекой TWI.

зависит от твоего желания.
лично я жду (процессор ждет) окончания операции (передачи байта или приема байта).
процессор у меня не "висит", а проверят бит TWINT регистра TWCR, ожидая окончания операции.
а можно разрешить прерывание по TWI, тогда процессор может выполнять другую работу, пока не наступит прерывание по TWI.
если нужно передать несколько байт, следует создать буфер и сначала заполнить его требуемым количеством байт. потом по прерыванию процессор из буфера будет брать очередной байт и отправлять его, и так, пока не закончится вся очередь.

Starichok51, ок. А если такого буфера не делать, а просто накидывать? У модуля TWI какой-то свой буфер наверно есть? Он будет перезаписываться каждый раз когда прилетит новый байт? И на момент отправки следующего сообщения, что в этом буфере будет лежать, то и отправится?

Из документации (+трансл.):

Нужно знать какая задача стоит, может и не потребуются все эти измудроствования..
А так да, пока отправляется байт можно заниматься другими делами, а потом проверка флага TWINT.
По SPI интерфейсу тоже самое кстати, во время отправки байта готовится следующий, и потом проверка SPIF.

а еще, кстати, то же самое по USART.

да, и USART

но:
если на скоростных интерфейсах прирост производительности ощутим, то на айтуси вряд ли можно выкружить многое

Нужно рассматривать конкретный пример.

как МК может что-то накидать без вашего ведома?

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

ну да, я это и имел ввиду
если частота интерфейса 400кГц, а тактовая МК 16МГц (например), то прирост в производительности будет невелик, если готовить следующий байт во время отправки предыдущего.

А вот в коде возможна излишняя путаница.

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

Никакой путаницы не будет, если не городить синхронизм подготовки данных и его передачи.
Для подобного делают кольцевой буфер, на который есть два указателя - один куда писать из кода, другой - откуда брать для интерфейса.
Это стандартный прием работы.
Получается совершенно автономный код.

Добавлено after 3 minutes 16 seconds:

Нужно помнить, что частота определяется мастером шины и никаких ограничений на ее номинал. кроме верхнего значения нет. То есть частота может быть ЛЮБАЯ не превышающая максимально допустимую. 400 кГц (где она указана) - это и есть максимальная.

Мы - новички, можем все Конкретный пример:
Дисплей I2C. Реализовал ползунок, который двигается переменным резистором подключенным к АЦП. Данные с АЦП снимаются по завершении преобразования и отправляются в дисплей функциями glcd_rectangle() и glcd_block() (CVAVR). Полагаю, что АЦП работает быстрее чем интерфейс I2C. Ну вот так и накидывается в буфер . В результате получаю движение ползунка с рывками и тормозами. Скорость I2C 400 КГц. На интерфейсе SPI все летает. Прихожу к выводу, что лучше использовать SPI.

Хотя. дисплей SPI я без АЦП проверял. Просто по пикселю линию рисовал... было все очень быстро. Тогда, может это АЦП тормозит... не проверял.

Я тоже новичёк

Однажды была у меня задумка, подключить дисплей через отдельный контроллер. То есть один контроллер получает, обрабатывает и прочее, и льёт уже готовые данные (но скорее условные команды) во второй. А второй тупо данные на дисплей выводит, поле подчищает, с цветами разбирается.. там же тоже много работы бывает

PS: На подобии дисплея Nextion хотел сделать

shonty, получилось?

Разве? В AVR, насколько я помню, приёмный буфер USART содержит два байта, а так же ещё есть сдвиговый регистр, который принимает следующий символ. Приёмный буфер организован по типу FIFO - первый пришёл, первый вышел. При чтении регистра UDR считывается первый принятый байт. После чего данные в буфере сдвигаются и регистр UDR указывает уже на второй принятый байт.

Задумка так и осталась задумкой.

во-первых, речь изначально шла про передачу, о приеме разговора не было.
во-вторых, если нужно передать несколько байт, то в буфер USART ты их не запихнешь.