cnc-club.ru

Или контроль и коррекцию целостности данных, что заметно проще в реализации.
Нужно просто правильно выбрать среду передачи, чтоб успевать всё делать в сервоцикл.

P.S. Надо на досуге попробовать сгенерить SPI на базе LPT или пинов типа DTR, DSR, RTS, CTS...

Nick писал(а):Ну надо делать что-то типо сервы - команду получаем на положение в шагах (два-четыре байта). Обратно выдаем текущее положение - т.е. полноценный внешний stepgen.

Да я чего попроще хотел - передавать приращения по каждому сервоциклу.

UAVpilot писал(а):Надо на досуге попробовать сгенерить SPI на базе LPT или пинов типа DTR, DSR, RTS, CTS...

Была у меня такая мысля. Только скорость передачи будет не более базовой частоты (20-30кГц), а то и половины ее. Тогда как COM-порт не напрягаясь дает 115200.

Да это понятно, просто COM-порт не очень интересен т.к. вопервых он скоро будет таким-же дефицитом, как и сейчас LPT, а во вторых тем, что это лишь соединение точка-точка. А очень хочется хотя-бы CAN.

UAVpilot писал(а):Да это понятно, просто COM-порт не очень интересен т.к. вопервых он скоро будет таким-же дефицитом, как и сейчас LPT

А где ж тогда брать пины LPT или DTR, DSR, RTS, CTS
и вообще выводы, которые можно просто шевелить из программы? Больше, вроде, не остается в писюках тупых и доступных интерфейсов

Кстати, можете посмотреть, как реализован компонент hal для mesa 7i43. Она вроде как через LPT общается.
Если у принемающей стороны будет хватать скорости разве нельзя просто пихать данные в lpt без остановки? Тогда можно большую пропускную способность получить раз в сервоцикл.

Вот тут оно похоже: http://git.linuxcnc.org/gitweb?p=linuxc ... =HEAD#l238

Nick писал(а):Вот тут оно похоже: http://git.linuxcnc.org/gitweb?p=linuxc ... =HEAD#l238

Надо взглянуть. Тем более, следующий вопрос был бы насчет того, где брать эти данные

Данные из пинов. Тут все просто.
Как в обычном компоненте создаем пины и потом в hal заводим на них данные.

Serg-tmn писал(а):

UAVpilot писал(а):Да это понятно, просто COM-порт не очень интересен т.к. вопервых он скоро будет таким-же дефицитом, как и сейчас LPT

А где ж тогда брать пины LPT или DTR, DSR, RTS, CTS
и вообще выводы, которые можно просто шевелить из программы? Больше, вроде, не остается в писюках тупых и доступных интерфейсов

PCI-то живёт и здравствует. И если уж делать PCI-карты, то уже не банальные LPT и COM, а с нормальными интерфейсами.

UAVpilot писал(а):CI-то живёт и здравствует. И если уж делать PCI-карты, то уже не банальные LPT и COM, а с нормальными интерфейсами.

Ключевое слово - "делать". И появилась нехорошая тенденция и PCI устранять, пока что из бюджетных MB

Не заметил такой тенденции. Или это бюджетные вообще без разъёмов? Но не думаю, что они "делают погоду".

Ну вот, хотя бы http://www.asrock.com/mb/Intel/H61M-GS/index.ru.asp
Только PCI-E, а это, сам понимаешь, маленько не то

А в названии PCI-E первые 3 буквы никаких ассоциаций не вызывают?..
PCI и PCIe имеют общую программную модель, разная только физическая среда передачи. Фактически в устройстве, разработанном для PCI достаточно сменить краевой разъём и чип адаптера шины на соседнюю модель и получится PCIe устройство. Так-же сущёствуют недорогие решения (чипы) по преобразованию одного в другое. На заре появления PCIe многие производители просто на свои PCI-карты добавляли конверторы PCIe-PCI. У нас в серверах используются специальные райзеры с преобразованием PCI-PCIe и наоборот, что позволяет не заморачиваться с обеспечением широкого ассортимента ЗИП.
Кстати, на примере Mesa 5I70 можно посмотреть насколько "сложен" такой конвертор.

UAVpilot писал(а):А в названии PCI-E первые 3 буквы никаких ассоциаций не вызывают?..

В любом случае, плату PCI в PCI-E просто так не воткнешь, а там, глядишь, еще какую фигню придумают..

Просто так - это в смысле бесплатно?

http://dx.com/p/pci-express-to-pci-adapter-card-26080