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

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


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

Не удивительно, если для хранения 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. Тоже вполне пристойно. При комнатной температуре, по крайней мере.

Ну я лично только с 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-а и останется три бита для адресации байта в исходном буфере. Код будет довольно эффективный...