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

 

[Laptop]

[...]
Первое что пришло на ум - сделать что-то типа "прозрачного" контроллера. Например, "наливаем" по RS232 16*32=512 восьмибитных символов в память какого нибудь AVR (если бит в 1 то соответствующий ему пиксел светится, если в 0 - не светится) . А потом с помощью этого AVR разворачиваем эту "точечную" картинку. От картинок динамичности не требуется. А если что и выдумают то при скорости порта 115200 и 16МГц у AVR вроде как все должно быть гладко и плавно. Но создается ощущение что изобретаю велосипед. Наверняка есть более красивое решение. Может даже и дисплеи есть готовые - подскажите что-нибудь люди добрые....

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

Пример TIC32 и TIC218. Но тут больше I2C виноват несмотря на 400 кГц.
Проявляется как прорисовка полного экрана за 1-2 секунды.

С параллельной шиной чуть побыстрее, но тоже контроллер может сам по себе томозить(смотри время выполнения команд в даташите). Лучше если дисплей виден как память в адресном пространстве, тогда все зависит только от процесора.

[rx3apf]

Большинство графических дисплеев с контроллером тормозные, порой очень сильно...
Пример TIC32 и TIC218. Но тут больше I2C виноват несмотря на 400 кГц.
Проявляется как прорисовка полного экрана за 1-2 секунды.

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

[rezident]

Это что, передать 640 байтов на i2c 400 kHz занимает 1-2 секунды ?

Не передать, а отрисовать (отобразить). Laptop прав (хотя про 1-2 с немного преувеличил, я бы оценил отрисовку экрана 128*64 в 0,5-0,7с), TICи с интерфейсом I2C довольно тормозные дисплеи. Даже при комнатной температуре, не говоря уже о минусе.

[rx3apf]

Не передать, а отрисовать (отобразить). Laptop прав (хотя про 1-2 с немного преувеличил, я бы оценил отрисовку экрана 128*64 в 0,5-0,7с), TICи с интерфейсом I2C довольно тормозные дисплеи. Даже при комнатной температуре, не говоря уже о минусе.

Да, но сказано было "виноват I2C". А интерфейс-то чем провинился, если стекляшка тормозная ? Буфер загружается за десятки mS, а уж сколько времени займет собственно переориентация кристаллов - вопрос только к химии. При изменении 4 раза в секунду качество более-менее приемлемое (хотя некие цветовые артефакты на бело-синих индикаторах наблюдаются). На сайте "Гаммы" есть ролик с анимированной графикой на таком модуле - там десятки Hz. Тоже вполне пристойно. При комнатной температуре, по крайней мере.