информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetSpanning Tree Protocol: недокументированное применениеВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / hardware
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Устройство работает на базе AT91SAM7X256 19.03.06 10:38  Число просмотров: 3338
Автор: zpv78 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
<hardware>
Вывод данных на LCD 18.03.06 20:45  
Автор: zpv78 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Ребята, подскажите есть ли микрухи или устройства, выполняющие функции видеоадаптеров. Мне необходимо выводить
информацию (текстовую) по пикселям на LCD-монитор (разрешение достаточно 800 х 600) с микроконтроллера. Может кто скинет варианты решения
этой проблемы. Заранее огромное спасибо.
Может пригодиться. "Single Board Computers for Embedded Systems". Мы только начинаем (точнее планируем) юзать и пока у меня нет больше инфы. 25.04.06 11:59  
Автор: Garick <Yuriy> Статус: Elderman
<"чистая" ссылка>


Single Board Computers for Embedded Systems
а что тут сложного? 30.03.06 13:55  
Автор: lebaon Статус: Незарегистрированный пользователь
<"чистая" ссылка>
а что тут сложного?

берется микра памяти, с объемом, равным или большим размеру экрана,
шина данных подключается через логические ключи к двум системам триггеров,
входным и выходным, шина адреса к спец триггеру на входе и счетчику на выходе,
тактовый генератор работает на частоте 2*частота выборки на экран,
ключи попеременно поключают память то ко входным триггерам,
то к выходным, получаем пиксельную графику на большом разрешении,
координаты и значения пикселей заводить на вход можно сколь угодно медленно,
всю логику при желании можно запихнуть в плиску
Извини что не ответил, был в командировке. Можно,... 24.04.06 19:32  
Автор: zpv78 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> а что тут сложного?
>
> берется микра памяти, с объемом, равным или большим размеру
> экрана,
> шина данных подключается через логические ключи к двум
> системам триггеров,
> входным и выходным, шина адреса к спец триггеру на входе и
> счетчику на выходе,
> тактовый генератор работает на частоте 2*частота выборки на
> экран,
> ключи попеременно поключают память то ко входным триггерам,
> то к выходным, получаем пиксельную графику на большом
> разрешении,
> координаты и значения пикселей заводить на вход можно сколь
> угодно медленно,
> всю логику при желании можно запихнуть в плиску

Извини что не ответил, был в командировке. Можно, пожалуйста, скинуть схему описанную выше. Только если можно рассыпухой, а то я с программируемыми матрицами не работал. Мой e-mail: zpv78@mail.ru
тупой вопрос 22.03.06 15:47  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
А нельзя ли просто найти четыре (помоему R+G+B+Sync) пина на контроллере и самому гнать картинку? Или это слишком сложно?
Вряд ли микроконтроллер потянет 23.03.06 11:04  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> А нельзя ли просто найти четыре (помоему R+G+B+Sync) пина
> на контроллере и самому гнать картинку? Или это слишком
> сложно?

Думаю не сложно, но pixel rate будет 640*480*50 = 15.3 МГц
И это только на выходе КАЖДОГО пина. Так как выходы дергаются вручную через порты, то как минимум нужно 50 МГц. Стоит еще учесть, что тактовая частота микроконтроллера должна быть гораздо выше (один такт на одно дерганье пина - нереально). Так как никакой конвейеризации у контроллеров нет, то каждый оператор будет выполняться где-то 4 такта (работа с памятью -- дольше), чтобы дергать порты нужно как минимум десяток-другой команд. Итого, допустим, что на одно переключение нужно 100 тактов -> тактовая частота контроллера 5 ГГц :-)

Нужна специализированная железяка
Вспомни спекки 23.03.06 11:25  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
Думаю можно в инете найти схему его контроллера.
Помню. И помню что ULA (и все рассыпухи-эмуляторы) были как раз "специализированными железяками" 23.03.06 14:01  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Специализированная не в том смысле, что микруху разработали специально для этого, а то, что никакого программирования чего нибудь универсального (микроконтроллера) не надо.
И все-таки оно работает! 23.03.06 11:17  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 23.03.06 11:17  Количество правок: 1
<"чистая" ссылка>
И все-таки оно работает!

> Думаю не сложно, но pixel rate будет 640*480*50 = 15.3 МГц

Картинка то на 20 строк по 38 символов. Частота раза в три меньше получается.

> И это только на выходе КАЖДОГО пина. Так как выходы

Там всего один при дергается сразу на три канала, а второй пин синхронизации дергается во много раз реже.

> дергаются вручную через порты, то как минимум нужно 50 МГц.
> Стоит еще учесть, что тактовая частота микроконтроллера
> должна быть гораздо выше (один такт на одно дерганье пина -
> нереально). Так как никакой конвейеризации у контроллеров
> нет, то каждый оператор будет выполняться где-то 4 такта
> (работа с памятью -- дольше), чтобы дергать порты нужно как
> минимум десяток-другой команд. Итого, допустим, что на одно
> переключение нужно 100 тактов -> тактовая частота

Ну не 100. Если памяти в нем несколько десятков килобайт, то ее проше статической заделать - меньше проблем с адресацией, регенерацией и обращение за 1-2 такта. Алгоритм и хранение видеообраза оптимизируется так, что на точку не десяток, а пару команд достаточно будет.
Все реально.

> контроллера 5 ГГц :-)
>
> Нужна специализированная железяка

Специализированная лучше, хотя необходимости нет.

К стати, чем ЛЦД лучше - можно с вдвое-втрое меншей частотой экран регенерить. Еще символы можно рисовать не 8х16, а 8х8, как на CGA. Еще раз в пять можно частоту dot-clock снизить.
20*38*64*50 = 2.5 МГц - уже легче, но с остальным все равно... 23.03.06 14:10  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Картинка то на 20 строк по 38 символов. Частота раза в три
> меньше получается.

20*38*64*50 = 2.5 МГц - уже легче, но с остальным все равно туго.

> Там всего один при дергается сразу на три канала, а второй
> пин синхронизации дергается во много раз реже.

Нужно ч/б - тоже хорошо

> Ну не 100. Если памяти в нем несколько десятков килобайт,
> то ее проше статической заделать - меньше проблем с
> адресацией, регенерацией и обращение за 1-2 такта. Алгоритм
> и хранение видеообраза оптимизируется так, что на точку не
> десяток, а пару команд достаточно будет.
> Все реально.

Нереально. Пара команд (на ОЧЕНЬ урезанной системе команд микроконтроллера) это инкремент (или декремент), проверка и условный переход по флагу. Регистров мало - нужно дергать память, многие команды (тот же вывод в порт) доступны только для одного регистра (например аккумулятора) - надо дергать другие регистры или опять таки память. 10-20 команд это ОЧЕНЬ оптимистичный прогноз.

> Специализированная лучше, хотя необходимости нет.

> К стати, чем ЛЦД лучше - можно с вдвое-втрое меншей
> частотой экран регенерить. Еще символы можно рисовать не
> 8х16, а 8х8, как на CGA. Еще раз в пять можно частоту
> dot-clock снизить.

Все равно нужно тактировать бедный контроллер сотнями мегагерц. Где такие контроллеры, которые это выдержат? Легче уж рассыпуху а-ля эмуляторы спектрумовского ULA - дешево и сердито.
Разрешение 800х600 меня тоже тронуло. Если оно действительно... 23.03.06 15:46  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 23.03.06 15:47  Количество правок: 1
<"чистая" ссылка>
Разрешение 800х600 меня тоже тронуло. Если оно действительно нужно, то это другой разговор.
Если немного подумать, убавить аппетит и ограничится 10 строк по 20 знаков. Если изображение по бОльшей части статическое, то рефреш можно опустить до 25Гц и ниже. Причем инерционность матрицы подавит и на этой частоте мерцание, то:
10*20*64*25=0.32Мгц.

> 20*38*64*50 = 2.5 МГц - уже легче, но с остальным все равно
> туго.

> Нереально. Пара команд (на ОЧЕНЬ урезанной системе команд
> микроконтроллера) это инкремент (или декремент), проверка и
> условный переход по флагу. Регистров мало - нужно дергать
> память, многие команды (тот же вывод в порт) доступны
> только для одного регистра (например аккумулятора) - надо
> дергать другие регистры или опять таки память. 10-20 команд
> это ОЧЕНЬ оптимистичный прогноз.

Есть таблица шрифтов. В регистре символ. Из таблички выдергиваем байт, описывающий одну восьмиточечную строку. В основном цикле (8 раз) закидываем байтик в параллельный порт, младший бит которого является сигналообразующим, делаем побитовый сдвиг регистра. Итого 4 инструкции. out a; shr a; dec c, jne -4. Разумеется для каждых 8 бит нужно будет сделать следующее: загрузить регистр-счетчик значением 8, сделать выборку очередной строки для символа, а для этого значение символа нужно умножить на 8 (сдвинуть влево на 3 бита), добавить номер строки. Ничего страшного, если между символами будет маленький зазор.

> Все равно нужно тактировать бедный контроллер сотнями
> мегагерц. Где такие контроллеры, которые это выдержат?

Можно это дело спаять на двух-трех микросхемах: одна/две ОЗУ, третья ПЗУ и еще счетчик нужен.
В ПЗУ прошиты адреса строк шрифтов. ОЗУшка минимум одна - буфер экрана, вторая можно ПЗУ, но лучше ОЗУ, чтоб шрифты можно было грузить. Со счетчика сигналы подаются на адрес ПЗУ порядка выборки, с ПЗУ порядка выборки данные подаются на адрес ОЗУ фрейм-буфера. Значение байта фрейм-буфера подается на младшие 8 разряд адреса ОЗУ шрифтов, на старшие 3 разряда подадим сигнал от ПЗУ выборки (это будет номер строки шрифта). На выходе регистр сдвига, который загружается строкой шрифта, каждые 8 тактов.
Сотни мегегерц не нужны, 5 вполне хватит для 20*40*64*50.

> Легче уж рассыпуху а-ля эмуляторы спектрумовского ULA -
> дешево и сердито.
Ну да, я грубанул. 23.03.06 19:57  
Автор: zpv78 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Это снова я. Спасибо всем за помощ. Просто с данной темой я сталкиваюсь впервые. Я даже пока слабо представляю принцип передачи сигнала на монитор. Да, с разрешением 800х600 я конечно погорячился. Мне хватит и 640х480. Короче мне необходимо получить 33 строки по 80 символов. Размер символов 8х8. Получается мне вполне хватает разрешения 640/350. Картинка действительно статическая и 25МГц обновления вполне достаточно. Контроллер действительно не слабый. Можно выдавить 25MIPS. Но скорее будет 17MIPS. Потянет?
А схема товарища из Тольяти меня очень обрадовала и даже обнадежила. Не думал что будет столько проблем. Вообще я с самого начала склонялся к тому, чтобы использовать какую-нибудь специальную микруху, но пока ничего подобного не нашел. Опять блин затык.
Ну это можно и в двух словах. 24.03.06 11:13  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 24.03.06 11:14  Количество правок: 1
<"чистая" ссылка>
> Это снова я. Спасибо всем за помощ. Просто с данной темой я
> сталкиваюсь впервые. Я даже пока слабо представляю принцип
> передачи сигнала на монитор. Да, с разрешением 800х600 я

Ну это можно и в двух словах.
ЭЛТ аналоговый монитор выводит изображение построчно/поточечно. Электронный луч в трубке бегает слева направо постепенно опускаясь сверху вних. Подаем в кабель 1 вольт - луч светит ярко, экран заполняется светлым фоном, нулевое напряжение - темный фон. Быстро чередуем 1 вольт и 0 вольт - на экране чередующиеся черные и белые точки. В кабеле есть еще пару проводов (Hsync и Vsync). Подача напряжения на один из них предписывает монитору начинать водить лучем сверху, на другой - быстро перевести луч налево и опять начать медленно двигаться направо.

> конечно погорячился. Мне хватит и 640х480. Короче мне
> необходимо получить 33 строки по 80 символов. Размер
> символов 8х8. Получается мне вполне хватает разрешения
> 640/350. Картинка действительно статическая и 25МГц

Изобретать полноценный видеоадаптер сложно, мучительно и больно. Нужно учитывать временные характеристики системы развертки. Для цифровых мониторов на базе ЖК матриц все может быть несколько проще, но все-равно, проще купить ноутбук за 50 долларов, подключить к нему устройство по СОМ порту или Эзетнетке и не замарачиваться.

> обновления вполне достаточно. Контроллер действительно не
> слабый. Можно выдавить 25MIPS. Но скорее будет 17MIPS.
> Потянет?

Саме простое, что можно предложить - взять матрицу, у которой будут всего пяток проводов - сигнальный монохромный ТТЛ, синхронизационный (DOT clock), два сигнала синхронизации (H и V), земля, питание, подсветка. На однокристалке не менее 10 Мгц изваять видеоадаптер. Прелести ЖК - можно сильно опустится по частоте регенерации изображения, отсутствие временных задержек на синхронизацию (переход на первую точку следующей строки или на первую строку).
Изображение гнать в адаптер и хранить в его памяти графическое - по точкам.

> А схема товарища из Тольяти меня очень обрадовала и даже
> обнадежила. Не думал что будет столько проблем. Вообще я с
> самого начала склонялся к тому, чтобы использовать
> какую-нибудь специальную микруху, но пока ничего подобного
> не нашел. Опять блин затык.

Сделать нормальный полноценный адаптер для большого экрана на базе не специализированного, а универсального микропроцессорного контроллера - лучше не браться.
А это... На многих ЖК-мониторах есть уже сразу цифровой интерфейс. Может его заюзать? 24.03.06 12:13  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Пиксельклок=100мегагерц. Если про DVI, то нужно еще на 8 умножить. 24.03.06 14:19  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
Ребята, спавибо. 24.03.06 20:39  
Автор: zpv78 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Ребята, большое спавибо. Сегодня почитал литературу, покапался в сети, немного посчитал и понял что не реально. Ничего не бывает зря. Хоть разобрался с принципом выдачи сигнала на монитор. Сейчас хочу попробовать подвязаться под карточку на PC/104.
Посмотри схемы всяких синклер-совместимых агрегатов 27.03.06 13:10  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Ребята, большое спавибо. Сегодня почитал литературу,
> покапался в сети, немного посчитал и понял что не реально.
> Ничего не бывает зря. Хоть разобрался с принципом выдачи
> сигнала на монитор. Сейчас хочу попробовать подвязаться
> под карточку на PC/104.

Думаю, твою задачу можно решить с бюджетом баксов в 10. Просто решение лучше искать не программное на универсальной базе (микроконтроллере), а специализированное аппаратное. Синклеры вполне справлялись с разрешением 256x192 (32 на 24 символа) и 16 цветов. С учетом того, что тебе не нужна цветность (и даже полутона), то и разрешение ты сможешь получить повыше.
Это уже реальнее 23.03.06 16:58  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Причем инерционность матрицы подавит и на этой частоте
> мерцание, то:
> 10*20*64*25=0.32Мгц.

Маленькие дисплеи на небольшой частоте - не такая уж и редкость.

> делаем побитовый сдвиг регистра. Итого 4 инструкции. out a;
> shr a; dec c, jne -4. Разумеется для каждых 8 бит нужно

Можно сократить до 2-х (нереальных, хе-хе), если раскрыть цикл

> будет сделать следующее: загрузить регистр-счетчик
> значением 8, сделать выборку очередной строки для символа,
> а для этого значение символа нужно умножить на 8 (сдвинуть
> влево на 3 бита), добавить номер строки. Ничего страшного,
> если между символами будет маленький зазор.

От зазора можно избавиться, если раскрыть цикл и повставлять между каждым out-ом столько nop-ов, чтобы время их исполнения было равно времени выборки нового символа.

> Можно это дело спаять на двух-трех микросхемах: одна/две
> ОЗУ, третья ПЗУ и еще счетчик нужен.

Вот именно. Даже дешевле и проще выйдет. И главное при той же тактовой частоте можно будет рисовать гораздо бОльшие картинки (вполне реально сделать схему: 1 такт - 1 пиксель).

ЗЫ: Вариант с контроллером чем то напоминает мне времена Спектрума, когда все увлеклись рисованием на бордюре и мультиколором
действительно тупой 22.03.06 19:35  
Автор: zpv78 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> А нельзя ли просто найти четыре (помоему R+G+B+Sync) пина
> на контроллере и самому гнать картинку? Или это слишком
> сложно?
А можно об этом поподробнее. Я не сталкивался и не знаю формат вывода. Это был бы оптимальный вариант.
ссылок вроде дофига 22.03.06 22:06  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
> А можно об этом поподробнее. Я не сталкивался и не знаю
> формат вывода. Это был бы оптимальный вариант.

К сожалению я полный бамбук в электротехнике и однокристалках (как я понял они используются).
Вот - посмотри:

http://www.google.com/search?hl=en&lr=&q=vga+microcontrollers
и подробнее
http://www.serasidis.gr/circuits/AVR_VGA/avr_vga.htm
там внизу пара ссылок. И вроде там упоминается парень из Тольятти - можно попробовать с ним связаться
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach