roboforum.ru

Извиняюсь, что немного не про роботов, но пока больше не знаю где спросить. Есть очень простая задача - непрерывный опрос дискретных датчиков и ввод полученной информации в PC. Хотелось бы решить с минимумом железа и головной боли. Поискав в интернете, нашел почти подходящую микросхему, но некоторые детали портят картину. Помогите найти более подходящий аналог. Микросхема: WoodmanUSB. Её PORTB в синхронном режиме с внутренней синхронизацией и съемом данных по этой же синхронизации (http://www.pcports.ru/articles/usb21.php) работает практически так, как мне хотелось бы, но есть такие моменты:
1. У этой штуки всего 8 линий (у порта B). Уложиться можно, но хотелось бы хотя бы 16. Есть ещё PortA, но это не то.
2. Совершенно не нужны ни 30, ни 48 мегагерц частоты опроса. Пары сотен герц хватило бы с головой, но эти герцы железка должна отсчитывать самостоятельно (а не опрашиваться с этой частотой с ПК). Понятно, что синхронизирующий генератор можно внешний прицепить, но это - дополнительные цацки.
3. Пока не обязательно, но в будущем, вероятно, пригодились бы 1-2 встроенных АЦП на 8-10 бит.
Вопрос главный: есть ли что-либо подобное в природе, и как оно называется?
Микроконтроллеры под эти условия вроде бы есть, но это уже сложнее - его надо программировать, и, наверное, ещё USB сверху цеплять, внешний тактовый генератор, опять же.
Ну и, чтоб два раза не вставать, поясните мне тупому пару непонятных моментов:
Цитата:
"Например, буфер модуля пуст. Начинаем заполнять его данными с частотой тактового сигнала. Дошли до 512 байт. В этот момент пакет из этих 512 байт уходит на PC (512 байт - размер контрольной точки для модуля WoodmanUSB). Продолжаем записывать в модуль данные. Заполнили еще 512 байт. Этот пакет тоже ушел на PC. Теперь на компьютере у нас есть 1024 байт. Мы можем говорить о том что врмеменное расстояние между байтами в этом пакете равно переоду тактвого сигнала, кроме стыка двух 512 байтных пакетов (время Ttr), т.к. в течение этого временного промежутка происходила транспортировка предыдущего пакета на PC и заполнение буфера модуля следующими 512 байтами."
То есть оно, пока обменивается данными с ПК через USB, входы опрашивать прекращает? Почему? Буфер у него 1024 байта, после заполнения 512 байт данные передаются в ПК (если, конечно, их кто-то там ждет), и ещё 512 байт в этот момент могут оставаться незаполненными, так почему опрос останавливается, и что с тактовым генератором - тоже останавливается что-ли?
И ещё: объясните на пальцах, зачем в схеме на http://www.pcports.ru/articles/usb22.php нужен операционный усилитель с подстроечниками, и почему исследуемый сигнал не подать прямо на вход АЦП (напряжения у них соответствуют, вроде)?
PS - не железячник я ни разу - программист и админ. Вот, пришлось заниматься и этим.

WoodmanUSB вроде чисто мост - ему врядли нужный функционал можно зашить.

Можно взять [[OR-PROG-USB]] + [[OR-AVR-M32-D]], но в них сейчас прошивка позволяет только по запросу с ПК всё делать, хотя наверное не сильно сложно будет модифицировать (прошивка открытая - сделать не ответ на команды с ПК, а по таймеру самому команду запроса данных генерить с частотой 100-200Гц, а ответы будут уходить в ПК). У вас минимальный опыт программирования МК есть? Или вообще программирования на Си?

Добавлено спустя 2 минуты 47 секунд:
Бонус: можно потом отказаться от проводов до устройства, используя скажем [[OR-BT20-115.2]], не меняя ничего в программе.

=DeaD= писал(а):WoodmanUSB вроде чисто мост - ему врядли нужный функционал можно зашить.

Меня бы устроило, я изначально и не планировал функционал в железке реализовывать - для этого у меня нормальный компьютер есть. Мне бы просто данные с датчиков читать. Оно у меня и сейчас работает - через LPT. А там функционал - ух Но неудобно - проблемы с отсчетом времени под виндами, и не только это.

=DeaD= писал(а):Можно взять [[OR-PROG-USB]] + [[OR-AVR-M32-D]]

Посмотрел. Не могу въехать, что это за штука Ну то есть про контроллер, на котором она построена, тоже прочитал, там более-менее ясно. А что этот модуль умеет кроме того, что умеет сам контроллер, и наоборот - что из функционала контроллера становится недоступным, а также в чем состоит задача прилагаемого ПО (прошивки) - убей не понимаю.

=DeaD= писал(а):У вас минимальный опыт программирования МК есть?

Нет

=DeaD= писал(а):Или вообще программирования на Си?

Да. С задачей организации цикла для опроса датчиков справлюсь однозначно Наибольшая проблема будет не написать код, а обеспечить компиляцию, заливку и выполнение написанного в железке. Если действительно свяжусь с чем-нибудь на основе микроконтролера, может быть даже кое-какую первичную обработку входной информации прям на месте реализую.

=DeaD= писал(а):Бонус: можно потом отказаться от проводов до устройства, используя скажем [[OR-BT20-115.2]], не меняя ничего в программе.

Это тоже интересно.

На рас вообще программируете, то и тут особых проблем не будет.. вам нужно то по идее настроить таймер для опроса, да опрашивавть, ну и если чего еще захотите... в комплекте с программатором-мостом усб-уарт без особых проблем можно и зашить и отладить.. да и опыт в программировании МК не лишний )

вообще данное устройство и его прошивка рассчитаны на обработку запросов с ПК, ибо OR выбрали такой путь (если не ошибаюсь )

но если писать прошивку самостоятельно алгоритм работы возможен любой...
модуль конечно несколько ограничивает возможности МК, так как это изделие с определенным функционалом, но большую часть возможностей раскрывает..

идеальный вариант конечно сделать свое устройство.. но вы сами понимаете) задавайте вопросы в общем )

Shamus писал(а):

=DeaD= писал(а):Можно взять [[OR-PROG-USB]] + [[OR-AVR-M32-D]]

Посмотрел. Не могу въехать, что это за штука Ну то есть про контроллер, на котором она построена, тоже прочитал, там более-менее ясно. А что этот модуль умеет кроме того, что умеет сам контроллер, и наоборот - что из функционала контроллера становится недоступным, а также в чем состоит задача прилагаемого ПО (прошивки) - убей не понимаю.

OR-AVR-M32-D - это готовый к использованию в робототехнике модуль по сути содержащий сам МК, обвязку для питания (регуляторы напряжения, фильтры питания), защитные резисторы на куче портов и кучу удобных разъемов (удобных для предусмотренных целей конечно - т.е. есть разъемы RoboGPIO - в них втыкаем самые простые датчики или исполнительные устройства, например, сервоприводы или кнопки или ИК-дальномеры или переменные резисторы, есть разъемы RoboI2C - в них втыкаем i2c-устройства, сразу идёт питание +5В и т.д.).

Прошивка ORFA даёт возможность получать данные с портов или выдавать команды непосредственно с ПК по уарт-каналу (проводному или радио) - что позволяет решать существенный круг задач, не прибегая к программированию МК. Но даже если это понадобится (вам не хватит возможностей предусмотренных нами) - прошивка ORFA открыта для доработки - вы легко можете дописать нужный вам функционал (добавив свой драйвер) не потеряв совместимость и возможность обновления нашего функционала.

Добавлено спустя 48 секунд:

Duhas писал(а):вообще данное устройство и его прошивка рассчитаны на обработку запросов с ПК, ибо OR выбрали такой путь (если не ошибаюсь )

Скажем так - это один из основных предусмотренных нами вариантов использования.