Есть небольшой проэктик под который заложил дисплей 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

Не удивительно, если для хранения 50 бит использовать 50 int'ов, а для кодирования используется вагон switch/case и присваиваний. Странно что вообще влезает. Для начала хотя бы сделайте битовый, а не целочисленный массив, правда вряд ли это кардинально поможет, надо искать в корне другой подход.

Неправильная ссылка.

вот нормальная ссылка http://www.xdevs.com/e107_plugins/content/....php?content.21

как эти свичи обойти?

Переписать (перепишу) на ассемблере.
И оставшуюся программу - тоже :-).

На Сях никак?

К сожалению (хотя и небольшому), но на Сях - я не пинг-понг.
Зато все остальные - легко.

если можно то и на асме будет понятно алгоритм

Можно поступить тупо, если не жалко 462 байт конечно. Храним на каждую цифру в каждом знакоместе массив из 7 байт, т.е. массив получается трехмерным. Символ 0-9+пробел, позиция знакоместа и собственно байты массива (несколько длиннее чем нужно).

Только не забудь в коде что-нибудь аналогичное IAR __flash использовать.

Извращенный и более медленный вариант хранить номера битов посылки в массиве позиций и сегментов. Тут получается 78 байт, но еще код для установки нужных битов и знакогенератор на 11 байт.

Делаем массив во числу загружаемых сегментов (там надо загрузить 80 битов, но, поскольку остальные нули, то 50 байтов хватит). В каждом элементе адрес бита в некоем "исходном буфере" (обычный битмап, организованный как удобнее, типа по байту на цифру с одинаковой расстановкой сегментов в битах, плюс байт на транспаранты). Адресация как удобнее, 4+4 либо 5+3 бита. При формировании очередного бита на вывод загружаем байт из таблицы, по нему проверяем "исходный" бит, копируем его значение на выходе, стробируем... Тут особо спешить некуда (при работе с этими индикаторами нужны заметные задержки, существенно больше, чем для самого драйвера ML1001). Думаю, идея понятна ?

Доброго времени суток.

Долго думал где спросить и решил что эта тема ближайшая...
Вкратце задача стоит так: есть графический дисплей - 128 на 32 точки и надо как-то из мощного вычислителя рисовать на нем простейшие графики. Для общения с дисплеем у этого вычислителя есть только RS232. Какие либо протоколы для рисования графиков выдумывать не хочется - потому как фантазия заказчика границ не знает.

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

PCBExp, во-первых, вы неудачно влезли в чужую тему. Нужно было создать свой собственный топик.
Во-вторых, определитесь, нужно ли действительно рисовать графику или достаточно определенного количества фонтов и заранее подготовленных картинок/пиктограмм/спрайтов? Если второе, то это получается обычный терминал. Изобретено на заре компьютеростроения. Когда машины (ЭВМ) были большими (ЕС ЭВМ, например). Терминалов существует много разных, погуглите какой вам более подходит. Связь с терминалом происходит посредством передачи ему команд позиционирования, управления курсором и кодов символов/пиктограмм.

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

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

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

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

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

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