Прошу сильно не пинать, если вопрос окажется слишком глупым, но... что-то у меня никак не получается...
В обшем имеется АВР и ЖК-индикатор. Имеем картинку в виде двоичного файла (полученную из *.bmp путем обрезания заголовков, инверсии и пр.). Эту картинку надо вывести на ЖК (GLCD_write_data (*pBmp++) в цикле...). Пока ничего умнее не придумал, чем такой способ:
Компилим проект, узнаем адрес последнего байта во флеше, к примеру 0x77F;
Компилим поект еще раз, изменив в нем явно указатель на флеш pBmp =
0x780;
Заходим в НЕХ-редактор, склеиваем бинарник проекта с бинарником картинки;
Получившуюся смесь заливаем в кристалл...
Все работает, индикатор показывает, но ... уж больно способ-то топорный и корявый! :-(( Может можно это как-то атоматизировать (под размер проета), облагородить стандартными сишными способами?
С регардсами, Павел В.
P.S. Если это критично - компайлер кодевизион или иар, без разницы.
Самое простое - написать утилитку, которая из бинарного asm файл делает с директивами DB, в которых эта картинка в текстовом виде изложена. А можно и в виде С массива - кому как нравится. Заодно там же можно и заголовок обрезать, палитру преобразовать, и т.п. Объем исходника возрастает раза в 4-5. А полученные asm или С файл(ы) уже подцепить к проекту естественным образом. У меняк одному проекту так 128К (в исходниках 0.6М) речи подключалось.
Есть готовые утилиты, но вообще-то такое пишется за 10 минут самостоятельно, переводящие бинарные данные в текст на С или ассемблере. Дальше компилируешь и линкуешь как обычно. Бывают еще утилиты, переводящие бинарник в объектник, но это может быть, а может и нет.
PV> Имеем картинку в виде двоичного файла (полученную из *.bmp путем PV> обрезания заголовков, инверсии и пр.). PV> 1. Компилим проект, узнаем адрес последнего байта во флеше, к примеру PV> 0x77F; 2. Компилим поект еще раз, изменив в нем явно указатель на флеш PV> pBmp = 0x780; 3. Заходим в HЕХ-редактор, склеиваем бинарник проекта с PV> бинарником картинки;
Ты режешь заголовок BMP и инвертируешь строки - некоей утилиткой? Тогда шагни чуть дальше, и сделай вывод результата не в бинарный формат, а в HEX. Через запятую. Если совсем лениво - можно сразу же и добавлять unsigned char pBmp[] = { в начало файла, и }; в его конец. Потом подключаешь командой #include "picture.hex"
Кстати, что за ЖКИ юзается, сколько стоит, и как оно тебе нравится (в смысле API)? Давно мечтаю сваять что-нибудь графищенское, да все никак не решиться...
Спасибо всем ответившим... Насколько я понял - нихрена такой финт не пройдет, чтобы подключить в проект (в исходник на Си) двоичный файл... жаль...
"Serge Bryxin" snipped-for-privacy@p26.f.n5030.z2.fidonet.org> сообщил/сообщила в новостях следующее:
Так утилитка уже готовая есть - от графикс ГУИ... А самому писАть... Как-то не очень хочется... Тем более что ни простотой, ни изяществом такой способ не отличается :-((.
М-да-а... И получим чудовищных размеров листинги... В общем все с вами ясно :-))
Ampire AT160160AFIEWA53, квадратный, 160 на 160 точек, на базе SED1335. СтОит сколько - не знаю, в районе 40-ка баксов, может чуть больше. На счет симпатий пока ничего определенного сказать не могу, т.к. это пока мой первый графический индикатор.
Ну, апи... Сейчас пройден пока самый первый этап - при подключении индикатора не пошел дым :-)). Потом традиционное "Хеллоу, Ворлд!", Потом симпатичная мордашка Элизабет Харли, в качестве битмапа :-))) Я, конечно, почитал всякие самплесы от всяких там uC/GUI... Но там уж больно все универсально и монстроидально. 24-битный цвет, палитры, RGB и прочее. Это потом.
Так и хочется перефразировать из к/ф "ДМБ" - "Тому, кто придумал SED1335, надо в голову гвоздь забить!". А может сам чип не виноват, а гвоздь тому, кто описалово на этот кристалл писАл. Как вам нравится такая длительность программного цикла:
tCYC8 = 2tC + tCC + tCEA + 75 > tACV + 245
Я размышлял над этим значком "больше" и в трезвом виде, и с кружкой пива - но почему-то озарение на меня так и не снизошло. Что они хотели этим сказать - я так и не понял. Величина tACV нигде не указана, так что я, наверное, так никогда и не узнаю, чему равно это tCYC и с какой минимальной периодичностью пожно пулять данные в видеоОЗУ...
"Andrey Sineok" snipped-for-privacy@odmail.com сообщил/сообщила в новостях следующее:
что
Да-да, что-то похожее... наверное... Просто в этой программке все жестко привязано к конкретным индикаторам, и мой битмап 160х160 в нее никак не влез. Придется достать с полки визуал басик и слепить самому :-))
09 Dec 03 06:49, Pavel Vasyuk wrote to Serge Bryxin:
Hу так тем более :)
PV> А самому писАть... Как-то не очень хочется... Тем более что ни PV> простотой, ни изяществом такой способ не отличается :-((.
Чего там писать-то? Я решал ровно эту задачу когда-то давно - так написал... ну... минут за 10... не помню. Способ отличается простотой и изяществом. IMHO.
PV> И получим чудовищных размеров листинги...
Команду #nolist (или что у тебя там конкретное) - использовать не изящно? :-)
"Serge Bryxin" snipped-for-privacy@p26.f.n5030.z2.fidonet.org> сообщил/сообщила в новостях следующее:
Хех! Та утилитка из ВМР делает похожий бинарный файл, только с растром не снизу вверх, а сверху вниз. И усе... :-( В принципе спасибо и на этом :-))
Ну, это тебе понятно... :-))
Тогда подскажи, Pls, если не трудно, следующее:
Сколько наносекунд ему надо, чтобы он успел прожевать байт данных перед тем, как получит новый? Я что-то никак не могу понять то неравенство, что постил тут уже. Все остальные мануалы (даже нечто русифицированое на гав.ру) старательно передирают эпсоновский :-((. На платке индикатора у SED1335 кварц на 10МГц.
Влияет ли величина TC/R на что-либо практически? В том плане, что коль скоро ее можно выбрать и 24 (C/R+4) и 40 и 60 и вообще какой угодно - существуют ли тут какие-либо осмысленные рекомендации? Может быть стОит подобрать какую-то оптимальную частоту смены кадров? (Из-за того, что экран у меня маленький, сейчас около 170 Гц!)
Переводы строки для убочитаемости и обрезание последней лишней запятой - по вкусу. Или у тебя TurboC нету?
Мне трудно. Я эти ёпсоны программил только в Палме. А там доступ через палмовское железо (регистры замаплены в адресное пространство), и вообще все может быть достаточно не так.
"Понятно" в том смысле, что никаких секретов тут нет: бери и пиши. Только деньги плати (и пытайся потом содрать с клиента). Я-то все мечтаю какой-нибудь бесконтроллерный дешевый дисплюй раскачать...
PV> 1. Сколько наносекунд ему надо, чтобы он успел прожевать PV> байт данных перед тем, как получит новый?
А поэкспериментировать? Я бы в первом приближении запрограммировал, чтобы нисколько (в рамках быстродействия контроллера). Заглючит - будешь nop'ы вставлять :-)
PV> 2. Влияет ли величина TC/R на что-либо практически?
Это частота рефреша, что ли? Если судить по Палму, чем больше - тем меньше мерцает. Хорошо заметно на анимациях. Если дисплей ч/б, то от частоты очень сильно зависит возможность вывода градаций серого (на малых частотах светлые тона мигают просто жутко). Hо на больших частотах больше жрет электричества (весьма существенно).
"Serge Bryxin" snipped-for-privacy@p26.f.n5030.z2.fidonet.org> сообщил/сообщила в новостях следующее:
О том, что тому, кто придумал SED1335, надо в голову гвоздь забить! :-)) (а может мне - тому, кто не смог в нем разобраться... :-))
Ну да, вайл... вайл...
(Краснея и ломая шапку) не-е-ету.....
все
Ну вот...
Ну это понятно... Одако, если есть эха "ру.ембеддед" - почему бы не спросить возможного имеющнгося практического опыта? Может уже есть какой бедолага, который прошел данный путь экспериментов?
Добрый день! "Serge Bryxin" snipped-for-privacy@p26.f.n5030.z2.fidonet.org> сообщил/сообщила в новостях следующее:
Скорее читателю :-)
Да, конечно, сам чип не виноват... :-) Потыкав, попробовав разные варианты инициализации, я вроде понял, что там в нем унутри. А вот ПДФ, на мой взгляд, что-то не очень. Вот в свое время начинал ковырять символьные ЖКИ на HD44780, тогда мне попался ПДФ от Шарпа - роскошная дока! Все расписано, последовательно, почему, отчего и для чего. Вся адресация, куда какие биты попадают и как отображаются, примеры, картинки... - все для полных идиотов :-))
В свое время я до ДОСовского Си так и не добрался - все на асме писАл. У меня валяются мои примерчики 10-ти летней давности, пИисанные в ТАСМе, где открытия-закрытия файликов идет через "инт двадцать один аш" :-)). А сейчас... не знаю... Может для своих собственных одноразовых микротулзов под винду какой-нибудь визуал-пакет использовать, который осваивается за 1 день.
Тут вон перекинул все в Кайл (AT89S8252), прошил чип... светодиоды заморгали, на индикаторе - болт! Опять засада. Кругом враги... :-(( Может надо было на порт данных (Р0) подтягивающие резюки повесить? Что-то такое помню, что в MCS-51 порт 0 какой-то неправильный, без единиц...
Такая, блин, вечная молодость. С регардсами, Павел В.
Tue Dec 09 2003 06:49, Pavel Vasyuk wrote to Serge Bryxin:
PV> Так и хочется перефразировать из к/ф "ДМБ" - "Тому, кто придумал SED1335, PV> надо в голову гвоздь забить!". А может сам чип не виноват, а гвоздь тому, PV> кто описалово на этот кристалл писАл. Как вам нравится такая длительность PV> программного цикла:
PV> tCYC8 = 2tC + tCC + tCEA + 75 > tACV + 245
PV> Я размышлял над этим значком "больше" и в трезвом виде, и с кружкой пива PV> - PV> но почему-то озарение на меня так и не снизошло. Что они хотели этим PV> сказать - я так и не понял. Величина tACV нигде не указана, так что я, PV> наверное, так никогда и не узнаю, чему равно это tCYC и с какой PV> минимальной периодичностью пожно пулять данные в видеоОЗУ...
Документация вполне нормальная, вроде все что надо описано, просто надо немного въехать в работу контроллера и все станет ясно. Попробую немного пояснить.
Период ввода/вывода данных в/из контроллера полностью определяется периодом вывода данных контроллером на индикатор (см. рис.70 и 71 даташита). То есть контроллер постоянно крутит цикл обращения к своей памяти для регенерации экрана. Если пишешь в него команду чтения данных - контроллер при очередном цикле обращения к своей памяти читает себе в буфер первый байт из заданной области. После того, как процессор его прочтет, контроллер читает следующий байт, опять же при очередном цикле обращения к своей памяти, и так далее. При записи - данные попадают сначала в буфер, а затем, уже в память (опять же при очередном цикле обращения контроллера к своей памяти).
С неравенством вроде тоже все ясно - посчитанное tCYC8 должно быть больше правой части неравенства, единственно, что оно всегда так получается, при любых допустимых значениях.
Да, tACV указана в таблице рядом с tCEA, странно что ты не заметил.
Tue Dec 09 2003 21:58, Pavel Vasyuk wrote to Serge Bryxin:
PV> Тогда подскажи, Pls, если не трудно, следующее:
PV> 1. Сколько наносекунд ему надо, чтобы он успел прожевать PV> байт данных перед тем, как получит новый? Я что-то никак PV> не могу понять то неравенство, что постил тут уже. Все PV> остальные мануалы (даже нечто русифицированое на гав.ру) PV> старательно передирают эпсоновский :-((. Hа платке PV> индикатора у SED1335 кварц на 10МГц.
Это я уже рассказал, сможешь посчитать сам.
PV> 2. Влияет ли величина TC/R на что-либо практически? В том плане, PV> что коль скоро ее можно выбрать и 24 (C/R+4) и 40 и 60 и PV> вообще какой угодно - существуют ли тут какие-либо осмысленные PV> рекомендации? Может быть стОит подобрать какую-то PV> оптимальную частоту смены кадров? PV> (Из-за того, что экран у меня маленький, сейчас около 170 Гц!)
Эта величина определяет как бы полную длину строки развертки, включая выходящие за край индикатора символы, которые реально никуда не выводятся, но время на их выборку тратится. Это время можно использовать для вывода на экран без мусора. А так же для регулировки частоты развертки экрана. Кстати при слишком большой частоте еще и падает контрастность.
"Andrey Androsov" snipped-for-privacy@online.debryansk.ru> сообщил/сообщила в новостях следующее:
Да, действительно, tACV приводится в даташите, посыпаю голову пеплом... Только оно приводится _ПОТОМ_. Никак я этого не пойму - как можно сначала использовать функцию, а потом ее объявить? :-))
Вот-вот, это как раз я и хотел узнать.
С регардсами, Павел В.
P.S. Мыло у тебя интересное... Помнится ездили мы года 4 назад в Брянск в командировку - так вот там прикупил бальзам, называется "Дебрянск" :-))
Sat Dec 13 2003 12:06, Pavel V. Vasyuk wrote to Andrey Androsov:
PVV> From: "Pavel V. Vasyuk" snipped-for-privacy@vaz.ru
PVV> Да, действительно, tACV приводится в даташите, посыпаю голову пеплом... PVV> Только оно приводится _ПОТОМ_. Hикак я этого не пойму - как можно PVV> сначала использовать функцию, а потом ее объявить? :-))
<Ctrl>-F тебе в руки - и найдется всё ;)
PVV> Вот-вот, это как раз я и хотел узнать.
Про вывод или про развертку? У меня на 320x240 нормально смотрелась частота развертки 70-100 Гц.
PVV> С регардсами, PVV> Павел В.
PVV> P.S. Мыло у тебя интересное... Помнится ездили мы года 4 назад в Брянск PVV> в командировку - так вот там прикупил бальзам, называется "Дебрянск" PVV> :-))
Дебрянск - это старинное название г.Брянска, вот один из наших провайдеров и изголился :)
PV> 1. Компилим проект, узнаем адрес последнего байта во флеше, к примеру PV> 0x77F; PV> 2. Компилим поект еще раз, изменив в нем явно указатель на флеш pBmp = PV> 0x780; PV> 3. Заходим в HЕХ-редактор, склеиваем бинарник проекта с бинарником PV> картинки; PV> 4. Получившуюся смесь заливаем в кристалл...
#!/usr/bin/perl
binmode STDIN; $c=0; while (read(STDIN, $s, 1)) { $n=unpack("C", $s); if (!$c) {print "\tdb ";} else {print ", ";} printf("0x%x", $n); if (++$c >= 16) {print "\n"; $c=0;} }
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.