возникла такая проблема. есть АЦП нужно связать его с программой через com порт. и в программе вывести значения амплитуды.

на АЦП подается тактовый сигнал 7 контакт порта и сигнал для начала преобразования сигнала в АЦП 4 контакт порта. Данные снимаются с 8 контакта порта
то есть нужно подавать тактовый сигнал частотой 1-1000Гц на 7 контакт
подать логическую единицу на 4 контакт
и считать информацию с 8 контакта.

ПОМОГИТЕ ПОЖАЛУЙСТА.

помогите конкретным примером на delphi если кто знает как это реализовать.
Буду очень благодарен   

Возможно Вам скорее надо в "Программирование контроллеров"...

дело не в контроллерах. Нужно в делфи работать к конкретным выводом в COM порте

наверное никто не знает как это реализовать. Обидно ведь у меня есть exeшник в котором это реализовано :(

Советую почитать "Последовательные интерфейсы ПК" П. Агуров

перечитал уже все что возможно найти. но нигде не написано как работать с конкретной ножкой ком порта как например в паскале port[$2F8+6]:=2 например

может все таки ктонибудь знает как это раелизовать

Агуров П."Последовательные интерфейсы ПК", стр.104-106. Запустил прогу ports.exe:Но когда я захожу в Свойства компа->Устройства, то там лишь:
Последовательный порт(COM3)
Последовательный порт(COM4)
Порт принтера(LPT1)
Profilic USB-to-Serial Comm Port(COM6)
Почему тогда програма не написала, что "COM1 не обнаружен"(а также и COM2)?
Почему программой не упомянут COM6 ?

WinXP_sp2, Delphi 7

По-поводу ножек (пинов). Есть возможность проверять "состояние модемных линий", с помощью WinAPI. В компоненте Агурова это реализовано, если память не изменяет. И это описывается в любой статье в инете по программированию СОМ-портов. Просто нужно потрудиться, почитать, поизучать коли уж этим занимаетесь. Тем более что обычно СОМ-порты - это коммерческая тема, денежная ;).


malor, не путайте адеса в области данных последовательных портов виртуальной машины DOS и конфигурацию оборудования, а также Delphi7 и Turbo Pascal. Неужели вы скомпили в Делфе тот PORTS.EXE ) ?

Это сообщение отредактировал(а) Злоумышленник - 2.9.2007, 23:53

svip, непосредственно ножкой дергать в прямом смысле не получится, т.к. последовательный на то и последовательный, что у него нет как таковой шины данных.

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

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

Короче, тут думаю тебе самому придется ковыряться. Почитай книжку которую тебе тут рекомендовали и про работу с портами в MSDN, вобщем-то там все понятно... Если есть конкретные вопросы, то попробую ответить.


Ну если мне телепатия не изменяет то:
Потому что 3 и 4 это виртуальные порты (либо у тебя по какой-то причине изменилась нумерация), а реальных может и не быть вообще. Потому что твоя программа видимо ищет не все порты, а только до определенного номера.
Не обнаружены они потому, что их нет в системе.

Felan, ты видимо невнимательно прочитал мой предыдущий пост. Прога эта на Турбо Паскале сделана, и не порты она ищет, а адреса стандартных портов от 1 до 4 в служебной области БИОС из под ДОС (СОМ1-4 подставляется прогой "в лоб"). А что такое адреса портов в данном случае - почитай какой-нить учебник по Ассемблеру.

Насчёт использовать компоненты или "API". Во-первых, компоненты делаются "на API". Во-вторых, из тех, что я видел, всё уже есть. В-третьих, используя компоненты, получаешь программу без ошибок, быстро сделанную и при грамотном компоненте компактную.

Это сообщение отредактировал(а) Злоумышленник - 3.9.2007, 09:30

Рас уж ты все это хочешь под Windows, то рекомендую тебе соответствующую книжку почитать, а не козырять решениями из DOS'а...

Ну да ладно. Дело твое.

Что понимается под фразой "Коммуникационные порты занимают в пространстве ввода/вывода по восемь смежных 8-битовых регистров и могут располагаться по стандартным базовым адресам" ?

Еще вот эта фраза убивает- "Базовый адрес - это 2-байтовый адрес порта, который является младшим из группы адресов портов, дающих доступ к UART". Что за "группа адресов портов"?
(Агуров, стр. 104)

Это сообщение отредактировал(а) malor - 4.9.2007, 13:17

как говорится комментарии излишни





OUTSIGNAL(SETBREAK); это вам в пику


Это сообщение отредактировал(а) Virtuals - 5.9.2007, 16:23

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



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

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  использовать реально

Я хочу этим сказать, что прежде чем давать советы по какому либо вопросу надо хотя бы немного в нем разобраться! У COM нет шины данных как у LPT. И то, что  пошлешь в порт, будет передаваться последовательно, бит за битом, потому он и "последовательный", а не параллельный.

Последовательный интерфейс RS232 (СOM порт)