В общем сразу к делу - надумал я научить компьютер общатся с некиеми датчиками. В принципе есть всё - конвертер 232-485 (правда нерабочий), есть Билдер Си++, есть сами датчик с рабочим 485-ым интерфейсом. Но я не знаю с чего начать... Протокол обмена написан, но он собственного сочинения, который ни на один существующий протокол не похож (этому были свои причины). Так вот, есть ли у кого-нибудь опыт в этом деле? Если есть, то меня интересуют несколько вопросов:

1. Есть ли для билдера какие-нибудь компоненты для работы с ком-портом (стандартные нехочу, ибо слишком много возни)?
2. Есть готовые исходники рабочей программы обмена данных через ком-порт (только не сильно нагруженных, мне надо пересылать пакеты по одному-двум байтам)?
3. Есть ли схема конвертера 232-485 с опторазвязкой, способной выдержать нарузку в 32 датчика?

Вроде пока всё, если ещё чего, то я напишу позже...

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

Главное не задавайтесь целью управлять RTS.
Этим должен заниматься преобразователь.

Любой преобразователь в RS485 работает на 32 нагрузки,
это минимальная опция стандарта.

Обратие внимание на состояние шины перед транзакцией,
желательно передать в начале пару раз байт 0FFh для очистки приемника
от мусора. Либо растягивать шину в 1.

Если вы не хотите набить себе кучу шишек ковыряясь во внутренностях WinAPI, а за разумное время получить желаемый результат, то рекомендую воспользоваться библиотекой ComPort Library.
Мы с удовольствием используем этот продукт в своих проектах.

BVU, спасибо за предоставленные материалы, но я как раз хотел уйти от винапи... В данный момент я нахожусь в учебном отпуске, за который хотелось бы сделать что-то дельное. А винапи мне предстояло бы изучать и изучать... Конечно это совсем не значит, что я лентяй или лодырь, просто сейчас мне интересней что-либо попроще. Вот когда мне предстоит работа посеръёзней чем переслать пару байт, вот тогда я с головой и окунусь в винапи. Но всё равно спасибо з предоставленный материал!

vm1 спасибо за дельные советы, но на этом я уже набил себе много шишек...

aforestmanспасибо. я ещё не скачал, но думаю это то, что мне надо....

Для тестирования и разработки протокола устройств, использующих com-порт советую:программа для приема передачи данных через rs232

А почему? У меня всегда все работает нормально по RTS.
Во многих компиляторах вообще заложена стандартная процедура этого - подключаете опцию и все дела.

Проблема в том что в виндоз невозможно найти конец передачи, хотя это легко решается по другому -
чтением переданных байтов из порта после записи всех байтов в передающий буфер. Это можно с одним условием - приемная часть 485 драйвера должна быть всегда включена для приема и cвоего эха и удаленного девайса.
Во всяком случае на моем компютере без проблем работает

Мы похоже говорим про разное.
Сигнал RTS стробирует обычно каждый бит отдельным импульсом - есть режим в компиляторах (настройки порта) называется RS485 в этом случае сигнал RTS просто выставляется и удерживается на все время передачи байта. Этот вывод подключается к выводу прием-передача трансивера RS485 и все дела. Ничего больше ненужно делать.
По этому принципу можно сделать "просто удлинитель RS232" между двумя компьютерами - хоть на 4 км (AD позволяет) - нужно только следить чтобы прием и передача не пподдерживались ПО одновременно.

Конвертер, удовлетворяющий требованиям MAX1480 .
Библиотеку и примеры для PC можно взять здесь MOXA

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

Отсюда вопрос - какие есть и где взять? Если кто работал с такими, то просьба написать отзывы и линки на них))

ЗЫ:. tyro, спасибо, но я ещё не смотрел, сейчас качаю))

После возни с ВинАпи(так и не понял как создать событие приема байта в буффер) попробовал TMS Async32. Ощущения положительные. Сейчас откозался от него в пользу протокола WAKE - недавно про него писал на форуме в этой ветке.

Воть, скачал оба компонента, ссылки на которые указаны в этой теме и ещё один с другого форума. И вот что у них обещее - если читать данные из буфера по событию RxChar, то он (компонент) читает блоками по 8 байт. Т.е. если на вход передаётся скажем 12 бай, то возникнет два события и примется сначала 8 байт, потом оставшиеся 4. Если скажем 19 байт, то 8+8+3. Даже не знаю с чем это связано(( Кто юзал эти компоненты - скажите как с этим бороться!!!

otrog

Вечно все путают протокол и интерфейс))) В данном случае разговор идёт об интерфейсе RS-232, а протокол может быть любым (хотя в итоге надо реализовать поддржку модбаса)))

Делал опторазвязанный преобразователь RS232-485, вот схемка и плата (он для подключения к контроллеру, а не посл. порту компьютера) :
www.umup.narod.ru/rs485_conv.zip

Из библиотек для связи по RS232/485 наиболее мощный - Turbo Power Async Professional, им и пользуюсь (сначала тоже пользовал TMS Async32) :
http://sourceforge.net/projects/tpapro

Вот программа на Delphi3 для тестирования сети modbus (протокол RTU), легко можно адаптировать для Builderа :
http://umup.narod.ru/modbus_test.zip

Есть еще полноценная программа опроса приборов в сети Modbus. Также почти закончен проект кросплатформенной клиент-серверной системы на Python для работы с Modbus и Owen приборами (с базой данных, отображением графиков, возможностью работы в режиме сервера с генерацией Html страниц). Пришлось написать так как под Linux такого не нашел, а коммерческие SCADA системы слишком дорогие, сложные. При желании можно добавить и Wake.