Прежде чем пиками тыкаться, читаем посты полностью 



Это во первых.
Во вторых, я посмотрю, как ты будешь дергать эти сигналы с частотой в 
. Еще при это наверно и стабильность частоты будет хотеться???

1

это

и есть прямое дерганье ножки дата
про остальные молчу

2

так вот судя по первому посту как раз стабильность не требуется (интуитивно по опыту)

есть тактовая - стабильность идет лесом //стандартный алгоритм типа шины I2C

в чем не прав?

В теории мы про одно и тоже... только разными словами.

На практике ты не прав в том что:

1 - Гигагерц у тебя не получится. Попробуй. Если сделаешь, и будет у тебя действительно гигагерц, да еще и хотя бы иногда действительно осциллограф будет показывать эту частоту, буду век тебя помнить, если исходниками поделишься. Насколько я знаю, еще никому гигагерц не удалось с COM-порта получить, уж тем более под Windows.

2 - I2C - протокол межмикросхемного взаимодействия. Да, его, теоретически, возможно эмулировать COM-потом, на практике, как человек 2 года писавший программы для работы с контроллерами по COM-порту, я тебе говорю, не получится! А если и получится, то я бы не поручился за поделку. Потому как Windows не должна, и не обеспечивает нужные параметры. Они могут совпасть, а могут и нет. И будешь ты объяснять заказчикам что верблюд не ты, а Гейтс. Но им будет все равно, им главное, что твоя программа не работает (ну или если повезет, то переодически не работает).

3 - Можно шуруп забить молотком... Никто не мешает, но это неправильно. И то, что хочет сделать автор, сделать  можно (если забыть про верхний предел требуемой частоты), но это неправильно! Ибо все, что завязано на тайминг windows обеспечивать "НЕ ОБЯЗАНА", а следовательно надо делать управляющий контроллер, который будет посредником. Или же все это сделать на одном, что бы его просто конфигурировать, а дальше он уже сам.

ЗЫЖ Про Modbus слышал? Так вот там есть умные переходники, а есть не очень, и что бы не очень умный работал, ему надо правильно подавать сигнал о том, что надо изменить направление передачи... В теории все просто, как у тебя! А вот на практике 50/50. То работает, то нет. И чем больше устройств и выше частота, тем чаще не работает. Вобщем проблему решили, но это все было через не то место, и к тому времени я уже уволился... 

Короче, я хочу сказать, что надо делать как положено, если надо что бы работало как положено.

уважаемый Felan "мы же взрослые люди, лучше возьмем линейку и сравним"   шутка цитата
по теме
вы допустили несколько важных неточностей!:

1 речь идет о 1-1000 ГЕРЦ!

2 - I2C - протокол межмикросхемного взаимодействия. реализуется на раз и без проблем. в нем главное не ПОСЛЕДОВАТЕЛЬНОСТЬ СИГНАЛОВ!. а скорость не важна

3 в одном вы правы тайминги виндовс не обязан выдерживать (ну не реалтайм система)

4 еще как (как никак в отделе асутп уже более 6 лет, и специализация именно контроллеры и взаимодействие между ними)
вы наверное имели в виду не Modbus, а RS485   где приходится переключать прием и передачу отдельным сигналом. так вот да на больших скоростях бывают трудности но до 57600 включительно работает стабильно (но приходится извернутся с программированием, есть свои тонкости- но все решаемо)

и последнее проблема описанная автором решается стандартным апи системы. без каких либо извращений


Это сообщение отредактировал(а) Virtuals - 7.9.2007, 11:22

Точно... Блин, посыпаюсь пеплом! 
Хотя и сомневаюсь в реальности даже мегагерца...


Здесь не согласен!
Т.к. то, о чем говоришь ты, это выполняется напрямую. А данные пересылаются драйвером Windows.  Поэтому нет возможности точно определить, когда какая чать данных уже ушла на устройство (только когда они поступили во внутренний буфер драйвера). А так, что бы сам драйвер выставлял сигналы, можно сделать не всегда, т.к. это зависит от того, какие сигналы и как выставлять.
Хотя, опять же в элементарном варианте может это и будет работать, но вот я бы не стал так делать...


Да, именно.  Просто описАлся малость. Для меня это был по большей части ModBus, это для электронщика (напарника) это был RS485 
У нас все начиналось рушиться на 38400. 

Я и писал, что лучше использовать API. Тогда может получиться. Хотя решение не хорошее на мой взгляд (не в смысле использования API а вообще таким образом управлять контроллером через порт.

Ну что ж... Вроде выяснили ситуацию 
Дабы не сваливаться в холивары, предлагаю мировую  Тем более автор пропал 

Ок мировая.  

есть такая противная вещ как FIFO буфер , а в случае USB-RS232 и не один вот из-за него проблемы (но есть возможность его отключить и сделать мин обьема, ) информация на будущее //сам не одни сутки убил на решение данной задачки (кстати относится не только к виндам, а вообще к портам в общем)


есть очень надежный способ STS-CTS DTR-STR DI-DO   для полного контроля.

ЗЫ сам так епромки программирую

Это сообщение отредактировал(а) Virtuals - 7.9.2007, 14:58

Что-то не припоминаю в стандарте RS232 сигналов STS или STR... возможно имелось ввиду RTS-CTS и DTR-DSR?

Ну да это не важно.
Их можно и нужно использовать. Только в Delphi7 неправильно указаны константы для настройки дравера :(
Совершенно случайно на это наткнулся... Очень много тр...ся... пока выяснил это... потом переобъявил как надо и было счастье 

ЗЫЖ А что такое DI-DO???

RTS-CTS и DTR-DSR виноват зарапортовалси, они самые а di-do в rs232 это txd-rxd

а что за константы? (правда у меня D6)

Это сообщение отредактировал(а) Virtuals - 10.9.2007, 10:22

Битовые константы DCB структуры.


В дефийских обертках битовая часть представлена как Flags: Longint; И выставлять их надо через присвоение комбинации констант использую "or". А они объявлены не как битовые, а как числовые.

Например:
Объявлено   DTR_CONTROL_HANDSHAKE = 2;
Должно быть dcb_DtrControlHandshake = $00000020;

Т.к. в делфи, в отличае от билдера нет полей для присвоения значения конкретному битовому полю... :(

Это сообщение отредактировал(а) Felan - 10.9.2007, 11:00

   За хорошим обсуждением забывается изначальный вопрос.  
А вообще-то "подергать" можно сигналы RTS (Request To Send) и DTR (Data Terminal ready) соответственно контакты 7 и 4 на 9 контактном разъеме.  

сам такой ответ в последнем посту на первой странице!  

svip  дляработы с портами в xp, я использую библиотеку inpout32.dll если тее еще нужен модуль для работы с этой DLL то скину. 

теперь по твоему вопросу 



ты сам то знаешь где этот седьмой контакт находится или ты сам его обозвал седьмым контактом,  и какой тактовый сигнал нужен логический ноль или еденица 

с Com портом не работал работал только с LPT но может тебе это поможет 8 ножек это есть байт на каждой ножке один бит

значит нужно подать в порт 01000000 в 2 систе сч.  подавать тактовый сигнал частотой 1-1000Гц на 7 контакт 

нужно подать в порт 00001000 в 2 систе сч.  подать логическую единицу на 4 контакт 

если правильно понял твой вопрос и то что я тебе говорю тебе подходит тогда могу дать пример в Delphi

COM != LPT. У ком порта двухпроводная шина данных и биты там передаются последовательно. Не путай человека.  

Ну и что ты этим хочешь сказать???

svip http://www.pcports.ru/articles/pic9.php посмотри здесь

Сорри с COM не так просто как с LPT, и его полноценное использование потребует значительно больших усилий. Главной загвоздкой является и его главное преимущество - передача данных в последовательном виде. Если в LPT байт данных передается по 8-ми линиям по биту на каждую, и состояние каждой линии можно было легко посмотреть, то в COM порту байт данных передается бит за битом по одной линии (относительно земли, конечно)

c сайта http://www.pcports.ru 

Добавлено через 3 минуты и 4 секунды
хотя библиотеку inpout32.dll  использовать реально