Alexander_Grig
14-02-2007, 00:11
Здравствуйте, господа
Хотелось бы услышать ваше мнение по следующему вопросу.
Есть сигнал, поступающий от одной системы, который принимает 2 состояния - 0 и 1 (амплитуду можно изменять). Необходимо регистрировать длительности состояний 0 и 1. При этом регистрация должна происходить желательно с точностью до 1 мкс (в крайнем случае - 10 мкс).
Возникла идея использовать для этих целей либо COM, либо LPT порт.
Скорость COM-порта ведь можно изменять от 75 до 128000 бит/с , т.е. потенциально возможно считывать данные с минимальной длительностью одного импульса от 1/75=0,01(3) с до 1/128000= 7,8125мкс . Один недостаток COM-порта - это наличие "стартового" бита (и, возможно, стопового и четности ), который будет несколько "мешать", т.к. фактически будет забирать "на себя" один из битов передаваемых данных (хотя это модно будет и учесть в программе-обработке).
При использовани LPT-порта нет проблем с "лишним" битом, мы можем использовать любую из линий данных - D0..D7 (контакты со 2-го по 11-й), принимая на нее данные и регистрируя их значение. Однако я нигде не нашел, с какой максимально возможной частотой может происходить опрос порта (линий данных), а главное, чем это можно регулировать.
Нашел пару программ по работе с LPT портом - http://valery-us4leh.narod.ru/dlpt.html . В принципе они выполняют эту задачу, но опрос LPT происходит лишь с частотой 1 кГц (т.е. может регистрировать передаваемые данные со скоростью 1000 бит/с ).
Хотелось бы услышать ваше мнение по изложенному.
Также если кто-то знает программу, способную считывать из указанных портов с определенной частотой данные и записывать их значения в файл, просьба дать на нее ссылку. На лучшее, что сам нашел, дал выше ссылку.
Заранее благодарю.
P.S. а можно ли вообще стандартными средствами винды установить ком порт в режим приема (подавать ему на линию RX этот самый сигнал необходимого уровня) и считывать с СОМ-порта данные, записывая их в файл (например с помощью нупертерминаа или еще чего). Пробовал в Матлаб реализивать работу с компортом, но что-то не получилось в реальном масштабе времени это делать.
Хотелось бы услышать ваше мнение по следующему вопросу.
Есть сигнал, поступающий от одной системы, который принимает 2 состояния - 0 и 1 (амплитуду можно изменять). Необходимо регистрировать длительности состояний 0 и 1. При этом регистрация должна происходить желательно с точностью до 1 мкс (в крайнем случае - 10 мкс).
Возникла идея использовать для этих целей либо COM, либо LPT порт.
Скорость COM-порта ведь можно изменять от 75 до 128000 бит/с , т.е. потенциально возможно считывать данные с минимальной длительностью одного импульса от 1/75=0,01(3) с до 1/128000= 7,8125мкс . Один недостаток COM-порта - это наличие "стартового" бита (и, возможно, стопового и четности ), который будет несколько "мешать", т.к. фактически будет забирать "на себя" один из битов передаваемых данных (хотя это модно будет и учесть в программе-обработке).
При использовани LPT-порта нет проблем с "лишним" битом, мы можем использовать любую из линий данных - D0..D7 (контакты со 2-го по 11-й), принимая на нее данные и регистрируя их значение. Однако я нигде не нашел, с какой максимально возможной частотой может происходить опрос порта (линий данных), а главное, чем это можно регулировать.
Нашел пару программ по работе с LPT портом - http://valery-us4leh.narod.ru/dlpt.html . В принципе они выполняют эту задачу, но опрос LPT происходит лишь с частотой 1 кГц (т.е. может регистрировать передаваемые данные со скоростью 1000 бит/с ).
Хотелось бы услышать ваше мнение по изложенному.
Также если кто-то знает программу, способную считывать из указанных портов с определенной частотой данные и записывать их значения в файл, просьба дать на нее ссылку. На лучшее, что сам нашел, дал выше ссылку.
Заранее благодарю.
P.S. а можно ли вообще стандартными средствами винды установить ком порт в режим приема (подавать ему на линию RX этот самый сигнал необходимого уровня) и считывать с СОМ-порта данные, записывая их в файл (например с помощью нупертерминаа или еще чего). Пробовал в Матлаб реализивать работу с компортом, но что-то не получилось в реальном масштабе времени это делать.