И кто тогда будет поддерживать программатор Вашего имени, который я всем рекламирую.

Возможно и может, надо глянуть в эту сторону (мысля очень интересная)
дело в том что у OpenGL должны быть очень шустрые таймеры(не помню уже, давно это было, да и не на PC), ему ведь 3D графику в реалтайме выводить надо.
А стандартные виндусовые таймеры нормально начинают работать от 10мс.

Некоторые пытаются использовать MMTIME, там вроде такт получается 1-3мс

Я некоторое время занимался программированием 3D графики, и, как человек икушенный в этом не легком деле, скажу Вам что OpenGL базируется на DirectX, DirecX создан для Windows и он не использует точных таймеров. Для сдерживания, допустим FPS, используется обычный софтверный тамер системы Реалтайм для игрухи это 25 -50 ФПС.



ЗЫ: Представляю картину. Огромный зал с компьютерами, супер АСУ так сказать. Дядьки с умными лицами ставят Ваше ПО на систему удаленного управления объектами, бубны, торжественная музыка... Хлоп ... Аншлаг... Версия DirectX на Вашей системе устарела, требуется обновление ПО... ... Ну а че, прально, и оператору хорошо, вечером мона Кваку новую погонять, хехе

Дабы не заморачиваться с микросекундными задержками в windows я использую протокол WAKE. В нем определение границ пакетов происходит по служебным байтам. Есть исходники и на мк и на компьютер, за что огромное спасибо Леониду Ивановичу.
К сожалению ссылка на протокол не работает. Если интересно могу выложить исходники здесь.

ПС WAKE открытый и бесплатный протокол, в отличие от MODBUS.

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



А в каком месте MODBUS закрытый протокол?????????????

в WAKE используется байт-стаффинг, так что удвоение получится если передавать данные, совпадающие со служебными символами...

Это минус... Всю посылку придется сравнивать со служебными символами, а это опять потеря времени, за которое мы боремя

не все так плохо.. признаком стаффинга является один из 4х служебных символов, с ним и сравнивается каждый байт..

Ссылка на WAKE
http://www.spetspribor.com/support/software/wake/wake.html
к сожалению не работает , поэтому выложил сохраненную страницу со всеми файлами на ФТП
/upload/DOCs/WAKE.rar

байт-стаффинг конечно не очень хорошо, но жесткая времянка еще хуже(ИМХО).
А то что MODBUS закрытый может я и ошибся, но всякие там оговорки типа:
мне не нравятся.

ПС
2 prottoss На Вашем сайте исходников MODBUS нет, значит это закрытый протокол .

У меня к сожалению нет доступа к этому ФТП, может закинеш эти файлы мне на e-mail: labor@online.ua?

Мдя, после того, что я тут выложил, и Ваших слов некоторые точно подумают, что MODBUS придумал я , хм....я уже подумываю о новой версии - PROTTOSSBUS, а че? звучит ...

Зато на моем сайте есть достаточное количество информации, что бы разобраться в протоколе и начать продуктивно работать в этом направлении. Что касается исходников - я уже говорил выше - есть на http://modbus.org совершенно БЕЗВОЗМЕЗДНЫЕ готовые исходники (под PIC, но переделывается влет за неделю) и для клиента и для сервера. Все на Сях. Может быть выложу и свои - надо их причесать немного...

Положил сюда:
http://rapidshare.com/files/11035544/WAKE.rar.html (1.8 Мб)



Отличная идея

Это замечательно, может кому то понадобитсся именно полный MODBUS. Я, правда достаточно давно, реализовывал его на ASM51. В принципе с точки зрения микроконтроллера ничего сложного нет. Но для меня немного нафталином попахивает.

А вот с точки зрения PC, всё не так просто. Например задача - контроллировать задержку в 1.5 символа (пишу по памяти) на высоких скоростях (а RS485 поддерживает до 2Мбит) представляется сомнительной. Я столкнулся с тем что у меня PC самопроизвольно рвала пакеты. Иногда вставляя незначительные промежутки, но и скорость у меня не рекордная! А что будет на большой? Кроме того незнание момента окончания передачи для PC, а расчёт его, - тоже вызывает ощущение - не очень.

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

Интересно было бы повозится с LIN и с CAN. Чтобы самому составить своё собственное мнение.

А вообще интересно наблюдать, что все более-менее современные протоколы в конечном итоге приближаются к сетевым.

Разве идея MODBUS это не master-slave (запрос-ответ)?
Насколько помню там тупо до ужаса.
Посылаешь пакет, ставишь тайм-аут (отфонарный) ~100ms, если в ответ что-то пришло - хорошо, считаешь CRC, 0 - отлично, проверяешь код функции, совпал - значит ответ на наш запрос, ну а дальше парсишь сообщение.
Слейву еще проще. Получил команду - отправил незамедлительно ответ.

Где там задержки в 1.5 символа-то?

фунции modbus драйвера:

Не, незамедлительно нельзя!
по стандарту нужно выдержать интервал не менее 4 длительностей байта

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

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

Когда мастер PC под Win то существует проблема обрезания длинных пакетов:

Кстати SasaVitebsk какая у Вас скорость ?
Удалось ли победить обрезание пакетов ?