roboforum.ru

Что в данном случае имеется ввиду под коммутатором?

_________________
Как назвать ребенка?

По поводу загрузки процессора, я думаю это сечас не актуально, программа под такой девайс, работающая в фоновом режиме будет по минимуму загружать процессор, с оперативкой тоже проблем быть не должно.

Я тоже думаю что лучше это дело организовывать под USB, ИМХО скорость быстрее, да и программно реализовывается не сложнее чем с LTP, так что, Александр, дерзайте, пишите что требуется к программной части, чтоб управлять этим устройством.

Про железо:

1)Прототип сделаю через ком-порт, с FTDI буду позже возиться... (по сути она - тот-же ком-порт, только через USB)
2)Прога не будет жрать ресурсы, нам ведь не надо весь экран сканировать, а только точек по 200 с каждой стороны.
3)Т.к. полноцветные диоды все еще редкость - будем делать на обычных, а значит надо разработать функцию подстройки под разные диоды, чтоб не было перекоса в сторону какого-то из цветов. Делать ее на уровне МК или задавать командами сверху?

Система команд будет такая: (8 байт)
1 - номер излучателя
2 - Красный (верхний байт)
3 - Красный (нижний байт)
4 - Зеленый (верхний байт)
5 - Зеленый (нижний байт)
6 - Синий (верхний байт)
7 - Синий (нижний байт)
8 - 00 (для спокойствия)

Тоесть так для каждого излучателя по-очереди задаем цвет.
Надо еще попробовать - может 16 бит многовато и с 8 будет смотреться нормально, но много - не мало.

Первый байт можно юзать и для сервисных команд, их мы еще придумаем. Скажем первые 8 номеров - излучатели, еще 10 зарезервируем на будущее, а все что выше - команды. Соответственно к каждой команде можно дать 6 байт параметров - вполне достаточно.

Энтузиасты программинга пока могут потренироваться:

1)Сколько надо пикселей на область, чтоб стабильно уловить общий цвет?
2)Сколько областей имеет смысл делать? Только по сторонам или еще и по углам?
3)Как это сделать минимально нагрузив процессор?
4)Как работать с оверлеями и поверхностями DirectDraw?

Что-то, что будет переключать сигнал между интеграторами или выбирать интегратор в зависимости от положения луча развертки.

Не, сложно это все очень... 768 (или 1024 или вообще 1200) строк пикселей (а строк луча и того больше) 100 раз в секунду, при том черезстрочно - тут нужна просто неимоверная производительность....

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

ftp://81.222.202.128/Temp/LED/

Думаю для начала трех-четырех диодов на сторону будет вполне достаточно. Стоют они по 8(красные и зеленые) и 15(синие) рублей за штуку, так что получается вполне бюджетно. А вот если их туда десятка 3 запихнуть - это будет сильно!  :wink:

Кстати, кто мне посоветует полевичок для управления всем этим делом? А то у меня валяется пачка 540-ых ИРФов, но через них включать диоды - это как из пушки по воробъям...

1) В принципе, самое простое, составить матрицу и каждому элементу присвоить пиксель, а потом удалить каждый нечётный или чётный элемент
2) Как вы и сказали достаточно будет по ~200 пикселей с каждой стороны, но ещё проблема в том что с одной стороны может быть одного цвета много, а с другой с другого, вы это учли?
Поуглам можно делать, только если там будут расположены светодиоды
3)Придётся делать вставки из ассемблера в критически важных
точках, можно ещё запустить прогу не как процесс, а как сервис, это будет гораздо лучше. И обновление цвета делать не синхронно с дисплеем, а пореже - для глаза это будет незаметно.
4)Оверлей имеет место быть в случае, если запущен фильм на весь экран, или в игре присутствует видео, в таких случаях и придётся заюзать DirectShow или посмотреть как это делается в других прогах (например SnagIt).

По воду ваших LED-ов: зелёный бледный какой-то, остальные оптимальные.

авм  поможет отцу российской робототехники
а коммутатор, ИМХО, можно на операционниках сделать

Я не об этом. сное дело что сканировать надо не каждый пиксель. А вот как оптимальнее - просто сетку через каждые скажем 10 или случайное распрадалание?

Так вот неясно, имеет ли смысл управлять ими отдельно? Или пусть вся сторона светит одинаково?

Я думаю кадрова 30 в секунду вполне достаточно...


Зеленый будет ярче, ему напряжения по-больше надо...

А чего такое авм?

аналоговая эвм да, я ошибся, не на оу, а на транзисторах

1. я думаю будет лучше работать с сеткой, т. к. ИМХО случайные действия приводят к непредсказуемым последствиям

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

И ещё один вопрос, ведь светодиоды как я понимаю вряд ли смогут отображать всю 32 млн. палитру??? Тогда надо программно приводить "пойманные" цвета к приближённому стандарту, например светло-синий к синему и т.д.

Тоже верно...



Экран делится на зоны: верх, низ, лево, право. Центр экрана нам не интересен, так что будем брать края зоны, скажем на 1/3 глубины. В каждой зоне считаем цвета и отображаем их на соответствующем излучателе. Тоесть то что посчитали в левой зоне - выводим на левый, то что в правой - на правый. Суть в логическом продолжении картинки.



Может оно и реально, но нам особого смысла в этом нету. Будут 48-битные цвета (по 16 бит на каждую компоненту), 4096 цветов. Потому-что 256 ИМХО мало, а 16 млн ИМХО трудно и бесполезно. Оттенок можно передать любой, но для 32 млн надо делать очень деликатный ШИМ, а это займет много времени и AVR может не потянуть. 16-битный ШИМ он потянет запросто. Ради эксперимента можно конечно попробовать, но не думаю что будет практический смысл.

1. Что значит на 1\3 глубины?
раз 4 стороны, то следовательно нужно посылать 4 потока информации параллельно...или лучше последовательно?

2. То есть нужно будет преобразовывать палитру из 16 или 32 млн. в 4096 цветную?

Это значит что каждая область представляет из себя трапецию, ограничена двумя диагоналями краем эерана и линией параллельной ему. Высота этой трапеции - 1/3 от ширины(для боковых) или высоты (для верхней и нижней) экрана.



Да. Я уже описывал протокол связи:
Посылки идут по-очереди каждому излучателю. В каком порядке - не важно. Если цвет области изменился - посылка происходит. Если не - не происходит. Обмен идет последовательно на скорости 11520 бит в секунду. На такой скорости последовательный обмен не будет заметен визуально. А параллельные потоки - бочсь через ком-порт они не пролезут... Картинка изменилась - всем по-очереди выдается новый цвет. В посылке идет номер излучателя (а их будет 4) и 6 байт (по 2 байта каждого цвета). Первым битом кроме номера может дити сервисная команда, например вкл. или выкл. систему.

Как я понял всё должно делиться на такие области?