Ну я лично только с TIC234 (133*64) работал. Хотя читал аналогичные мнения (о тормознутости отображения) и относительно других графических TICов примерно такого же размера. Насчет напраслины, возводимой на интерфейс I2C, согласен. Интерфейс тут не при чем.

Я штуки четыре разных графических TIC опробовал (по номерам сейчас лениво смотреть). У всех стекло тормозит примерно одинаково и примерно так же, как и у других монохромных модулей (и экранов во всякой аппаратуре). Примерно так же, как и у знакосинтезирующих модулей на 44780. Некоторые шустрее, некоторые тормознее - от химии зависит.

Там несколько больше пересылается... TIC218 133*64, т.е. у него строка посылается как 2, итого 9+128+9+5 = 151 байт на строку, 151*8 = 1208 байт на заполнение экрана. Это не считая старт-стопов и рестартов I2C.
Если заниматься только выводом, то больше 50 миллисекунд не должно получаться.
Так что может зря я на I2C погнал
Но между передачей байтов контроллер еще и другие задачи успевает сделать. Понятное дело что тут еще немного набегает.
Но жаба давит 360 тактов простаивать ожидая отправки следующего байта и 54360 тактов на всю строку. С SPI быстрее бы вышло.
На плате стоит Мега16 и конечно строки уходят раздельно, так как буфер маленький.

Надо будет светодиодом моргнуть при записи и посмотреть сколько идет запись и через сколько дорисует. Завтра проверю.

Визуально стирание экрана после включения проявляется как исчезновение точек на экране сверху-вниз, т.е. горизонтального заполнения строки не видно. Длится это около секунды. Шрифты рисуются конечно медленнее.

Если честно, не подозревал что сама стекляшка так может тормозить. Вроде уже везде даже мигающие курсоры рисуют, а тут на тебе.

Я при 200 kHz не замечал ничего подобного, заполняя экран символами с программным знакогененатором, посимвольно. Сам процесс заполнения - мгновенный, десятки mS. А если из буфера - то тем более быстро. А вот стекляшка тормозит.

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

Вопрос плавности вывода информации наверняка встанет, но чуть позже. Сейчас хотим определится с логикой. Дело в том что панель с индикатором и кнопками это отдельный узел который может быть как опция, а может и не быть. Подключить его к вычислителю (на основе ARM9 и Linux) можно только по RS232, причем свободный порт у нас всего 1. Если индикаторы с последовательным вводом мы нашли (например NORITAKE они кстати недешевы) то как быть с кнопками в этом случае непонятно. Первое что пришло на ум, взять графический индикатор (например Winstar) и повесить его на дешевый AVR вместе с кнопками. Использую UART на AVR общаться с ARMом. Собственно весь мой вопров в протоколе. Не хочется изобретать велосипед Надо как то красиво (лучше используя стандартный протокол - чтоб не изобретать техническое задание) опрашивать кнопки и выводить на экран текстовое меню и графики. То что это мини TERMINAL понятно, но как графику рисовать? Она должна отображать физические величины вроде температуры и давления, которые псевдографикой отобразить не получится.

Думается так.
Берете модбас. Кнопки лучше опрашивать не прозрачно, чтением очереди низкоуровневых событий, а с помощью некоторой регистровой модели, туда впихнуть и удержание кнопки, и нажато/отпущено, и код клавиши, и задавать typematic rate для автоповтора - в общем, эдакий сферический конь "клавиатура". Авр создает при нажатии/отпускании параллельно все мыслимые события, хост пользуется только тем, что нужно.
Далее, в пространстве регистров чтения записи создаете область для ввода/вывода текста.
Для графики - лучше покурить, как устроены VCL компоненты типа рисователей диаграмм, некоторую систематизацию входных данных сделать - то ли это пары точек, то ли коэффициенты аппроксимирующих полиномов - все фичи тоже распределить по регистровой модели.

Неужели ни у кого нет наработок с дисплеем TIC5234?

Ну ведь рассказал же, как компактно сделать перестановку битов, чего ж еще ? Индикатор из малопопулярных (у основной массы остальных гаммовских индикаторов сегменты расположены более "системно").

Спасибо, что то я не узрел. Сейчас попробую.

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