>>>модем управляется по одному порту, либо свой прогой, либо драйвером windows (PPP протокол), как они поделят порт? Если есть соединение, то доступа к порту нет.

Неверно.
Любой драйвер API прозрачный - то есть может быть проключен в своей проге использованием in/out стека.
Другое дело что в это время вторая прога к нему не будет иметь доступа.

Ведь сам драйвер PPP не может работать с внешним миром - ему нужно пихать параметры и потом поток данных - а этим должен кто то заниматься на более высоком уровне.


>>>вот хорошо бы без такого устройства обойтись

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

поэтому так или иначе, что-то должно контролировать связь и принимать решение о перезапуске.

я об это и говорю,
при подключение модема к системе, драйвер поднимает на нем PPP, запускает TCP/IP , сверху начинает пахать HTTP, FTP и прочий кардабалет, и куда нам приткнуться ?



Вот именно

так что, этот микроконтроллер должен сам анализировать трафик на UART и без посторонней помощи из PC принимать решение о перегрузки



а как работают сторожевые таймеры в промышленных модемах? по моему они тупо периодически перегружают модем



типичный сторожевой таймер

В упрощенном варианте - перезагружают периодически. Но в M680-OC можно реализовать свою логику работы WD.

встроенное ПО может работать параллельно работать с PPP соединением установленным по входу UART?
Судя по примерам внутреннее ПО управляет модемом через эмуляцию UART, или я чего то не понимаю

Вот с этого и надо было начинать. Т.е. считаете, что винда надежнее модема?? Вот когда ваша винда поработает несколько недель в режиме 24 на 7 с внезапными отключениями питания, собственными глюками, которых в ней чуть больше, чем дохрена, и глюками вашей проги, вот и оцените, что чаще глючит - винда или модем

ЗЫ. Вообще всегда умиляет то, когда работают под виндой и ищут "очень надежный модем"



Как правило - так и есть, причем иногда бывает, что сбрасываются и настройки, которые были введены без &W в командах.
Видать программерам там не больно надо было, например, отследить отсутсвие данных от модема и тогда уж его сбрасывать

вот на практике винда, с прогами, ПЛИС и т.д., работает неделями, а 3G модем часы




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



мдя, я то размечтался что в промышленных модемах, сделано по нормальному

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

Только не на ножку "сброса", потому, что она там - фикция, это не физический сброс МК модема, а просто сигнал его операционке, если она не зависла, что надо сделать "теплый" сброс. Нужно ставить полевичек на питание модема - самый надежный способ.



Че-то странно, у меня даже дешевые "свистки" неделю, как правило, отрабатывали честно, винда, бывало по нескольку раз в месяц висла...
Когда поставил "плановую перезагрузку" в полночь - стало гораздо легче

Сообщение отредактировал mantech - Sep 8 2015, 18:38

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





в свое время и wavecom (тогда еще) и simcom, уверяли что вот в этой новой версии reset теперь аппаратный, как сейчас не знаю

Ну если RTS есть, то в чем проблема?

Я больше скажу. Эксплуатировал сервер на линуксе дома. Он выходил из ждущего режима и раздавал инет по сети. Стоял обычный 3G свисток (huawei e171), за полгода не повис ни разу. питание с него не снималось.

Аппаратный сброс и сброс по питанию могут работать по-разному. Например, при аппаратном сбросе содержимое ОЗУ можно сохранить, со всеми вытекающими.

при аппаратном сбросе содержимое ОЗУ и не меняется, оно стирается всегда программно

По поводу сброса поправлю - это аппаратный сброс baseband + interface. DSP не сбрасывается.
А значит если подвисон по вине сбоя сети, то этот ресет не поможет, только снятие питания.

О, как еще оказывается! С каждым разом узнаешь все более интереснее
А если без шуток, тогда непонятна одна вещь - если сбрасывается основной контроллер, то почему б ему, при запуске не проинициализировать и дсп?? Вроде, как логично, например, когда моя прога запускается, то в любом случае инициализирует повторно и всю периферию и граф. сопроцессор и т.п. А тут как-то странно все...

Я еще больше вас огорчу - этим даже производители модулей управлять не могут - алгоритм сброса происходит на уровне чипсета.
И кстати первичная инициализация тоже - чипсет имеет кусок памяти где находится загрузчик и стартовый кусок программы.
Можно конечно получить доступ к extbl и часть регистров переинициализировать, но не все и если только не нарушает соглашений с производителем чипсетов.

Если грубо то старт модуля выглядит так