Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Свой драйвр для COM
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Интерфейсы
Timofey
В силу ряда причин пишу свой драйвер для встроенных в материнку COM портов. Возникло несколько вопросов:
1. Читал, что через биос можно узнать адреса стандартных портов, путем чтения данных по адресу 0040h. Читаю от туда данные, а они постоянно меняются. Верен ли адрес? Где вобще можно узнать адреса стандартных портов?
2. В системе есть один порт с ресурсами 0x3F8-0x3FE, читаю эти адреса, а там одни фф. Получается порт не исправен? Или он на самом деле лежит по другим адресам? Запись других значений ничего не дает, там по прежнему лежат ФФ. Может это из-за того, что порт на самой плате внутри корпуса на разъем выведен (не сзади системника стандартный ДБ9) и он все таки по другим адресам в памяти?
3. На домашнем компе при выполнении пункта 2 вижу нормальные, адыкватные числа. Порт настраивается. Теперь хочу перехватить прерывание. В каких то случаях получается прерывание настроить на свою программу, в каких то нет, возвращается ошибка параметров. Удачный перехват происходит только если в диспетчере задач выключить порт и снова включить. тогда без проблем. до следующей перезагрузки. Можно ли как то этого избежать?
V_G
Если упоминается диспетчер задач, стало быть, под винду хотите драйвер писать? Она (винда) будет этому сильно сопротивляться, что видно уже по описанию проблем. За Линух не скажу, не знаю. Под ДОС - реально.
Timofey
Да, под винду ХР СП2 пишу.
adnega
Может в Вашем случае и не обязательно обращаться в портам ввода-вывода. Напишите, типа, надстройки над стандартным com-портом с необходимым интерфейсом. "Я так сто раз делал".
Timofey
Все дело в том, что программа будет стоять на компе, где уже есть одна прога и для неё были написаны свои драйвера для портов. стандартных в системе нет. стоит вопрос, как не удаляя драйверов той программы. просто закрыв её. пользоваться этими же портами.
еще почему хочу написать свои, так как в драйвере есть таймер с дискретом 100нс, что в нашем случае подходит, нужно улавливать 1,5 байта тишины для модбас.
з.ы. в целом стоит задача реализовать модбас, где комп выступает слэйв устройством и отвечает мастеру не позднее 3.5 байт тишины
Demeny
Цитата(Timofey @ Dec 14 2010, 05:06) *
1. Читал, что через биос можно узнать адреса стандартных портов, путем чтения данных по адресу 0040h. Читаю от туда данные, а они постоянно меняются. Верен ли адрес? Где вобще можно узнать адреса стандартных портов?

Адрес не 0040h, а 0400h, или в нотации "сегмент-смещение" 0040:0000h. Только это адрес реального режима, или, проще говоря, физический адрес. В драйвере под ОС, работающую в защищённом режиме (Windows, Linux), его необходимо смаппировать в свое адресное пространство.
Цитата(Timofey @ Dec 14 2010, 05:06) *
2. В системе есть один порт с ресурсами 0x3F8-0x3FE, читаю эти адреса, а там одни фф. Получается порт не исправен? Или он на самом деле лежит по другим адресам? Запись других значений ничего не дает, там по прежнему лежат ФФ. Может это из-за того, что порт на самой плате внутри корпуса на разъем выведен (не сзади системника стандартный ДБ9) и он все таки по другим адресам в памяти?

Скорее всего, порт просто не включен в BIOS Setup.
Цитата(Timofey @ Dec 14 2010, 05:06) *
3. На домашнем компе при выполнении пункта 2 вижу нормальные, адыкватные числа. Порт настраивается. Теперь хочу перехватить прерывание. В каких то случаях получается прерывание настроить на свою программу, в каких то нет, возвращается ошибка параметров. Удачный перехват происходит только если в диспетчере задач выключить порт и снова включить. тогда без проблем. до следующей перезагрузки. Можно ли как то этого избежать?

ISA-прерывание не является разделяемым ресурсом, поэтому система не даст подвестить два обработчика прерывания от legacy COM-порта. Если Вы хотите обслуживать COM-порт своим драйвером - стандартный виндовый драйвер необходимо отключить.
Timofey
Цитата(Demeny @ Dec 14 2010, 09:39) *
Адрес не 0040h, а 0400h, или в нотации "сегмент-смещение" 0040:0000h.

Понял. Переделал. Заработало на домашнем компе.
Цитата(Demeny @ Dec 14 2010, 09:39) *
Скорее всего, порт просто не включен в BIOS Setup.

Включен. И сама система его видит прекрасно и предлагает с ним работать. Ну тут я еще поковыряюсь.
Цитата(Demeny @ Dec 14 2010, 09:39) *
ISA-прерывание ...

Понял.
Спасибо большое за ответы.
XVR
Цитата(Timofey @ Dec 14 2010, 06:56) *
Все дело в том, что программа будет стоять на компе, где уже есть одна прога и для неё были написаны свои драйвера для портов.
Ой.
Цитата
стандартных в системе нет.
Ой ой.
Цитата
стоит вопрос, как не удаляя драйверов той программы. просто закрыв её. пользоваться этими же портами.

Ой ой ой!
Цитата
з.ы. в целом стоит задача реализовать модбас,
удачи вам в вашем нелегком труде cranky.gif
Windows НЕ ЯВЛЯЕТСЯ системой реального времени, даже на уровне ядра. Т.е. сделать ГАРАНТИРОВАННО рабочий modbus RTU на ней нельзя, можно лишь говорить о вероятности успешной работы и среднем временем до сбоя crying.gif

По поводу драйвера - возьмите DDK/WDK, там есть (в примерах) стандартный драйвер COM порта. Допиливайте его напильником до требуемой кондиции

По поводу совместной работы разных драйверов с одними и теми же портами, то это целиком зависит от самих драйверов. Стандартный драйвер COM порта в Windows поддерживает разделение ресурсов (точнее, их захват и освобождение). Если драйвера от 'одной проги' это поддерживают, то все должно срастись
Timofey
Да я знаю, что очень точно время считать все равно не получится, но попробую. sm.gif
DDK - установил, примеры смотрел. что то из них и беру.
Спасибо.
_Pasha
Цитата(Timofey @ Dec 14 2010, 16:38) *
Да я знаю, что очень точно время считать все равно не получится, но попробую. sm.gif

Компы бывают слейвами? cranky.gif
А, прочитал. Пробуйте что-нить на основе "пустых" передач, при выключенном драйвере передатчика. Так можно не 1.5, а 2 символа тишины отловить. И хрюша тут ни при чем - прерывание покажет количество переданных символов, если оно на 2 больше чем принятых - поймали.
Timofey
я такого в инете не нашел, но начальство сказало сделать, значит надо сделать ... причем на скорости 57600 все таймауты надо строго выдержать sad.gif
firstvald
Если уж взялись за modbus RTU, то используйте обычные функции ReadFile и WriteFile. Допустимый зазор между байтами задайте просто задав тайм ауты в структуре тайм аутов, их надо подбирать , т к все таки реально получающиеся миллисекунды крепко отличаются от того, что пишем в константы, причем отличаются как от операциоки к операционке, так и от машина от машины. Но вам совершенно не надо выгребать миллисекунды.
1.5 вам не надо совершенно, вам надо опознать конец передачи и все. Для больших скоростей в спецификации RTU введено ограничение 1.7 по моему, точнее не надо, но с точки зрения реализации на компе и это нонсенс - нету таких возможностей.

Для скорости 57600 я в константы структуры тайм аутов пишу 6. С просящимся изначально туда числом 2 прием не работает и еще серьезнее не работает если в винде крутится процесс который чего-то хочет: работа по сети, файловые операции, медиаплеер, запуск эксплорера.

Пы Сы Через USB вирт компорты или через Ethernet вир com порты modbus rtu работать не будет, может, но это уже будет крепко за спецификациями sm.gif
Timofey
Таймауты там задаются в мс, мне же надо аж мксек выдержать (цитата из ТЗ):
"Пауза между байтами внутри сообщения, а также между запросом и ответом не должна превышать 1.5 байт на рабочей скорости передачи, что для скорости 57600 бит/сек составляет 260 мкс."
Но все эти времена очень сильно зависят от того, что на данный момент запущенно в системе, но попытка-не пытка ... Посмотрим, что получится.
firstvald
Посылайте всех нах.

Документ: Modbus_over_serial_line_V1_02 (это хелпик к одному из приборов, я там и спецификации пристегнул)
пункт 2.5.1.1.

Remark :
The implementation of RTU reception driver may imply the management of a lot of interruptions due to the t1.5 and t3.5 timers. With
high communication baud rates, this leads to a heavy CPU load. Consequently these two timers must be strictly respected when the
baud rate is equal or lower than 19200 Bps. For baud rates greater than 19200 Bps, fixed values for the 2 timers should be used: it is
recommended to use a value of 750μs for the inter-character time-out (t1.5) and a value of 1.750ms for inter-frame delay (t3.5).

Для скоростей превышающих 19200 два фиксированных значения ДОЛЖНЫ быть использованы : рекомендуется использовать для межсимвольного тайм аута значение 750 мкс в качестве t1.5 и значение 1.75 для межкадровой задержки (t3.5).

А на практике в компьюторе никто время считать не умеет. Крепко теоретически можно завести мультемедийный таймер и сдвинуть процессу максимальный приоритет, но в компе есть сетка 1 мс временных интервалов и все. А уж заставить винду каждую миллисекунду чего-то делать - сизифов труд. Это все глупости. При приеме RTU можно воспользоваться без особого гемора возможностями UART, он от рождения аппаратно отслеживает 3.5 временные интервалы между байтами. Но точно сделать вы врядли сможете.

В том же документ указано: по мньшей мере 3.5 мс.

Мы в своих приборах в руководстве приводим табличку в которой пишем вменяемые цифры межкадрового временного интервала.
Timofey
В ТЗ есть ремарка, что мол да, это противоречит стандарту модбас, но сделать надо так и никак иначе.
Кстати, во время работы общался с разными разработчиками и все почему то трактуют модбас по своему.
Знаю двоих, которые с пеной у рта доказывали мне, что на любой скорости устройство должно ответить не позже 3,5 байт. Поэтому скорости у себя они закладывали не выше, чем 9600, ибо на тех что выше, контроллер просто не успевал обработать посылку.
Когда распеатывал даташит и показывал им стандарт, они говорили, что это я не правильно трактую его и тп ... sm.gif
firstvald
Ха! Не удивляюсь. Даже разработчики модбаса такую хну несут, а что делать с эксплуатационщиками? Я руководству сразу сказал, что в подавляющем числе случаев на любой вопрос потребителей ответить будет нечего, только взять и все за них сделать. А протокол-то несложный и документ очень сжатый, там только десяток страниц просмотреть и все, это не USB.

Помочь тут вам не смогу sm.gif

Вообще говоря, все на самом деле идет к числу тразакций в секунду. Я исхожу из максимально возможного числа 8 в секунду вне зависимости от скорости обмена, коллеги настаивают на максимум 5 в секунду.. А чего хотят от вас? Это вообще чего такое будет? Может лучше не вы*** и делать сразу TCP ( и может вообще свой протокол, я сталкивался с тем, как пендосы просили в авиационном стенде сделать TCP, пофиг какой, только чтобы успевал) просто результат будет гарантированный, а тут, похоже, на ни к чему не проиводящее эстетство.


Timofey
Прога будет стоять на мониторе, где крутится Windows XP Embedded. Вся система подключается к двум ком портам. Нужно опрашивать оба параллельно и объединять информацию, потом её обрабатывать и отображать. Период опроса по одному каналу всех устройств не должен превышать 100 мсек.
Хотят - сделаю. А то что может не получится, я уже объяснял, но доводам моим не вняли sm.gif
firstvald
Смотрите. Прежде всего устройство должно уметь в одном кадре говорить о текущем состоянии измерения всё. Т е за один запрос мы должны получить результат измерения всех каналов из одного прибора (если он многоканальный) и всех вспомогательных переменных (состояние реле , уставок, кнопок, достоверность измерения по каждому каналу прибора и т п; это называется групповым запросом, в обычных скадах это делать не умеют, только если на устройство есть специфический драйвер), а в скада любят по одному или по два регистра выспрашивать из прибора.
Timofey
В этой системе уже стоят 20 устройств, одно из которых уже является мастером. Наш монитор должен прослушивать линии обмена и анализировать данные из всех посылок, но при этом отвечать только на свою. У каждого устройства разный размер посылок, минимум 8 на запрос и ответ, у другого 11 байт есть в ответе. Сейчас сделано так, что в мониторе программа в отдельных потоках принимает по одному байту, накапливает данные, пока не поймет, где начало посылки и дальше уже обрабатывает её, то есть никаких проверок на таймауты. Но такой подход не нравится. Было решено написать отдельный драйвер, чем я и занимаюсь )
Практически закончил, осталось докупить железа и проверить, думаю к новому году отлажу и получу первые результаты )
_Pasha
Цитата(Timofey @ Dec 16 2010, 16:56) *
Сейчас сделано так, что в мониторе программа в отдельных потоках принимает по одному байту, накапливает данные, пока не поймет, где начало посылки и дальше уже обрабатывает её, то есть никаких проверок на таймауты. Но такой подход не нравится.

Что характерно - метод, реально работающий без шума и пыли - не нравится. Можно довесок к ком-порту прицепить, чтоб анализировал паузы и по DCD сигналил.
firstvald
Да там такую хрень замутили, что все чихать потом год будет и, самое противное, отладить, скорее всего, не удастся никогда. Уж написали, что винда не реал тайм и любой поток будет время от времени при ширкании мышой или там еще чего тормозить и ессно будет обмен падать. Глубоко и долго. У меня на штатных API как винамп запускаешь - падал.

ИМХО для такого чуда внешняя приблуда была бы самым тем.
XVR
В принципе на уровне драйвера можно обеспечить требуемые времянки, но путем глухого блокирования всей жизнедеятельности Windows на время обмена. Так что при запуске WinAmpа ничего падать не будет, а вот при обмене по ModBus'у WinAmp'у будет долго и сильно икаться wink.gif
firstvald
Так мне и рекламация такая была: а чё музыку низзя слушать при обмене?
singlskv
Цитата(Timofey @ Dec 14 2010, 09:56) *
з.ы. в целом стоит задача реализовать модбас, где комп выступает слэйв устройством и отвечает мастеру не позднее 3.5 байт тишины
Че-то Вы модбас совсем не вкурили...
3.5байта тишины это всего лишь конец посылки, т.е. по наличию не менее чем такой паузы
принимающая сторона понимает что посылка закончилась.

Slave на PC(16550A), ну-ну...
RS-485 ? если да, то RTS хотя бы аппаратный ?
Timofey
В модбасе конец посылки обозначает пауза 1,5 байта. А 3,5 байта тишины должно быть выдержано перед началом передачи следующей посылки. cranky.gif
RS-485 с аппаратным RTS
firstvald
Цитата(Timofey @ Dec 18 2010, 08:02) *
В модбасе конец посылки обозначает пауза 1,5 байта. А 3,5 байта тишины должно быть выдержано перед началом передачи следующей посылки. cranky.gif
RS-485 с аппаратным RTS


В модбасе конец посылки обозначает перерыв в течении времени не менее чем 3.5 времени передачи символа (почувствуйте разницу формулировки), а если в кадре встретилась пауза 1.5 - то кадр плохой. На практике это означает, что в контроллере, когда мы сами хозяева положения, мы начинаем анализировать приемный буфер тогда, когда в течение времени не менее чем 3.5 ничего больше не пришло.

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

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

Про 16650 я уже не смеюсь даже, там еще и времена чудесатые им понаписали. Мужики запорят тему на ровном месте или что хуже - чихать все это будет долго долго у заказчика, пока все не плюнут.

Покажите всю эту писанину руководству. angry.gif
singlskv
Цитата
RS-485 с аппаратным RTS
Если с аппаратным RTS то может быть прорветесь... хотя пакеты будете терять на приеме постоянно.
Цитата(Timofey @ Dec 18 2010, 08:02) *
В модбасе конец посылки обозначает пауза 1,5 байта. А 3,5 байта тишины должно быть выдержано перед началом передачи следующей посылки. cranky.gif
Читайте внимательнее...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.