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

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > > > Физический интерфейс чисто последовательный, как 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 объектов, а дальше - выходные каскады (это уж мы как-нибудь)... 
> Просто пытаться паять то, чего никто в обозримом окружении не проверял, при этом ни бельмеса не понимая в том, что эти мс вообще делают - как-то не тянет... :)
> 
>

_, _, _, _, _ _ _,_ (_ \| / \ \|\ \| \| \|_/ , ) \| , \ / \| \\| \| \| \ ~ ~~~ ~ ~ ~ ~ ~ ~