TIC5234+Attiny2313, Алгоритм работы с дисплеем Опции

[sabrat]

Есть небольшой проэктик под который заложил дисплей TIC5234 и Attiny2313. Начал разбиратся с дисплеем, накатал библиотеку. Всё скомпелировалось и работает но только библиотека работы с дисплеем занимает больше половины флеши Attiny2313, а задач ещё много. Может кто-то с ним работал и есть более компактная библиотека?

P.S. У дисплея TIC5234 контроллер является обычным сдвиговым регистром на 49 бит. Загружаются биты последовательно начиная с 49-го. Дело в том что у него есть куча дополнительных сегментов которые мне использовать не нужно. А сегменты знакомест разбросаны как попало. Немогли бы Вы мне подсказать как тогда формировать пакет 49 бит для загрузки в дисплей в таком случае?

Вот тут его мучают http://www.xdevs.com/e107_plugins/conte ... content.21

Вот его pdf http://www.trt.ru/products/tic/pdf/segment/TIC5234.PDF

Заранее благодарю за помощь.


вот пример библиотеки

Сообщение отредактировал sabrat - Jan 20 2011, 11:07

Прикрепленные файлы

 tic5234.rar ( 1.5 килобайт ) Кол-во скачиваний: 97

 

[rezident]

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

[rx3apf]

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

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

[Laptop]

Сколько-сколько ? Это что, передать 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]

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

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

[PCBExp]

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

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

[_Pasha]

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

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

[sabrat]

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

[rx3apf]

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

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

[sabrat]

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

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

[rx3apf]

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

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