RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : 6chanel audio?


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Alexey Bezditko
To : Юрий Пронякин
Subj : 6chanel audio?
> > > Физический интерфейс чисто последовательный, как COM-порт.
> > Тогда не получится: некому для подобного делать цап.
>
> Технически это весьма просто - есть и преобразователи
> последовательного кода в параллельный (банальные сдвиговые
> регистры), и у однокриссталок многих есть последовательные
> порты: даёшь обычную команду чтения из порта - получаешь
> готовый байт.
> А что делать некому - это да...
Там предлагается идея dmx - вроде можно вывести поток, подготавливаемый готовым общеизвестным софтом, на lpt. А далее - пара микросхем + оконечные каскады усилителей.
Если окажется, что есть готовая _проверенная_ или, хотя бы, оценненная, как правильная, тем, кто в этом что-то понимает, схема - сдаётся мне, что лучше будет спаять именно её: софт цветовой под неё готовый вроде есть...
Придумать мы её сами не придумаем, а прикурутить к ней оконечники под нашу нагрузку - без проблем...

> > > Два байта (в общем случае) не выставить, разве что полтора.
> > 1. а почему?
>
> Потому что у стандартного LPT-порта столько битов на выход работают:
Так я ведь специально говорил о есp|epp... там же вроде есть...

> > > А поскольку там предполагается задавать RGB, то двух байт за раз
> > > всё равно было бы мало, так что просто выводите три раза по байту.
> > Кто его знает... Может, проще полубайт использовать в виде переключателя,
> > куда это, а основной байт - в виде амплитуды... Простой логикой можно
> > развязать такой выход, в принципе.
> Именно это я и предложил. Тебе же нужно по одному байту (256 уровней)
> на каждый цвет - вот их в три приёма и выведете.
Хочется в 1 приём - параллельными двумя байтами... Или - dmx: тогда редактор
выдумывать не нужно, готовые есть...

> То есть - каждый выводимый мной by rexxio байт будет тупо висеть
> на параллельном интерфейсе, пока я не выведу следующий, который
> и заменит его без какого-либо участия внешней стороны?
> Да.
Thanks - это, по крайней мере, решило проблему, как с оси перезагрузить хрюшу с камерами, если траффик от хрюши к оси отсутствует заданное количесвто минут... Зависла если она, то есть...
Просто выдам на порт байт, где в нужном месте 1 - а дальше на уровне кружка "умелые руки"... И через секунду - сброшу...

> > > Данные стоят на выходе до тех пор, пока ты их сам оттуда не снимешь.
> > Cнимешь - то есть просто заменишь следующим байтом, выводимым тем же способом?
> Почти. Если я правильно помню (давно уже не занимался этим), выдача данных
> наружу разрешается одним из тех управляющих битов. Если она разрешена
> - данные идут так, как ты написал выше. Если запрещена - выход переводится
> в неопределённое состояние.
ага... Ладно, бум искать...

> > > Работа исключительно асинхронная. Компьютер выставляет данные и строб,
> > > что данные готовы. Когда принтер данные прочитал, он выставляет подтверждение.
> > Вот... О чём я и спрашивал: нужна ли и есть ли там какая-либо синхронизация...
> Принтер выдаёт подтверждение не контроллеру порта, а программе, выводящей данные.
Всё, это именно то, что хотелось услышать. Просто я с детства привык, что такие вещи - вроде побайтной передачи по шине - есть уровень контроллеров, и до сих пор уточняю и/или удивляюсь, когда это оказывается уровнем программиста...:/

> Технически это совсем не обязательно (если есть гарантия, что получатель прочитал
> выставленный байт до того, как он исчез, или если пропуск байта значения не имеет).
Разумеется. Как, например, в моём случае при двубайтном параллельном выводе...
Или - в случае в перезагрузкой другой машины по сигналу от моего лпт.

> > Благо, что вроде был для рекса какой-то пакет с миллисекундными задержками.
> > Но ecp и прочая меня интересовали для того, что там якобы есть возможность
> > выставлять два байта параллельно - на входных и выходнных шинах сразу.
> > И читать их, соответственно... Если это не брехня, то было б интересно...
> Есть такая возможность. Причём не только в ECP, но и в EPP, и в bidirectional mode.
Вот-вот... Это б где-то почитать попрозрачнее - вроде того, как Мызыченко о миди писал...

>Только вам же для RGB три байта надо вывести.
Нет, мы тогда просто карусель из группы двубайтных подач закрутили бы: первый байт в каждой паре определяет, кого заряжать, а второй - амплитуда. Без проблем. Выходной фильтр цапа это всё (ожидание во время чужих подач) сгладит нараз: время перелива - десятые доли секунды или длиннее, а частота вывода - гораздо выше... В очереди шли бы пары байт, где второй амплитуда, а первый: n-я буква m-й цвет, где m до 3, а n до 5, по полубайту.

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

Обещано вроде 2-3 МС хватает, чтоб получить от лпт поток управленяи цветом и разбросать на штук 60 объектов, а дальше - выходные каскады (это уж мы как-нибудь)...
Просто пытаться паять то, чего никто в обозримом окружении не проверял, при этом ни бельмеса не понимая в том, что эти мс вообще делают - как-то не тянет... :)



Mon 20 Mar 2006 22:50 Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/2003062



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.