Приветствую., собрал управляемую от LPT светодиодную матрицу 8Х8, в самом начале работы скорость у LPt почему то маленькая(скорость развертки не достаточная), примерно через полчаса скорость увеличивается и изображение рисуется нормально, с чем это может быть связанно?
Работа параллельного порта определяется фактически двумя сигналами: Data Strobe "Данные на линиях готовы" - длительность 5 мкс и Asknowledge "Подтверждение приёма данных" - 10 мкс. Также сигнал Busy "Не могу принять данные" - сигнал приостановить передачу данных. В самом начале всего идёт сигнал Init "инициализация устройства" - (50-100) мкс, по этому сигналу устройство должно выдать сигнал Select "Готов", но обычно он сделан постоянным.
Считайте времена.
Память очень интересная штука: бывает так, что запомнишь одно, а вспомнишь другое...
мышонок писал(а):Работа параллельного порта определяется фактически двумя сигналами: Data Strobe "Данные на линиях готовы" - длительность 5 мкс и Asknowledge "Подтверждение приёма данных" - 10 мкс. Также сигнал Busy "Не могу принять данные" - сигнал приостановить передачу данных. В самом начале всего идёт сигнал Init "инициализация устройства" - (50-100) мкс, по этому сигналу устройство должно выдать сигнал Select "Готов", но обычно он сделан постоянным.
Считайте времена.
Это выдержки из спецификации протокола CENTRONICS, однако в предложенной конструкции, скорее всего, протокол не используется, т.к. линии ASK и т.п. просто не использованы. Предполагаю (как обычно, ибо правду почему-то никто сразу не говорит), что STROBE выдается записью в регистр управления порта, т.е. минуя драйвер порта Windows.
Мои эксперименты показывают, что даже на машинах с очень слабым процессором под Windows 98 (из проги на Delphi) можно обеспечить частоту смены уровней на линиях (любых) LPT-порта примерно до 100 кГц, однако период этой частоты нестабилен - ОС вмешивается.
Если же вывод ведется через системный драйвер (т.е. обычными файловыми функциями вывода) - обеспечить какие-то гарантии временных интервалов невозможно в принципе. В этом случае все сигналы могут быть непредсказуемо задержаны ОС. Отчасти это предположение объясняет странное поведение программы: при непрерывной работе только одного-двух активных процессов Windows постепенно "оптимизирует" содержимое системного кэша так, что быстродействие программ повышается (грубо говоря, Windows выкидывает из памяти все то, что в данное время не работает). Проверить это предположение можно просто: спустя 30 минут, когда схема+программа станут работать "быстро", взять и запустить какой-нибудь фильм или музыку на воспроизведение, а потом отключить. Предполагаю, что при этом "быстродействие" устройства снова понизится, а потом, спустя некоторое время, снова возрастет.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
С ARV не поспоришь. Отмечу основное: Windows, так же как и MS DOS (в девичестве CP/М) не являются ОС реального времени. Скорость параллельного порта (LPT) также не является строго фиксированной, в отличие от RS-232 (COM). Плюс ещё сама программа управления. В ней просто могут быть плохо организованы циклы и переходы.
Память очень интересная штука: бывает так, что запомнишь одно, а вспомнишь другое...
Судя по ряду тестов именно это и происходит, в прожке наврят ли, потому как она просто последовательно в цыкле загружает в порт номера светодиодов. в данном случае идеалньеым вариантом было бы туда в схему МК пихнуть типа AT90S2323 или 2313, и побайтно в него загружать номера диодов перед выводом. Спасибоз а помощь осталось только растолковать столь объёмистое(для него это вполне объёмистое ) объяснение учителю в оправдание такого глюка в начале работы моего курсача.
Можно попробовать задать для программы приоритет повыше, вплоть до RealTime При этом сама система может слегка притормаживать, но львиная доля процессорного времени будет выделяться именно программе с наивысшим приоритетом. Так же перед началом критического цикла дать команду системе реорганизовать память, сбросить буфера из памяти на винт и т.п. В WinXP проблемы распределения времени решены лучше, чем в Win9x - стОит запускать программу именно под хрюшей. Наконец, в программе надо отказаться от процедур sleep для организации задержек - именно из-за них задержки и плавают.
100% избавления от проблемы эти меры не дадут, но могут несколько сгладить отрицательные эффекты.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
вопрос в тему:
Есть задача. На вход компа посупает тактовая последовательность с длительностью такта 1,33 мкс (750 кГц). За этот период времени процессор должен обработать информацию. Я решил использовать параллельный LPT порт, поскольку информация поступает параллельно (в соответствии с вышеприведенной частотой). Программное обеспечение будет писаться на Assembler'е, поскольку высокая тактовая частота.
Теперь вопросы: сможет ли LPT порт обмениваться информацией с такой скоростью и как лучше сопрячь его с ТТЛ логикой? Сможет ли отработать, например, оптопара? Да и в целом, сможет ли процессор обрабатывать информацию за такой промежуток времени?
В целом поставленная задача очень тяжелая и нужен совет практика, поскольку у меня опыта нет, а делать надо....
Спасибо!
мне кажется, что это если возможно, то потребует серьёзнейших усилий, в частности знания ядра Windows, WDM-драйверов и т.п. При этом все равно гарантии того, что сигналы не будут пропущены не будет. Другое дело - написать программу под DOS и запустить ее монопольно, т.е. без загрузки Windows. Но и в этом случае проблем будет хоть отбавляй.
LPT сопрягать никак не надо, его сигналы ТТЛ-совместимы. На такой частоте порт сможет работать (теоретически), однако суметь с этим справиться будет сложно - см.выше. Оптроны можно подключать к линиям порта напрямую (если ток не превысит 10 мА), однако оптроны, работающие на такой частоте - редкость, еще поискать придется.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Я бы не стал использовать лпт-порт, не для того он предназначен. И ассемблер бы не стал, не дает он сильного выигрыша в производительности. Я бы поставил ARM+ по USB заливал бы поток в комп - а уж дальше обрабатывал бы чем угодно. Вместо арма можно попытаться заюзать FT245.
А что за обработка? Может воткнуть ПЛИС мелкую (а то и не очень) и не связываться с компом?
ЗЫЖ На счет оптопар. Есть оптопары предназначенные для высокоскоростной передачи данных - например H11L1, а есть предназначенные для других целей, например PC817.
Тогда такой вопросик.
А с помощью чего лучше всего сопрягать? Мне еще надо с ТТЛ-логики 12 вольт подать сигналы на вход порта и при этом предусмотреть схемы защиты как компа, так и схемы, с которой подаются сигналы.
Защиты от чего? Ставь опторазвязку, она обеспечит защиту порта.
H11L1 к стандартной TTL логике можно подключить межу питанием и выходом, через резистор 470-1000 Ом.
А откуда взялось 12В?
dx40 писал(а):Я бы не стал использовать лпт-порт, не для того он предназначен. И ассемблер бы не стал, не дает он сильного выигрыша в производительности. Я бы поставил ARM+ по USB заливал бы поток в комп - а уж дальше обрабатывал бы чем угодно. Вместо арма можно попытаться заюзать FT245.
А что за обработка? Может воткнуть ПЛИС мелкую (а то и не очень) и не связываться с компом?
(пока писал ответ, не видел пришедшие сообщения)
Задача довольно сложная. Надо компом заменить старую аппаратуру (тренажер), которая сопрягается с другой аппаратурой. Делается это в рамках курсового проекта. Аппаратура старая и по сути, в ней реализован процессор. Процессор обрабатывает информацию параллельно и выдает ее обратно. Т.о. необходимо обеспечить параметры входных и выходных сигналов устройства. Система чисто цифровая, но работает параллельно. Как я уже говорил, тактовая частота примерно 750 кГц (такт 1,33 мкс), но, в процессе работы может уменьшатся в 2 раза в зависимости от режима работы (поступает с внешнего устройства). Моя задача расписать алгоритмы работы программы и составить схему сопряжения компа с другим устройством.
На комп должно поступать 8 сигналов параллельно, с него выходить 5, поэтому решено было использовать параллельный порт.
Частота высокая, поэтому, наверное, стоит использовать ассемблер, как самый быстрый.
ПЛИС был как вариант, но тогда по сути на нем надо будет реализовать целый процессор, здоровый кусок ОЗУ и т.д и т.п. + т.к. тренажер, то надо будет непрерывно менять прогу. Короче, работы в таком случае на целое КБ .
Один из поступающих сигналов имеет напряжение "1" 12 вольт.
Всем огромное спасибо за оказанное внимание и ответы.
dx40 писал(а):Защиты от чего? Ставь опторазвязку, она обеспечит защиту порта.
H11L1 к стандартной TTL логике можно подключить межу питанием и выходом, через резистор 470-1000 Ом.
Забыл сказать. Время нарастания и спада импульсов составляет 80 нс. Т.о. предложенная оптопара, к сожалению, не подойдет, у нее время спада составляет 2 мкс, что сравнимо с длительностью тактовых импульсов
Хммммм......
ЛПТ порт это хорошо, но только когда 5 на вход, 12 на выход. Тогда порт работает в режиме spp, легко и непринужденно программируется. А вот как обеспечить 8 вход 5 выход я представляю с трудом. Нужно использовать режим ECP но он не так прост как SPP. И я не уверен что это получится сделать.
http://www.datasheet4u.com/ неплохой.
Почему не подойдет? Вполне. Скорость до мегагерца, фронты по 100нс, Самолично смотрел на осцилле на 500кГц - все идеально.
Отмечу основное: Windows, так же как и MS DOS (в девичестве CP/М) не являются ОС реального времени. Скорость параллельного порта (LPT) также не является строго фиксированной, в отличие от RS-232 (COM). Плюс ещё сама программа управления. В ней просто могут быть плохо организованы циклы и переходы.
) объяснение учителю в оправдание такого глюка в начале работы моего курсача.
При этом сама система может слегка притормаживать, но львиная доля процессорного времени будет выделяться именно программе с наивысшим приоритетом. Так же перед началом критического цикла дать команду системе реорганизовать память, сбросить буфера из памяти на винт и т.п. В WinXP проблемы распределения времени решены лучше, чем в Win9x - стОит запускать программу именно под хрюшей. Наконец, в программе надо отказаться от процедур sleep для организации задержек - именно из-за них задержки и плавают.
