[rezident 0]

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

[rx3apf 0]

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

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

 

[Laptop 0]

Сколько-сколько ? Это что, передать 640 байтов на i2c 400 kHz занимает 1-2 секунды ? Это на чем писано, на интерпретируемом васике, что ли ? Потому как чисто передача из буфера займет меньше 15 mS...Сама стекляшка на порядок тормознее, так что и такой скорости не требуется.

Там несколько больше пересылается... TIC218 133*64, т.е. у него строка посылается как 2, итого 9+128+9+5 = 151 байт на строку, 151*8 = 1208 байт на заполнение экрана. Это не считая старт-стопов и рестартов I2C.

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

Так что может зря я на I2C погнал :)

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

Но жаба давит 360 тактов простаивать ожидая отправки следующего байта и 54360 тактов на всю строку. С SPI быстрее бы вышло.

На плате стоит Мега16 и конечно строки уходят раздельно, так как буфер маленький.

 

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

 

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

 

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

[rx3apf 0]

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

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

[PCBExp 0]

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

 

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

[_Pasha 0]

Собственно весь мой вопров в протоколе.

<кусь>

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

Думается так.

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

Далее, в пространстве регистров чтения записи создаете область для ввода/вывода текста.

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

[sabrat 0]

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

[rx3apf 0]

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

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

[sabrat 0]

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

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

[rx3apf 0]

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

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