rudy_b

В стандартных случаях источником запроса на прерывание является периферия, DMA и т.п. Например при приеме байта UART при разрешенном прерывании, таймер, SPI и т.д. Они устанавливают запрос на прерывание, он отрабатывается процессором и запускается соответствующий обработчик прерывания. Для сброса источника прерывания, как правило, нужно считать соответствующий регистр или ручками сбросить бит в периферии. А, затем, снять бит в NVIC процессора. Последнее может делаться автоматически при возврате из прерывания по reti.

Сразу видно, что вы не умеете работать с прерываниями. В начале нужно сбросить не флаг прерывания, а источник запроса, и, только потом, сбрасывать флаг (pending бит)

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

У меня Мегафон. И действия операторов меняются быстро - проблемы 10-летней давности частично поправлены, но, похоже, взамен старых проблем появляются новые. Но, увы, у операторов нет никаких статей, хелпов, errat и т.п. Если бы они эти проблемы хотя бы обозначили - сколько времени было бы сэкономлено.

Ну вот, провел еще один эксперимент - открыл UDP сессию модема на 1 час 56 минут. Закрыл сессию сам по окончании эксперимента. Результат - ни адреса, ни порты за время сессии не изменялись, пакеты (с некоторой точностью - см. далее) ходили туда и обратно. Возможно мне повезло. Но выяснилась одна интересная подробность. В NAT, кроме внешнего адреса и порта есть, похоже, и еще один параметр - что-то типа "Разрешение трансляции внешнего пакета на локальный адрес модема". Этот параметр исходно выключен, но первый пришедший пакет его включает на время 16-20 минут (специально проверил, но грубо), а сам пакет пропадает (не транслируется). Если следующий пакет придет до истечения этого интервала - он пройдет и продлит интервал на это же время (это предположение, специально не проверялось). Если интервал между пакетами превышен, то пришедший пакет включит разрешение, но сам пропадет. Причем при открытии UDP сессии этот параметр отключен - вот почему пропадает первый ответный пакет сервера после открытия сессии. Т.е. для нормальной работы сервер должен посылать два пакета - первый, "просирающий" NAT, который может пропасть, и, только затем, второй с данными. И вот это уже почти точно проделки оператора. Да уж, накрутили ребята...

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

Не хочу спорить с опытным человеком, возможно вы правы. Мой опыт слишком невелик. Поживем - увидим, если поживем.

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

В момент подъема GPRS модему присваивается локальный адрес, который сохраняется до отключения GPRS. В момент коннекта (запуска сессии UDP модема), формируются и сохраняются данные NAT, т.е. выделяются внешний адрес и порт и запоминается связь между внешним адресом и портом и локальным адресом и портом. Все пакеты, поступающие на выделенные внешний адрес и порт транслируются на соответствующий локальный адрес и порт. Вот на какой именно локальный порт - не знаю, задание порта UDP не влияет или незаметно. Запомненные параметры NAT должны сохранятся до дисконнекта (завершения сессии UDP модема). Так что у оператора нет проблем на какой локальный адрес отправить пакет, пришедший на конкретный внешний адрес и порт. Эта информация запомнена в NAT и сохраняется вплоть до дисконнекта. Другие данные поступающего пакета ( в частности порт отправителя) в общем случае не должны проверятся. То, что пакеты фильтруются по порту отправителя - это дополнительная фича.

Ух, тяжек путь познания. Запустил Wireshark и посмотрел ответные пакеты от моего UDP сервера и от SocketTest в одной сессии модема. Вы правы, контрольная сумма IP заголовка может быть равна нулю - и так и есть в обоих случаях. Пакеты различаются только в одной детали - порте отправителя. Мой сервер отвечает с того же порта, на который пришел пакет. А вот SocketTest отвечает с другого порта, то ли случайно выбранного, то ли назначенного, но изменить его ручками нельзя. Формально это вполне допустимо, но, похоже, не в этом случае. Получается, что оператор или сам модем блокируют пакеты, если порт отправителя не совпадает с тем портом, который был указан при коннекте. Можно предположить, для чего была сделана такая фильтрация. В старых форумах народ ругался на то, что как только открываешь UDP, на него начинает валиться разный мусор, предложения от операторов и т.п. Эти пакеты попадают в трафик и платит за них пользователь. Возможно оператор добавил такую фильтрацию для блокировки этого. А может это делает сам модем. Так что моя ругань на SocketTest неправильна, точнее не совсем правильна.

Что-то не похоже. Почему тогда мой UDP сервер, запущенный в тех же условиях вместо SocketTest не делает этой ошибки? И ответные пакеты от него (исключая первый) всегда доходят? А пакеты SocketTest не доходят никогда? Причем и адрес и порт те же. Т.е. совершенно очевидна ошибка именно в пакете.

Разобрался с SocketTest 3.0.0. Внимательно посмотрел ответные пакеты Wireshark. Раньше смотрел только адреса и порты, а сейчас влез в заголовок ответного пакета. В нем обнаружилось несовпадение контрольной суммы заголовка: Header checksum: 0x0000 [incorrect, should be 0x3589 (maybe caused by "IP checksum offload"?)] Вероятно поэтому ответные пакеты и не доходят до модема. Не пользуйтесь этой программой. Заодно еще раз внимательно посмотрел пинг средствами модема. Картина та же - первый запрос - всегда таймаут, три последующих проходят нормально. Ну, вроде теперь все понятно, кроме того кто виноват -модем или оператор. Спасибо всем ответившим. Когда доберусь до SIM800C отпишусь, правда это будет не скоро.

А потому, что я делал только одну попытку связи с сервером NTP в одной UDP сессии. Ессно ответного пакета я не получал. А потом я перезагружал UDP сессию и делал следующую попытку. С тем же результатом. Вместо того, чтобы сделать несколько попыток в одной сессии. А при использовании NTP команд модема, я (фиг знает почему) делал несколько попыток в одной сессии - и все работало со второй попытки. А догадаться, что только первый ответный пакет пропадает - мозгов не хватило. И еще - в режимах чистого UDP я использовал чужой сервер SocketTest 3.0.0. Причем проверил его в режиме TCP - отлично работает в обе стороны. А вот в режиме UDP - оказалось глючит. Сервер слушал заданный порт, входящие пакеты получал и показывал адрес и порт отправителя - все честно. Отправка ответных пакетов делалась ручками (задание адреса и порта из входного пакета). Но вот модем этих ответных пакетов не получал и сейчас не получает, ни первого, ни следующих. Что-то в этом сервере не то, но продукт чужой, фиг его знает в чем дело. А когда написал свой UDP сервер - сразу начал получать ответные пакеты кроме первого и стало все понятно. Другого модема сейчас нет. Но скоро буду делать нормальный модем на SIM800C, вот тогда и посмотрю что там будет. Пока точно неизвестно кто глючит - модем или оператор.

Проверил. В одной UDP сессии и первый и все последующие пакеты приходят на сервер с одного и того же адреса и порта. Заодно проверил NTP через UDP. В одной UDP сессии делаю 4 запроса. Первый - не выполняется, на остальные три ответ нормальный. Т.е. пропадание первого ответа в UDP сессии подтверждается и тут. P.S. Заодно проверил и NTP через соответствующую функцию модема - та же история, первый запрос пропадает следующий проходит нормально. Вот такие пироги...

Возможно. Но, он иногда перебрасывает меня на другой "фиг его знает что" и при этом модем дает отдельное сообщение. Здесь его нет. Кроме того, после получения локального IP при подъеме GPRS он не имеет права это делать. Я смотрел - локальный адрес и порт модема я специально не выставляю, они равны нулю. Кстати надо бы попробовать снова задать UDP порт и посмотреть что будет. Я раньше его задавал, но, потом, в экспериментах, перестал. И после коннекта все пакеты к серверу идут с одного и того же адреса и порта (и первый и остальные), т.е. адрес и порт стабильны. Но это навскидку, специально не отслеживал, проверю. В этот момент, точнее при коннекте, должны задаваться и запоминаться параметры прокси (NAT). И они должны быть строго постоянны до дисконнекта. Нет, у меня нет другой симки для модема. Можно попробовать симку из телефона, но как-то не хочется, да и оператор тот же. У меня SIM800L. Да и работает все исправно с точностью до первого ответа.