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?

40inD писал(а):Что в данном случае имеется ввиду под коммутатором?

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

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

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

ftp://81.222.202.128/Temp/LED/

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

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

-= Александр =- писал(а):Энтузиасты программинга пока могут потренироваться:

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

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

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

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

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

1) В принципе, самое простое, составить матрицу и каждому элементу присвоить пиксель, а потом удалить каждый нечётный или чётный элемент

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

2) Как вы и сказали достаточно будет по ~200 пикселей с каждой стороны, но ещё проблема в том что с одной стороны может быть одного цвета много, а с другой с другого, вы это учли?
Поуглам можно делать, только если там будут расположены светодиоды

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

3)Придётся делать вставки из ассемблера в критически важных
точках, можно ещё запустить прогу не как процесс, а как сервис, это будет гораздо лучше. И обновление цвета делать не синхронно с дисплеем, а пореже - для глаза это будет незаметно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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