Может это не по теме, но другого места я тут не нашол.
Такая ситуация: Написал я програмку на DELPHI которая общается по RS-232 с МК. Использовал стандартные API функции. В чем проблема? На моем компьюторе все нормально работает, но при переносе на другой компьютер ниче не работате - обмена нет.
Я думаю, что это связано с опциями копиляции или с самим COM-портом. Если у кого была такая ситуация подскажите.
Есть ли разница в уровнях в COM-портах на разных компьютерах?

Во-первых, хотелось бы узнать разные операционки на этих компах или нет.

По поводу опций компиляции. Прогу можно компилировать с включением библиотек и без. Выбирается это в опциях проекта, закладка "Packages", галочка "Build with runtime packages". Проверьте ее.

Есть программка DEPENDS.EXE. Запускаете ее и ей "скармливаете" Ваше приложение. Она покажет, какие DLL, BPL и пр. используются для этой программы. Если на другой машине чего-то не хватит - то сразу увидете.

Методика примерно такая:
1. Делаете заглушку Tx-Rx. Одеваете ее на порт, открываете штатную программу Монитор и передаете символы. Если есть прием - значит порт нормально работает.
2. В Вашей программе реализуете аналогичную функцию. Заодно тут выяснятся подробности с программной или аппаратной синхронизацией приема-передачи, те куда девать DTR-DSR. Добиваетесь, чтобы был прием.
3. На Вашем микроконтроллере делаете программную заглушку, которая выполняет то, что было описано в п.1. Передаете символы в мк, он должен отвечать ими-же.
4. Только после этих шагов переходите к проверке "родной" программы. А шаги 1-3 оставляете для проверки оборудования.
Удачи!

Было такое давно, но до конца не победили (не нашли все причины, шаманством обходились).

Проверьте свойства COM-портов в драйвере Windows (лучше не использовать автоматическую настройку), Ваша программа должна сама инициализировать порты. И вообще советую еще раз сравнить компьютеры по этой вкладке и найти отличия. Результаты сообщите, пожалуйста .

При разработке и отладке своего компонента
KlientServComConnect пришел к выводу, что работа с COM-портом не особо зависит от системы (когда корректно все сделано) и конкректного компьютера. Больше вопросов было с модемами - разные модемы по разному работают. В вашем случае, предполагаю, вы не инициализируете порт, а используете настройки порта по умолчанию. Параметры, от которых в первую очередь зависит работа порта - скорость порта, таймауты порта (которые кстати в настройках системы не предусмотрены), причем они взаимосвязаны.
Уровни логических сигналов на выходах портов разных машин естественно могут быть разными, но если они будут находиться в диапазоне -5...-12 В (для лог. единицы) и +5...+12 В(для лог. нуля) то все должно быть нормально, входы портов должны без проблем воспринимать сигналы -3...-12 В(лог.1) и +3..+12 В (лог.0), если есть сомнения, измерьте уровни осциллографом (или вольтметром)...

Фух разобрался. Я просто не включил в проект юнит с классом для работы с ком портом. Все заработало покрайней мере на 15-ти машинах. Ужас как часто причины отказов кроются в мелочах.

<<Фух разобрался. Я просто не включил в проект юнит с классом для работы с ком портом. Все заработало покрайней мере на 15-ти машинах. Ужас как часто причины отказов кроются в мелочах.>>

Тогда расскажите, как все это работало на вашей машине? Что - то я начинаю разочаровываться в
DELPHI

Так вы к порту обращались непосредственно через API, или использовали какой-то класс (или компонент)? Если через класс, то непонятно как проект удалось скомпилировать, когда юнит с классом не включен в проект ...

Не совсем понятно, в чем именно разочарование Если касательно работы с COM-портами под win32, то лучшее, что нашел в инете - статья Олега Титова (http://www.megalib.com/books/461/mastering/ports5.htm). Изложено толково и достаточно подробно, недостающую информацию по используемым API-функциям и структурам можно посмотреть в родном хелпе delphi.

В DELPHI, как и в Borland Builder и VC для генерации исполнительного кода есть настройки, что бы проект собирался и содержал в одном файле все необходимые библиотеки которые используются, если конечно они не системные. Exe-шник правда становиться большим, но будет работать на всех компах имеющих требуемую Windows среду.

Возможно, что вместе с дэлфой идут какие-то драйверы. попробуй на том компе установить дэлфу, и если всё заработает, то причина именно в этом

Драйверы для общения с периферией - не идут.

При работе с портами идет обращение к стандартному драйверу порта посредством вызова соответствующих функций API. Только в случае использования собственных нестандартных драйверов их придется переносить на каждую машину. Кстати, если кого интересует работа с LPT из delphi, могу найти ссылку на ресурс ( сейчас не вспомню). Там предлагается готовый шаблон и набор функций типа "если хотите установить эту ножку, сделайте то-то". Все на русском и с примерами использования.

Подняли старую тему.Вероятно у меня плохая копия Delphi.Без подключенных компонентов или
юнитов у меня не получается управлять СОМ-портами.

Интересно было бы взглянуть...

Взгляните http://valery-us4leh.narod.ru/main.html

Не знаю насчет плохой копии... Собственно, единственное, что требуется - вызов нужных API- функций, по-моему должно работать в любом случае. А вызовом расширенных команд с помощью функции EscapeCommFunction можно произвольно управлять ногами TxD, RTS, DTR, реализуя протоколы, отличные от стандартного. Повторюсь насчет ссылки на статью Олега Титова - неплохо расписано. Если что - пишите

Спасибо Shans.Я хорошо разбираюсь в портах и API функциях. Я просто хотел
обратить внимание на то , что ASV вешает всем лапшу на уши.